DT variable with the FE kernel of telemac2d

Summary

Add variable time step compatibility with the Finite Element kernel of telemac2d

Why is this feature useful?

To ensure numerical stability under CFL condition, when such condition exist for the considered scheme.

How to implement it?

In telemac2d.F [l.543] there is a draft of CFL condition which is only valid for LEO, N and PSI schemes. There are several flaws in the current draft:

• CFL conditions are not defined for all scheme options
• LEO and graphical printouts are not modified, which leads to erroneous outputs (LEO should be based on AT not LT if DTVARI is .TRUE.)
• There is a range of DT variation which is limited in the bounds [1/2, 2]. This should be removed as it could be misleading (this does not apply strict CFL conditions.

The following modifications should be considered:

• Add a condition on the numerical scheme used for advection to adapt DT based on CFL conditions that are specific to each scheme
• Add a new keyword to apply simplified CFL conditions (based on wave speed of the SV system, similar to the FV condition). This could be usefull when CFL condition for the selected FE scheme are unkown or not well defined in literature. It would also allow direct comparison between FE and FV kernels.
• Update LEO base on AT (similar to what is done in caldt.f for FV schemes). With FV scheme there is an option to write results at closest time step or at required times (default), the same option should be used with variable time step in FE.

Additional resources

When DTVARI is activated (i.e., variable time step to respect a CFL condition), the code adapts DT at each time step according to the computed Courant number, but the variable LEO is not modified in this process.

What is LEO?

• LEO is a logical variable that controls whether graphical outputs (results) are written at the current time step.
• It is typically set to .TRUE. when a result output is required (e.g., at a regular interval, or at the last time step).

How is LEO managed in the code?

• At the start of each time step, LEO is set to .FALSE..
• The only place where LEO is set to .TRUE. is in the subroutine PRERES_TELEMAC2D, which is called at the end of the time step, and only if .NOT.ADJO.

Problem with DTVARI : When DTVARI is active, the time step DT changes dynamically, so the time at which outputs should be written (e.g., every hour, every day, or at specific times) may not correspond to a fixed number of time steps. However, the code still uses the counter LT and the interval LISPRD to decide when to output, which is only correct for constant DT.

• With DTVARI, the output logic should be based on the simulation time (AT), not on the time step counter (LT).
• The current code does not update LEO (nor the output logic) based on the actual simulation time when DTVARI is active.
• This means you may miss outputs at the intended physical times, or get outputs at irregular intervals.