open TELEMAC-MASCARET The mathematically superior suite of solvers

Hello,

I've noticed that when VARIABLE TIME-STEP=YES is used, that Telemac-2D does not write out the last time step to the results file. It writes out the results according to the GRAPHIC PRINTOUT PERIOD interval, but it won't write out the last time step (unless by coincidence it matches one of the periods written out because of GRAPHIC PRINTOUT PERIOD). Thus the last time step written out is usually before the DURATION called out for the model. The user manual states that "the last time step is systematically saved" but that does not seem to be the case when variable time steps are used.

I've tried a workaround, specifying the NUMBER OF TIME STEPS instead of DURATION but this option does not seem to work when variable time steps are used. (the model will only run briefly and then quit).

I end up having to set GRAPHIC PRINTOUT PERIOD not too high, so that the last written step will not be too far from end of the run. This leads to heavy disk I/O and really large results files. In many cases I'm only interested in the last time step.

Another approach to reduce disk I/O and file size, setting NUMBER OF FIRST TIME STEP FOR GRAPHIC PRINTOUTS, does not work too well either. That approach will delay a fixed number of time steps from being written to the results file, but with variable time steps, I don't know how many time steps there are going to be. There's a lower bound of DURATION / (TIME STEP) steps, but it could be much higher.

I modified one of the Malpasset example runs to show the issue. The input files are attached. The only changes I've made to the originals is that I renamed the .cas file, and in the .cas file I've commented out the following lines:

/NUMBER OF TIME STEPS = 1000
/TIME STEP = 4.

And added these 4 lines:

TIME STEP = 10.
VARIABLE TIME-STEP=YES
DESIRED COURANT NUMBER=8
DURATION=4000

Note that GRAPHIC PRINTOUT PERIOD for this run is 50. The objective of this modified run is to get large enough time steps to demonstrate the issue, thus the high Courant number target. When I run it, the last time step written is not at 4000 or later, but earlier, at 3672 seconds.

I was wondering if anyone had a workaround or knew how the Fortran code could be modified to write out the last time step. Aside from this bookkeeping issue, Telemac-2D has worked very well for me.

Hello

Which version of Telemac are you using ?
Actually, variable time step is often used with finite volumes. With finite elements, it is used in order to test mesh convergence by setting a fixed Courant number (of 1 for instance) and then refine the mesh. In that case, Telemac will adapt the time step accordingly.
I did not see your case, however, I see that you have chosen a Courant number of 8 which is really high and thus could represent a case which is not handled properly by Telemac. I'll see.

with kind regards

Riadh ATA

Thanks for your response. I'm using v7p2r0 the latest official release. I've compiled it under Ubuntu 16.04 and the standard gfortran from the repository. I did not compile in the mpi multi-processor routines.

The Courant 8 target was chosen to exaggerate the issue. Even if had chosen 1 as the target Telemac 2D would still not have written the last time step. A larger value for the GRAPHIC PRINTOUT PERIOD would have accomplished the same effect of increasing the likely time gap between the last time written and the last time step actually calculated. Unless the GRAPHIC PRINTOUT PERIOD is 1 there is no assurance the last time step will be written.

My models are finite element and I find the Courant number target useful. I usually set the target at 1.0. Unfortunately the program won't write the last time step.

Hello

You will find here attached a patch that fixes the problem of listing and graphic output in case of variable time step. The patch deals with 2 subroutines:
1- subroutine preres_telemac2d.f that you can add to you fortran file
2- subroutine telemac2d.F which is a big one and thus it is not recommanded to add it to the fortran file. In your subroutine telemac2d.f (sources/telemac2d) at line 1646 add the folliwing lines
! for final time step
IF(DUREE+AT0.GT.AT)DT= MIN(DT,DUREE+AT0-AT)

and at line 1691 add the following

ENTET = LISTIN
TOTAL_ITER= NIT
Do not forget to recompile the sources !
I will add this fix to the next stable version and to the trunk.

with my kind regards

Riadh

Wow, fantastic! Thanks so much.

I had some issues patching the v7p2r0 files, so I download the trunk (Revision 9641). It did not appear to have your changes yet so I dropped in the two Fortan files you posted into the "sources/telemac2d" folder (except changing the extension of telemac2d.f to telemac2d.F as it appears in the sources, in case that makes any difference). Probably the next revision will already have your changes. I compiled that and it worked great. If I'm later able to patch the v7p2r0 sources later, I'll post the revised Fortan files for the v7p2r0 release and the diff output.

What your patch appears to do is that it truncates/shortens the last (variable) time step, to prevent it from overshooting the DURATION, so that end time of the run is exactly equal to initial time (usually 0) + DURATION. So if I set DURATION=2000 for example, if the initial time step is 0 then the last time step will complete at exactly 2000 seconds. And then it writes it out the last time step to the results file. If GRAPHIC PRINTOUT PERIOD is higher than DURATION then it looks like only the initial and final time steps are written to the results file.

This is great! Thanks again.

Yes You have anderstood allmost everything.
These patches will be in the next release and un the next stabilized version of the V7p2.

with my kind regards
Riadh

Hi, I am getting the same error as mentioned above. I can see that the changes riadh talked about are already there in v8p2. I have added the subroutine preres_telemac2d.f to fortran file, but most of the times the results file doesn't get written and the simulation stops with an error just before reaching the total duration.
Even 'telemac2d.py --merge -w' is not working to get the result file.

I have attached the input files and error files. I hope someone can help.

Thanks and Regards,
Nitesh

Hello Nitesh,

I think your problem is that data are missing in your BINARY ATMOSPHERIC DATA FILE after time 255,600 s, as you ask for a duration longer than this final time.

Hope this helps,

Chi-Tuan