open TELEMAC-MASCARET The mathematically superior suite of solvers

Hi,

I use the rainfall-runoff module and read rainfall from an external data file. I noticed that total accumulated rainfall as given in the results file (variable "ACC. RAINFALL") is different from what is given as input and that this difference depends on the (shape of the) time series and steering parameter GRAPHIC PRINTOUT PERIOD.

I am using TELEMAC-2D v8p2. I use the FV HLLC scheme with variable time step. For illustration I defined the following examples, see also results attached.

I used two rainfall time series, both 1 hour duration, 300 s resolution, the same total rainfall (68 mm), but one with concave shape (higher intensities at the beginning of the event) and one with convex shape (higher intensities towards the end); distinguished by different linetypes (solid vs. dashed) in the plot. Rainfall is given to TELEMAC as FORMATTED DATA FILE. The plot shows its accumulated values in red ("input"). For comparison you also see the accumulated rainfall as derived from the results file in blue ("results").

See in the attached plots that the values from the input and the results file are similar but slightly different when the resolution in the FORMATTED DATA FILE is equal to output resolution (GRAPHIC PRINTOUT PERIOD); see figure 1.

However, this difference gets extremely large when specifying a different GRAPHIC PRINTOUT PERIOD, in this case 900 s (vs. 300 s in the rainfall input), see figure 2.

Also note that these differences differ for different rainfall time series with the same total sum.

This looks to me like a bug (or at least unexpected behaviour) or am I missing something? I guess this could be a side-effect of variable time steps used with parameter GRAPHIC PRINTOUT PERIOD. Recommendations how ti handle this?

Regards,
Tobias

Fig. 1: graphic printout equal rainfall input


Fig. 2: graphic printout 900 s (vs. 300 s of input)

Hello,

This looks like a strange behaviour. Can you please share the files, especially the hyetograph and the steering file?

Kind regards
PL

Hello,

I made some quick tests with v8p2r0 and I could reproduce something similar with FV using the test case pluie. The strange behaviour that I have identified is happening if you define the output printout period with both TIME STEP and GRAPHIC PRINTOUT PERIOD.

If you define TIME STEP in the steering file, the given value will be used in variable DT during the first iteration (this is at least this value that is passed to runoff_scs_cn) but the real time step is another value, the one satisfying the CFL criteria chosen. So, I could reproduce something similar by defining my output period (120 s) with:
TIME STEP = 120
GRAPHIC PRINTOUT PERIOD = 1

I then get a wrong ACC RAINFALL because the rainfall depth used at the first iteration is determined for a (fake) time step of 120 s. The error only gets bigger if you define an even greater value in TIME STEP.

On the other hand, if you don't define any time step (it is not needed as you use variable time step in FV), the error on ACC RAINFALL disappears and you get results matching the indata. To be fully clear, there is a slight difference because the value of DT used at first iteration is 1.0 (default value I guess) and not the actual time step, but the error should be very small.

So, I suspect that you use TIME STEP in your steering file. First thing to try is to remove it. If you still observe strange behaviour, this needs to be investigated further.

Keep in mind that when using a hyetograph, the input data is interpreted as a block-type hyetograph, see the notes in runoff_scs_cn.f. Rainfall values ARE NOT linearly interpolated between different time points.

Finally, I noticed that the subroutine used in the test case pluie is slightly different than the source file. For instance, the array corresponding to ACC RAINFALL is an array called ACCR in the source file while in the subroutine version used in the test case it is still the temporary array T7 (as what was done in earlier versions). I don't know if this can be a source of error but one thing to try would be to restart from the source file instead of reusing the file provided in the test case.

Hope it helps.

Kind regards
PL

Hi,

thanks for your response and having a look at the issue.

I am not using variable TIME STEP. So the reason must be somewhere else.

I used the user code of the pluie example. However, I now also tried with the code from source and there is no difference. I.e. the graphs as shown in my initial post are identical.

One possible explanation of the small differences in figure 1 could be the calculation of RFM in the code (line 209). When AT is between AT1 and AT2 for several timesteps, all having a different DT due to the numerical scheme, it might happen that the sum of all these DT is larger (or smaller) than AT2-AT1 and therefore the rainfall sum is higher (or smaller). This also depends on how exactly AT is defined (haven't had a closer look here). I guess this could be accounted for somehow (e.g. adding / substracting the remaining / excessive rainfall).

However, I still don't know what could be the reason for the large discrepancy of figure 2. I guess there must be some side-effects between GRAPHIC PRINTOUT PERIOD and the current DT?

I added my setup to retrace what's going on.

Best,
Tobias

... what just occurred to me: Maybe variable AT at the beginning skips the first rainfall events because DT is too large (larger than rainfall resolution in the rainfall input file)?

Hi,

You are right, the computation of RFM is approximative and some errors can be expected if the the duration (AT+DT) is larger than (AT+AT2). AT is the current time in the simulation, in seconds. Here is a tentative correction, where RFM also includes the rest of the rainfall depth after AT2:


Please test it - if it works I can check with EDF to include it in the next versions.

What can be causing trouble in your case is that, since you're using the CN model the runoff is zero at the beginning of the simulation, hence yielding a large time-step. So some erros can be expected for the case where you start with a large precipitation.

I notice that you apply approx 30 mm rainfall during 3 minutes, this is very extreme and I guess you do this for testing purposes. But this might explain why you see some discrepancy in the results. To minize this you could try to set some nodes with CN = 100, hence direct runoff. This should help to avoid too large time steps during too long time at the beginning of the simulation.

I haven't had the time to test your example but with my own tests with pluie and without using TIME STEP in the steering file, I don't see differences in the results when changing only GRAPHIC PRINTOUT PERIOD, it is consistent. It is expected as this variable is not used in this subroutine.

Kind regards
PL

Thanks. Unfortunately it doesn't work. At least the results are rather unexpected, i.e. large discrepancies even when GRAPHIC PRINTOUT PERIOD is equal to rainfall input resolution. I also considered your remark about the dry catchment and had another try with some initial water (INITIAL DEPTH = 0.01 with INITIAL CONDITIONS = 'CONSTANT DEPTH'). The results are attached, 'fig1_*' as figure 1 above but with your patch 'fig1_codechange.png' and one version with initial water 'fig1_codechange_initdepth.png'. In analogous manner for figure 2.

Looks like some more magic going on somewhere deeper in the code. I guess I've found a very specific case here. When using some other events with longer durations and also wider intervals in the rainfall input the problem seems to become more and more negligible (i.e. discrepancies similar to fig. 1 of my initial post).

I also just noticed that for the "convex" rainfall event with dry initial conditions and low intensities at the beginning I got the following warning (sorry, I didn't see it earlier as it just occurs a few times for specific cases):

BTW: Some of the rainfall pulses are high, true. However, this is a design storm with 100 years return period in a tropical region. I have 2 years of station data with high temporal resolution from the region and the highest intensity is 25 mm in 5 min, so I guess it's not entirely unrealistic.

Hi,

The results from fig2_codechange_initdepth.png look reasonable: input = output excepted for the concave case where the results are likely spoiled by the initial time step. This shows that the problem is linked to the time step size at the beginning of the computation, before runoff starts. It would be nice to be able to define a maximum time step...

Instead of starting with an initial water depth (which is not physically correct for your study), you could try to do as I suggested, defining CN = 100 is some areas where it will not affect your results but where runoff will be generated directly and thus bring down your time step. You could also possibly use a lower CFL value.

As for the influence of GRAPHIC PRINTOUT PERIOD, this is strange. I will try to test your case. If there is a problem it is however not linked to runoff_scs_cn I believe and other persons would need to have a look at this (I am not a developper). However, for such study, it does not make sense to output every 900 s if your rainfall resolution is 180 s. How become the results if you output say every 60 s?

I live in Sweden and we have here drastically different hydrological conditions that what you describe for the tropics :) Sorry for my comment!

Kind regards
PL

Hi,

I have tested your case. The reason of your problem is the very long time step that you obtain at the beginning of the simulation. For example, with the concave rain:

This will spoil the reading of the hyetograph with 180 s resolution. The code would need further modifications to take into account such a case, where DT spans over more than two time series points. On the other hand, it is not a good idea to allow such a long time step because some runoff, triggered during the time step, can be missed, hence leading to wrong results.

I could also reproduce the strange behavior when changing GRAPHIC PRINTOUTS PERIOD. It looks like it is linked to some internal FV / time step parametrization which I am not aware of. Would be intresting to have feedback from developpers.

I made some changes to your case with:
- refining the mesh in one area near the outlet (your base mesh is extremely coarse with 100 m side length - this for sure does not help to reduce time step)
- I set CN = 100 in that area to force direct runoff from 1st time step



I ran the case for concave and convex rain and for GRAPHIC PRINTOUTS PERIOD 60 and 600 s. The time step in those simulations is much smaller at simulation start and the rainfall as applied in the simulation is matching the input data, see graphs below. Yes, the total simulation time will be longer, but your mesh is pretty coarse as it is, some refinement would be beneficial if you have enough resolution in your DEM.

Kind regards
PL

Thank you very much for taking your time and doing such detailed analysis on my problem!

So, I think we can summarise that:

1. Regarding the strange results for different values of GRAPHIC PRINTOUTS PERIOD something in the code is going on that the core developers should have a look at.
2. The core problem of my use case is that the resolution is too coarse.

My problem is the poor data avilability in the study area. I thought I could still try to run TELEMAC but maybe it just doesn't make sense here. Of course I could increase the mesh resolution but for the DEM I (so far) have to rely on publicly available products, i.e. 90 m for hydrologically pre-processed products or 30 m, whereas the latter have the disadvantage of higher noise which makes such products even less applicable for hydrological applications.

Regarding the CN values: Along roads and streams I was already using high values of 98 and 95 (e.g around the outlet in the SW corner), so I thought that wouldn't make so much difference to using values of 100 (sorry, forgot to explicitly mention that in my last post).

I will have a look at what I can still achieve here. Thanks for your support so far!