open TELEMAC-MASCARET The mathematically superior suite of solvers

Dear Users,

I wonder if anyone could help me to sort my ongoing problem. I have complicated big domain with mulilayering stratification - two tracers and tides. The bathymetry is very steep. The maximum depth is 900m. It has only one open boundary.

My problem is that I cannot run in "one go" for long period as I get messge error below. To avoid it I have to run it for short period, say 3 dyas, and they use result file and continue computation for another 3 days etc. However the last time I run it stoped after 14 hours with message:

@STREAMLINE::SCARACT: THE NUMBER OF TRACEBACK INTERFACE CROSSINGS IGEN > 99

I have seen topics suggesting to reduce the Time Steps, it is already 7.5 in my case, so it is not too large. Is there anything else I can adjust to sort this problem. Thanks in advance.

Kind Regards!

Violeta

Hi Violeta

Even it's not a very beautiful solution, and without any guarantee this will sufficient for your case, you could edit the scaract.f subroutine and change the hard coded limit from 99 to 999 for example.

Some of my colleagues with such message have modified this limit to allow Telemac pass the moment when this situation arrived.


Hope this helps

Hi Christophe,

Thank you very much for your advice. I will definitely follow it. It is much better what I am doing these days by breaking case into multiple runs, and there is no guaranty that it will run. Thanks again.

Kind Regards!

Violeta

Hello,

This behaviour is a hint of an error of parallelism. We had this before when some interface points had slightly different digits on different processors, which triggered at long last the conjugate gradient to crash. A restart would put again the same digits and would allow to go on.
A test that you can do is uncommenting all the CALL CHECK_DIGITS at the end of telemac3d.f (adding it to your FORTRAN FILE). If something is wrong it will stop the program in a few time steps and tell you which variable is guilty.

Then we would need to get the case to run it, but it may take time to debug, especially if we have to wait hours for a run, but well I see no other possibility. A first thing to do probably before this would be looking at your specific Fortran file.

With best regards,

Jean-Michel Hervouet

Thank you very much Jean-Michel for your reply. I am rerunning the case now, hopefully to get results tomorrow, but if it crashes i will know tomorrow morning. In mean time I have attached fortran file for this run, just in case, but hope that new case will be ok. Thanks for your reply.

Kind Regards!

Violeta

Hello,

you are encountering a seldom and ugly case in which in the advection step solved by method of characteristics and in the parallel case a trajectory (streamline) traced back in time - one time step - jumps between mesh partitions, between elements adjacent to the interface between partitions.

It happens sometimes when goes along a mesh edge being an interface between the mesh partitions (submeshes ordered to MPI tasks) and changes from one partition to another and back during this procedure. The reason for this (apart from evident errors in the connectivity table of the mesh or by mash partitioning) are the criteria steering by which element is the one applied for the following of the streamline which are imperfect if you just go along the edge between two elements: the velocity field in element says - cross to the neighbour - and once in the neighbour, the velocity field there says - go back. It happens when the the velocity field in both elements slightly converge along the edge in question.

Without a tedious debugging session showing in which elements on the both sides of the interface it happens and trying to change the mesh there (change the edge angle?) I would recommend enlarging (yes!) the time step, change the number of partitions (i.e. moving the interface between partitions away from the problematic spot). Other solutions require programming...

As mentioned above another source of errors of this kind are nasty errors in the connectivity table which may occur if you have some strange non-connected or doubled nodes, "flatties" (triangles of three nodes along a straight line), doubled or overlapping elements. Sometimes modifying the mesh with inadequate tool can bring strangest effects in the topology.

In the mesh generator we use we have had a bug in the past that sometimes the connectivity table of an element was corrupt showing not the neighbour but some element away of it. And this element usually pointed back to the first lement as a false neighbour. If between these elements the the partition boundary appears - you will effectively cheat the poor tracking algorithm and do large jumps between mesh partitions...

I know it is complicated - and therefore no-one has found any other solution yet - than a cryptic erroro message and "STOP".

Best regards,
jaj

Hi Jaj,

Thank you very much for your detailed explanations. I have re-done the mesh, to be sure that interpolation is to the nearest point, but results are same. However, I must admit the bathymetry is not perfect, it is a Greenland fjord, very steep and there is no detailed bathymetry available, I am afraid. So angels could be very steep in some places. Funny, I thought that bathymetry is not a problem as I run just stratification case for long time, well in stages but for 30 days each, and in total I got 170 days! When I added tides the problems have started. The Mesh/interpolation I have done with Blue Kenue.

You were right I am using Method of Characteristics for Scheme of Advection for Velocity, I have tried others in past and some did not run or number of iterations exceeded etc, this option gave me the best result so far. Maybe I picked the wrong solver? I increased the time step- 60; 500; 1000, but all with same result error. Unfortunately, I am not a programmer, but I am happy to learn. Is there is anything else to try? Thanks.

Kind Regards!

Violeta

Dear Violeta,

sorry I cannot help you much with your problems concerning the actual model itself -- let's say I do not know much about Greenland -- and there are surely much more knowledgeable people on this forum which can help you in choosing a particular solver or advection scheme for this or another purpose. I have just commented what is the possible cause of the particular error message you encounter.

Best regards,
jaj

No problems, thank you Jaj for your reply. I will do as Jean-Michelle advised yesterday, to post my files after checking CALL CHECK_DIGITS, which gives me troubles now:). Thanks again your comments were valuable.

Kind Regards!

Violeta

Dear Jean-Michel,

Sorry to bother you with such a minor question, but when I uncommented CALL CHECK_Digits in telemac3d.f I got message: undefined reference to 'check_digits_'. It is not stated at the beginnng of the subroutine and I wonder if it is linked to another subroutine i need to include as well. Sorry again. Thanks.

Kind Regards!

Violeta