open TELEMAC-MASCARET The mathematically superior suite of solvers

Dear TELEMAC Community,

I am getting quite desperate because what I initially thought would be a simple channel simulation is taking much more time than expected.

First, about the case: It involves a trapezoidal channel with a length of 90 m, a bottom width of 4.33 m, and a bankfull water depth of 0.178 m. On both sides, there are floodplains that remain dry throughout the simulation. The discharge is steady at 0.499 m³/s, and the material is homogeneous with dm=1.2mm.


I created an initial condition file with a water depth of 0.178 m in the channel and a channel velocity of 0.598 m/s. The upstream boundary is defined by the discharge, while the downstream boundary is defined by the water surface elevation. The purpose of this file was to prevent a floodwave (which occurred without it) and to ensure the boundaries are wetted.

The issue: I am experiencing a strange, jet-like inflow at the upstream boundary on the right side. From what I can tell, my geometry and boundary condition files do not contain any irregularities. I have tried adjusting various parameters in the steering file, testing different advection schemes and velocity profiles, but I have not been able to identify the cause of the problem. My experience with TELEMAC-2D is limited, so it is possible that I have made a fundamental mistake.
www.transferxl.com/download/08v7h1rj8JFWmD this is a folder with the .slf files.

Thank you in advance for reviewing my files. I hope someone can provide some insights or suggestions!

Hi Debora,

I took a quick look at your files and here are some ideas :
- You have negative y and negative z in your geometry. I never test with negative y but negative z causes filling with water all elements below 0 (see pictures).
Initial time :


First timestep :



- In your .cas you can remove the DISCRETIZATIONS IN SPACE which is not needed.
- If you really can't make it, you can also try a finite volume approach, which takes longer to calculate but is more stable.

Hoping you make it!

Thank you for checking my files!

It was actually the negative y-values that made the difference! Now the velocity is a least homogeneous at the upstream boundary.

Oh great! Well done

Dear all,

Well, I thought my problem was solved. But I still have unstable behaviour at the upstream boundary. I have tried many different things including changing the initial conditions, velocity profiles, variable time step on/off and mesh resolution.
I only get a stable inflow when I have a prescribed height and discharge with 5 5 5, but as this can lead to numerical instability I would prefer not to use it. Attached and in the link are the files I'm currently using.
www.transferxl.com/download/08rtP2L3PdKvW

I would appreciate it a lot, if you have some feedback!
Thanks!

I tried to increase MAXIMUM NUMBER OF ITERATIONS FOR ADVECTION SCHEMES to 1000 to vanish the warning messages. The results are better, but we're not there yet.

Did you try to set a TYPE OF ADVECTION for k-e model ? According to #19046 it could work.

If nothing work, you can still increase the length of your flume to let the instabilities stabilizing before reaching your zone of study. This is not a solution but it's still a way to dodging the problems...

Let me know if you find it!

Kindly

Hello Debora,

Why do you mesh the floodplain if you are sure they remain dry?- In that case it is useless and you will save computation time.

In your mesh, particular areas should be more refined than others to my point of view: the areas where you have the biggest bottom gradients: the slopes.
Here, you mesh a rather homogeneous discretisation.

If I were you, I would start from a coarser mesh in the deeper part of your channel, refined mesh on the slope (perhaps 2 times what you did, around 10 triangles) and exclude your floodplain.
It would then be easier to debug.

I would adapt the time step to your mesh resolution (see Courant number), perhaps decrease it.
I would also start with FREE SURFACE GRADIENT COMPATIBILITY = 0.9 or less (0.5 or even 0. if it helps).

If you have to increase MAXIMUM NUMBER OF ITERATIONS FOR ADVECTION SCHEMES to a value greater than the default value (50), e.g. more than 100, you should understand why. First test is to decrease the time step but if it does not solve, investigation is to be done.

I am not sure that your initial condition fits well what you want. You can keep what you did for the free surface but with a 0 velocity + use a LIQUID BOUNDARIES FILE to prescribed a linear flowrate at the entrance from 0 to 0.499 during a short period of time (and then = 0.499 after). See e.g. $HOMETEL/examples/telemac2d/canal/t2d_canal.qsl

Hope this helps,

Chi-Tuan