Quoted from: https://sourceforge.net/p/caesar-lisflood/wiki/Instructions/ 

Useability:

CAESAR is coded in Visual C#, and runs as a windows program on Windows NT, 2000, XP, vista, 7 and 8 - 32 and 64 bit. No programming experience is required in order to use it, and example files can be loaded and the program successfully run in minutes.

Applying it to data sets other than the sample ones described below requires the capability to manipulate and edit DEM files, and the user would require some basic knowledge about data manipulation using (for example) Excel and ArcGIS or equivalents.

The source code for CAESAR is openly available for download under the terms of a GNU licence which prevents it from being sold for profit. The code is presently more than 10000 lines, but there is much duplication, and users with medium programming skills should be quite capable of editing and altering it for their own purpose.

Data requirements

CAESAR can be run in two modes; a catchment mode, with no external fluxes or inputs aside from rainfall; and a reach mode with one or more points where water and sediment are inputted to the system. It can be run in both catchment and reach mode together.

Catchment mode data requirements

For the catchment mode, CAESAR requires rainfall data which ideally shold be hourly, but different time periods (mins to days) has been used. Ideally, the study catchment should have a rainfall record as well as a gauged point or outlet which allows the hydrological component of the model to be evaluated/calibrated. Thereby modelled discharges match the field observed discharges for a given flood. However, if this is not available nearby rain data can be used and there are ranges of example settings from which the hydrological model can be parameterised.

CAESAR also requires a raster DEM (not TIN) for the catchment, and editing and correcting the DEM is an important part of preparing for a CAESAR simulation. The model can cope with a wide range of DEM resolutions, and has been applied with DEMs of grid cell sizes ranging from 1m to 100m. Some DEM’s can be applied in their raw form, but often the data contains errors which can cause the model significant problems, for example an erroneous series of cell elevations can cause an obstruction across a valley floor. It is therefore recommended that DEMS are first processed to remove any sinks or pits, and to ensure that the drainage network follows a straightforward descent to the exit point. This can be carried out simply using the freely available ARC-HYDRO extensions toolkit for ARC-GIS 8.x and 9.

CAESAR is set up so that the water and sediment exit point from the DEM (where sediment and water outputs are measured) must be on one of the edges of the map (This is an important change for versions 1.2 onwards). The model will not route water or allow water to exit from 'no data' cells (those with a value of -9999) so these must be removed from the edge of the DEM where you want flow to exit.

CAESAR accepts DEM data in an ascii raster format which consists of a 6 line header, followed by the grid cell elevations in rows and columns. This is in the same format as data exported from ARC-VIEW, ARC-GIS etc.. using the RasterAscii command or equivalent.

Reach mode data requirements

For the reach model, CAESAR also requires a DEM file in the same format. Again, it is worth taking time to ensure that there are no errors in the DEM. Sometimes, there are individual cells, or groups of cells that may require editing or removing, and for this purpose a useful program called RasterEdit (created by Marco Van de Wiel) is available from the CAESAR website.

As for catchment mode, water must exit directly from ANY edge of the DEM – it will not be routed into -9999 or nodata cells. In reach mode an additional file is required that contains the water and sediment inputs for the reach. These are stored in an ascii file with the time step in the first column, water discharge in the second, and the inputs for the separate grainsize fractions (in m3 for the time step) in the 6th to 14th column. This file is in the same format as one of the catchment output files (see later). CAESAR can also be run in both catchment and reach mode, so for catchments that also contain a point source (for example a major tributary) the model can take both rainfall and point inputs.

Notes on other parameters

CAESAR also requires information on the grainsize distributions for the catchment. It presently takes up to 9 different grainsize fractions and can cope with both bedload and suspended load fractions. The model operates using a variable time step controlled by the amount of erosion and deposition occurring within the catchment. A parameter (erodelimit) is set which represents the maximum amount of erosion or deposition that can happen within any one time step. If this amount is exceeded, the model halves the time step and repeats erosion calculations until it is below this limit. This ensures numerical stability (as too great a time step can lead to excessive amounts of erosion and deposition) and allows the model to have long time steps (up to 1 hour) during periods of quiescence (e.g. low flows) yet have small time steps (<0.1s) during floods or periods of erosive activity.

Grid cell size and resolution

CAESAR can accept any grid cell size in the DEM (though all cells must be the same size) and has been used with DEM’s from 1m to 100m cells. However, choice of grid cell size is important, as there are significant compromises to be made between the area that can be modelled, the resolution, and the time it takes the model to run. CAESAR can run with up to 2 million grid cells, but is probably best suited to applications with 250 000 to 500 000 cells. Quite simply, the smaller the number of grid cells, the faster the model will operate. This is particularly important as increasing the resolution linearly, results in an exponential increase in the number of grid cells. Furthermore, the erodelimit parameter - or the amount that can be eroded or deposited on a cell per iteration - can be contingent on grid cell size. Changes in cell elevation represent changes in local slopes, and a 0.1m change with 1m cells equals a 10% change in slope, yet a 0.1m change in 10m cells equals a 1% change. Thus increasing the grid cell size of the DEM that is being modelled results in a greater than exponential increase in computational time, as changes between grid cells result in less severe alterations in slope. These resolution issues are also contingent upon the time that is required to be modelled. If a single flood is to be simulated, then this can be carried out at a higher spatial resolution that may (for example) take a day to run. If 100 years are to be simulated, this period may contain 300+ floods, and so take 300 days to complete. Extreme examples of model run times include 2 months to simulate 10000 years on a 800 by 200 cell DEM (50m resolution) of the River Swale, U.K. There are many ways in which the model speed can be increased, including parallelisation by dividing a catchment into sub catchments and running these sub catchments simultaneously on separate machines. In addition, the cell size affects the time step of the flow model. This time step is controlled by the courant number, flow depth and the grid cell size. Smaller grid cells will lead to smaller time steps, as flow cannot me moved across more than one cell (in distance) at once. Furthermore, smaller grid cell sizes leads to (as above) greater relative changes in elevation between cells and a smaller courant number may be required in order to maintain numerical stability of the flow model. If you start getting a checkered pattern for your flow depths, either the courant number is too high, erodelimit is too high or both.