OR/14/011 CLiDE Pre-processing: Difference between revisions

From MediaWiki
Jump to navigation Jump to search
Line 150: Line 150:


===DEM===
===DEM===
The CLIDE will accept a digital elevation model (DEM), to represent the height of the terrain surface above a defined datum, at any uniform discretised size. The DEM used will act as the reference spacing for all other input files unless otherwise specified. Unlike previous versions of CAESAR, on which the CLiDE is based, no pre-processing rotation of the DEM to a particular orientation is required. This rotation was necessary to allow surface water to drain at the right hand edge of the model, but has been superseded by a specified output location in the ''hydrological boundary'' file (([[OR/14/011 3 CLiDE Pre-processing#Hydrological boundary|Hydrological boundary]])). It is suggested that a north orientated DEM is used, as the coordinate system and many of the post-processing tools, such as GIS, rely on this orientation.
The CLIDE will accept a digital elevation model (DEM), to represent the height of the terrain surface above a defined datum, at any uniform discretised size. The DEM used will act as the reference spacing for all other input files unless otherwise specified. Unlike previous versions of CAESAR, on which the CLiDE is based, no pre-processing rotation of the DEM to a particular orientation is required. This rotation was necessary to allow surface water to drain at the right hand edge of the model, but has been superseded by a specified output location in the ''hydrological boundary'' file (([[OR/14/011 CLiDE Pre-processing#Hydrological boundary|Hydrological boundary]])). It is suggested that a north orientated DEM is used, as the coordinate system and many of the post-processing tools, such as GIS, rely on this orientation.
   
   
The first six lines of the ''DEM data'' file contain the domain number of columns and rows, its geospatial referencing details, grid sizing and attributes representing no-data. The remaining lines show the daily elevation (m) for each location on the grid, separated by a white space. There also needs to be a white space at the bottom of the file.
The first six lines of the ''DEM data'' file contain the domain number of columns and rows, its geospatial referencing details, grid sizing and attributes representing no-data. The remaining lines show the daily elevation (m) for each location on the grid, separated by a white space. There also needs to be a white space at the bottom of the file.

Revision as of 11:19, 22 April 2022

Barkwith, A* and Coulthard, T J**. 2011. CLiDE version 1.0 user guide. British Geological Survey Open Report, OR/14/011.

* British Geological Survey, Environmental Science Centre, Keyworth, Nottingham, NG12 5GG, UK
** Department of Geography, Environment and Earth Science, University of Hull, Cottingham Road, Hull, HU6 7RX, UK

Introduction

This section introduces the setup, simulation process and required input data for the CLiDE platform. A brief description on how to access the platform source code is described in Software, followed by an overview of the different input file structures in the section Input file properties. The graphical user interface (GUI) (Graphical user interface) allows users to select input data, load initialisation files and view run-time imulation information. Finally model spatial and temporal discretisation is discussed in Discretisation and a description of each input parameter presented in Meteorology to Climate factors.

Software

Running The CLiDE platform software is straightforward on the windows platform. The model- component portion of the package is self contained in an exe file. The CLIDE source code for the c# visual studio compiler (10 or higher) is contained with the executable in a zip file, accessible using freely available software. The CLiDE platform may be built to run on a single-processor machine or a shared-memory machine through utilisation of the OpenMP API.

The CLiDE platform code has a fairly simple build mechanism. It tries to determine the windows architecture that you are running (32 or 64 bit), and then presents you with options to allow you to select the preferred build method. A description of the build process and components is contained below:

  • Obtain the CLIDE zipped file from https://www.bgs.ac.uk
  • Always get the latest version if you are not trying to continue a long project, or duplicate previous work
  • Unzip the file and extract contents
  • Open the CLIDE.csproj file in visual studio
  • In the solution explorer panel, right click CLIDE.cs to view the main source code

The code can be compiled in the standard way, either as a debug or release executable. Control of the build, parallel, icon and reference properties can be assessed from the solution explorer panel.

Input file properties

The philosophy behind the structure of the CLiDE platform input, is to separate different types of data between files. That is, each file contains one specific type of information only. Whilst this results in the model requiring many input files compared to other models, they all have a very simple format and are easily modified using a text editor. For example, one file contains all information relating to hydraulic conductivity, another to soil depth, and another to surface water depth. Examples of all these files are contained in the supplied zip file that contained the executable. These are in the correct format but the data contained within requires tailoring to the user specification.

The list of input files required by CLiDE is presented in Table 1. Though there are thirteen files listed, not all of these are required for a simulation. For example, if grain sizes are set in the user interface, the grain size input file is not needed. The files can be renamed as the user desires as long as the relevant information is updated in the user interface.

Table 1    Input files for the CLiDE platform.
Input file Relevant section
Bedrock 3.5.2
DEM 3.5.1
Distributed Hydraulic Conductivity                   3.8.2
Distributed Specific Yield 3.8.3
Grain Size 3.5.3
HOST 3.7.4
Initial Debris Thickness 3.12.3
Initial Soil Moisture Deficit 3.7.1
Landuse 3.7.3
PE Grid 3.6.2
PE List 3.6.2
NSSS 3.7.2
Precipitation 3.6.1
Initial Surface Water 3.7.5
Surface Water Influx 3.7.6
Initial Groundwater Heads 3.8.1
Hydrological Boundary 3.6.3
PE Numbers 3.6.2

Graphical user interface

The Graphical User Interface (GUI) for the CLiDE platform is launched when the executable is opened (Figure 3). The GUI allows users to populate the model, set parameters, decide on model output, launch simulations and visualise model progression during run-time. The GUI is arranged into bars (along the top of the GUI) and upper and lower series of tabs. The bars allow configuration files to be saved and uploaded, runtime graphics to be selected, and model output files at particular intervals to be specified. The tabs provide model input and runtime properties for different components of the model. Table 2 gives a brief description of the upper tabs.

Figure 3    The CLiDE GUI under the setup tab.

When the model has been setup as required, the metadata can be saved as an XML file using the save option in the Config File bar. This allows the platform setup to be reproduced at a later time and will save time if multiple similar setups are required.

Populating the CLiDE platform with initial data and forcing factors is executed by clicking the Load Data button at the bottom left of the GUI. Upon loading data, the CLiDE platform will check the compatibility of the input files, assess the potential stability of the model and suggest ways to correct the model input.

Following the upload of information to the model, a new GUI page is visible. It is worth noting that the previous page can be accessed but not modified by selecting the view tabs? box. Without starting the simulation, the initialisation data can be viewed in graphical form by toggling components on and off in the upper graphics tabs. If the hydrological components need to be calibrated, the sediment flux processes may be switched off using the relevant tick box before the simulation is started.

Table 2    The upper tabs available in the GUI and description of their parameters.
Tab Overview
Setup Allows the DEM, Grain Size and Bedrock Elevation file names to be specified. The temporal settings for the simulation and the output of files are also controlled here.
Hydrology Specify values or distributed files for the surface water partitioning and groundwater components.
Sediment Enter the distribution of grain sizes, the scheme to transport sediment and the transport properties.
Description A description of the simulation can be saved as metadata for future reference.
Grid Grid settings from the input files can be overridden (not recommended).
Vegetation The shearing, maturity and erosion characteristics may be modified.
Slope Processes A general creep rate may be required for longer term simulations. There are three slope failure schemes — a simple sand pile algorithm, the SCIDDICA debris flow model or the SIBERIA sub model.
Flow Model Controls the LISFLOOD surface flow routing characteristics.
Climate Factors Allows uniform or a linear climate factor to be applied to the input precipitation and potential evapotranspiration datasets.

To initialise the simulation select the Start! button at the bottom left of the GUI. During simulation, the simulated time, number of iterations, and catchment discharged sediment and water can be viewed at the bottom of the GUI. The graphical options in the upper tabs may be switched on and off to view the runtime output from the model. These will be updated at the file save interval, specified before loading the data into the model (under the setup tab), or when the Update Graphics button is clicked. The image in the GUI will be saved in the .jpg format, ready for display in Google Earth, if the Graphic to Google Earth button is clicked or when specified under the pre-load setup tab.

The simulation may be terminated at any time using the Quit and save button, producing output files for the current time-step and shutting down the GUI.

Figure 4    The GUI after the simulation input data has been loaded into the model.

Discretisation

The CLiDE platform will accept any grid cell size (though all cells must be the same size and an integer) and has been used with DEM’s from 1 m to 200 m 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 simulation time. The CLiDE platform 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, which controls the nodal erosion and deposition volume per iteration, can be contingent on grid cell size.

Changes in cell elevation represent changes in local slopes, and a 0.1 m change with 1 m cells equals a 10% change in slope, yet a 0.1 m change in 10 m cells equals a 1% change. Thus, increasing the grid cell size of the DEM results in a greater than exponential increase in computational time, as changes between grid cells result in a less severe alterations in slope.

These resolution issues are also contingent upon the time that is required to be modelled. If a single event 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 hundreds of events, and so take weeks or months to complete.

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 at once. Furthermore, smaller grid cell sizes lead 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.

Due to the daily input of distributed rainfall and potential evapotranspiration into the CLiDE platform, start and end dates must be specified in the Setup tab. The day data is input as day number within the year, for example 23rd January would be 23 and 30th October would be 303 for a standard year or 304 for a leap year. The start date also needs to be entered into the Google Earth animation section if this output is required. Due to the inclusion of set dates in the CLiDE platform, the maximum number of iterations is irrelevant, however, it must be set at a high enough number not to interfere with the simulation being undertaken.

DEM

The CLIDE will accept a digital elevation model (DEM), to represent the height of the terrain surface above a defined datum, at any uniform discretised size. The DEM used will act as the reference spacing for all other input files unless otherwise specified. Unlike previous versions of CAESAR, on which the CLiDE is based, no pre-processing rotation of the DEM to a particular orientation is required. This rotation was necessary to allow surface water to drain at the right hand edge of the model, but has been superseded by a specified output location in the hydrological boundary file ((Hydrological boundary)). It is suggested that a north orientated DEM is used, as the coordinate system and many of the post-processing tools, such as GIS, rely on this orientation.

The first six lines of the DEM data file contain the domain number of columns and rows, its geospatial referencing details, grid sizing and attributes representing no-data. The remaining lines show the daily elevation (m) for each location on the grid, separated by a white space. There also needs to be a white space at the bottom of the file.

Bedrock elevation

Bedrock elevation is referenced to the same datum (usually mAOD or mAMSL) as the DEM. The surface represented by the bedrock elevation depicts the interface between soil/debris with the underlying solid bedrock. The difference between the bedrock elevation and the DEM at a particular point represents the thickness of soil/debris cover. This information is primarily used by the fluvial sediment transport and shallow landslide components to define maximum scouring depth. At the time of writing it is also intended that this interface will be used for the near-surface transport of water in the unsaturated zone as a potential trigger for debris flows. The bedrock elevation can never be greater than the DEM and, if this rule is violated, the model will reduce the thickness of the bedrock elevation to that of the DEM. The bedrock data file shares the same characteristics as the DEM data file.

Grain data

Grain size data may be entered using either the grain data file method, contained in the Setup tab, or manually through the Sediment tab (Section 3.10.3). The latter method initialises the model with a laterally and vertically homogeneous sediment. By inputting a grain data file, the model may be initialised with a distributed (both vertical and horizontal) sediment grain size dataset. The grain data file contains the percentages of each grain size, specified in the Sediment tab, for the active layer and each sub-layer, for every node within the model domain. Each line of the grain data file contains the x and y cell location, the index number within the model, the active layer grain size proportions and ten sub-layer grain size proportions. To use the grain data file, the average grainsize proportion information must also entered into the appropriate place under the Sediment tab.

There are two options for creating the grain data file. Firstly, a simulation could be started with the tab-only data and allowed to run to a steady state (equilibrium) condition; here the model will produce a grain size output file, which may be used for a subsequent transient model runs. This method can be time consuming, and any sub-layers that remain non-active will still have the homogeneous initial grain size proportions. The alternative is to use a downloadable windows based program to generate an initial grain size distribution (Coulthard, 2013). To generate the file using this method, the DEM file (Section 3.5.1) and an ascii map (same format as DEM) of up to five sediment types is required.

Meteorology

Precipitation and potential evapotranspiration force the model through time, affecting the amount of water in the various stores across the model. Both attributes are distributed, however they have different file format styles due to the way that the data is collated in the UK. The area represented by each meteorological file must be the same as the CLiDE platform boundary.

Rainfall

Rainfall is presented as a gridded ascii file for each day of the simulation. The spatial discretisation of the rainfall files does not have to be the same as the modelled grid, however it must be a factor of the grid spacing. These files must be daily totalled and contained in a folder labelled Rainfall in the same folder as the CLiDE executable. The name of each daily rainfall file has the format rainYYYYD.asc, for example rain19623.asc and rain1968321.asc would represent the daily total rainfall for 3rd January 1962 and 17th November 1968 respectively. A rainfall data file must be present for each day within the simulation, including the extra day in leap years.

The first six lines of each rainfall file contain the number of columns and rows in the rainfall file, their geospatial referencing details, grid sizing and attributes representing no-data (Figure 5). The remaining lines show the daily rainfall (mm d-1) for each location on the grid, separated by a white space. There also needs to be a white space at the bottom of the file.

Figure 5    First six lines of a rainfall file, specifying the spatial attributes of the data. The next two lines show the beginning of the dataset (mm d-1).

Potential evapotranspiration

The three files needed to represent monthly averaged potential evapotranspiration are specified under the Hydrology tab. The file system is designed for use with the Meteorological Office Rainfall and Evapotranspiration Calculation System) MORECS (Hough and Jones, 1997), although the CLiDE system can be populated with other data.

The PE grid file consists of a single distributed ascii file, where individual nodes contain an identifier, which for the MORECS dataset is related to UK evaporation stations. The gridded file has to use the same discretisation as the CLiDE platform. The first six lines of the gridded file contains; the number of data columns and rows in the file, their geospatial referencing details, grid sizing and a no-data value. The grid file links to the PE List file, which contains a list of time stamped, monthly averaged potential evapotranspiration (kg m-2s-1) values for each of the identifiers (Figure 6). As the MORECS dataset is valid for the whole of the UK, the time stamped dataset contains unnecessary data. To reduce the computational cost of reading all the data from the time-stamped file, the third potential evapotranspiration file (PE Numbers file) required by the CLiDE contains a list of the PE identifiers required from the PE List file (Figure 7) by the PE grid file.

Figure 6    An example of a PE List file. The first line is a header, and the remaining lines comma-separated, time-stamped, potential evapotranspiration (kg m-2s-1) data for each identifier over the length of the simulation.
Figure 7    The PE Numbers file contains a list of the identifiers used in the PE gridded file. The first line is a header and the second a white-space separated list of identifiers.

Hydrological boundary

The Hydrological Boundary file allows the surface water and groundwater boundary conditions to be specified. The first six lines of the file contain the number of columns and rows in the Hydrological Boundary file, its geospatial referencing details, grid sizing and attributes representing no-data. The remaining lines show a two digit number representing the boundary type for each location on the grid. The first digit of the boundary number specifies the groundwater boundary type and the second the surface water boundary type. Table 3 shows the boundary condition numbers and type. For example 12 would be a no-flow groundwater boundary with a river outflow at the surface.

Table 3    Hydrological boundary conditions for the CLiDE platform. *Numbers have been reserved for this boundary type but it has not yet been implemented in the model code.
Boundary number Groundwater Surface water
1 No-flow or internal node No-flow or internal node
2 Static specified head node River outflow node
3* Static in/outflow node -
4* Time variable specified head node -
5* Time variable in/outflow node -
88 Internal fixed debris depth in SCIDDICA landslide module
-9999 No data (outside catchment domain)

Water balance

By checking the Daily Water Balance box, a water balance file is produced that is updated on a daily basis. This file contains the all of the external fluxes of water (m3 d-1), the amount of water contained within each store (m3 d-1) and the amount that has been passed between stores during that timestep (m3 d-1). The water balance information may be used during the calibration process or to assess the model output.

Surface partitioning

The links to the data that describe the soil hydrological characteristics are contained within the Hydrology tab. They are all distributed ascii files, with the same discretisation as the CLiDE Hydrological boundary file. The first six lines of each data file contain the number of columns and rows in the rainfall file, their geospatial referencing details, grid sizing and attributes representing no- data (the same as Figure 5). No-data nodes within these files should define the same the model boundary as for groundwater (see 3.6.3), without the associated conditions.

Figure 8    Hydrological tab parameters in the GUI.

Soil Moisture Deficit (SMD)

The Initial SMD file allows the hydrological model to be initialised from a steady state condition. The initial SMD (mm) can be determined by starting with values of zero, running the hydrological model to steady state, and using the final SMD output as an input for the transient run. This process may form part of the calibration process (see Section 5).

Near Surface Soil Storage (NSSS)

The Initial NSSS file allows the hydrological model to be initialised from a steady state condition. The initial NSSS (mm) can be determined by starting with values of zero, running the hydrological model to steady state, and using the final NSSS output as an input for the transient run. This process may form part of the calibration process (see Section 5).

Landuse

Landuse divides the model domain based on vegetation properties at each node in the data array based on 10 class types (Morton et al. (2011). The Landuse file provides the surface partitioning model SLiM with the rooting depth (m), depletion factor (-) and crop coefficient (-) for each landuse class. Rooting depth is defined as the maximum depth of root penetration for a particular vegetation type. Depletion factor and the crop coefficient take into account the influencing conditions under which evapotranspiration is determined for vegetation classes.

Table 4    Landuse habitat numbers and associated descriptions (Morton et al., 2011).
Landuse number Habitat description
1 Broadleaf woodland
Broadleaved, Mixed and Yew Woodland
2 Coniferous woodland
3 Arable
Arable and Horticulture
4 Improved grassland
5 Semi-natural grassland
Rough Grassland Rough grassland
Neutral Grassland
Calcareous
Grassland
Calcareous
Grassland
Acid Grassland
Fen, Marsh and Swamp
6 Mountain, heath, bog
Dwarf Shrub Heath
Heather
Heather grassland
Bog
Montane Habitats
Inland Rock
7 Saltwater
8 Freshwater
9 Coastal
Supra-littoral Rock
Supra-littoral
Sediment
Supra-littoral
Sediment
Littoral Rock
Littoral Sediment
10 Built-up areas and gardens

Hydrology Of Soil Type (HOST)

The HOST file allows further vegetation and soil hydrological properties to be defined, and is composed of 31 different classes (Boorman et al., 1995) as defined in the input file. Each class has a known field capacity (m), wilting point (m) and baseflow index (-). Field capacity describes the maximum amount of water that the soil can hold and wilting point the minimum soil moisture a particular vegetation class requires not to wilt. The soil baseflow index (between 0 and 1) determines the partitioning ratio between groundwater recharge and surface runoff under conditions of excess water for each HOST soil class. Under high BFI values greater proportion of excess surface water is passed on as recharge. As BFI approaches zero, a greater proportion of excess surface water is partitioned as runoff. The HOST datasets work in conjunction with the Landuse dataset described in Section 3.7.3.

Table 5    Definition of the 29 HOST soil class numbers (modified from Boorman et al., 1995). The remaining two classes (30 and 31) are used to describe surface water features. The integrated air capacity (IAC - is the average percentage air volume over a depth of one metre) is used to differentiate some classes.

Initial surface water

The Initial surface water depth file allows the hydrological model to be initialised from a previous condition and can reduce model spin-up time. Surface water depth (m) can be initialised either; by entering the file name ‘null’, whereby all values will be zero and a long spin-up time will be required or by taking a previously saved waterdepth.##.out file, renaming and initialising from these water depths. This process may form part of the calibration process (see Section 5).

External surface water IOs

Surface outflow from the boundary of the model at specified location (Section 3.6.3) can be recorded by checking the nodal discharge box. The output file, Surface_Water_Discharge.out, logs the daily water discharge (m3 d-1) from each node and gives the coordinates for each point. The inclusion of a surface water influx file allows a time series of surface water to be added to any nodes within the model boundary. The surface water influx file takes the same format as the surface discharge file, allowing the output from one subcatchment to act as the input for the next subcatchment.

Figure 9    Example surface water discharge file. The first line defines the coordinates of the outflow nodes and the following line the daily water outflow (m3) from that node.

Groundwater

Groundwater is linked to the surface water routing model Lisflood through baseflow return to rivers, and to the SLiM water partitioning code by the daily recharge that it receives. Spatially the groundwater module is discretised at the same scale as the hydrological boundary file. The module has a timestep that is uniform over a day but that can vary on differing days based on the domain maximum cell Reynolds number. If the maximum domain Reynolds number approaches one, the number of time steps within a day is increased until a more stable setup is found. The groundwater module is initialised using groundwater head levels and constrained by the hydraulic conductivity and specific yield of the aquifer. These constraints may be specified as either uniform for the entire catchment or as distributed using ascii files. The groundwater module may be disabled to aid calibration of the surface hydrological components. Under these conditions recharge continues to be removed from the surface water store, however, baseflow is no longer returned to rivers.

Initial groundwater

The Initial groundwater file allows the hydrological model to be initialised from a steady state condition. If initial groundwater levels (mAOD or mASL) can not be determined from other sources, they may be found by setting initial values to the same as the DEM and letting the model relax to a balance point. Following this model spin-up stage, or if initial groundwater levels are known, future transient runs may be initialised. This process may form part of the calibration process (see Section 5).

Hydraulic conductivity

The aquifer hydraulic conductivity (m d-1) must be specified as either uniform or distributed. To set a uniform value across the domain, enter the required value in the Hydraulic Conductivity Multiplier box and leave the Hydraulic Conductivity file name as ‘null’. For a spatially distributed hydraulic conductivity, a gridded ascii file with header information is required in the same format as the Hydrology boundary file. If a distributed hydraulic conductivity file is used, the Hydraulic Conductivity Multiplier box allows every value to be scaled by the number in the box. For example, ‘2’ would double the hydraulic conductivities as specified in the file and ‘0.25’ would quarter the values. This value must be positive and if no scaling is required, then it must be set to ‘1’. The scaling factor may be useful in determining hydraulic conductivity during the calibration process (see Section 5).

Specific yield

The aquifer specific yield (-) is set using the same method as hydraulic conductivity and must be specified as either uniform or distributed. To set a uniform value across the domain, enter the required value (0 - 1) in the Specific Yield Multiplier box and leave the Specific Yield file name as ‘null’. For a spatially distributed specific yield, a gridded ascii file with header information is required in the same format as the Hydrology boundary file. If a distributed specific file is used, the Specific Yield Multiplier box allows every value to be scaled by the number in the box. For example, ‘2’ would double the specific yield as specified in the file and ‘0.25’ would quarter the values. This value must be positive and if no scaling is required, then it must be set to ‘1’. The scaling factor may be useful in determining specific yield during the calibration process (see Section 5). Specific yield is limited to unity and therefore any values greater than this will be reduced to one without producing any warnings.

Lisflood surface flow

Following the daily partitioning of surface water by the SLiM module, and calculation of baseflow return to rivers by the groundwater module, Lisflood controls the surface routing of water around the domain using a variable timestep based on domain maximum water depth. The calculated daily addition or removal of water by SLiM and the groundwater module are discretised at the timestep used by Lisflood. Lisflood takes slope, water depth, and surface frictional characteristics into account whilst distributing water around the catchment.

Figure 10    Flow model (Lisflood) tab parameters in the GUI.

Input — output difference

The Input — output difference allowed option (Figure 10) allows the speed of platform operation to be increased. CLiDE calculates surface water discharge from the catchment boundary and, if this is equal to that being added by SLiM and through baseflow return, we assume the flow model is running in a steady state. If so, we can detach the time step of the flow model from that of the erosion and deposition model and allow the time steps to extend to that determined by erosion and deposition. The value of Input — output difference allowed is the difference in cumecs between the input and output that is acceptable to allow the model to run in this faster mode. It is sensible to set this value close to the low flow value or mean annual flow. The CLiDE platform will shift automatically between the two states of operation.

Min Q and water depth threshold

The Min Q for depth calc box (Figure 10) defines a threshold above which the CLiDE platform will search for the domain maximum flow depth that determines the time stepping attributes. If this is set too low, computing resources are wasted calculating sub-millimetric flow depths, which will not result in erosion or deposition. The variable is dependent upon grid cell size and as a guide is set to a 100th of cell width, for example; a DTM with 10m cell size will have a Min Q of 0.1, and a DTM with 50m cell size will have a Min Q of 0.5. The flow depth (m) above which CLiDE calculates erosion can be set under the Flow Model tab. The standard value is set to 0.01 m, however lower values can be used on very high resolution DEM's and larger values on large grid cell widths (>50 m).

Courant number

The Courant number ((Figure 10) is a value that controls the numerical stability and operation speed of Lisflood. More details can be found in Bates et al. (2008). The Courant number should only range between 0.2 and 0.7, where higher values increase the model time step but are more unstable. Stability, and thus coefficient values, depend upon the grid cell size. Larger cells widths (>50 m) can take values of 0.7, smaller cell widths (< m) may need the smallest value (0.2). Stability is also linked to the erodelimit value, which controls the amount of sediment that can be eroded or deposited from a cell during a timestep.

Sediment

A range of options are available for the representation of initial sediment grain size proportions, transport and erosion properties. The grain size (m) and proportion (as a fraction of 1) columns allow the initial grains size properties to be assigned. The distribution of these sizes is considered homogeneous both vertically and horizontally across the domain. If a Grain data file (Section 3.5.3) is used to initialise grain size distribution, a more heterogeneous distribution can be achieved. As a simulation progresses, the sediment grain sizes are distributed across the catchment.

Fall velocity and transport method

The CLiDE platform retains the two methods of fluvial sediment transport used by CAESAR where a flow depth exists. The Einstein-Brown method can be used for a single grainsize and the Wilcock and Crowe formulation for up to 9 different grainsizes. The suspended sediment check box (Figure 11) allows sediment grain sizes at the value specified in the size 1 box, to be treated as suspended. The fall flow velocity for these grains may be specified in the fall velocity box (m s-1).

Figure 11    Sediment tab parameters in the GUI.

Max velocity and max erode limit

Where steep gradients exist between cells in the DEM, a value can be set for the maximum velocity (m s-1) used to calculate sediment transport. A max erode limit (Figure 11) may also be imposed to define the maximum amount of material that can be eroded or deposited within a cell. This parameter prevents numerical instability caused by too much material being moved from cell to cell. The max erode limit also controls the time step, which is restricted to allow this value (as a maximum) to be moved from one cell to another.

Active layers

Sediment transport occurs using a series of active layers. Below these active layers a series of non- active subsurface layers exist, allowing development of a limited stratigraphy. Erosion and deposition of sediment occurs in the active layer at the surface. If deposition occurs and the thickness of the active layer exceeds 150% of the depth (m) specified in the Active layer thickness box (Figure 11), the specified depth of active layer is archived in the topmost subsurface layer and the active layer is reduced in depth by 67%. When this occurs, the grainsize record in each subsurface layer is passed to the layer directly below. Where erosion occurs and the active layer thickness is below 25% of the depth (m) specified in the Active layer thickness box, the topmost subsurface layer depth, and its grainsize record, is incorporated into the active layer. Within the active layer and each subsurface layer, grainsize distribution is assumed to be homogeneous at the cell scale. In order to maintain stability, the acive layer thickness specified must be at least four times the max erode limit.

In channel lateral erosion

The in channel lateral erosion rate (Figure 11) controls channel width by setting the sediment cohesion properties. Sediment that is loosely packed and unconsolidated is represented by a higher value, and can be readily eroded and laterally transported (within the channel) resulting in a shallow wide channel. If it is more cohesive (represented by a lower value), it is harder to move laterally then a narrower deeper channel results. The in channel lateral erosion rate is required to reduce the positive feedback exhibited where erosion focuses more flow on that cell, which causes increased erosion, leading to single thread deep channels. Initial values of between 10 and 20 are recommended for most river types.

General lateral erosion and rate

The lateral erosion check box (Figure 11) determines whether bank erosion can occur within the platform. The lateral erosion rate is calculated by the radius of curvature, which is done according to the edge counting method described in Coulthard and Van de Wiel (2007):

rate of lowering of bank cell = (1/Ca) x Tau x LateralErosionRate x Time

Where Ca is radius of bend curvature (m), Tau is the shear stress of the cell adjacent to the bank, lateral erosion is the specified rate and time is in seconds. Material removed from the bank cell is added to the cell adjacent to the bank. Lateral erosion only occurs for 4 orthogonal neighbouring cells. Values for this parameter need to be derived through calibration as each catchment is unique. Following experimentation a lat erosion rate of between 0.01 and 0.001, seems adequate for braided rivers, and a lat erosion rate around 0.0001 for meandering channels or channels with little lateral erosion. This value is grid cell independent, so rates of erosion for the same site on a 20 m DEM should be the same for a 50 m DEM.

Number of passes and cell shifting

The number of passes for edge smoothing filter value (Figure 11) describes how smooth the calculated curvature of the channels is. Values calculated by this method can displayed when the model is running with the lateral gradient display option (Section 4.4.2). This will show red for the outside of bends and green for the inside. As a rough guide, this value should be set as the frequency of meanders (or distance between two meanders) in grid cell size. Too small a number will result in lumpy lateral development, too large will result in too little movement and smoothing across bends. The edge gradient that the CLiDE platform uses to determine lateral erosion can be shifted downstream. This allows meander bends and bars to migrate downstream. Suggested values are around 10% of the values used for the above number of passes for edge soothing filter (typical values ranges from one to five). Both the number of passes and shifted number of cells need to be integers.

Vegetation

The Vegetation tab contains parameters relating to vegetation parameterisation within the CLiDE platform. Vegetation parameters under this tab restrict sediment erosion and surface water flow rates and are not currently linked to the vegetation properties in the SLiM water partitioning or the SCIDDICA shallow landslide modules.

The vegetation critical shear is the shear stress value, imparted by water flow, above which vegetation will be removed by fluvial erosion. Low values allow vegetation to be swept away easily and higher values result in a more resistant vegetation.

Grass maturity defines the time taken (in years) for vegetation to reach full maturity, with greater maturity reducing erosion rates. The proportion of erosion that can occur when vegetation reaches fully grown (0 to 1) determines how vegetation maturity affects the in channel lateral erosion and general lateral erosion rates (Section 3.10.5). If set to 0 then, when fully grown, there can be no erosion using these two methods and if set to 1, then vegetation will have no affect on erosion. If set to 0.5, then when vegetation is fully grown 50% of normal erosion by channel and general lateral erosion will be allowed. However, this rate is affected by the level of maturity, so if the vegetation is 50% mature and the proportion of erosion is 0.5, the maximum allowable amount of erosion will be 0.75 of the no vegetation rate.

Slope processes

This tab contains the parameters used to control non-fluvial sediment transport processes within the CLiDE platform. Creep rate and Soil erosion rate (Figure 12) allow the impacts of decadal and centennial scale processes to be included in the landscape evolution aspect of the platform. Shallow landsliding events can also be captured using either a simple sand pile model, which uses slope angle to trigger landslides, or by a more complex system that also takes soil properties, friction, adhesion and momentum into account.

Creep and soil erosion rates

Soil creep is represented using a simple diffusive function defined by equation 2.18. The function will tend to create erosion on steeper slopes, and to round off of sharper features in the terrain. Typical values are 0.0025. The soil erosion function is an adaptation of USLE type approaches, where soil erosion is a function of the slope length, slope and a series of coefficients. Notably the slope length is derived by the square root of the drainage area at a point. There are no suggested values for this function, and it has not been calibrated or tested against field data to date.

Figure 12    Slope Process tab parameters in the GUI.

Sand pile

A simple sand pile function (Figure 12) can be used to generate shallow translational landslide events, which are triggered when the slope angle between two or more cells is greater than the stated threshold. The sand pile algorithm is similar to that described by Metha and Barker (1994) and can be triggered either by erosion at a slope base or by the addition of sediment to the slope top. Both of these processes allow the slope failure threshold angle to be exceeded and sediment to be passed between cells. The passing of sediment between two cells often leads to a cascade effect that can influence many cells. Non-fluvial movement of sediment as shallow landsliding is considered instantaneous within the model framework.

SCIDDICA

SCIDDICA allows for a more advanced representation of shallow translational landslide processes in comparison to the simpler sand pile method. The module calculates the potential energy contained within each ell based on the volume, weight and momentum of material. Like the sand pile model, SCIDDICA may be triggered by a change in slope between cells that exceeds a threshold value, however, it may also be triggered by the evolving hydrological properties at the surface or within the soil layer. Many of the SCIDDICA variables can be determined through calibration. Currently all factors are homogeneous across the catchment.

Soil entrainment

Along the landslide path, soil may be entrained into the landslide material, adding mass to the flow. The Soil entrainment coefficient (0 to 1) determines the maximum percentage of available soil material that may be entrained into a particular landslide event. The higher the coefficient, the greater the volume of soil material available for entrainment.

Friction angle

The Friction angle (0° to 90°) is a threshold value similar to the slope failure threshold (Section 3.12.2), which determines the minimum slope angle between cells over which a landslide can occur. Unlike the slope failure threshold angle, not all inter-cell slopes above this angle will fail as failure is determined by several factors including the landslide run-up; the additional landslide thickness produced by the drop in overall density when under momentum. A greater friction angle reduces the number of landslides within the domain.

Relaxation rate

The Relaxation rate coefficient (0 to 1) determines how many internal time steps are undertaken per simulated timestep. This avoids instability within the module, whilst maintaining efficiency. The relaxation rate must take into account cell size and the duration of each internal time step. The lower the coefficient, the greater the number of time steps used by the module to reach a balanced condition. If this value is too high, numerical instability may occur, and if set too low, computational resources are wasted.

Adhesion

Defines the minimum depth (m) of loose material that will remain following a debris flow.

Density

The density (g cm-3) of the soil above the bedrock surface.

Mobilisation

Within SCIDDICA, the mobilisation of loose soil cover occurs when a landslide entrains and mobilises the subsurface soil cover. A certain amount of energy is required within the landslide to entrain the soil and this threshold is set using the mobilisation coefficient. The lower the value (m3) the easier it is for soil to be entrained into the landslide.

Friction loss

The Friction loss parameter (m) accounts for the loss of energy through frictional processes at the landslide-surface interface. Within the model this parameter acts as the limit to which run-up thickness may reach and thus removes some of the energy from the system if run-up tries to exceed this limit.

Initial debris thickness

A gridded ascii file containing the thickness of surface debris (m), where the first six lines of the contain, the number of data columns and rows in the file, their geospatial referencing details, grid sizing and no-data value. The remainder of the file contains the thickness information discretised at the same spatial scale as the CLiDE boundary file. The values within this file must be equal to or less than the soil depth.

Climate factors

The Climate factors allow the input rainfall (PPTN) and potential evapotranspiration (PE) files to be perturbed in order to simulate the impacts of climate change. Both inputs may be perturbed on a monthly basis and the value entered each month represents a multiplication factor. For example, a value of 2 entered for January PPTN will double all input rainfall and a value of 0.5 will reduce the input rainfall by half. The perturbation is applied evenly throughout the simulation unless the linear CF application box is checked. If this box is checked, the perturbation is applied linearly over the duration of the simulation, starting with no change and ending with the full perturbation being applied.