open TELEMAC-MASCARET The mathematically superior suite of solvers

Attached is a simple geometry of a weir in a flume which I am using to test different parameters like turbulence, advection, diffusion and vertical layer placement. The model is the basis for looking at scour/erosion generated by the weir. The two steering files in the attachment are identical except for the method used to set the layer position (mesh transformation 1 versus 2) and the time step. The layer spacing set in the fortran file should result in then being at or close to those set with the uniform spacing option (mesh transformation =1).

A couple of questions/inquiries regarding the results I am getting.

1. Why can I run st-4e.cas with a time step of 0.25 s while st-4h.cas will not run even with the time step reduced to 0.005 s when the 3-D computational mesh should be the same or almost the same? Attempts to run st-4h.cas were made with the initial constant elevation option and using the results of the st-4e.cas run.

2. Not as important > st-4e.cas can be run with the time step increased to 20 s. Very nice as the run takes a few minutes opposed to hours. However, the results are unrealistic. A plot of the velocity vectors near the bed shows the weir having little impact on the horizontal direction of the flow and relatively minor effect on the vertical component. A similar plot when using a 0.25 s time step has flow being accelerated around the nose of the weir with recirculation occurring on the downstream side.
Any explanation as to why the model actually runs with the 20s time step. The smallest 2-D mesh size is in the order of 3 m and the mean velocity approximately 2.8 m/s. Based on this I would have expected the program would have crashed or not run with a 20 s time step. Especially considering how sensitive the program has been to the time step when run previously with different geometries and flow conditions.

Thanks and regards
Bruce

Hello Bruce,

I've got your files and I'll have a look at them. Allow me until end of next week to give you an answer. Here it is holiday time and we are hard at finilising version 6.2.

With best regards,

Jean-Michel Hervouet

Hello Bruce,

Here is a first quick answer :

You will get the expected behaviour if you take :

SCHEME FOR ADVECTION OF VELOCITIES = 4

so the difference or problem is in the method of characteristics. In this case, the generalised sigma transformation makes a big difference in the algorithm, as the vertical velocity W* in every layer is not at the same 'scale' as the others, so we have to reinterpolate the velocity at every layer crossing. I have now to investigate what happens really there and why it makes so much difference, so I thank you for your post which puts us on the track of a possible problem.

With best regards,

Jean-Michel Hervouet

P.S. a minor problem I noticed is that my version does not accept keywords as: MASS BALANCE=true
and I have to put YES instead, this seems to be a compiler sensitive problem and maybe not all of them will accept "true".

Hi again,

I notice that you use the Nikuradse law without giving the
FRICTION COEFFICIENT FOR THE BOTTOM

which is set by default to 60., this is meant for the default law which is Chezy and is certainly a problem here (but the first problem is probably not linked to this)

Regards,

JMH

Hello again,

Last advice before week-end : add the following line in your parameter file :

FREE SURFACE GRADIENT COMPATIBILITY : 0.9

This is to avoid spurious oscillations of free surface (the famous inf-sup condition in Navier-Stokes equations). From 0.9 down to even 0. you can test the effect on free surface.

The problem with characteristics makes a clear crash in version 6.2, so probably I'll fix it next week.

Regards,

JMH

Hello,

I think I got the problem. In subroutine condim.f you should state also :

ZSTAR%R(1)=0.D0
ZSTAR%R(NPLAN)=1.D0

The error stems from the example given. As a matter of fact when building the mesh we assume these values but in the method of characteristics we do not and they must be duly built. I'll secure this in the next version.

With best regards,

Jean-Michel Hervouet

Jean-Michel

Sorry for not replying earlier.

Thank you for your efforts and the information.

1. Regarding your comment about the friction coefficient. My geometry file contains the roughness (ks) information (created in Blue Kenue as a variable). My interpretation of the information in the manual was that these values would be used if no “global” value was provided in the steering file. During the program initialization there is a message “FONSTR : FRICTION COEFFICIENTS READ IN THE GEOMETRY FILE”. This seems to be the case with this model as my roughness is 0.045 and if the default value of 60 was used the water surface slope would be a lot steeper. Could you confirm that the method I am using is providing the correct roughness for the computations?

2. Regarding your last comment about setting the top and bottom layers in the condim routine. In my testing I found that if you run the steering file st-4h with NON-HYDROSTATIC VERSION=NO and MASS LUMPING FOR DIFFUSION, VELOCITIES, DEPTH =NO, it will run using either the HORIZONTAL AND VERTICAL TURBULENCE MODELs = 3 or using HORIZONTAL AND VERTICAL TURBULENCE MODELs = 4.
This would suggest that the problem may also be related to the use of the hydrostatic version and/or the mass lumping.

3. Regarding MASS BALANCE variable. I didn’t notice an error message when using “true”. Did your version of the software crash when YES was not used or was there an error message?

4. Last thing. Any opinion as to why the model will run at the large time step (20s) which generates very different results to runs performed with a time step of 0.1s


Regards

Bruce

Hello,

You are correct with point 1, I did not notice. On point 2, the non-hydrostatic version has no real vertical velocity and this may trigger large differences. The fact that ZSTAR was not given for planes 1 and NPLAN was really the problem, as they turned out to be infinite in the method of characteristics. Point 3 is due to the fact that some parts of lines in the parameter file are read with Fortran instructions like READ(PART_OF_LINE,*) L where L is a logical value, then we depend on the forms accepted by the compiler to represent a logical value, some will accept true, some will not, it is not the first time I notice this.
Point 4 is just the accuracy in time, which is in our case mostly first order, so you have less accuracy with the higher time step, this is why it is necessary to do some sensitivity analysis when you do a study. As we have very stable numerical schemes, the algorithms will not crash but will give less accurate results.

With best regards,

Jean-Michel Hervouet