open TELEMAC-MASCARET The mathematically superior suite of solvers

Dear all,

I try to understand how the discharge boundary conditions are implemented in telemac2d. So far I think I understood the basics.

The discharge must be transferred to a Dirichlet boundary condition. Which means that u/v must be computed, h is not fixed and can change depending on the flow into the domain (subcritical flow). The Velocity Profiles option is used to set the profile in the BORD routine and DEBIMP is used to adopt the velocities to the actual inflow.

In DEBIMP this code

is used to compute the actual flow over a liquid boundary is this correct?
I can not imagine which surface is used since each node has two boundaries especially on corners. I've read somewhere that one side of the boundary is used e.g. always the left segment. But ok, this somehow works.

The result
is then the sum of the incoming water. Later the inflow velocities U/V are scaled with the actual discharge value:

to correct the inflow.


Debugging a simple flume example (e.g. bosse-t2d) I recognized that Q1 never get's equal to Q. However the correct mass enters the system. So I thought that the source term may explain this behavior. It's true, changing the friction value changes also the Q1. But I can't get the big picture

Why get's the ratio between Q/Q1 not constant? When computing work1 with FLUBDF I do not get the inflow. It must be the inflow and something else?

So to be more precise:

• What is computed with FLUBDF?
• What are the differences between Q and Q1 (e.g. Fricition)?

Thanks and sorry for the long post

Leo

I was thinking. Now it's clear a different friction changes also h and so u/v must be different when I change the friction.

Hello Leo,

You have understood most of it (congratulations). The rest is technical details:

The flux taken into account by the program comes from the integration by part of the div(hU) term. In this term h is explicit (taken at time tn) and U is semi-implicit (depending on the keyword IMPLICITATION ON VELOCITY). The value that is taken into account for mass conservation is this one, this may not correspond to what we imagine, which would be h(N+1)*U(n+1) or a mixture with H(n)*U(n).

The section taken into account for computing fluxes are segments, a segment may be liquid or solid, it is liquid only if between two liquid points, so in corners there is no special problem.

Now Q1 is never equal to Q because Q1 is computed with a velocity profile, like unit velocities normal to the boundary. The real values of the velocities at this level have no importance if we have the correct wanted profile. Then the coefficient Q/Q1 on velocities will give the wanted Q.

I hope this sheds some light...

With best regards,

Jean-Michel Hervouet

Thank you very much!

Now most of it (95%) is clear

I have some problems with the discharge boundary conditions when using the Finite Volume Methods of Telemac-2d.

My idea was to compare the different FEM/FVM schemes implemented in Telemac. During the studies I observed that the inflow rates were not imposed correctly. The differences were very large so I thought that I made somewhere else an error that causes the wrong inflow rates. To localize the problem, I used a smaller laboratory flume example. This resulted in the following example.




Using a FEM scheme like "14:5", the imposed inflow gets for a stationary case identical to the defined boundary condition. For the FVM schemes there is still a difference that is larger then expected (truncation error).

Further the water level is not homogenous at the inflow boundary when using the FVM schemes (tested with kinetic and HLLC scheme).



FEM (14-5):


FVM (Kinetic)


I could not localize form where the error comes. Maybe it is still an error in my *.cas file? If not I would like to help to fix it.

Best regards

Leo

Sorry I have some problems to attach the geometry file.

sorry

Dear Leo

Sorry for this very late reply. Actually I'm attending a training for all the week (I'm answering from the training room) and I'm not able to answer to your request right now. What I can say is that the problem exists and I made a first attempt to fix it but it without success. I will try to focus on the problem by friday and I hope to overcome the problem.
With my best regards

Riadh

Dear Riadh,

It's good to know that there is a general problem. I'm not in hurry and I hope you have a good training.

I've looked into the code but have not fully understood how the conditions are set. I'm more an expert in finite volume methods for multiphase flows in porous media, there it is very simple to set boundary conditions (implicit schemes,...).


I know it is hard to document all the things which are implemented in Telemac. However, for me it is important to understand how the schemes are working and how they are implemented. I can read the source code of Telemac but sometimes I can't get the idea how something works. I'm sure that there are more advanced users, I sometimes need a small picture/sketch to understand the things .

I have the feeling that documentation is a general problem of large software projects which makes it hard for new users to contribute to open source projects like the Telemac system.

To make it short. I like to help to improve the existing documentation about the FVM schemes. I know your paper from the last User Conference and the release notes form v6p2 and I have some books and papers about HLLC schemes etc. so I have some ideas what there is implemented and I find it also in the source code of Telemac.

Maybe I should start a new topic about documentation.


With my best regards,
Leo

Dear Leo

Many thanks for proposing to help on the documentation. Further documentation is indeed one of the key request we get from new users wanting to learn to use the system.

Please could you update your profile? With these details we can then hopefully give you access to the wiki for editing .

Dear Leo

You've pointed out a very important issue. Surely, for large systems like Telemac, it is not an easy task to have a full, explicit and clear documentation. Also, you're right, this is one of the main reasons that makes hard contribution from external (and even internal :) ) users.
It will be a very appreciated if you (and other users) can help to improve the existing documentations. Please feel free to contact us for any help or suggestion.

With my best regards,

Riadh