open TELEMAC-MASCARET The mathematically superior suite of solvers

I have a TELEMAC3D-GAIA coupled computation and have set in TELEMAC3D steering file the following parameters (including a graphical output at time 0):According to GAIA manual, time stepping and GRAPHIC/LISTING PRINTOUT PERIOD is taken from the TELEMAC3D steering file. At the end of the computation, I get 7 frames of results in both result files (1 at time=0 + 6 more as one would expect with a printout period of 1200s).
In TELEMAC3D results, at step 1 (which time defaults at 1900/1/1 0:0:00) I get, as expected, zeros everywhere.
In GAIA results, at step 1 (which time reads 0 days 00:19:58) I get results in sediment transport and bed evolution, which is not something one would expect at time=0. A closer look at the time indicates that the first result occurs at the first GRAPHIC PRINTOUT time - the TIMESTEP (1200s - 2s). After that, the subsequent results are printed correctly at 1200s intervals (i.e. 00:39:58, 00:59:58, ..., 1:59:58) except the LAST one which is printed 2s after the previous one at 2:00:00.
Setting aside the time offset in the results, GAIA is fully coupled with TELEMAC2D/3D and one would expect the same treatment for time (absolute vs duration).

Costas

Dear Costas,

I am also running Gaia coupled with telemac3d. I just checked again but I got the same output times for the gaia file and the telemac3d file.
I am using NUMBER OF TIME STEPS instead of DURATION. Maybe this makes a difference? You could try it.
I remember that I had the same problem you describe here with an older version. I am using the squalius branch. Which version do you use?

By the way the 6 outputs are correct, as you have 2s timesteps, so your number of time steps is 3600 and a graphic printout period of 600 gives 6 output (+ 1 for the initial conditions). The graphic printout period is not in seconds but in parts of number of iterations.

Best regards,
Rebekka

Hello Rebekka,
Thank you for your quick reply. I am using the trunk (2 commits behind ATM) but updated my squalius branch and tested with it as well. Explicitly defining TIMESTEPS instead of implying them with DURATION does not make a difference in both.
I did not mention that I my computation is in fact a TOM-T3D-GAIA 3-way & 3D (TOMAWACT3D) coupled computation. TOMAWAC has a 2.0s timestep as well. Could that be a reason for this issue? I tried taking TOMAWAC out of the question but I have a hard time (quickly) forcing my model with wind only.
Costas

Hello Costas,
Thanks for raising this issue. I have had exactly the same problem with TELEMAC3D recently using a fairly recent checked out Squalius branch. I think it must be a problem with T3D. I will check if it has been fixed in the latest trunk version or whether it is still an issue.
Regards
Tom

Hello Tom,
I checked with the trunk before squalius and it is the same. The interesting thing is that I am unable, so far, to replicate the issue with the GAIA examples that are coupled with T3D (bosse-t3d & hippodrome-t3d). I even tried a 'hybrid' case between TOMAWAC's 3DCoupling and hippodrome to test with 3way coupling.
So it could have something to do with the computation specifics, like boundary condition timeseries etc.
Costas

Hello Costas

Yes I think you might be correct. I have only just recently noticed this and it seems to not always happen.

I have got a very simple test case which just uses TELEMAC3D and I do get the problem. The case does not have a boundary condition file (it uses just a PRESCRIBED ELEVATION).

I will investigate a bit more and raise the issue as a ticket.

Tom

Hello guys (and Rebekka),

Can you share an example to try to reproduce your problem? A simple one would be the best. I am not sure to have a lot of time to investigate, but maybe I can help.

First, could you send your steering files, please.

Chi-Tuan

Hello Chi-Tuan,
My case is a real application with nested models and complicated boundary conditions thus harder to troubleshoot. If Tom's example is simpler, it would be preferable.
However, if you like, I can make a package of a working directory with all files.
Costas

Good Morning Costas and Chi-Tuan

I realised that my problem in the simpler test case was unrelated (I had made a mistake, sorry for the confusion).

Costas - if you could try to package together a test that reproduces the problem that would be great.

Many thanks
Tom

Hello,

Costas, it seems that your example is the only one to reproduce your issue. So you can send it to us (whole package to be run).

And you can already send your steering file + FORTRAN files.

Chi-Tuan