open TELEMAC-MASCARET The mathematically superior suite of solvers

Hello,

Got it, thank you. A first report :

You must correct CORFON, by checking that MESH%KNOLG%I(a) is > 0 before trying to modify ZF at this address, otherwise you change a ZF%R(0) which may trigger problems.

After that, it worked on Intel up to 17 processors, but seems to stop in PROPAG with 32 processors.

Nag compiler is more interesting and says that there is a problem of buffer size when reading on the weirs data file. It works up to 32 processors if I change in lecsng.f the first END=900 into ERR=900 (just when we skip the line of comments, very strange... this comment line triggers the buffer problem, this is not understandable !).

I keep trying but it could be that we are playing with some maximum size of lines in a formatted file.

With best regards,

Jean-Michel Hervouet

Hello Jean Michel,

I have never seen problem in CORFON with this way to program. Do you think it depends on the machine/configuration?

I have tried to replace END=900 by ERR=900, there is no difference in my simulations, it stops at the first time step for both.

When you talk about maximum size of lines in a formatted file, do you have an idea of the limit value?
I have tried to reduce the size of the lines by clipping the weirs. I have now 44 weirs with a maximum of 99 points. I have already the same mistake with more than 16 processors... It works for 16 so I have "win" one processor but it is not enough!

Should I reduce the maximum points yet?
Have you another idea?

Regards

Hello,

No, there must be another problem, and I can look for it with the Intel compiler, where there is a crash in propag.f with your case and 16 processors, probably due to weirs, but a bit far from them, so it may take time to trace back. Anyway I am not currently at work so be patient...

Regards,

Jean-Michel Hervouet

Hello,

I got something. As soon as there is one sub-domain that has no boundary point, a call to P_DSUM for weirs in propag.f stops the program (because the sub-domain without boundary point sends no data...). This happens here in your initial mesh as soon as we have 18 processors (but partitioning is compiler and machine dependent...).

I enclose a tentative correction in subroutine propag.f (look for the sequence 17/04/2014 in the Fortran, a test IF(MESH%NPTFR.GT.0) THEN... is stopped before treating the weirs and started again after. This test was meant to avoid loops from 1 to 0, which are not very compiler friendly and you never know what they do in that case.

I hope it is the last problem, everything works here now,

With best regards, thanjk you for your patience,

Jean-Michel Hervouet

Hello Jean-Michel,

Thank you for your correction, I will test it on my computer.

Regards.

Hello Jean-Michel,

I finally got to test the configuration with more than 17 processors : it is successful.
Will you add this correction in the next release?

Thank you again.

Regards

Hello,

Yes of course, it is already on the trunk.

Regards,

JMH