open TELEMAC-MASCARET The mathematically superior suite of solvers

Regarding GRAPHIC PRINTOUTS PERIOD, one possibility would be that some discrepancy occurs for the time steps around each time when graphic printouts are applied since the code automatically adjust the time step to match the desired period. But I don't know how this is done into detail and how it affects the results you showed here. On the other hand, what we now know is that this is a problem when the time step i very large (> 100 s) and this is not an issue with common time steps (range of seconds and lower).

Anyway, for problems with very abrupt variations such as yours, a time step > 10-100 s should be avoided.

Regarding your case and the DEM quality you have, it is tricky but I would use a refined mesh (at least in some parts), mainly to make sure that the time step is kept at a reasonable level.

Regarding CN values, even with 98, you will likely have some abstractions at the first time step and if the entire model is dry, you don't have any control on the initial time step, which is large in your case (497 s...). Setting 100 (even at some nodes only) will trigger direct runoff and if mesh size is small enough, set a reasonable time step.

Good continuation!

Kind regards
PL

Hi,

I tested examples with a much denser mesh and some CNs set to 100. The results now look fine, comparable to PL's figures, i.e. rainfall in the results file is as given via the input file.

However, I also observed 2 further strange things:

First, I printed the first 100 time step lengths in the listing output to see what's going on. I observed that with high printout rates (GRAPHIC PRINTOUT PERIOD = 10) the time step lengths are generally small, between 0.0086 and 9 seconds while with higher GRAPHIC PRINTOUT PERIOD (100 and 300 s) the time steps become longer (between 0.4 and 90, and 1 and 90 s, respectively). Yet acc. rainfall in the results files is (almost) the same.

Second, I run the examples with MASS-BALANCE and the summary at the end of the listing output reports considerably less rainfall than there should be, i.e. VOLUME ADDED BY SOURCE TERM is always about 6 million m3 but it should be almost 10 million m3 (67.9 mm over an area of 145 km2).

The variable time steps really seem to have some unexpected side-effects that are not accounted for.

Regards,
Tobias

Hi,

Thanks for reporting your testing.

Regrding the mass balance issue, is your observation based on the same model you shared here, that is with the rainfall-runoff model activated? If yes then the volume added by source term will correspond to RUNOFF and not RAINFALL. If you set CN = 100 everywhere then you should obtain RAINFALL = RUNOFF.

Kind regards
PL

Ah, right, that makes sense. At least a part of the problem explained.

However, VOLUME ADDED BY SOURCE TERM varies also slightly with GRAPHIC PRINTOUT PERIOD (e.g. 6025602 m3 vs. 5723089 m3 for 10 vs. 100 s printout period) while rainfall in the results file is almost exactly the same (65.774813 mm vs. 65.731533 mm). This is strange as VOLUME ADDED BY SOURCE TERM now only depends on the CN values (and related parameters) which are constant (the very same mesh file etc. was used).

I just want to say, even if you define your CN to a very high value (just say above 90), the amount of rainfall loss could still be very high. If you define your CN to 100, the amount of rainfall and runoff should be the same.

And also the GRAPHIC PRINTOUT PERIOD is not in seconds but rather in timesteps.

Hi,
annatrinh wrote: Well, this is what it's supposed to be but it is in seconds when using FV method with variable time-steps as I am doing. Not sure if this is intended (I think it's not documented) but it is the case. Only LISTING PRINTOUT PERIOD is still interpreted as number of time steps.