Instructions for using Visual CAESAR/TRACER
1st December 2003
Tom Coulthard, Ian Dennis & Gez Foster
Introduction
Visual CAESAR is a fully functional MS windows based version of CAESAR. It is a
cellular landscape and river reach evolution model. It allows the user to input a DEM of a
river catchment or reach, enter water and sediment fluxes, or rainfall data and let it
evolve. It features slope processes (soil creep, mass movement), hydrological processes,
multidirectional routing of river flow and fluvial erosion and deposition over a range of
different grainsizes. Furthermore, it has a tracing component embedded, so that users can
input a different type of sediment and watch its movement, diffusion and concentration
downstream.
This model has many more potential uses than I have the time to explore, so it is freely
available for anyone to use – and modify for their needs. I hope it is of use or interest to
you. I must however state the following. CAESAR was developed as a research tool and
whilst providing real numbers – and is perfectly applicable to real situations, all results
should be treated with suspicion. River environments are highly non-linear environments
and the smallest difference in model parameters or initial conditions can result in a quite
different result. This is not to say that the model is wrong, but it could be, and the only
way to truly know is to validate the findings against field data. This has been successfully
carried out on several occasions, but many simulations that CAESAR is capable of are
generally un-testable.
How CAESAR works
CAESAR is a cellular model, and represents a landscape with a mesh of grid cells. For
each cell, further values are stored representing hydrological parameters, grainsize, water
discharge, vegetation levels etc.. Then for every model iteration, these are altered
according to a set of rules, loosely grouped into 1. hydraulic routing, 2. Fluvial erosion
and deposition and 3. Slope processes. A full description of the model is provided in
chapter 4 of my thesis (available online) and in various publications – though I wish to
recommend the article in Earth Surface Processes and Landforms 2002. However, I shall
provide a brief description here.
1. Hydraulic routing. The model takes a discharge either prescribed from a point, or
determined via the in built hydrological model then routes this to neighbouring
cells. This is carried out through a ‘scanning’ procedure that works across the
catchment in four directions (l-r, r-l, up to down, down to up) pushing flow to the
three cells in front – in a manner akin to Murray & Paola’s 1994 braided river
model. In CAESAR however, a depth is calculated for this discharge, which
allows flow to be routed over as well as around obstacles.
2. Fluvial erosion/deposition. After the hydraulic model has determined flow depths
and inundation locations for the reach/catchment, fluvial erosion is calculated.
This is carried out using the Einstein-Brown formulation, and applied to 9
different grainsizes embedded within a series of active layers. This allows bed
armouring effects and the development of a limited stratigraphy.
3. Slope processes. Soil creep is calculated and mass movement (landslides) occur
when a critical slope threshold is exceeded.
How CAESAR actually works…
Well, the above is the theory, but in reality there are several modifications to make things
work more rapidly. The main one is spatial optimisation. In a river catchment, most of the
action or erosion and deposition if you like occurs in and around the river channel. For
hours, weeks, sometimes even years, very little may be occurring on for example the
hillslopes. Therefore, it seems good sense to concentrate most of the models operations
around the channel – whilst periodically checking the hillslopes – for land slides etc..
This is carried out within CAESAR, but using an initial scan, that routes a set discharge
through the catchment picking out the drainage network. Then a 3 cell buffer is placed
around this area making a zone within which the model spends most of its time. This
zone has to be dynamic – so as a flood increases the inundated area will increase beyond
the limits of the zone. If this happens the model will automatically re-scan and delimit the
zone within which it operates. Similarly, on the falling limb it will re-scan so it only
concentrates on a smaller zone or area. This speeds things up considerably and also
reduces the size of the model when running – thanks to Vis C#’s dymanic memory
handling.. Other optimisations include only checking for landslides across the whole
catchment every 100 iterations, and soil creep us carried out every modelled day.
Getting going
There are a large number of parameters required to get CAESAR going, and most of
these are set at defaults and can be changed by the user. I’ll go through these to start with.
When you first load up CAESAR you get the following screen, with most of the
parameters filled in with defaults. (if you want to change the defaults, you need to get
into the code – though I many add a routing to save the settings if there is enough
interest).
Its not the best designed of windows programs – I guess I never got as far as reading the
chapter on menu design! But I have to admit I’m far more interested in how the model
works and what it produces than what it looks like! I have grouped the controls into 5
boxes which I shall describe below.
4
1
2
3
Box 1
1. X and Y co-ordinates are the number of Columns and Rows of data in the DEM.
2. Init # of scans refers to the number of scans required to establish the zone or
buffer around the channel where the model concentrates. Some experimentation
may be required with this figure. In a complex topography, e.g. with a
meandering river, flow may take 20, 30 or 50 iterations to progress from the
upstream end to the lower. If this actually takes 50, and the model only carries out
20 flow iterations before calculating the zone around the channel, the downstream
parts may not be included, so the model will not be able to route water down that
far. This parameter requires some experimentation, but once set for your DEM
should not have to be changed. For a simple catchment or reach – it may only
have to be 2 or 3, but if in doubt – or water appears to be bottlenecking at one
point in the catchment, try a larger value. The penalty however is more scans =
slower runs.
3. Max erode limit (m). This specifies the maximum amount of material that can be
eroded or deposited within a cell. This parameter prevents numerical instability
caused by too large amounts of material being moved from cell to cell. It also
controls the time step, which is restricted to allow this value (as a max) to be
moved from one cell to another. Never set it to greater than 0.05, as the active
layers are set at 0.2m, and too much material will be moved for the active layer
system to accurately compensate. Too great a figure will result in some numerical
instability – blocky or check pattern erosion and deposition patterns – so if in
doubt make it smaller, but again this causes the model to run more slowly
(usually). This factor also depends on the grid cell size. For example with 1m
cells, a erode limit of 0.02 means that a maximum slope change of 0.02*2 can
occur – slope change of 0.04. With 10m cells, as they are 10m apart the slope for
this case is less, 0.004. It also depends on the environment. In a steep upland
basin with an average slope of 0.1, a change of 0.02 in slope is not great, but the
same change in a system with an average slope of 0.00001 would be a huge
perturbation!
4. Cell size (m). The size of the grid cell. CAESAR automatically adjusts for the
difference in distance for diagonal neighbours.
5. Memory limit. This value is a purely computational one, but it can affect the size
of the program when it first runs. CAESAR stores values for elevation,discharge
etc in a series of large arrays (a matrix of numbers). For the grainsize part of the
model however, this means that there are 10 numbers stored for each grid cell, for
each active layer. So, 10 numbers, 10 active layers, and 100 000 grid cells = 10
000 000 data points. In a catchment model, many (most) of the cells are hill slope
cells, so require none of the grainsize calculations carried out by the fluvial
erosion and deposition terms. Therefore, these values are stored in an array
accessed by a linked list. Put simply, there is a separate array that carries an index
number that references the grainsize parameters for that cell. This number
(Memory limit) determines the size of the array that holds the grainsize values.
When it is set to 1 (as here) it means that there are as many places in the grain size
array as there are grid cells. When set to > 1 it means that the array is not large
enough to cope with all cells having grainsize values. Therefore, if you are
running a reach model, I would set this value to 1, or close to 1. If it is a
catchment model, a value of between 5 and 10 is usually appropriate. If the value
is wrong, and CAESAR tries to access a number too large for the array the
program will crash. This value may be largely irrelevant now the model is coded
in C#, as this dynamically allocates the memory. But, you may find in machines
with smaller memory capacities changing this value can speed things up – at least
initially.
6. Min Q for depth Calc. This is a threshold above which CAESAR will calculate a
flow depth. If this is not set, then it wastes time calculating flow depths of
fractions of a mm which will not cause any erosion or deposition. At present
CAESAR starts to calculate erosion on flow depths greater than 1mm – which I
feel is small enough. This variable is of course dependant upon grid cell size. For
smaller cells I would reduce this value, e.g 0.005 for 2-3m cells. Conversely for
larger cells (50m) It can be increased to 0.02 or 0.04. Again an element of trial
and error is involved, but it increases or decreases flow in marginal areas.
7. Creep rate. Rate of soil creep in ** per *.
8. Lateral erosion rate. A constant that is used to scale the lateral erosion rate. Here
it is set so lat erosion averages ** m per year.
9. Max # of iterations. The maximum number of iterations the model will perform
before it stops.
10. Max run duration (min). How long the run will last (in model or simulated time)
before it stops.
11. Slope failure threshold. The angle in degrees above which landslides happen. (this
may not be connected/working at present)
12. Water smoothing radius. The number of cells around a cell used for water surface
smoothing, if this option is enabled.
13. ‘m’ value from the hydrological model. For running in catchment mode, best to
range values from 0.005 to 0.02. The lower the value the flashier the hydrograph.
14. Grass grow, the length of time for grass to grow on the surface layer.
Box 2
These boxes contain the grain size characteristics use by the model. There are nine grain
sizes available. More can be added, but it does mean changing several items in the code.
If you need more than 9 – you could always try re-classifying them.
All units are in meters, and the first column contains the size of each grain size – in this
example running from 0.0005m to 0.128m in phi classes. They do not have to be in phi
classes, the model just reads the numbers, but this is the normal way grainsize is
measured.
The second column contains the initial proportion in each size fraction – as a fraction of
1. To move from percentages to the values used here simply divide by 100. All the values
in this column must add up to 1. In the example shown here we have a nice bimodal
distribution taken from the Waimak braided river in New Zealand (Thanks to Murray
Hicks for this).
Box 3
These boxes all deal with loading and saving of data. More details of the format of these
files are described in the examples of runs in a later section. I will go into each box in
more detail, but this may be a good time to talk about the saving data options. CAESAR
saves data for the elevations, water depth, grain size parameters and elevation change
(since the run started) every 100 iterations – in order that the model can be stopped and
restarted without loosing too much or any data. It saves this data with the file names
elev.dat, waterdepth.dat, grain.dat and elevdiff.dat respectively. CAESAR also has the
option to save the data at regular time intervals with a unique file name, for example to
save a DEM and the water depths every day of simulation – so more detailed analysis of
the results can be carried out. If the unique file name box is checked, every time the file is
saved, it will be followed by the time simulated. For example, if data is saved every 1000
minutes, then files would be saved called elev.dat.1000, elev.dat.2000 etc….. Be careful,
with large simulations these files can be large (up to 100mb) and can rapidly fill up a
hard drive.
All files are loaded and saved from the same location as the executable CAESAR file, the
caesar.exe file.
1. DEM data file. The data file used for the DEM of the model landscape. If you
wish to restart from where a model run stopped, simply enter elev.dat
2. grain data file. This contains all the grainsize information for the simulation. If
left as null the model will assume that the whole DEM contains the same
proportions as entered in Box 2.
3. Rainfall data file. If a file name is entered here then the model will operate in
catchment mode (see below), this file contains hourly rainfall data in mm per
hour. If left as null and discharge data file and hydrograph data file are not null
then the model will operate in reach mode.
4. tracer run? Checkbox. If checked then the model will operate in TRACER mode.
This allows the user to specify locations for the input of a different type (or colour
if you like) of sediment, which can then be tracked or traced downstream. This
may be used for studying the effects of a tributary input – or for tracking the
location and concentration of contaminated sediment.
5. tracer input file. This contains the location of input points for the tracer sediments,
and is in the same format as the discharge data file.
6. Tracer sediment vol file. This file contains the timing and volume of tracer
sediment to be added to the reach or catchment. This is in a similar format to the
hydrograph data file.
7. Save file every * mins. This specifies the (model) time interval between when
data is saved.
8. Unique file name? checkbox. If checked, this allocates a unique file name to each
data file as it is saved, so the user can build up a sequence of how the catchment
or reach has changed.
Box 4
These four text boxes provide real time information during the run, showing the number
of iterations elapsed, time elapsed in minutes, water discharge from the right hand edge in
m^3/sec and sediment discharge in m (multiply by the grid size^2 to turn into volumes).
Menu’s
The menu’s choose what information is displayed on screen, for the top frame and
bottom. The third menu determines what information is saved.
Useful note: If you change the display options – or at any time wish to refresh the
display, just minimise the window then maximise it again and it will refresh.
Other options
The recirculate sediment option allows the user to add sediment removed from the right
side edge of the reach directly into the input points specified by the discharge data file.
W/S smoothing applies a simple averaging smoothing over the water surfaces, this is
simply toggled on or off.
Grass/sediment check box. If checked then cells eroded or deposited on start with a
surface layer of grass. If not checked then they start with sediment. When first running
the model, it is best to run this unchecked for the first couple of small floods, so that cells
where the channel lies start with sediment values. Then check the box so any overbank
areas are defined initially with grass.
Grass now button. This grows grass ‘instantly’ when pressed on all cells without water
depth.
The load data button loads data from the files specified in box 3.
Start starts the simulation and when running quit and save stops the simulation when
running.
Types of run
There are three types of run that can be carried out with CAESAR, a catchment run, a
reach run or a TRACER run.. First I shall discuss catchment and reach runs. As the
name suggests a catchment run simulates an entire catchment, whereas a reach run just on
a single reach or section of a river. As far as the model is concerned, the important
difference between the two runs is that in a catchment run, a rainfall record is used by the
hydrological model to determine the flow inputs at various parts of the catchment, and
the sediment delivery is determined by the model itself, e.g. through lateral erosion,
incision of the headwaters and landslips. With a reach run, the user has to specify the
location of where water is inputted at the top of the reach, where sediment is inputted,
and how much water and sediment is added – as well as when. Therefore, when running
in reach mode, CAESAR requires two files to describe they input sources and the input
sediment and water hydrographs. In catchment mode you just enter the rain data file. On
the main CAESAR starting page, if you enter a rain data file name and set the discharge
data and hydrograph files to ‘null’ then it will operate in catchment mode. If the rainfall
file is ‘null’ and files are specified for the discharge and hydrograph then CAESAR will
operate in reach mode.
In TRACER mode CAESAR allows the user to input and track a different type of
sediment through the reach or catchment. This can be used when the model operates in
either catchment or reach mode.
Probably the easiest way to explain how it operates is to run through three examples from
start to finish. First in catchment mode, then in reach mode and finally a TRACER
example.
Catchment mode example
The main data sources required are the DEM and the rain fall data. CAESAR is set up to
take DEM’s in an ascii text format – usually created in arcinfo using the gridascii
command, but can be outputted from surfer or even made in excel. The format is 6 header
lines,
ncols 601
nrows 241
Xllcorner 388000
Yllcorner 663300
cellsize 5.0
NODATA_value -9999
These lines are actually ignored by CAESAR, so you could have any six lines here, as
long as each line ends in a new line char, but these are the standard lines left by arcinfo .
The main data is read from columns and rows. Each data point (col) is separated by a
space (or more than one space) and each row is terminated by a new line character.
CAESAR will not (at present) read rows and cols separated by any other characters (e.g
tabs or commas). If your data is comma or tab separated, you can always load the file into
a simple text editor (e.g. notepad or emacs) and do a find-replace on the tab or comma
with a space. If you are not sure about the format of the data, the best way is to look at
the sample files that can be downloaded. Units are in m.
Important points about the DEM.
1. CAESAR is set up so the main direction of flow is from left to right, so the
catchment exit point has to be on the right hand end of the DEM. This can be
changed in the source code, but is a real pain to do. Normally its easier just to
rotate your DEM so it is pointing in the correct direction (try the GRIDROTATE
command in arcinfo or grid).
2. -9999 values. CAESAR will not route water or sediment or anything into a cell
whose elevation carries the -9999 marker – which means no data. This is a handy
way of marking the boundaries of the catchment – surrounding the area of interest
with -9999’s. However – be careful, as if you bound the exit point of the
catchment with -9999 cells, no flow will leave the basin! So its generally best to
leave the right hand edge of the DEM (where flow goes out) free from nodata or 9999 cells. When creating DEM’s in arcinfo and grid, I have found that the easiest
way is to make a line coverage of the catchment boundaries, then use the gridclip
command to clip the DEM to the catchment limits. Then to prevent a series of 9999 cells by the exit, use the grid clip command again using the interactive
editor (* option) and trim off the right hand edge a little.
3. Sinks and DEM quality. The old adage of garbage in garbage out holds true a
little for CAESAR, so the better quality of DEM you use will generally cause you
less problems. CAESAR is fairly tolerant of poor DEM’s and will fill up sinks
and pits as it goes along. But if there are any major errors (huge pits – major
obstacles across the channel – or sections where the DEM shows the channel to
flow uphill for a section) these can cause problems. Whilst some of the above
DEM errors may sound unlikely, having dealt with many DEM’s there are a
surprisingly large number of errors in them.
The Rain Data. This is again in an ascii format but a single column, each line separated
by a new line. Each line represents an hour of data, and the format is in mm of rainfall
per hour. In this example, the data file is hourly_rain_data.dat
Set the two tracer input files to null. It will not operate in tracer mode if there are files
there, but it will look for the files – and will crash if they are not there.
For this example, we shall use a sample DEM from the River Swale in the Yorkshire
Dales called swale.dat, and a rainfall record caller hourly_rain_data.dat. This is 10 years
of hourly rainfall data from the Vale of York, with hours 2-4 altered to 10mm to generate
a flood.
So, enter swale.dat for the DEM file, and hourly_rain_data.dat for the rain data file.
Change the number of x co-ordinates to 887, and Y co-ordinates to 204, also change
memory limit to 5. Click the load data button. After a few seconds, a box will appear –
this contains a number, if 0 it is running in reach mode, if 1 then catchment mode. Then
click start and the model will begin to operate. There will be a delay of a few seconds
while the code initialises then carries out its initial scans to determine the channel area to
concentrate on. When the model starts to operate properly, the iterations and time step
boxes should start to increase, and the model will display the water depth and grain size
characteristics – as shown below.
Here, after only 16 iterations there is very little flow, but the lower half of the screen
shows that the model has identified the main channel network, but there is not yet enough
flow to run water in all areas of the channel.
This screen shot shows the model after it has been running for 226 iterations – and the
river is running under a minor flood (133 m3/sec). Here I have clicked the erosion check
box, so the lower display is indicating where there is erosion (yellows and reds) and
deposition (greens).
In this screen shot (below) the model has crashed. This is because the memory limit was
set too low (5) – and as the flood expands there is erosion and deposition occurring in
more than 20% of the cells. This caused the program to try to write to an array location
beyond the limits of the array – so it crashed. If this occurs, try lowering the memory
limit and re-starting.
CAESAR will save the elevation data as elev.dat and grainsize data as grain.dat every
100 iterations, so if you need to quit the program, when you re-start enter elev.dat and
grain.dat for the initial data and it will re-start with the same elevation and grainsize data
as where it left off.
When running, CAESAR tends to hog most of the CPU resources, so will considerably
slow down your PC. It will however run quite happily in the background, and an easy
way to set this, is when CAESAR is running, load up the task manager (ctrl + alt +del in
XP/2000). Identify the process and right click it. Then you can change the priority to low
– as shown below.
Reach mode example
In this example, I am going to make a simple braided river simulation, generating the
initial topography in excel (this file is downloadable as bare3.txt). There is also another
example described at the end of this section, but for now, load up excel with a clear
spreadsheet. Excel limits us to 256 columns, so we shall make a reach 256 cells wide by
100 deep (256 cols and 100 rows). If we give this a cell size of 10m and a average slope
of 0.01 this makes the reach approx 2.5 by 1km. We can make all the cells from A1 to
A100 equal 105. Then in cell A2 enter the formula = A1-0.1, fill down and fill right (as
far right as you can go) this will create a matrix of values running from 105 down to the
right with a slope of 0.01 (as they are 10m cells, 0.1 drop/10m = 0.01). Screen shot
below:
To stop water flowing off the sides or the back (left side) edge add a row of higher cells
for all of column A, and rows 1 and 100 (e.g set them to 110).
Now, for the braided river model to work nicely, an element of ‘random’ noise or
roughness has to be added to this surface. This can be done using the rand() in excel,
which returns a random number between 0 and 1. So in sheet 2, select cell B2 and enter
=Sheet1!B2+(0.5-RAND()) which will add or subtract a random value from the value in
sheet 1 and place the result in sheet 2. Fill down and right to copy this formula across the
whole of the sheet. Copy the raised edge values across directly. Now insert an extra 6
rows at the top of the spreadsheet, which are the header files that CAESAR reads (and
ignores!). These can be blank, but in the example here they contain information about the
size of the DEM and its co-ordinates etc. Your sheet should then look like below:
This is the elevations for your reach braided DEM. Now this has to be saved in a format
that CAESAR likes – with the values separated by spaces. Excel has many options for
saving data, but its option with space delimited values is not very good. So my advice is
to save as tab delimited. Then load the file in a text editor (e.g notepad or emacs) and use
the find and replace tool to replace the tab characters (they look like little boxes) with
space characters. Save your file and you have a DEM ready for CAESAR. In notepad it
should look like the below:
When in reach mode, CAESAR also needs water and sediment input data. For this we
need to create a new text file with 16 columns. The first contains the time – or sequence
of input. This can be in days or hours – or even min’s if you like. The time step can be
defined in the textbox detailed below (input data time step). Cols 2 and 3 are blank (to be
used in later versions). Col 4 contains the discharge data (m^3/sec). Col 5 blank, then
columns 6-14 contain the total volume of sediment deposited during the time step for
each grainsize defined on the start up screen. An example of such a file is shown below,
each column must be separated by a space and each line ended with a new line.
Note, on version 2.4 onwards, the discharge data is placed in column 2 not 4, so that it is
in the same format as the output data (generated in the file catchment.dat) 8/7/04
This allows you to enter a hydrograph at any time resolution and to input a sediment
hydrograph as well – with varying grainsizes.
Then the input points have to be defined. CAESAR allows you (at present) to input water
and sediment at up to four locations. You can also use different files, allowing different
water and sediment inputs at different locations. This is fairly self – explanatory, just tick
the check box, enter the x and y co-ordinates (in model co-ordinates from top left corner)
and the file name.
Finally, after going through the input data we can load up CAESAR by double clicking
on the CAESAR icon. This brings up the main screen as shown below.
We need to change some parameters here, so enter 256 for x-coordinates, 100 for ycoordinates, change init # of scans to 5 and cell size to 10. Over in the file area, change
the DEM file to bare3.txt.
Also ensure that the text boxes for the rain data file, and tracer input files are set to null,
else CAESAR tries to open these files when it loads up.
Press the load data button and wait a couple of seconds. A message box should then
appear and click OK. You have now loaded up the data, and CAESAR is ready to start.
Press the start button and the model takes a few seconds (or longer) to initialise and
determine the initial scan area. A checkbox will then appear to indicate that the model is
ready to go. Click OK and you should notice the numbers starting to increment as the
model iterates. Every 10 iterations CAESAR updates its graphics. You may after a few
hundred iterations see something like below:
Here you can see the water depths in blue and erosion/deposition patterns below.
The Teifi example. For this example which is part of the river Teifi near Lampeter Mid
Wales, double click on the CAESAR icon to bring up the main window. For the input file
enter ‘whole9-edited-bed.dat’ and the input file ‘out1.dat’ to input values at location 30,
300 (x any Y co-ordinates). The X co-ordinates should be 593, and Y 258. Set init # of
scans to 60 and cell size to 5. Then click load data – this will take a while – then OK the
message box and click start. CAESAR then carries out the initialising which will take
about a minute (on a Celeron 2.0 pc). Then OK and it will start. Nothing much will
happen until the time elapsed gets to about 1400 – as there is no input from out1.dat until
then. CAESAR will then pause for a while again, as it calculates the scanning area, then
carry on running.
TRACER example
For this example, I shall take the braided river simulation described above and add a
different type of sediment. First you need to go through the text of the example above, or
use the sample files from that example. Then double click the CAESAR icon to start the
program, and enter the files described in the previous example, for the DEM, discharge
and hydrograph data. Check the tracer run box. Two more text files are required for the
tracer run. The first two columns of the ‘tracer input file’ contains the x-y co-ordinates of
points where the tracer sediment is to be inputted, column three the proportion of the total
to be added there and in the fourth the grainsize fraction that the tracer is in. The tracer
sediment volume file has three columns, the first containing the time (in hours) the
second is ignored, so enter 0, and the third the volume of contaminated material to be
added in the hour denoted in column 1. Each column is separated by a space, so will look
something like below:
Having created out DEM data files, we need to assign points for water and sediment to be
inputted. This example uses the file inputpoints.dat (see below)
Having entered the data, click load data, then OK, then start then OK the check box.
During the model run if you select the view erosion/deposition option, the tracer
concentration will be graphically shaded under the erosion/deposition. Shading from
yellow (low conc) to dark red (high).
As tracer has two distinct sediment types –this means it has to create two arrays to store
the sediment grainsizes and proportions – therefore it uses nearly twice as much memory.
Resolution and computation issues
Speed and resolution are unfortunately inversely proportional. This is due mainly to the
number of grid cells. A 1km by 1km model running with 10m grid cells, will have 100 *
100 = 10 000 grid cells. Simply halving the pixel size to 5m will result in 200 * 200 = 40
000 grid cells. So, 4 times slower for a 2 times increase in resolution. So choosing the
resolution depends largely on the length of period you wish to simulate, the spatial
resolution at which it is to be studied and how long you want the simulation to take.
The speed of model operation also depends heavily on the amount of ‘activity’ taking
place within the simulated reach or catchment, as well as the number of ‘active’ cells. By
active, we generally mean cells that have water flowing over them and are undergoing
fluvial erosion and deposition. The two examples described earlier for the catchment and
reach models provide a good example of this. With the catchment model, most of the
activity is concentrated on the cells representing the channel. With the reach model – as it
is simulating a braided reach there are nearly as many ‘active’ cells as the model is set up
to look at the reach in more detail. The number of cells where erosion and deposition is
taking place will also depend upon the hydrograph – or the level of flood. The catchment
example will significantly increased the number of ‘active’ cells during a flood – which
will slow the model down during these periods. CAESAR contains several tricks within
the code to speed things up when there is little erosional activity. Unfortunately, when
you are simulating a large flood in detail (large number of active pixels) there is a large
amount of erosion and deposition going on – which leads to many calculations which
slows the model considerably.
How can CAESAR be sped up? The easiest way is to increase the size of the grid cells –
unfortunately at the expense of spatial resolution. A good strategy often adopted is to
start with large grid cells to get the model working and to get a feel for how the model
works. Then when all is set up a more detailed smaller grid cell DEM can be used. These
simulations can take a long time and we have had some running for over 2 months. This
is and extreme example, but it is not uncommon to have a simulation running for a few
days. CAESAR is set up for this purpose – data is regularly saved and the model can
easily be restarted where halted. Options include using other machines over night when
they are not being used for normal purposes, or buying dedicated ‘boxes’ with low spec
or no monitor etc.. simply to run the code.
The final option is to use the C version of the code. This operates approximately 60-70%
faster than the Visual version presented here – but is much less easy to use.