open TELEMAC-MASCARET The mathematically superior suite of solvers

Hello everybody!

I'm having some issues with a liquid boundary.

I'm working in a 2d model where I want to compute the dilution of a tracer discharged as an inflow boundary condition (from a new liquid boundary).
The original mesh of my model had 4 liquid boundaries. So I open a new boundary condition in the *.cli file, from this boundary I want to impose the discharged and later the tracer.

But first, I have to compute the hydrodynamic so that the steady flow is achieved.


My liquid boundaries are as follows :


FLUX BOUNDARY 1: Downstream (H prescribed, T free )
FLUX BOUNDARY 2: New BC, Rejet sédimentaire (Q and T imposed )
FLUX BOUNDARY 3: Canal sortie (Q et T imposed )
FLUX BOUNDARY 4: Canal amenée (Q imposed , T free)
FLUX BOUNDARY 5: Upstream (Q et T imposed )

I'm sharing my *.cli and *.cas files.


The first 5000s of the simulation runs smoothly but then the program stops after an error. I'm stuck in this part. The message I got is :

DEBIMP: PROBLEM ON BOUNDARY NUMBER 2
GIVE A VELOCITY PROFILE
IN THE BOUNDARY CONDITIONS FILE
OR CHECK THE WATER DEPTHS.
OTHER POSSIBLE CAUSE:
SUPERCRITICAL ENTRY WITH FREE DEPTH
IN THIS CASE GIVE A POSITIVE DEPTH
IN THE INITIAL CONDITIONS
OR PRESCRIBE THE DEPTH AT THE ENTRANCE.

So the problem is on the new BC(2), where I've imposed a discharge equal to 0.25 (m3/s). I don't know if it has some instabilities issues due to a having a very small discharge imposed in comparison with the discharged of 1200(m3/s) imposed upstream BC(5).


I've read that I could be because I don't have water on the boundary where I want to impose the discharge so Telemac cannot compute a result.

I've also read that this message occurs when the velocities or the depth on a boundary make a discharge equal to 0, where I prescribed a non zero discharge. Then the program cannot multiply the velocities by a constant to get required discharge.

I'm trying to solve it but without success. Can anyone give me a recommendation on how to deal with this error?

Hi
Could you check at the beginning of the listing file if the liquid boundaries are ok with your numbering.
With a such small discharge, this message will appear if the water height at the boundary become nul so you could check this in the result file...

Regards

Thank you for the quick response.

I didn't quite understand your suggestion. What do you mean by "if the liquid boundaries are ok with your numbering".

I'm copy-pasting the messages that I've got at the * END OF MEMORY ORGANIZATION: *


INITIALIZING TELEMAC2D FOR
INBIEF (BIEF): NOT A VECTOR MACHINE (ACCORDING TO YOUR DATA)
STRCHE (BIEF): NO MODIFICATION OF FRICTION

THERE IS 5 LIQUID BOUNDARIES:

BOUNDARY 1 :
BEGINS AT BOUNDARY POINT: 1 , WITH GLOBAL NUMBER: 443
AND COORDINATES: 40519.69 69474.50
ENDS AT BOUNDARY POINT: 16 , WITH GLOBAL NUMBER: 445
AND COORDINATES: 40697.31 69572.50

BOUNDARY 2 :
BEGINS AT BOUNDARY POINT: 608 , WITH GLOBAL NUMBER: 14706
AND COORDINATES: 37376.75 79228.50
ENDS AT BOUNDARY POINT: 610 , WITH GLOBAL NUMBER: 14708
AND COORDINATES: 37371.81 79237.00

BOUNDARY 3 :
BEGINS AT BOUNDARY POINT: 722 , WITH GLOBAL NUMBER: 32629
AND COORDINATES: 37556.31 79671.50
ENDS AT BOUNDARY POINT: 736 , WITH GLOBAL NUMBER: 32389
AND COORDINATES: 37526.19 79725.00

BOUNDARY 4 :
BEGINS AT BOUNDARY POINT: 938 , WITH GLOBAL NUMBER: 32101
AND COORDINATES: 37062.94 79778.50
ENDS AT BOUNDARY POINT: 944 , WITH GLOBAL NUMBER: 32097
AND COORDINATES: 37116.75 79813.50

BOUNDARY 5 :
BEGINS AT BOUNDARY POINT: 1058 , WITH GLOBAL NUMBER: 33664
AND COORDINATES: 37570.25 84178.00
ENDS AT BOUNDARY POINT: 1075 , WITH GLOBAL NUMBER: 33759
AND COORDINATES: 37277.06 84084.50

THERE IS 5 SOLID BOUNDARIES:

BOUNDARY 1 :
BEGINS AT BOUNDARY POINT: 16 , WITH GLOBAL NUMBER: 445
AND COORDINATES: 40697.31 69572.50
ENDS AT BOUNDARY POINT: 608 , WITH GLOBAL NUMBER: 14706
AND COORDINATES: 37376.75 79228.50

BOUNDARY 2 :
BEGINS AT BOUNDARY POINT: 610 , WITH GLOBAL NUMBER: 14708
AND COORDINATES: 37371.81 79237.00
ENDS AT BOUNDARY POINT: 722 , WITH GLOBAL NUMBER: 32629
AND COORDINATES: 37556.31 79671.50

BOUNDARY 3 :
BEGINS AT BOUNDARY POINT: 736 , WITH GLOBAL NUMBER: 32389
AND COORDINATES: 37526.19 79725.00
ENDS AT BOUNDARY POINT: 938 , WITH GLOBAL NUMBER: 32101
AND COORDINATES: 37062.94 79778.50

BOUNDARY 4 :
BEGINS AT BOUNDARY POINT: 944 , WITH GLOBAL NUMBER: 32097
AND COORDINATES: 37116.75 79813.50
ENDS AT BOUNDARY POINT: 1058 , WITH GLOBAL NUMBER: 33664
AND COORDINATES: 37570.25 84178.00

BOUNDARY 5 :
BEGINS AT BOUNDARY POINT: 1075 , WITH GLOBAL NUMBER: 33759
AND COORDINATES: 37277.06 84084.50
ENDS AT BOUNDARY POINT: 1 , WITH GLOBAL NUMBER: 443
AND COORDINATES: 40519.69 69474.50

CORFON (TELEMAC2D): NO MODIFICATION OF BOTTOM

TITLE OF PREVIOUS COMPUTATION: SAINT-ALBAN - REJET SEDIMENTAIRE - 2020

NAME: VITESSE U UNIT: M/S
NAME: VITESSE V UNIT: M/S
NAME: HAUTEUR D'EAU UNIT: M
NAME: SURFACE LIBRE UNIT: M
NAME: FOND UNIT: M
NAME: VITESSE SCALAIRE UNIT: M/S
NAME: VITESSE DE FROT. UNIT: M/S

READ_DATASET : READ OF RECORD 6

TIME OF RECORD: 5000.000 S
ELAPSED TIME RESET TO ZERO
RESCUE : K AND EPSILON WILL BE SET AGAIN



I'm also sharing the last time-steps of the simulation before it crashed. In this test I imposed a flow of 1 (m3/s) and not 0.25, it's still small and I've got the same message.



I understand that in t=4900s the BC(2) reaches a value of 1(m3/s) so it's fine.



================================================================================
ITERATION 4900 TEMPS : 1 H 21 MIN 40.0000 S ( 4900.0000 S)

---

ETAPE DE DIFFUSION-PROPAGATION
JACOBI: 5 ITERATIONS, RELATIVE PRECISION = 9.6741384986753537E-005
CVTRVF (BIEF): 1 SUB-ITERATIONS
JACOBI: 1 ITERATIONS, RELATIVE PRECISION = 7.9956652617232463E-005
CVTRVF (BIEF): 1 SUB-ITERATIONS
EQUNOR (BIEF) : 86 ITERATIONS, RELATIVE PRECISION: 0.9049774E-04
POSITIVE DEPTHS OBTAINED IN 10 ITERATIONS

---

MODELE K-EPSILON
CVTRVF_POS_2 (SCHEME 13 OR 14): 10 ITERATIONS
GRACJG (BIEF) : 7 ITERATIONS, RELATIVE PRECISION: 0.4030598E-09
GRACJG (BIEF) : 2 ITERATIONS, RELATIVE PRECISION: 0.5445068E-09

---

BILAN DE VOLUME D'EAU
VOLUME IN THE DOMAIN : 0.3471362E+08 M3
FLUX BOUNDARY 1: -1175.569 M3/S ( >0 : ENTERING <0 : EXITING )
FLUX BOUNDARY 2: 1.032786 M3/S ( >0 : ENTERING <0 : EXITING )
FLUX BOUNDARY 3: 130.2915 M3/S ( >0 : ENTERING <0 : EXITING )
FLUX BOUNDARY 4: -130.3861 M3/S ( >0 : ENTERING <0 : EXITING )
FLUX BOUNDARY 5: 1199.963 M3/S ( >0 : ENTERING <0 : EXITING )
RELATIVE ERROR IN VOLUME AT T = 4900. S : -0.2043825E-14

================================================================================
ITERATION 5000 TEMPS : 1 H 23 MIN 20.0000 S ( 5000.0000 S)

---

ETAPE DE DIFFUSION-PROPAGATION
JACOBI: 3 ITERATIONS, RELATIVE PRECISION = 9.6006425856561334E-005
CVTRVF (BIEF): 1 SUB-ITERATIONS
JACOBI: 4 ITERATIONS, RELATIVE PRECISION = 6.1513916741753912E-005
CVTRVF (BIEF): 1 SUB-ITERATIONS
EQUNOR (BIEF) : 41 ITERATIONS, RELATIVE PRECISION: 0.8729875E-04
POSITIVE DEPTHS OBTAINED IN 10 ITERATIONS

---

MODELE K-EPSILON
CVTRVF_POS_2 (SCHEME 13 OR 14): 10 ITERATIONS
GRACJG (BIEF) : 5 ITERATIONS, RELATIVE PRECISION: 0.1440933E-09
GRACJG (BIEF) : 2 ITERATIONS, RELATIVE PRECISION: 0.5198573E-13

---

BILAN DE VOLUME D'EAU
VOLUME IN THE DOMAIN : 0.3471641E+08 M3
FLUX BOUNDARY 1: -1115.383 M3/S ( >0 : ENTERING <0 : EXITING )
FLUX BOUNDARY 2: 0.6982021 M3/S ( >0 : ENTERING <0 : EXITING )
FLUX BOUNDARY 3: 130.3326 M3/S ( >0 : ENTERING <0 : EXITING )
FLUX BOUNDARY 4: -130.4015 M3/S ( >0 : ENTERING <0 : EXITING )
FLUX BOUNDARY 5: 1199.994 M3/S ( >0 : ENTERING <0 : EXITING )
RELATIVE ERROR IN VOLUME AT T = 5000. S : 0.1736707E-14
DEBIMP: PROBLEM ON BOUNDARY NUMBER 2
GIVE A VELOCITY PROFILE
IN THE BOUNDARY CONDITIONS FILE
OR CHECK THE WATER DEPTHS.
OTHER POSSIBLE CAUSE:
SUPERCRITICAL ENTRY WITH FREE DEPTH
IN THIS CASE GIVE A POSITIVE DEPTH
IN THE INITIAL CONDITIONS
OR PRESCRIBE THE DEPTH AT THE ENTRANCE.

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




I

Sometimes, depending on the location of the first node, the order in the cli file is shifted...
But it's not your case...
The crash occur after 5000s and before 5100s...
So, with the hot start at 5000s, print all time steps and check the water height at the boundary

Hello,
Until you get an answer from a liquid boundaries expert, I would suggest to run another computation that stops just before the error occurs, i.e, for the first 5000s.
Then you can inspect the results which may give you a good indication to the source of the error.
Costas

I did that. I've run a 5000s simulation. Then I observed that the hydrodynamics reach the steady state.

But when I do a continuous computation with it. The new calculation also crashes with the same message.