open TELEMAC-MASCARET The mathematically superior suite of solvers

Hello,

We are having a difficult time getting dwater to run with hydrodynamics generated from telemac3d (v7p1r1). Tidal flat options were intiated along with mass dumping at z.

All files are recognized and loaded in dwater but mass conservation is shown as not good, and now checking dwater net boundary flow against telemac dwater processing boundary net flows. Telemac indicates that mass conservation is good thtrough the calculations

We have eliminated drying/wetting by artifically deepening, to keep the run simpler and we are now sure that this is not the problem. Does not provide a stable run

has anyone recently done any updaets to the code that is not in the current'stable' release. And is there anyone currently running this combination.

Thanks

Hello,

We have already checked and published that the mass conservation in Telemac is exactly the same as e.g. Delwaq, which is a finite volume program, so the question is how the mass conservation is checked in dwater, it may depend on the interpolation, the position of variables, etc. A possible problem is that on boundaries with prescribed elevation, the velocities provided are not fully compatible with the actual discharge taken into account in the code (because the equation elevation=prescribed elevation replaces the continuity equation), this might account for a few % of error if checked by another program that takes the velocities at exit for granted.

With best regards,

Jean-Michel Hervouet

Thanks for the reply. Sorry for the tardy reply.

My analysis of the dwater interface also pointed to what you say.

I have found the problem, I think. We needed to ensure that dwater runs with dry_thresh set to zero.

I was initially confused by telemac's requirements for tidal flat treatment, where the 'minimum value for depth' does not appear to be a minimum but a threshold for smoothing. Telemac (please correct me) will take the depth down to zero (different to many other systems that impose a +ve depth which is considerd dry).

Cheers
John

Hello,

Yes, and the threshold minimum value for depth is not even used if you choose :

TREATMENT OF NEGATIVE DEPTHS : 2

With this option all depths will be positive or 0 and the continuity equation is solved at machine accuracy.

With best regards,

Jean-Michel Hervouet

Thanks Jean-Michel,

We are still having problems even with this. We are going to run some simple examples from the distribution (thinking of Wesel) with dwaq activated. Will let you know how we go.

John

I still have problems ...

To provide a simple example I have run the Wesel example, running with only one layer. I have added dwaq output, reset the following

OPTION FOR THE TREATMENT OF TIDAL FLATS : 2
NON-HYDROSTATIC VERSION : NO
NUMBER OF HORIZONTAL LEVELS = 1

Everything else looks OK for a mass conserved solution. But please point out any I have missed. Cas file attached

Running my python script (attached) reads in the generated dwaq files (volume, fluxes, and connection info) shows large mass discrepancies.

Needed to ensure that for boundary fluxes the -ve ifrom indices were handled properly. Also the volumes and fluxes are synced properly, namely that the change from vol1(t1) to vol2(t2) is linked to flux(t1) values. I find this Delft sync requirement very strange choice - since the fluxes are not complete till t2, they dont exist at t1.

Despite the relatively simple test case, and that the tel4del mass check output saying that the mass balance is around 10e-12, the script is showing discrepancies above 5% at a number of points. The bulk of the mass balance is better than 0.1% mismatch. The first iteration has the worst results for some reason - bad initialisation.

Attached a results mass check output. I dont think that these results are good or expected. It suggests possibly that the tofrom connection info is wrong.

Any comments? I am happy to accept a script coding error but think i have covered everything. And it relates to the other problems I have been seeing.

One other problem found but not related, if I run the mpi version of telemac3d with ncsize=0 or 1, the dwaq outfiles havent been stripped of their telemac headers! I had to run with the non-mpi version to generate these output files.

Please ignore previous posting.

Found my problem - mass conservation is perfect for all except the first iteration!!

Python numpy has undefined behaviour in (which I have had come across before).

mass[index]+=flux

where index has non unique indices eg [1,2,3,4,1,1,1]

I am happy that this is the case. Further checking will be done.

Thankyou again for the discussion so far...

I am still having the problems so I have been doing some investigations.

All problems are related to telemac3d.

I have run the tidal_flat example and developed a simple python script to do a mass balance on the dwater output files. I am satified that flow linkages are correct and that the mass continuity is very good for a fully wet run as well for modified (shallowed) points going dry.

To look at a more complicated example I have gone to the Wesel example setting hydrostatic pressure, and adding a dwater output. I cannot get a good mass conservation with this problem. Dwater does not like the telemac output, when doing tghe mass balance check. My investigations seem to show the problem is due to a loss of precision linked to subtraction of nearly equal values and the required files being output in single precision resolution. My current experience seem to suggest that the problems are with dry or nearly dry nodes.

Is it possible that someone can do a run for me that confirms that this isnt just a problem I have, preferably being able to also do a dwater run. Or advice that I am running with the wrong control parameters at the telemac end. Specific ones I have set for the run are

OPTION FOR THE TREATMENT OF TIDAL FLATS : 1
TREATMENT OF NEGATIVE DEPTHS : 2
MASS-LUMPING FOR DEPTH : 1

I have run the 3d simulation with only 2 layers (minimum for a 3d run) to keep it even simpler.

I have attached the cas file that I run.

Any help appreciated.

John

I have realized over night that I missed out some info...

I added code to do a mass check over the dwater output timestep from telemac (not on intermediate timesteps), so I could compare file content with what telemac thought was happening. This is where I found telemac was returning very good mass balance (delta volume vs summmed net flux at each node). However the same analysis on the transfer files showed discrepancies of 5-10% or bigger.

As explained previous I think it is a loss of precision in the transfer from double to single precision on the write.

I will now change volume and sumflow to single precision to maintain consistent internal precision in the tel4del routine with that in the files. Will post results.

Cheers
John

Hello,

This is why we stopped doing water quality as a post-processing. There is not only the loss of accuracy (this could be cured by double precision files) but some history of the flow is lost if you do not have all the time steps in the results file, e.g. suppose you have a discharge during a very short time, this may be overlooked in the results file, but the mass balance will be wrong.

With best regards,

Jean-Michel Hervouet