open TELEMAC-MASCARET The mathematically superior suite of solvers

Dear community,

we examine different options for running pluvial flood events on quite fine (we have to) computational grids with Telemac-2d. A setup that results in wiggle-free water depths is using a FV solution.
Telemac is my preferable solution due to its scalability and applicability on Linux clusters.

In the steering file we define 'desired Courant number' of CFL=0.9.
'Variable time step' is obligatory.
Our basic time step is specified as 1 s, the reached time step is around 0.06s +/-50%. So the defined one is not a limiting factor.

In the results file we do not find any Courant number (output 'L' every 5 minutes of the simulated period) exceeding CFL=0.14 at any node in any time step.
At the end of the *.sortie-file it's giving:
'PRERES: MAXIMUM COURANT NUMBER: 0.6532735E-01'


Is there anything we are missing?
Is there any other setting that may throttle the time step?

The used *.cas-file and a clipped-in-the-middle *.sortie-file is attached.
Also, our extract of min-max Courant-values is attached.

The model in general is setup with a time-space-varying precipitation and a water level condition at the outlet. Initial conditions describe a tiny lake at the outlet matching the specified water level-BC, the rest is dry.

We are grateful for any hint.
Thank you so much.

Nico

... illegal file ending *.sortie.
So, here's the *.sortie.txt file

Sry,
Nico

Hello Nico,

You write calculated Courant number every 5 minutes. It could be interesting to have the maximum for every time step.
To do so, I suggest you to run your computation again but with only L as VARIABLES FOR GRAPHIC PRINTOUTS and let default value for GRAPHIC PRINTOUT PERIOD = 1 (or comment the line).

After the end of the computation run:
run_telfile.py scan res_207999.slf --data
and upload the output here. You will be able to know the maximum L for every time step.

Chi-Tuan

Many thanks for your reply, Chi-Tuan!

Attached I you'll find the recommended output as txt-file (cropped a bit, but leaving max Froude and max Courant fully inside.)
I reduced simulated time to 900s so the output file does not explode
The FV-scheme maintains the given GRAPHIC PRINTOUT PERIOD as time interval. So, I can't provide every time step. Anyway, I think the density of information shows what happens.

Additionally, I changed the DESIRED COURANT NUMBER to a value > 1.0.
T2D forces CFL=0.9.
Doing so, I force a slightly different terminal output like extracted for an arbitrary time step given below.

What can be seen from the 'run_telfile.py scan ... --data' output is a continuous increase of CFL followed by an instant reduction (graphically displayed in the attached picture, for instance at t=318s). Max value is around 0.15 << 0.9.

================================================================================
ITERATION 835 TIME: 59.6087 S
WARNING: CFL NOT GIVEN OR >1 !...!
TIME-STEP (WITH CFL = 0.9): 7.6089627239755778E-002

---

DIFFUSION-PROPAGATION STEP
TIME-STEP: 7.6089627239755778E-002

---

BALANCE OF WATER VOLUME
VOLUME IN THE DOMAIN : 899.4041 M3
FLUX BOUNDARY 1: -0.1255820E-01 M3/S ( >0 : ENTERING <0 : EXITING )
ADDITIONAL VOLUME DUE TO SOURCE TERMS: 1.095295 M3
RELATIVE ERROR IN VOLUME AT T = 59.68 S : 0.5603365E-15


BTW: To avoid any confusion: We use v8p4r0 and we adapted HO in fricti.f according to Broich et al. (conf. paper from the TUC 2019). Our other user fortran changes are related to reading rain input and should not influence Dt or CFL.

Nico

Hello Nico,

In FV, TELEMAC is reducing the last time step to adapt the graphical output to the time asked.

For example, if the time-step is set to 10 second in the cas file and the graphic printout period is set to 10, you will have graphical output at exactly : 100s, 200s, 300s etc...
In the same example, let's assume that with a the CFL of 0.9, the computed time-step in FV is 3s, you will have a listing result every 3s : 3s, 6s, ..., 99s.
Then, to match with the exact value asked in the graphical output time of 100s, the next time step will be reduced to 1s (which will correspond to a CFL of 0.3 and not 0.9). But as the results of courant number are written in this reduced time step, you will have the courant number value of 0.3 in your result file, despite the fact that all the other time-step where computed with a value of 0.9.

In short, it is not relevant to write the courant number in the result file and the computation is really using the courant number set in the cas file, if inferior to 1 as specified in the warning message.

I am not sure to be clear in my explanation but let me know if you have any further question.

Best regards,
Florent

Hello Florent,

please accept my apologies for getting back to you so late due to holidays.

Your explanation is absolutely clear!

And with your argumentation, the step-wise changes of the residual Courant number from my illustration also makes sense: Since the size of the CFL-conditional time step changes gradually during the simulation, the residual time step also changes at each desired output interval. The jump occurs when the residual time step just exceeds the desired output time step.

Many thanks for the valuable assistance!

Cheers,
Nico