Delay of simulated flows over observed flows

[Raphaël]

Hi everyone !

I am bothered with the flows simulated by CAESAR-Lisflood at the outlet of my catchment .

The simulated flows (in red in Figure 1) occur constantly some time after the observed flows (in black in Figure 1)  even when I drastically reduce the values of m and the manning coefficient (so that the model produces reactive responses (example in Figure 1)). My time series have a 30-minute time step. 

For this example, the delay between the observed and simulated flood peaks is 30 minutes (one time step). 

I have checked several times the time concordance of my time series (including rain). Everything looks good.

So what is the reason for this delay? Is CAESAR-Lisflood able to generate very fast responses to rain? 

Is it just a numerical problem that would be related to the way CAESAR-lisfood does the calculations?

Thank you for your help,

Raphael

[Tom]

Hi Raphael - sorry for late reply. Full Gmail inbox...

They dont look much later to me - though this could be the resolution/scalign of the graph....?? Is it consistently 30 min gap?

[Raphaël]

Hi Tom.

Unfortunately, no, I was unable to correct the delay. In the additions and revisions you have made to CAESAR-Lisflood, you indicate that you have modified the function 

catchment_water_input_and_hydrology to reduce the delay in the production of flows. What kind of changes did you make to the code? Have you changed the way input points are defined (catchment_input_counter[rfarea[x, y]])? 

 

In fact, I am trying to calibrate CAESAR-Lisflood on a mountain watershed subject to torrential flooding and high erosion rates (mainly suspended sediments).

I have noticed that overall, the flood simulation tends to be more satisfactory (Nash-sutcliffe efficiency > 0.5) when floods are high (in terms of peak flood and volume flow) (Figure 1 & 2). However, CAESAR-Lisflood is unable to reproduce small floods and there is either an overestimation (Figure 3) or an underestimation (Figure 4) of water volumes. Have you ever noticed that?

[Tom Coulthard]

Yes - the volumes is due to the in-out difference function - that speeds up model operation during low flows. This effectively means any flows under the value set take much longer to go - so tends to lead to an overestimate of water volumes (because all the small values add up). 

If precise water volumes is important run in-out close to zero - but it’ll run slower. The general assumption using in-out is that the modeller isn’t that bothered about low flow volumes - just high flows and sediment outputs. 

--
You received this message because you are subscribed to the Google Groups "caesar-lisflood" group.
To unsubscribe from this group and stop receiving emails from it, send an email to caesar-lisflo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/caesar-lisflood/7016f1b7-f7da-4b93-87bd-3669f187ede4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

<figure3.png>

<figure4.png>

<figure1.png>

<figure2.png>

[Tom]

[Raphaël]

Hi Tom,

Thank you for your advice.

I think I have identified the cause of the delay of simulated flows over observed flows. 

The rainfall and m files data starts at index 1 of the hourly_rain_data and hourly_m_value arrays. 

The index 0 corresponds in a way to a blank. 

In my opinion, the function calc_J does not correctly retrieve the values contained in hourly_rain_data.

When starting the model, the blank  is considered to be the first rain value, which generates an offset (and therefore a delay) equivalent to the time step of the rain file.

This indexing problem does not exist for hourly_m_value because there is a +1. 

Just add this +1 for rain to correct the problem.

I no longer have any delay when I look at the output of TOPMODEL but a delay remains (1h) for the output of lisflood. Does it take so long to route the flows?

 

On the other hand, TOPMODEL flows are systematically higher than Lisflood flows although the evaporation rate is set at 0 and storage effects are excluded (the sediment component is disabled).

 I have set minQ to 0.05 but this parameter only affects the degree of spreading of the drainage network anyway. 

 In/out difference is 0 so there is no risk of omitting some flows. 

Instead, I suspect the hflow threshold which could significantly reduce water volumes when the flow slope is too low.

Here is a graph to illustrate all this. The delay has not been corrected here.

[Raphaël]

Here is the extract of the code that must be adjusted with the additions in red : 

    if (variable_m_value_flag == 1)

    {

        M[n] = hourly_m_value[1 + (int)(cycle / mfiletimestep), n];

    }

    local_rain_fall_rate = 0;

    if (hourly_rain_data[1 + (int)(cycle / rain_data_time_step), n] > 0)

    {

        local_rain_fall_rate = rain_factor * ((hourly_rain_data[1 + (int)(cycle / rain_data_time_step), n] / 1000) / 3600); /** divide by 1000 to make m/hr, then by 3600 for m/sec */

    }

[Tom Coulthard]

Hi Raphael - a quick Q - are you running just one flood? EG is the graph below from midway through a sequence of just the one event? 

I ask because part of TOPMODEL is the store of water - and whilst this doesn’t start empty at the start of sims, its not at the same level it would be after a few events (for example). This can affect the first couple of events (generally leading to under-estimating). If this is the case (its your first event) try repeating the same event 3 or 4 times within the same run. 

OK- for your Q’s below. The top model output is the output from a single cell multiplied by the area of all the cells in the DEM (excluding no data cells of course) - so if you take this value as what water should be output this assumes that all cells in the DEM drain perfectly to the exit. This is rarely (if ever) the case... so the actual water output is nearly always less - hollows/obstructions/flat points within the DEM will store/slow down water flow from top to bottom. Top model output will also not account for any travel times for the water from top to bottom.

In other words TOPMODEL output is not a flow - but an ideal output - something to test /check all is OK (which is why it was output in the file in the first place). 

Hope that helps explain a few things...  

On 4 Jun 2019, at 20:06, Raphaël <bune...@gmail.com> wrote:

Hi Tom,

Thank you for your advice.

I think I have identified the cause of the delay of simulated flows over observed flows. 

The rainfall and m files data starts at index 1 of the hourly_rain_data and hourly_m_value arrays. 

The index 0 corresponds in a way to a blank. 

In my opinion, the function calc_J does not correctly retrieve the values contained in hourly_rain_data.

When starting the model, the blank  is considered to be the first rain value, which generates an offset (and therefore a delay) equivalent to the time step of the rain file.

This indexing problem does not exist for hourly_m_value because there is a +1. 

Just add this +1 for rain to correct the problem.

I no longer have any delay when I look at the output of TOPMODEL but a delay remains (1h) for the output of lisflood. Does it take so long to route the flows?

 

On the other hand, TOPMODEL flows are systematically higher than Lisflood flows although the evaporation rate is set at 0 and storage effects are excluded (the sediment component is disabled).

 I have set minQ to 0.05 but this parameter only affects the degree of spreading of the drainage network anyway. 

 In/out difference is 0 so there is no risk of omitting some flows. 

Instead, I suspect the hflow threshold which could significantly reduce water volumes when the flow slope is too low.

Here is a graph to illustrate all this. The delay has not been corrected here.

<plotForum.png>

Le mardi 28 mai 2019 10:37:50 UTC+2, Tom a écrit :

On Wednesday, 22 May 2019 20:03:45 UTC+1, Raphaël wrote:

Hi Tom.

Unfortunately, no, I was unable to correct the delay. In the additions and revisions you have made to CAESAR-Lisflood, you indicate that you have modified the function 

catchment_water_input_and_hydrology to reduce the delay in the production of flows. What kind of changes did you make to the code? Have you changed the way input points are defined (catchment_input_counter[rfarea[x, y]])? 

 

In fact, I am trying to calibrate CAESAR-Lisflood on a mountain watershed subject to torrential flooding and high erosion rates (mainly suspended sediments).

I have noticed that overall, the flood simulation tends to be more satisfactory (Nash-sutcliffe efficiency > 0.5) when floods are high (in terms of peak flood and volume flow) (Figure 1 & 2). However, CAESAR-Lisflood is unable to reproduce small floods and there is either an overestimation (Figure 3) or an underestimation (Figure 4) of water volumes. Have you ever noticed that?

Le lundi 20 mai 2019 19:15:10 UTC+2, Tom a écrit :

Hi Raphael - sorry for late reply. Full Gmail inbox...

They dont look much later to me - though this could be the resolution/scalign of the graph....?? Is it consistently 30 min gap?

On Saturday, 4 May 2019 08:49:52 UTC+1, Raphaël wrote:

Hi everyone !

I am bothered with the flows simulated by CAESAR-Lisflood at the outlet of my catchment .

The simulated flows (in red in Figure 1) occur constantly some time after the observed flows (in black in Figure 1)  even when I drastically reduce the values of m and the manning coefficient (so that the model produces reactive responses (example in Figure 1)). My time series have a 30-minute time step. 

For this example, the delay between the observed and simulated flood peaks is 30 minutes (one time step). 

I have checked several times the time concordance of my time series (including rain). Everything looks good.

So what is the reason for this delay? Is CAESAR-Lisflood able to generate very fast responses to rain? 

Is it just a numerical problem that would be related to the way CAESAR-lisfood does the calculations?

Thank you for your help,

Raphael

--

You received this message because you are subscribed to the Google Groups "caesar-lisflood" group.
To unsubscribe from this group and stop receiving emails from it, send an email to caesar-lisflo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/caesar-lisflood/d7210048-c4e3-45e5-a6f1-1ab3f2cc59c4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<plotForum.png>