open TELEMAC-MASCARET The mathematically superior suite of solvers

I was using version v8p2r1 and all my models ran perfectly well.
Almost always, I prescribe open boundaries with free depth and velocity (4 4 2).
I have now switched to version v8p4r0 and am getting ILL-POSED boundary errors.

The boundary inflow is positive, though it should be negative because the only source is rain.
The mass balance printed at the end is therefore incorrect.

I understand there are plenty of discussions on ILL-POSED boundary problems on this forum, but I would like to know why v8p2r1 runs smoothly and v8p4r0 does not. Every single model I try to run now displays the error above. Has there been any major changes?

I have attached a small example along with the .cfg and .cas files for those willing to verify this issue. Thanks in advance.

PS: I also tried v8p4r0_breach version, to no avail.

I tried it again with v8p5 and the issue remains.

However, I was able to get reasonable results without any errors by setting the boundary conditions to (5 6 6).
With:
Prescribed depth HBOR=0.0
Prescribed velocity LIUBOR=0.0, LIVBOR=0.0

This setup ran well without having to set thompson boundary conditions. Does anyone have any thoughts on this approach? Is it correct and is there room for improvement?

The main issue I wanted to raise is that we have A LOT of models using (4 4 4) BCs which are now broken for versions upward of v8p2r1. In a sense, there is no backward compatibility of boundary condition settings. (This might be a large pitfall for users)
I feel like using (4 4 4) should be usable out-of-the box as it was before without causing these issues.

I am providing an updated test case for those willing to verify. The one I provided before seems to have some encoding errors in the mesh.

Hello,

Sorry for the delay to answer. I needed some discussion with colleagues who better know what is implemented in Finite Volumes part.

Since release v8p3, there is a splitting of VOLFIN subroutines to give the right time step to source terms and Thompson boundary conditions. This may explain that results have changed.

Hard to say if results with v8p2 were really good but the change was mandatory (otherwise the time step was not good one).

Hope this helps,

Chi-Tuan

Thanks for the explanation.

What is then the correct way to prescribe free and open boundary conditions? Does the approach from my previous message where I set the boundaries to (5 6 6) with HBOR=0.0, LIUBOR=0.0 and LIVBOR=0.0 make any sense?

Hello

To set free boundary conditions, use the code 4 (= free) for every variable you want to let free.
With 5 6 6 codes with HBOR = 0., UBOR = 0., VBOR = 0., you prescribe elevation or water depth + horizontal components of velocities to 0. which is really different from free conditions.

You could also try to use Thompson boundary conditions (OPTION FOR LIQUID BOUNDARIES = 2).

Hope this helps,

Chi-Tuan

Thanks for the timely response,

The reason I opened this topic was because free and open boundary conditions (4 4 4) are not working as expected. Since then, I have tried (I think) every possible BC combination. Including thompson and soft BCs.

Here is a recap of the results I have gotten so far:

Free and open BCs (4 4 4): I get the message 'ILL-POSED PROBLEM, ENTERING FREE VELOCITY'. There is also a positive inflow into the model which is wrong since there should only be outflow. This is a pluvial model with rain as the only source. Water should be flowing out of the boundaries not in. Using Thompson BCs has the same effect except it takes longer because the timestep is reduced drastically.

Free H and prescribed U=0,V=0 (4 6 6): Model runs without errors or warnings. There is, however, still some inflow into the model from some boundary points. (Bad)

Free H and prescribed discharge U=0,V=0 (4 5 5): Same as (4 6 6)

Prescribed H=0 and free U,V (5 4 4): Results look quite good. Only outflow takes place. All velocity vectors at the boundary are pointing outward. The solver somehow adjusts the H values at the boundary nodes to values > 0. Good. If I turn off friction, however, I get:
CDL_FV: WARNING, LIQUID BOUNDARY 1
SUPERCRITICAL OUTLET
DESIRED BOUNDARY CONDITION MAY BE UNSATISFIED
FROUDE AT BOUNDARY IS: 2.102055
because the outflow is leaving the model with higher velocities. The Fr number is between 1-2.Ok, this is just a warning so I would be fine just ignoring it.

Prescribed H=0 and velocity U=0,V=0 (5 6 6): Exactly the same as with (5 4 4).

Prescribed H=0 and discharge U=0,V=0 (5 5 5): Exactly the same as with (5 4 4) and (5 6 6).

So currently I think either (5 4 4), (5 6 6) or (5 5 5) meet the needs of my model and yield acceptable results. However, I would have prefered just using the more intuitive (4 4 4) BCs (Which also worked perfectly fine up to version v8p3). I encourage you to check out the model I attached 't2dissue_2024-02-21.zip' and see if there is maybe a better way. I would like to hear your thoughts on this.

Thanks in advance.

Hi,

I'm not rainfall/runoff specialist... and not finite volume experienced user... but for me, 4 4 4 doesn't make sense.

4 4 4 doesn't work as you expect... and as it use to work (based on you experience)

4 4 4 should work for supercritical boundaries... with small time steps.

If you don't have information on boundary condition, I'm not sure 4 4 4 can do it for you.

In reality, runoff is probably collected by a river (or usually dry talweg) network and you should at least avoid 4 4 4 everywhere. If water leave the domain with subcritical outflow... you need to give information on free surface elevation... even if you don't know what.

1- You should replace 4 4 4 by 2 2 2 (solid boundary... even it doesn't look like solid boundary (vertical wall)) where water is not supposed to flow out of the domain.
2- For liquid boundary, you should try 5 4 4 providing a value (constant in time imposed by keyword in steering file for example... or a rating curve) with no influence in the domain. This value must be large enough to let water flow out...

Alexis