open TELEMAC-MASCARET The mathematically superior suite of solvers

Hi all,

Mid-way in my simulation I'm receiving the error for inter-crossing planes below, where the differences between the meshes are very small and occur at the boundary:

FLUX BOUNDARY 2: 0.7750000 M3/S ( >0 : ENTERING <0 : EXITING )
CALCOT: PLANES 4 AND 5
INTERCROSS AT POINT 5
LOWER POINT : 0.63383130114213038
HIGHER POINT: 0.63379595547197976
DIFFERENCE : -3.53456701506216220E-005
DEPTH : 2.92930866075214701E-002

PLANTE: PROGRAM STOPPED AFTER AN ERROR
RETURNING EXIT CODE: 2

The guilty point changes with each simulation. I'm using the tidal flats options below:

TREATMENT OF NEGATIVE DEPTHS : 2
TIDAL FLATS = YES
OPTION FOR THE TREATMENT OF TIDAL FLATS : 1

as recommended elsewhere on the forum to avoid problems with the mesh.

I've tried increasing the initial depths and the time-step but it doesn't change anything.

My MESH TRANSFORMATION = 0, as I prescribed a few of fixed layers at the bottom in CALCOT. I then changed the references to the bottom in CALCOT to the top-most layer of my prescribed layers, creating an artificial bottom. I did this in all sections, so that sigma transformation occurs between the new bottom and NPLAN, and the code assigning DISMIN also treats it as the bottom i.e.

The error states that the problem comes at the intersection between layers 4 (i.e. the new bottom) and the layer above it. However i'm not sure how this can be given that I stated layer 4 to be treated as the new bottom and so DISMIN should be applied as per the code above.

My simulations using the above code have worked fine when using coarser and more refined meshes, but for this mesh (0.2m, 24 layrs) it seems not to work! Does anyone know what might cause Telemac to crash in such a way given the above?

Re-visiting this it looks like the issue is related to mesh quality - large deformations in the mesh at the inlet caused meshes to clash. Generating a new mesh seems to have reduce this however I still get spikes in the corners.

This doesn't occur in my coarser/more refined meshes. The only thing I changed that seemed to have an impact was the sampling of the mesh boundary. Adjusting nodes doesn't seem to have much an effect. Results downstream seem fine but I want to avoid crashes in the future when long-term model runs begin in case the spikes might exaggerate again.

Does anyone have an idea of what might cause them more specifically?

Hi,

I just encountered the same problem as you did. In my case, the plane 1 and plane 2 is inter-crossed.

I solved it by modifying the code in subroutine calcot,f. The problem is that, due to certain reason, the elevation of the beneath layer at some point is higher than the above layer.

In the subroutine calcot.f, there is already a part for correcting this error (part 5). But this correction is below the place where the code saying stop the calculation (part 4). All you have to do is move part 4 to the bottom and make sure the correction works before calling STOP. Another thing is that, you have to change "IF(NPLAN.GT.2.AND.MIN_DZ.GT.0.D0) THEN" to "IF(NPLAN.GT.2.AND.MIN_DZ.GE.0.D0) THEN". In this case, the higher nodes will have the same elevation as the lower ones since MIN_DZ=0 by default.

The modified codes is attached and it works for me, for the moment (the simulation is still running...).

@Developers: If this is the right way to solve the issue, is it possible to add to the next release? Or there is a better way to solve it?

Kind regards,
Qilong

Update: I found another fix, which requires less modifications in the code.

The original code in calcot.f from line 154 to 158 is like:

I changed it to

so the above plane will not be lower than the beneath layer. It works in my case as well.

Qilong,


that is a typical problem you get when source points in the model become dry. I saw the same problem using culverts when I misplaced a source point on a dry node of my mesh.
The buse.f subroutine checks for available water and if the point is dry it sets the discharge to zero, but I never looked into the fact that planes could crush into each other. We should find out if we can prevent this from happening so a simulation could go further without producing NaN values.

Kind regards,
Sven