open TELEMAC-MASCARET The mathematically superior suite of solvers

Hi,

I have a problem with TELEMAC-2D v8p2r0 that I can't resolve.

When I add a private variable to the geometry file and specify it in the steering file (NAMES OF PRIVATE VARIABLES) the model crashes with


However, I have no liquid boundaries defined, i.e. in my cli file LIHBOR is 2. Besides, if I run the model without reading the private variable (commenting NAMES OF PRIVATE VARIABLES in the steering file), the model runs fine and correctly detects a single solid boundary.

This happens for any private variable, even "dummy" variables that are not used in the code.

However, if I run one of the examples (I tried "pluie") everything works fine, also with CN values in the geometry file.

So I guess it must be related to my setup, maybe the geometry file? I only have no idea what could be the reason. A look into the code shows me that LIHBOR seems to be wrongly read, but only if private variables are used, which puzzles me. Any hints where to start are appreciated.

Hello,

Have you tried adding the keyword NUMBER OF PRIVATE ARRAYS with the number of new private arrays as in every example where the keyword NAMES OF PRIVATE VARIABLES is used for TELEMAC-2D, or as suggested in the TELEMAC-2D user manual?

Hope this helps,

Chi-Tuan

Hi Chi-Tuan,

thanks, indeed I forgot that and it worked when providing the NUMBER OF PRIVATE ARRAYS keyword. Is there no way to catch this (i.e. that the keyword has to be provided if NAMES OF PRIVATE VARIABLES is given)?

HOWEVER, I played around a bit with the pluie example and here the keyword is not needed for the model to work. I.e. just comment line "NUMBER OF PRIVATE ARRAYS = 4" in t2d_pluie_cn_geo_hyetograph.cas.

Another strange observation: In my specific case, model runtime increased from 30 seconds to 43 seconds by just reading a dummy private variable that is never really used.

Cheers,

Tobias

Hello Tobias,

Thanks for your feedback.

It is not so easy. The NUMBER OF PRIVATE ARRAYS is not exactly connected to the NAMES OF PRIVATE VARIABLES. Some private arrays can be used independently on this last keyword.
We will think of how avoid this issue for next release.

I found why the pluie example works for your case, it is because, it is asked to write VARIABLES FOR GRAPHIC PRINTOUTS O, R and Z. If you delete the writing of these variables, you should get the same error.

Have you tried to run your 2 models several times each? Are 30 and 43 seconds mean values or just one time measurement? Are they parallel runs or serial ones? Are there other things running on your computer at the same time? Have you added FORTRAN FILE? What steering file/options have you used?
It is not easy to give you reasons for your observation without knowing a lot about what you tried.

Chi-Tuan

Thanks for clarification. That makes sense, the VARIABLES FOR GRAPHIC PRINTOUTS keyword.

Regarding the runtimes, I again played around a bit. There seems to be quite a large variation in runtimes (same setup, single core), even though I payed attention not have some other processes running in the background. I noticed that the variation seems to be larger for finite element than finite volume scheme. However, I conducted no full and systematic benchmark, just a few manual test runs. In any case, it doesn't seem to be related to the reading of private variables.

Thanks for help,
Tobias