open TELEMAC-MASCARET The mathematically superior suite of solvers

Hello,

when using the Finite Volume scheme (0,1) in v6p1, I noticed that the inflow flux in the log output is around 3% higher than the prescribed inflow value in the steering file. Actually, by comparing the results with those obtained with v6p0, the inflow is higher with v6p1.
Does anybody have some informations?


Best regards,

Clemens

Hi Clemens

The prescription of inflow for the finite volume kernel is managed in the routine flusew.f.
Until now to impose an inflow or outflow, we suppose a subcritical regime and we compute the water depth using the Riemann invariant. The velocities are given by the routine bord.f. At the end, the obtained discharge at the boundary do not correspond exactly to the one introduced in the case file.
Rigorously, we have to identify first the regime (by computing the Froude number) and then impose the boundary conditions consequently. Moreover, some iterations could be necessary in order to verifiy the well imposition of the in/otflow at the boundary. This problem is well known for the majority of FV-based codes descretizing the conservative form of Shallow water equations. We will try to overcome this problem (or at least improve the algorithm) in the next release.
Thank you for your interest to this part of Telemac. All other comments are very welcome.

Kind regards
Riadh

Hello Riadh,

thank you very much for the answer!
In v6p0 when using a Finite Volume scheme the log output gives me no informations about the fluxes at the boundaries. So I compared the results from v6p0 and v6p1 and noticed these differences.
So also in version v6p0 the computed discharge didn't correspond exactly to the prescribed inflow in the steering file?

Thank you for the clarification.

Best regards,
Clemens

Hi again Clemens,

Yes, there is no difference between V6P0 and V6P1 in the manner of imposing inflow/outflow. The only upgrading is the use of Telemac (already existing) ressources to print fluxes at the boundaries or through a control section in the listing (log) during the computation.

All the best.
Riadh

Hello Riadh,

sorry that I didn't express my problem in a clear way and for taking your time:
In the past for a small project I used v6p0 with Finite Volume scheme and it worked well. In the meantime I switched to the new version v6p1 and by analysing the results I noticed some differences:
1. the computation time with v6p0 was much shorter (maybe due to another times step / courant number management in v6p1?) In v6p1 the maximal courant number during the simulation is much lower than the courant number =1 imposed in the steering file.
2. Between v6p0 and v6p1 the obtained steady water depths differ in around 2%. In v6p1 the resulting water depths are higher because v6p1 computes a higher inflow discharge than that imposed in the case file.

Best regards,
Clemens

Hi Clemens
Sorry for this late reply, I was busy these two days.
About the CPU time, first of all you have to be sure that you are using exactly the same parameters (CFL number, simulation time, order of the scheme etc.) in both cases. If it is the case, I think that you should have almost the same CPU time.
I have updated some routines which influences the time step computation, but the resulting CPU time is expected to be almost the same as for the V6P0 version.
In the V6P1 release, you have the option to use a second order explicit time scheme (called Newmark scheme) by chosing the key word "Newmark time integration coefficient" = 0.5. The default value is set to 1. which gives the classic Euler first order scheme. If you use second order time scheme you may increase your CPU time.
An other probable cause of increasing the CPU is the use of second order kinetic scheme. This latter needs roughly two to four times CPU than the first order (kinetic or Roe) schemes.

About your second remark, you're right: while the inflow prescription is not the same in the two versions and because of several slight updates in various subroutines, the final result undoubtedly changes.

I hope that I was clear enough, if it is not the case, please do not hesitate to write me.
King regards

Riadh

Hello Riadh,

thank you for your remarks.
In the meantime I could figure out why the much faster computation time with v6p0 in comparison to v6p1 when using the ROE scheme.
In v6p0 for the ROE scheme the time step was computed via the vfcfl.f subroutine. In v6p1 the time step is determined for all schemes via the caldt.f subroutine. The vfcfl.f subroutine doesn't exist anymore in v6p1. The caldt.f subroutine seems to be more restrictive in the computation of the necessary time step. I don't understand for example why the factor 1.5D0 in line 48 (line 63 in v6p1). With caldt.f the maximal Courant numbers during the simulations are around 0.25.

In a test case (spillway) with v6p0 I used the vfcfl.f subroutine in combination with the 1st order kinetic scheme. The computation time is 3 - 4 times faster than with the "default" version! And the results (to a steady state) are the same. Are there maybe cases, where the vfcfl.f subroutine fails?

A Second order time scheme sounds good!

Best regards,
Clemens







An explicit second order time scheme sounds good!

Hello again,
the topic quicked my interest :) and so I tested the vfcfl.f subroutine with the 2nd order kinetic scheme with a prescribed Courant number of 0.9 in the steering file and the computation aborts after some time steps.
When imposing a lower Courant number it works well and still with a 4 times faster computation time than with the classical version. However this would be then a trial and error procedure always.
I tried some further modifications but then in any sub routines there are limiters, dependencies etc. which I could not figure out as no Telemac specialist.
But it shows that there is maybe a way to relax the actual CFL conditions (with very low CFL values) in order to get larger time steps still obeying CFL <1?

With best regards,
Clemens

Dear Clemens,

In deed time step in V6P1 is more restrictive than in V6P0. This restiction is only in the computaion of dthaut (the characteristic length used for the cfl). As you know, the FV description of Telemac is what we call a vetex-based description, which means that physical parameters are computed at the vertices exactly as for Finite element. (The majority of FV codes use the cell-centered description: they compute variables at the center of gravity of triangles). So, our control volume is defined in a such manner that it surrounds the vetex (the set of CV is what we call the dual mesh). The problem is then how to chose the characteristic length (dthaut) for the CFL; and the choices are multiple.
If you are curious to know more about the FV description of Telemac and how dthaut is chosen, I refer you to the thesis of E. Audusse and the papers cited therein.
All this introduction is to say that dt is more restrictive in V6P1 than in V6P0.
One important remark, the use of the second order kinetic scheme induces an extra cfl restriction and thus the CFL number you suggest in the steering file will never be reached. Moreover, in 1D like applications, you can introduce CFL near 1 but if the application is really 2D it is better to be limited to 0.5.

For the ROE Scheme, the vfcfl routine, was not consistant with theorical restrictions of CFL and that's why it was removed and replaced by the new caldt (which is more restrictive).
Finally, the coefficient 1.5 is used only for kinetic scheme dt computation to define the kinetic function. if you want to know more about it i refer you to the stability theorem in page 322 in the paper of audusse and Bristeau J.COMPUT. Phys. 206 (2005).

All the best.
Riadh

Hello Riadh,

thank you very much for the answer and the for the valuable references!

For information for other people, I found the paper on the Inria website since I don't have access to this journal.
The topic of the computation of the space step is interesting. So it seems that there is some margin in the computation of DTHAUT and if I understand correctly especially when dealing with cells which are elongated in the mean flow direction.

Best regards and have a good weekend!
Clemens