open TELEMAC-MASCARET The mathematically superior suite of solvers

Hello,

Actually every particle must be localised in a single element, as we do for characteristics (this is the trick to have no difference between scalar and parallel runs in the method of characteristics, and to avoid that two sub-domains treat the same particle). We thus check if a particle has been found in several sub-domains. Given your error, it can be either an overlooked bug or the fact that you release the particles on a node that belongs to 4 subdomains. A first tentative bypass of the problem could be that you slightly shift the point of release so that it is neatly within one single element.

Regards,

JMH

Hello JM,

What I do is release 231 floats spaced on a 25x25m grid within my domain that is later partitioned in 4 sub-domains (4 core proc). The first time I release the floats, there is no problem. The floats appear in my domain and their paths are computed until the second drop (in the same coordinates).

So, if the coordinates of at least one drop location lie on a boundary node/element, then the error should have occurred in the first drop, right?

Having said that, I still don't feel confident that the arguments I used in specifying coordinates/tags within the DO loop are not causing trouble in the ADD_PARTICLE subroutine, and that is what I am investigating. Any advice on this matter would be appreciated.

Regards,
Costas

Hello Costas,

Yes, I am not sure of what you do here:

DO I=1,231
TAGFLO(I)=I*(LT/100)


For me this loop, with the test before, is done when LT=100, then when LT=200, so your tag numbers the first time will be : 1,2,3,4,5,... 231

and the second time : 2,4,6,8,... ?

Perhaps what you want is : TAGFLO(I)=I+231*(LT/100-1)

Let's see...

Regards,

Jean-Michel

Thank you for the pointer. I noticed that too , and I was in the process of finding I solution. The aim is to start the tag counter from where it was left from the previous loop. I tried your suggestion but it didn't work. My programming skills are elementary, but I am working on it.

Regards,
Costas

You are right, it is rather :

TAGFLO(I+231*(LT/100-1))=I+231*(LT/100-1)

blush also...

Regards,

JMH

Well, neither solution worked, although they seem logical, so I guess it is the rest that is still causing some trouble.

I am suspecting the XFLOT/YFLOT arrays that I am filling in the first place from the formatted file that contains the 231 coordinates of the drop points (and therefore spans from 1 to 231) and again is reused within the ADD_PARTICLE subroutine. Maybe I should use a separate array to store the coordinates from the file, and use them to fill the XFLOT/YFLOT coordinate arrays in the ADD_PARTICLE subroutine that should span from 1 to NFLOT_MAX. Does it make any sense?

Again, thank you for your help.
Costas

Hello,

Yes, it is of course kind of this. XFLOT and YFLOT are evolving with the particle, from the original position to the last one, so you cannot store the original coordinates in them.

Regards,

JM

Dear JMH,

Thank you for your help, I learned a great deal today. I have managed to setup the subroutine FLOT so that it inserts the floating bodies as desired. However, when the second set of floating bodies is dropped and subroutine DERIVE is called, the computation hangs (like when in an infinite loop) without exiting.

The TDFLO file in the wdir is populated up to the previous listing period, however, only 194 out of 231 are written, which indicates that the floats of one subdomain are missing. The computation is so short that there is no chance so many floats exiting the domain (but some could move between subdomains). So I run the computation with mpi in 1 proc only and then the computation halted with the following error:I have tracked the trap in streamline.f:I have noticed the "PROBABLY EXAGGERATED" comment. Is it safe to modify this trap?

Regards,
Costas

Hello,

There is a keyword MAXIMUM NUMBER OF DROGUES that is used for dimensioning arrays for the computation of the trajectories in the module streamline. It seems that you have given a value of 231, but you are launching more actually, could it be this ?

The checking in streamline is necessary because when we deal with characteristics we do not know how many "visits" a sub-domain will receive from neighbours. It can be more than points in the sub-domain itself. With particle we dimension with the maximum number (NFLOT_MAX) because we anticipate that the user may launch all the particles in the same sub-domain (what you are probably doing).

Regards,

Jean-Michel

Dear JM,

I have set 'NUMBER OF DROGUES" in the cas file to 1155, i.e. 5 times the 231 floats I am dropping each time. I suppose that it corresponds to 'NFLOT_MAX' that is used to dimension the arrays, and with my latest iteration of flot.f, the DO statement spans from 1 to NFLOT_MAX, with each drop incrementing the counter (by 231) in XFLOT, YFLOT and TAGFLO.

As I mentioned before, the error occurs both with 1 domain and 4 sub domains (number of processors 1 and 4 - I haven't compiled a scalar version). I have also checked that all of the sub-domains receive initially at least a few floats. Actually, most of the floats are distributed within 3 sub-domains and 1 is receiving ~3-4, but I don't think it is the particle distribution that causes the problem.

The difference between NCHARA and NCHDIM is 231, i.e. the number of floats dropped the second time. So, could the problem be that NCHDIM didn't update for some reason?

Regards,
Costas

P.S. I am compiling a scalar version and will check as soon as it compiles.