open TELEMAC-MASCARET The mathematically superior suite of solvers

I am just trying to run a drogue case.

The hydraulics runs well but I get this error when I initialise the drogue release without it progressing even a single timestep of the HD.

"SORTIE EN VERTICALE PAR FRONTIERE LIQUIDE ..."

My french is hopeless. What may be the cause of this. It appears that some feature is not supported - looking at the code.

Does the drogue routines determine their own time stepping or do i need to run the HD at an applicable timestep for the particle tracking.

The cooridnates for starting the drogues are correct - taken directly from a GIS map of the system - which also used to generate the grid system.

Regards
John

The error is caused by sigma in schar41 being left undefined inthe call. Need to define asigma (i used the element type to determine if it was 3d or 2d).

However once this was added, all flot z locations (including shz variable) went nan after first call to schar41. All drogue examples that i used started in deep water, with the zlocation about 0.3m below the surface.

Has drogue modelling been tested in the latest releases of the code? It appears not based on the sigma error.

Still trying to find cause of nan (generally due to 0.0/0.0 error. To help I am using a type 3 vertical mesh. However the area of drogue release is 7m deep, and the mesh has a fixed level at -2.0m.. Water surface is at approx 0.1m.

Help appreciated.
john

Sorry,

The asigma missing argument is in calling scaract from derive.

Major Question

Question the derive function calls scaract with a zstar argument. This has not really been defined in the code!

I think that derive needs zstar in its call.

Please comment - urgent.

Hello John

I don't think that you need to go that deep in the code.
First did you edit the subroutine flot3d.f in order to give the position and times of departure and arrival of drogues.

Yes, when the drogues are implemented, they use the chaaracteristics to be located and to follow the flow. These features should work very well.

I hope that this helps
Riadh

Did you read my other posts? I really needed to get into the code! Drogue Characteristrics is NOT working correctly in the current code with a sigma vertical grid.

Yes I defined all the drogues in flot3d. The intial conditions that were generated were correct (printed out after all drogues were added from telemac3d), with X,Y,Z and shz defined correctly. That is where I thought my error was, hence the printouts. Not much else you can do when the internal start point is correctly interpreted but the end of iteration location shows Nan.

After the first iteration of scaract is where the z coord was nan'ed.

Please read the code. In BIEF/DERIVE function, zstar is declared but not initialised in DERIVE, it is NOT passed through the call!!! Zstar is used in velocity characteristics code, but is redefined to the zchar variable, though the CHARAC call. Importantly zstar is declared and defined as ZSTAR(1) but declared in SCARACT as ZSTAR(NPLAN) ... nasty error that could cause bad memory references.

The other main point, is that sigma IS NOT passed into SCARACT from DERIVE (only used for drogues) so it is defined in SCARACT as false for all vertical grids. This IS an error. Hence the original error where it was calling SCHAR41 with SIGMA = false.

Once a sigma grid is recognized, printing out zstar from SCHAR41 shows zero values ....

I would rather not have to do this .... on what is supposed to be working code. I have compared the current repository with the version I am running and there are no differences.

Some further comments.

After hacking the derive routines and calls to take account of zchar and sigma, calculated locations are garbage with shz >> 1.0 and even going negative. Unstable.

SCHAR41 routines appear to calculate the z values in a sigma coordinate which is efficient. Yet DERIVE recalcs the zflot values to real levels. I do not see any back conversions in the characteristic or derive routines to account for this.

Eg zp and zstar (sigma) are in same factoring equation (but zp is derived directly from zplot (which has been converted to a level in ).

It appears that derive is converting z to a print out value - also done by add_particle, but the characteristics routines expect it to be a sigma coordinate.

As my previous discussions explained, internal structure of the routines were the cause.

By applying a back conversion for zflot in DERIVE just before calling SCARACT fixed the problems - of course along with defining sigma and zchar/zstar correctly.

The back conversion to sigma was achieved with

! JMF need sigma defined somewhere for scaract call
ASIGMA=(IELM==41 .or. IELM==40)
! JMF - convert zflot back to sigma
do iflot= 1,nflot
iet=etaflo(iflot)
ZFLOT(iflot) = ZSTAR(IET) +
& SHZFLO(iflot)*(ZSTAR(IET+1)-ZSTAR(IET))
enddo

At this stage, no effects to algae will occur since it only operates in 2D. No chnages to the srteamline routines was required, so velocity characteristics are not changed. All required changes are in the DERIVE routine and in its calls.

I changed the DERIVE call to include ZSTAR and NPLAN arguments and assocaited calls in telemac2d and telemac3d but they could be optional arguments only used in 3d. Usede ZCHAR in the call itself, though it is referenced as ZSTAR internally.

Please check this out and incorporate it into the next release.

This shows that some sloppy changes were made sometime in the past without adequate checks to pickup conflicts.

Still source code help solve these problems. Suggestions - a very complete set of simple test cases is needed to check out major components and features.

Hello John

Thank you these contributions, eventhough mixed with several unhappy comments.
You should know that these features of the code were added long time ago and was updated in a major way during a recent PhD. It was scarecely tested by expert users. We use the test case called particles (folder examples/telemac3d) to validate a small part of these features.

I followed your remarks and in deed there are some uncoherent things. I fixed the arguments (nplan, zstar,...) and added the back conversion.
The code compile well, however, the validation example 'particles' crashed after 520 time step.
I would like to know if, eventhough your case works well, can you run the aforementioned validation case to see if runs well or there are still some unclear issues, or maybe I'm missing something.

with my best regards,

Riadh

Thanks for the reply. I was annoyed because of your initial comments suggesting it was a setup problem. Sorry - I am running to a strict timetable at the moment.

Info regarding what i am running...

telemac3d v7p1r1
3D with 10 layers.
Compiled nad running on Linux using mpi.
Running over 12 processors. The drogues are definitely switching through different processors (based on individual processor log files)

I will try to get to the validation case as soon as possible.

Cheers
John