open TELEMAC-MASCARET The mathematically superior suite of solvers

Hello,

We're using v6p3r2 (gcc/gfortran 4.9.2, OpenMPI 1.8.4, ...) and encountered a problem when using SISYPHE.

Running TELEMAC in debug version (including -fcheck=all) shows (see attached file debug-log.txt)

Without debug mode (see attached file nodebug-log.txt), the computation starts but crashes

Does there exist a fix for this in v6p3r2? Because of KNOLG and KNOGL variables in our additional Fortran files, although not being used for this specific example, we're still using that version.

Thanks in advance!

Regards,
Stefan

Hello,

This is a well known problem of Metis, that I have with Intel compiler. The work around I use is to compile all the system with the debug and checkall options, then recompile only the library partel without checkall (I do this in Perl with two commands in the sources, after modifying the file systel.ini and the command cfgmak : "maktel menage", and then "maktel all install", it is certainly possible also in Python).


The crash in the module Streamline is something else, possibly a bug now corrected, since nobody reported this in recent versions.

With best regards,

Jean-Michel Hervouet

Hello,

I just tried using following setup: TELEMAC v7p1r1, GCC/gfortran 5.4.0, OpenMPI/1.10.3
I get (apart from the addresses) exactly the same backtrace, so is there something wrong with streamline, which only pops up in particular cases? Any ideas? Thanks!

Regards,
Stefan

Update (running the debug version)

|At line 749 of file /opt/TELEMAC/v7p1r1-foss-2016b/sources/utils/bief/streamline.f
|Fortran runtime error: Index '1051' of dimension 1 of array 'heapchar' above upper bound of 1050

Hello,

I can try to reproduce the problem but I cannot download the case, it says:

You don't have permission to access /media/kunena/attachments/8640/example.tgz on this server.

I tried on 2 different machines and always get this. Maybe you post it again or put it at a different adress.

With best regards,

Jean-Michel Hervouet

Let's try again!

Hello,

Thank you but... definitely not... I'll see if I can get it from my colleagues and will report.

With best regards,

Jean-Michel Hervouet

Hello,

I now looked at your case. What happens in streamline is that we cannot predict the number of characteristics going to a sub-domain, we just try to overestimate it, and in your case this estimation is too low. In the next version 7.2. I have added an error message and possible solutions when this happens. Anyway forget streamline, this is not your main problem and I do not recommend to use the method of characteristics for advection of suspended sediment.

In fact I had to clip the depth in your subroutine dragfo.f, otherwise there is immediately a division by zero, due to dry zones.

Then I would suggest at least the following changes :

On Telemac-2D side, add:

MASS-LUMPING ON H : 1.
TIDAL FLATS : YES
OPTION FOR THE TREATMENT OF TIDAL FLATS : 1
TREATMENT OF NEGATIVE DEPTHS : 2
TYPE OF ADVECTION : 14;5
SUPG OPTION : 0;0
CONTINUITY CORRECTION : YES

in the steering file. This is to enable a correct use of the NERD advection scheme in Sisyphe, by just adding in its steering file:

TYPE OF ADVECTION : 14

Your case will go to the end. However I find in the listing large C.F.L. numbers for the suspended sediment, maybe reducing the time step would be a good thing.

With best regards,

Jean-Michel Hervouet

Hi Jean-Michel, thank you for your response. I'm taking over since this seems to be related to the application. Stefan is responsible for the HPC infrastructure of our university.

Your suggestions seem to have solved the problem, even though I'm still doing further tests to understand.

What I am still surprised is that the problem does not arise with the original setup and 2 or 4 cores. Only when doing the simulation on 20 cores. If I understand your answer correctly, it's related to the streamline functionality that is not really suited for our application, am I right?

You're right for the clipping of the water depth in dragfo. How small can be the threshold in your opinion?

Regarding the CFL condition, how do you express it for transport of sediments? Is it also Co = v dt / dx < 1?

Hello,

Yes it is normal statistically that there are more problems with more cores, the problem arises when a sub-domain receives more characteristics pathlines than the maximum number of points in a sub-domain. With a well decomposed mesh this is about the number of points in every sub-domain. The mesh may be built with a refined zone (your case) where all characteristics go in another domain, and we are already at the limit. The only secure implementation would consist in allocating arrays with the size of the initial mesh, which would ruin the advantage of parallelism. Anyway such situations always mean that the CFL number is very large and it is not recommended.

Yes for sediment the CFL number is also Co = v dt / dx. It seems that there is a high value somewhere in your mesh, maybe on the refined zone.

For clipping the depth in dragfo, you can use 1.D-3, or a limit corresponding to the grain size of the sediment.

With best regards,

Jean-Michel Hervouet