open TELEMAC-MASCARET The mathematically superior suite of solvers

Hello,

I run a Tomawac-Telemac2D-Sisyphe coupled simulation. I have specified a non-erodible bed and initial bed composition by modifying noerod.f and init_compo.f.

At first I was running the simulation fine using non-erodible bed and uniform sediment. As soon as I defined sediment availability with init_compo.f (10 sediment classes), I run into errors that are attributed to the LAYER subroutine. I have enabled some troubleshooting code within the LAYER subroutine and I come across with errors similar to this:

Here are my fortran and sisyphe cas files:





I have already found that a high morphological factor intensifies the problem, but I would be grateful if I could have some more insight into the nature of this error.

Best regards,
Costas

Hello,

Normally the sediment height should remain positive, this is why layer.f stops. Positivity of sediment height is ensured in bedload by the finite element option and the treatment of Exner equation by the bief subroutine positive_depths, so there remains to understand why you get this (very slightly) negative value (finite volume option ?). I do not see any mistake in your subroutine init_compo.f, except that you should give double precision numbers. If you do not fine your whole case would be necessary to test it here.
You can also try to bypass the stop in layer.f.

With best regards,

Jean-Michel Hervouet

Hello JM,

Thank you for your prompt reply. I will start with double precision in inti_compo.f and proceed with the other options one by one and provide some feedback.

Best Regards,
Costas

Hello Costas,

since I have been running also in layer problems..

Could it be perhaps that the error comes from the compilation of Telemac itself? So that e.g. with Gfortran and using optimization flags like -O3 truncation errors are induced?

I'm not that skilled in Fortran and so I don't know if it is worth to investigate in this direction, e.g. by turning off the optimizations.

I didn't try this and before doing this I would wait maybe for an answer from the developer front.

Best regards,
Clemens

Hi Clemens,

That is a good point. In fact I am currently using the -Ofast optimization which is more aggressive. Never thought that it could be a potential cause of errors. I will compile a version with less optimizations to eliminate any possibility.

Costas

Here are the results so far:

1. Specification of double precision seems to correct the problem regarding the occasional "ERROR IN LAYER" message. Now the computation halts at some point after "LAYER AFTER BEDLOAD" in written on the debugger log.

2. Changing the optimization flag did not seem to have any effect at all (I had already corrected the double precision in AVAIL definitions).

3. Specifying Finite Volumes in Sisyphe (and changing advection scheme to 14) won't complete even the first timestep. Specifying FV in Telemac2D as well, presents this strange message:
It is the first time I have used Finite Volumes. Am I missing something?

Costas

Hello,

This is OK for finite elements in Telemac-2D (and you just unraveled a possible problem of FV in Telemac-2D when coupling with Tomawac, probably that variable time step will not work), I was just mentionning the two options in Sisyphe, for the Exner equation. : keyword "FINITE VOLUMES", yes or no, default is no.

Regards,

JMH

Hello JM,

At first I had specified FV in Sisyphe only, but the computation wouldn't pass the first timestep and I though it might be necessary to change in Telemac2D as well. Still with FV in Sisyphe and FE in Telemac2D, the halt at the LAYER subroutine occurs at the first call ever. In FE at least it could do 80K timesteps.

Is there any point trying to bypass the stop in LAYER now that the error is "somewhere in LAYER" and not specific to "BAD DATA IN LAYER"?

Does the morphological factor (potentially) affect the error occurrence, other than the fact that the rigid bed is reached sooner?

Regards,
Costas

Hello,

So FE on both sides seems to be the best. I did not look at the morphological factor but it could be a reason (I do not know how the positivity of sediment height is kept when the evolution is multiplied by a factor). Anyway the problems in layer are often only a problem of truncation error (certainly your case if it works 80000 steps), and there is an epsilon in layer.f which is rather strict and that you can change. The only problem is that as soon as you allow a tolerance, this tolerance will be reached sooner or later if you do long runs.

Regards,

JMH

Hello,

I did not understand what you mean with 'epsilon' in layer.f. Is it the ZERO tolerance used check that the AVAIL for all classes sum up to 1?

Costas