Currently a maximum of three input points are supported (see figure), but for our use we have interpolated level data/gauge data resulting in multiple input points.

Summary

For the Hull work, HC will need the tidal/stage modes implemented.

(TBC)

It's not really clear from the code what the difference is between the two variables and how 'local' the local_time_factor actually is.

Make the code more self explanatory and consider a refactor later. Commenting may help, but review the logic first.

Just remembered following the meeting with @aproeme

Currently hard coded at:

Hi, can you confirm that evaporation isn't currently implemented in HAIL-CAESAR right now?

Similar to reach data mode (discharge), we want to be able to have multiple levels data points for input.

The logic for this could extend the stage_tide_inputs logic, or it could extend the reach input logic - i.e.

Extending Reach Mode logic

• Switch to flip between discharge and levels
• Multiple file support already there.
• Your input file would read the "discharge" column as either "discharge (cumecs)" or "river level (m)"
• Level get set by default as single pixel width (1D line)

Extending Stage Mode Logic

• Logic remains similar except:
• Switch to flip between local_datum and AOD datum.
• Current logic assumes AOD datum, i.e. the level is the elevation of the water surface, but many gauging stations report the local depth of the water relative to a local datum.
• Option to set a site datum?

Groundwater Input and Output

Need to figure out if any are not needed for GW simple vs SLiM options

Input

Output

• GW_heads.out
• Recharge.out
• Baseflow.out
• SM.out
• test_var.out
• GW_heads_XX.out (multiple)
• Recharge_XX.out
• Baseflow_XX.out
• SMD_XX.out
• test_var_XX.out

Summary

We need some documentation for reach mode. The inputs are the same as the CAESAR-Lisflood so should be fairly similar, the main difference is specifying the input files in the parameter file, rather than via the GUI/xml in CL.

I've no idea if this is the latest version of the caeser-lisflood software (is it this one? or this repository?), but I've noticed that your documentation states the following:

Make sure the DEM is in ascii (.asc) format.

.asc is actually a file extension commonly used with GNUPG, or GPG for short. I'd suggest changing it to something else so that it doesn't clash.

I'm a PhD student at the University of Hull whose project title is somewhat similar to the aims of caeser-lisflood - so I found it by a recommendation from my supervisor.

It's time to have a proper testing framework for HAIL-CAESAR. Initially I'm thinking along the lines of a set of regression tests or functional integration tests for some standard test cases. Then finer-grained tests can be introduced as the code is refactored or as new functions are written etc.

Test cases with Known Good Answers (KGAs)

Start with some simple test cases that can be run as part of the code, without having to read in external input files. (Rainfall, DEM etc.)

To tick off here as they are added to the test battery:

Idealised topography

Planar surfaces, i.e. totally flat, sloping E-W, N-S. NW-SE etc. Water inputs can be coded in as constants or setting the water depths to a constant value at given points and letting the water run off. (Testing the main LISFLOOD-FP algorithm and boundary conditions)

For example, @aproeme has made these test cases in the idealised LISFLOOD code (no real topography)

Water held constant at a single central source point, checks that it is routed away from the centre correctly:

Real topography

I.e. Some standard test cases using DEM input with rainfall input. Boscastle and the Swale test cases would be good to use.

Short term, flash flood event style test cases

• 50m DEM, 72hr simulation, flood-only #20
• 50m DEM, 72hr simulation, flood+erosion

Longer term landscape evolution

etc..

Enquiry via email:

I’m setting up a HC model (Karnali River / Nepal) and have two issues:

Segmentation fault: I can run the model up to a resolution of 7m (~9.5M cells) but for 6m and higher, I get a segmentation fault error and the model doesn’t run.

Does it sound familiar to you? Do you have an idea what could be the cause? Is it related to the number of cells? I’m running it on an HPC and doubt that it’s related to the computational resources (the 7m version uses 27GB RAM and 256 GB are available).

I’d like to provide spatially distributed grain sizes but am not sure about the file structure. Would it be possible to get an example file that helps me to figure it out?

This is the only place in the code where we check the leftmost + 2 grid cells to set tempslope, it would make it easier for the libgeodecomp refactor if this was consistent on all edges of the model domain.

Perhaps it is some legacy code from an older version of the CAESAR code?

It means that in libgeodecomp, there is lots of complicated "edge" cases:

Which make for lots of case statements

Try running the standard test with this changed to x<=1 and run standard case. (Arno and I could not see a reason why this wouldbe necessary at first glance.)

Several new components have been added to the CAESAR-Lisflood code upstream (the Windows version). AB has added these componets to the CAESAR_GW batch of code. The main additions are the model options of swappig out TOPMODEL for SLiM to incorporate groundwaer more realistically. There is a basic groundwater option and a separate option that allows the user to run with the SLiM model that includes water partitioning (overwriting the standard recharge process)

Groundwater inputs

• Initial groundwater
• Groundwater boundary file
• Hydraulic conductivity (m/d) file
• Specific yield (-) file
• Recharge rate (% rainfall 0-1)

Water Partitioning

• Start date
• HOST file(?)
• Landuse file
• Potential Evaporation location file
• Potential Evaporation table file
• Initial soil moisture deficit file

There is a test case for both GW and SLiM in the CAESAR_GW folder

The key functions to look at are:

• wpgw_water_input()
• water_partitioning(rain_data_time_step)
• Groundwater_Flow(1440)

Key data structures:

• dailyBF[][]
• wp_added_water_daily[][]

Hello, everyone.
I want to simulate the flood evolution in a river during the process of a dam break. And I know the flow of the dam break.
Is HAIL-CAESAR can be used for this kind of simulation? And is there any examples about this ?
Thanks a lot!
Best regards,
Henry

There is a bug in the reach mode on master and the reach mode tag. The parameters for setting the reach input points reach_x and reach_y are the wrong way round to the way most people think of them (sorry in my head I'm used to swapping them round for i, j notation in matrices....)

Most people have spotted this I think and just "flipped" the coordinates round (hopefully it produces obviously wrong/odd output if you don't...)

I'll add a fix soon but in the meantime you can just switch your x and y coords around if using reach mode.

This would be a nice feature, especially when considering standard results like the hydrograph output or water depths extent as a visual indicator of how changes affected the comparison to the KGA.

Something is producing abnormally low discharge values when running spatially variable mode. Also the TOPMODEL output is giving -nans at all timesteps!

This is a truly ridiculously trivial bug that has been on @dvalters to-do list since about 2014

First: could I say that this code is great!

Second: I am probably missing something obvious, but I am having difficulty understanding the rainfall input data format. From the read the docs, the rainfall data is "the rainfall rate at each rainfall input time step in mm/hr". Is it therefore a single column of data where the length of that column is equal to the number of time steps defined by max_run_duration in seconds divided by max_time_step? In the test run on Boscastle paleoDEM_v1_72hr_rain_u.txt has 864 rows, which is 72hrs in seconds divided by 300 seconds. However, paleoDEM_v1_72hr_rain_u.txt also has 28 columns, why?

Furthermore, I tried to run a 10 day simulation. I chose a max_time_step of 1000 seconds, and a max_run_duration of 240hrs. This means that my rainfall data should have 864 rows and one column. HAIL-CAESAR ended with a segmentation fault at some point after 2.5 days of model time. I increased the length of my rainfall input to 1000 rows, and the segmentation fault occurred at some point after 3 days. Therefore I am now guessing that the number of rows within the rainfall data file is not given by the max_time_step, but the actual time step the model uses based on the CFL condition?

Possibly add to documentation a brief explanation of how it works.

This is not clearly worded -implies 0.02 is low and 0.005 is high...it's refering to the hydrograph peaks rather than the values of m themselves, hence the confusion....

See also #34 but beware this wouldn't give comparable results necessarily - see Tom's comment in that issue.

Some extra follow up points from email discussion:

• For the digital twin/forecasting we’re doing this should work fine as we’re starting from the best known representation of what’s happening in reality.
• For stopping/restarting the model I’m sure it is technically possible to do this as the Met office (and other institutes/climate models) periodically save their entire simulation state on long model runs in case they need to be interrupted.
• It may require another solution than just dumping everything to a text file – but I’m not sure what that solution is.
• You won’t get the same number of DP saved to the file as stored in the memory (double) for all the parameters… If you can – it might work, but suspect if just one wee thing is a bit different the overall outcome will be similar – but not the same. Deterministically non-linear model

Acceptance Criteria

• Model now takes a water depths file AND a flow vectors file, which are used as initialisation DEMs
• Model produces similar results when using the prestart water files compared with single run uninterrupted

Summary

CL has option to load in previous model state and being the simulation by initialising water depths, sediment matrix and flow vectors (although don't think flow vectors was completed in CL?). This would be useful to re-implement in HC, so long runs can be broken up to fit into to wall clock limits on HPC etc.

Acceptance criteria

• Split the test simulation into two halves.
• Restart the second half of the test simulation from the output files written in Part I
• Verify that restarting from midway output files produces same results as a simulation run all the way through in one go.

Hi, not sure where to place this, so here we are! I'm looking at running your version of CL on our Linux computer, but looking at the instructions for compiling the model, it appears to produce an .exe file which isn't compatible with Linux machines. Is there a way of producing a .pbs file or similar?

Updated 25/02/22

This issue has been picked up again as it would also be good to support lat/lon and/or BNG specifically for the x/y positions for reach inputs.

At the minute, DX assumes the cellsize metadata is in metres, i.e. OSGB, UTM, basically a projected coordinate system that uses metres as the units. It would be more flexible to allow the user to specify the units (i.e. metres, km, decimal degrees etc.) in the parameter file, or even better, try to deduce it from any other metadata (not currently feasible as only ASCII grid format is supported, which doesn't require a header/metadata file to store units.

[dvalters@helmsdale dv_test]$ head -n 6 comonfort_dem_.asc
ncols        3427
nrows        4446
xllcorner    -98.632941404716
yllcorner    17.498771180130
cellsize     0.000045883021      <--- Decimal degrees! Results in wrong timestep multiplier (way too low)
NODATA_value  0

Tom released some minor changes and bug fixes to CAESAR-Lisflood 1.9f. Should bring inline with HAIL-CAESAR code where possible/sensible

https://sourceforge.net/p/caesar-lisflood/wiki/Update%20Notes%20%28details%20of%20revisions%20in%20CL%20versions%29/#19f

1.9f

11/9/2018

Overview

• Minor changes to address a couple of bugs/errors that may have slowed the model down in catchment mode:
• Revised how total water inputted is calculated in catchment_water_input_and_hydrology - error that did lead to long time delays in some catchment simulations.
• Ln 5550 change of how max depth used in time step calc (will only effect very fine scale low water depth simulations)
• Change in density of sediment in Einstein equation (from 2250 to 2650)
• Various code tidying - including making sure all check buttons and options are now saved in the .xml config files.

Feature updates

1. Meyer-Peter-Muller sediment transport rule added as an option.
2. Different veg model option (details to follow)

When I build a new project to make a simulation. I have to write DEM input file as ascii format.
I open the file and see some data about the elevation.
But I want to know the meaning of the variable such as: ncols, nrows, xllcorner,yllcorner,cellsize,NODATA_value.
And other data is similar about pixel （0-255），is there any connection between the pixel with elevation?
How can I generate this DEM file?
Can anybody help me?

best regards

dong
[email protected]

@aproeme's inital results showed that when a non-uniform water grid was imposed at the start of the simulation, this would not 'equalise' out over the domain as might be intuitively expected. This could be to do with the edgeslope or with unusual idealised case of routing algorithm being applied to a topography surface where all the heights are = 0.

Problem

• If I try to input one grainsize only, the output still gives me a volume of sediment for all 9 grain sizes.

Segfaults here: where area is set to one at i=4020, y=1 (from gdb backtrace)

From Freya's larger DEM mexico. (Sent to email for further debugging)

void LSDCatchmentModel::zero_and_calc_drainage_area()
{
  // Zeros the area and are-depth arrays
  // Sets area_depth to ones as a flag but
  // zeros the ones outisde the catchment
  for(unsigned i=1; i<=imax; i++)
  {
    for(unsigned j=1; j<=jmax; j++)
    {
      area_depth[i][j]=1;       <----------SEGFAULT 
      area[i][j] = 0;
      if (elev[i][j] == -9999)
      {
        area_depth[i][j] = 0.0;
      }
    }
  }
  drainage_area_D8();   // This refers to a newer area getting method in CaesarLisflood
}

Update - in fact this is already implemented in Tom's branch of Caesar Lisflood, so we could take his implementation and put it into HC

Couple of people have asked about this being implemented now (like CAEASR-Lisflood reach mode)

Would be nice to have implemented.

Summary

Reach model also requires a DEM in the same format as the catchment model/mode. Water will exit from any edge of the DEM, but as per catchment mode, not be routed in NODATA cells.

Reach mode requires an additional file that contains the water and sediment inputs into the catchment. The format of the file is a standard plain text/ascii file with the following layout:

The file format is in the same format as the catchment output file catchment.dat (Hence the blank columns, these do not need to contain data when used as input.)

Parameter file additions

• The parameter file will need modifying to accept the x y coords for all/any input points, and a routine needed to input these points into the reach_mode function.

Test Case

Use the same test case for comparability between the Win model and this one.

Reach mode: Modelling the River Severn nr. Caersws, U.K.

This example is for a c.2km by 2km section of the River Teifi, immediately downstream from Lampeter, Wales. The DEM is at 10m resolution and created from downgraded LiDAR data. To run this example, download the relevant files which include the main program file (Caesar 5.1.exe) and the sample data files teifi.zip and swale.zip. Unzip and place them all in one directory.

The three files to be used for the Teifi example are whole9.txt (the DEM file) input2.txt the water and sediment input data file and teifi1.xml - the configuration file.

Figure out whether updating in "continuous time" vs "discrete time" matters for LISFLOOD

I.e. if we iterate over the cells calculating their depths and update each cell one by one (continuous) or if we were to iterate over the cells basing their new values on only the previous values. (discrete) - i.e. water depth update carried out for whole domain at once.

Add a clang compilation build

The [x][y] notation in places implies Cartesian-like coordinates, but elsewhere references to imax and jmax are used. (i.e. [row][column] matrix-style notation)

Should pick one and be consistent, but best left until after the libgeodecomp refactor.

Is it possible to turn off catchment mode (i.e. remove the Topmodel element) and run entirely in reach mode? I've been examining the code and it looks like it is possible but I'm not 100% sure how I should do it without screwing it all up.