validation procedure hangs vnv_ritter test case with kinetic scheme

Summary

When running the validation procedure, the test case vnv_ritter using the kinetic scheme, all of sudden (after 1.025 s) determines a time step of 1e-16 in the automatic time stepping. This leads to a very long run times and output files (I killed the validation after a file of 1.5TB was generated).

Environment

  • Operating System: LINUX
  • TELEMAC version: trunk ddf21bc9

Steps to reproduce

The bug occurs when using optimized production compilation options (see $SYSTELCFG):

image.png

When running with debug settings (without optimization), the problem does NOT occur.

validate_telemac.py --report-name validation.csv -b  

What is the current bug behaviour?

A wrong time step (1e-16) is calculated

image.png

What is the expected correct behaviour?

It is expected that the time step remains more or less constant

Relevant logs and/or screenshots

see above

...

Possible fixes

I have had a further look. The problem exists in the subroutine caldt.f. This routine calculates a correct time step (around 1D-3 s), but then tries to adjust the time step to correspond to a moment of graphic output. there is a check that this number should be above 1D-16. In my case it is 1.1D-16, so the check does not work. Changing the hardcoded number from 1.D-16 to 1.D-15 solves the issue for now.

223 !       ADAPT DT TO TAKE INTO ACCOUNT GRAPHIC OUTPUT
224 !       ONLY FOR ORDER 1, ORDER 2 WILL BE DONE IN RESOLU
225         IF(SORDER.EQ.1)THEN
226           IS=CEILING(AT/GPRDTIME)
227           RESTE=IS*GPRDTIME-AT
228 ! imdc-abr. changing the code such that reste is larger than 1d-15 instead of 1d-16 solves a model hanging indefinitely and generating a TB of data.
229           IF(THEEND.OR.
230      &      (RESTE.LE.DT.AND.RESTE.GT.1.D-15.AND.LT.GT.PTINIG))THEN
231 !           HERE THERE IS GRAPHICAL OUTPUT
232             LEO = .TRUE.
233             DT=MIN(RESTE,DT)
234           ENDIF
235         ENDIF

However, it seems that there is a more substantial problem here, which should be looked at in more detail.

(Maybe introduce a user-defined minimum time step, or a user defined threshold for how much time steps may differ).

Edited by Alexander BREUGEM