open TELEMAC-MASCARET The mathematically superior suite of solvers

Hello Thierry,

I have tried the second step on a third computer, it works in scalar but not in parallel. All the computers have the same version of Telemac (V6P3) and the same compiler, very strange...
Please, could you check if it works for you in V6P3 scalar and parallel.
If yes, which parameters should I compare between my different computers?

Regards

Here is an answer on another topic which could be useful to link here :
www.opentelemac.org/index.php/kunena/16-...explicit-error#14773

I have used Jean-Michel correction of point_tomawac.f.
In scalar mode, all is good without problem of compatibility with V6P3 version.
In parallel mode I have the next error :



Concerning the writing format, I don't know if it is important or not but the main error for me is about file unit 99. I have used debug mode and some added some check points in Fortran file :



And I have the next error on the console :



So the bug seems to be coming from the loop on ILEO. At the first iteration, file 99 exists but as it is delete at the end of the first iteration, it can't work to open the file at the second iteration.

Does somebody know how to resolve this problem? I don't really master the subroutines called here and the links between...

Regards

Hello,

The problem of format is not the real reason (it could be a loss of accuracy, we'll see that).

The principle is that :

All processors create a file with an extension in the name.

Only processor 0 reads them all and deletes them 1 by 1, so there should be no attempt to read a file that does not exist, unless it has not been created. The reasons can be :

1) A processor crashed without warning and before creating its file.
2) A point is not in the domain ? I do not know if that is checked (quick answer waiting for the person in charge of Tomawac).

Regards,

Jean-Michel Hervouet

Hello Jean-Michel,

That's a little bit clearer with your answer.

I think it is the second reason : in proxim (called before ecrepse) I have the information if the point is in or out the domain and only points 1, 5 and 6 are in the domain computed by proc 0.
So in the loop on ILEO (in ecrepse) point number 2 (2nd iteration) is not found which is logical because out of domain.
I will take a look on proxim and search how to avoid out of domain point.

Regards

OK, the point is : could you have a point outside the initial (not splitted) domain (in this case we should stop the program immediately with a message).

JMH

Something similar is maybe implemented in Telemac2d with sources? It could be added at the beginning of the computation (I don't know where and how).

But do you agree that in ecrepse if all the initial domain was checked before, I have to bypass the out domain points on ILEO loop?

Regards

Hello,

The only explanation I see so far is that you would have a point outside the domain, I checked and it is not tested in subroutine proxim.f (library bief).

Could you try with the enclosed modified version ? (it compiles, but was not tested on a relevant case with this mistake).

With best regards,

Jean-Michel Hervouet

Hello Jean-Michel,

You had reason, all the points were out of the domain, it lacked some decimals in the steering file. Here is the right values to use :
ABSCISSES DES POINTS DE SORTIE DU SPECTRE =
-7429.98504638672;-2051.20086669922;3275.56228637695;7066.65802001953;
-12715.4541015625;-3640.49911499023;3874.46975708008;12139.1906738281
ORDONNEES DES POINTS DE SORTIE DU SPECTRE =
13664.4048690796;14746.8509674072;13877.0227432251;12045.3062057495;
20754.3487548828;25039.1960144043;25227.3235321045;21570.6596374512

With these corrections the next computation succeeds.

After I have used VALIDATION without NEXT COMPUTATION ("normal" validation case) and also validation after a next computation in the middle of the computation. The validation results are not strictly equal but I think pretty good (I don't know which precision should be assumed).

without next computation :
VARIABLE : HAUTEUR HM0 DIFFERENCE : 0.7206202E-04
VARIABLE : DIRECTION MOY DIFFERENCE : 0.1379395E-01
VARIABLE : FREQ MOY FMOY DIFFERENCE : 0.1178682E-04
VARIABLE : FREQ MOY FM01 DIFFERENCE : 0.8046627E-05

with next computation :
VARIABLE : HAUTEUR HM0 DIFFERENCE : 0.1909137E-03
VARIABLE : DIRECTION MOY DIFFERENCE : 0.1379395E-01
VARIABLE : FREQ MOY FMOY DIFFERENCE : 0.5123019E-04
VARIABLE : FREQ MOY FM01 DIFFERENCE : 0.1586527E-03

So for me all is good, thank you for your correction.

Regards

Hello,

OK, we'll try to put this new version of proxim.f in the new release 7.0.

REgards,

JMH

This post is an old one but I would like to continue the discussion.

To summarize the problem, "next computation" didn't worked in V7P0r0 and older version in Tomawac. Jean-Michel's correction in proxim.f has solved the bug, incorporated in version V7P0r1. I have used successfully this correction on my computer.

But today, and that's why I am reopening this post, my simulation failed with "next computation" on a cluster. I have the next mistake :

---

OUVERTURE DES FICHIERS POUR TOMAWAC

*******************************
* CONSTRUCTION DES POINTEURS: *
*******************************

READGEO1 : TITRE= M:\RESULSIMUL\Etudes\T2D_FUI_LITTO_CMS\02_Maillage\05_maillage_maritime_
NOMBRE D'ELEMENTS: 168
NOMBRE REEL DE POINTS: 102

FORMAT NON PRECISE DANS LE TITRE

MXPTEL (BIEF) : NOMBRE MAXIMUM D'ELEMENTS VOISINS D'UN POINT : 8
NOMBRE MAXIMUM DE POINTS VOISINS D'UNPOINT : 9
(MAILLAGE GLOBAL)
SEGBOR (BIEF) : NOMBRE DE SEGMENTS DE BORD = 34
EN COMPTANT CEUX DUS A LA DECOMPOSITION DE DOMAINE
CORRXY (BIEF) : PAS DE MODIFICATION DES COORDONNEES

MAILLAGE : MESH ALLOUE

READGEO1 : TITRE= M:\RESULSIMUL\Etudes\T2D_FUI_LITTO_CMS\02_Maillage\05_maillage_maritime_
NOMBRE D'ELEMENTS: 168
NOMBRE REEL DE POINTS: 102

FORMAT NON PRECISE DANS LE TITRE

MXPTEL (BIEF) : NOMBRE MAXIMUM D'ELEMENTS VOISINS D'UN POINT : 8
NOMBRE MAXIMUM DE POINTS VOISINS D'UNPOINT : 9
(MAILLAGE GLOBAL)
SEGBOR (BIEF) : NOMBRE DE SEGMENTS DE BORD = 34
EN COMPTANT CEUX DUS A LA DECOMPOSITION DE DOMAINE
CORRXY (BIEF) : PAS DE MODIFICATION DES COORDONNEES

MAILLAGE : MESH3D ALLOUE

****************************************
* FIN DE L'ALLOCATION DE LA MEMOIRE : *
****************************************

INBIEF (BIEF) : MACHINE NON VECTORIELLE (SELON VOS DONNEES)
STRCHE (BIEF) : PAS DE MODIFICATION DU FROTTEMENT

TOM_CORFON : PAS DE MODIFICATION DU FOND

**** SUITE DE CALCUL ****

TITRE DU CALCUL PRECEDENT :
test_tmw_seul_suite_calcul
LIT : ERREUR DE LECTURE
ON VOULAIT LIRE UN
ENREGISTREMENT DE 1 VALEURS
DE TYPE : R8
SUR LE CANAL : 4

PLANTE : ARRET DU PROGRAMME APRES ERREUR

---

This mistake remembers me something normally corrected (see upper in the post). I have checked, the cluster should be in V7P0r1 version. So here is my question, is there something linked to UNIX/WINDOWS in the correction added in proxim.f? And maybe this correction is not enough for clusters?
Other way to check, Telemac version is not the same between the computer and the cluster (V6P0r... are not "official"?) : how can I compare easily the two versions?

Regards