open TELEMAC-MASCARET The mathematically superior suite of solvers

Hi,

I want to model a weir inside a river. As I got a lot of problems working with the big mesh, I tried a simple case to learn more about using the weir function. Unfortunately I also have no satisfactory results with the simple case. Especially the free surface upstream the weir is lower than downstream the weir. The points directly next to the weir (upstream side) usually fall dry at low water. Here some general information:

- I’m working with telemac version v6p3r2 (svn 4734).
- I’ve run the “weirs”-test case from the telemac examples. The results were okay.
- I run the cases in scalar mode to eliminate errors due to parallel mode.
- I tried several meshes (refinements). Not even the finer mesh cause better
results. (I attach the slightly more rough mesh, because here the computing time is far better.)
- I tried meshes with or without points between the rows of the weir (sidewise in flow direction).
- I tried different heights of the level of dike. A higher value causes more stable results (with the same free surface phenomenon), but I also want to calculate the flow over a deepened or nearly deepened weir. In the attached case I set the “level of dike” to 20 cm over the upstream bottom.
- The results are dependent of the time step, but a smaller time step does not automatically improve the results.
- I tried several numerical parameters but didn’t find a good adjustment.
- The files are all in French because translating the weir file into English caused the problem that the data content was not considered any more.
- If I run the case with an island instead of the weir (case without weir file) and suitable more inflow, the water flows round the island without any problem.

I would be glad getting some help!
Thanks in advance,
Beate

Hello

In your case, the elevations upstream and downstream the weir are equal, thus, following the weir law, there is no discharge that will cross the weir. What you are observing is only the instabilities observed due to the existance of the singularity in the geometry i.e. a lack of well-balaceness which can be explained that the code is probably unable to keep a lake at rest with options (numerical and physics) that you have chosen. To have a flowrate crossing the weir you have to start with different elevations upstream and downstream this latter.

with my best regards

Riadh ATA

Hello,

Thanks a lot for your reply!

According to your post I changed my initial conditions. I set up a previous computation file with an elevation of 59m upstream the weir and 58m downstream. I used two meshes with different refinements. The results changed a bit to my previous results, but the disagreements still remain. (The result files are attached. See therefore also the note below.)

1. Q_out is not equal to Q_in
There is a big difference between Q_in and Q_out. Q_out is greater than Q_in. Considering the free surface along the centre axis for the latest graphic printout time steps (time-series-R103_v01.PNG and time-series-R104_v01.PN; including the initial condition), the computations seem to reach steady-state. Why do the flow rate values differ that much nevertheless?

2. Why seems the free surface to be dependent of the mesh?
If I compare the results of the two meshes, I determine different water elevations (free-surface-along-centre-axis_R103-104_v01.PNG, dashed colored lines to illustrate the difference). The free surface of the finer mesh is lower than the free surface of the rough mesh. (The Courant numbers were – except directly at the weir - okay for both computations.)

3. Water elevation upstream the weir
If I consider the results of the finer mesh, assuming that these results should be the better ones, I would have expected the water level upstream the weir to be higher (free-surface-along-centre-axis_R104_v01.PNG with lines to illustrate the free surface gradient and the level upstream the weir).

Thanks in advance,
Beate

Note for the attachment:
test-f-mesh-3 (computation number R103) shows the slightly more rough mesh, test-f-mesh-4 (computation number R104) the finer mesh. As R104 is the continuation of R102 (R102 did not seem to be steady-state), I also attach the previous computation file of R102 and the appropriate cas-file.
The analyses were done at points along the centre axis (shown in picture centre-axis_free-surface-R104_v01.PNG with R104 in the background).

Here are the first attachments (all files together exceed the upload limit)..

As the result file for R104 is too large, here only the last time step.
I hope you can help me anyway.
Thanks in advance,
Beate

Hello,

This message just to give you a hint on the difference between Q_in and Q_out. You should have the keyword CONTINUITY CORRECTION : YES.

When you have a prescribed elevation (at an exit) the continuity equation is not solved at the points of the exit (it is replaced by depth=prescribed depth). So the discharge computed with the velocities obtained at the exit is slightly wrong. With continuity correction, the discharge at the exit is defined as the discharge that solves the continuity equation. In this case and with a steady state you will get Q_out = Q_in.

I hope this helps,

JMH

Hello JMH,

thanks for your quick reply!

In my cas-files I set CORRECTION DE CONTINUITE =true. Is this the adjustment you meant? Is there a possibility to check if it is really used? If it is used then that would mean I do not reach steady state. Is there another way to check if I achieve steady state or nearly steady state? If I have a look at the free surface (as shown in the pictures) I would expect less difference between Q_in and Q_out.

Thanks in advance,
Beate

Hello,

In order to prove the influence of the number of iterations, I continued the calculation of the finer mesh (R104). At the end there were 19 500 iterations done, which means a solution time of 5 H 25 MIN. Q_out and the water level along the centre axis did not change. For the second mesh, I run the same case as before (R103), now with 50 000 000 iterations (solution time of 1 day 3 H 46 MIN). The results did not change. I still get an outflow greater than the inflow.

I would be glad if someone could help me with this problem. Maybe in combinations with my other questions, because I was not able to figure out the other questions, I wrote down before (03.07.2014), yet.

Thanks in advance,
Beate

Hello,

I looked at your parameter file and I am surprised by your time step of 0,002 s. Why is it so small? I am afraid that with this time step and the default value of accuracy of the solver (1.E-4) you get 0 iterations of the solver before reaching the steady state, and this could explain your problem. Moreover it must be very slow. I suggest that you look at the Courant number (which is asked in your results) and increase the time step so that it is about 1. This CFL number is U*DT/DX, U being the velocity and DX the mesh size, DT the time step. You can also increase the accuracy :

SOLVER ACCURACY : 1.E-6
or
PRECISION DU SOLVEUR : 1.E-6

and look in the listing if the solver (conjugate gradient) does iterations. When it says 0 iteration nothing will evolve after. If in doubt on the accuracy you can also test the direct solver 8 (but only in scalar mode, and it costs about like a conjugate gradient that does 50 iterations).

You can also inspire from other test cases to add some diffusion. Make sure also that when you compare two different meshes you change also the time step so that all runs have about the same Courant number.

With best regards,

Jean-Michel Hervouet