open TELEMAC-MASCARET The mathematically superior suite of solvers

This has shown up in previous posts where the solver hits a Nan situation eg 0/0.

I have had the experience where a longterm run continued through a Nan solver problem, and competed the whole run of months, where it should have failed very early in the calculation. There were a number of sequential cas files running the job, and each one was started and ran to completion generating only Nans throughout.

The solvers do not check if an Nan occurs. Also you cannot activate a generic trap_nan on the compiler if you are using multi processor code as this can trigger pre-mature failures. So the solver codes should check for Nan's, probably when calulating the error estimate (for the iterative methods).

this would make a more robust system.

PS My problem related to a poor conditioning for the particular solver that could be fixed.


John

Hello John,

I do not really understand your remark :

"Also you cannot activate a generic trap_nan on the compiler if you are using multi processor code as this can trigger pre-mature failures"

As I am (should say was, now retired...) mostly doing developments I always do my tests with full checking of errors, divisions by 0, etc. When it crashes, even in parallel, I get the reason why and the sequence of calls, and the guilty line (essential for debugging), and I never noticed a pre-mature failure. The only drawback is that it is time consuming and cannot be used unless you accept a slow down of a factor 4.

However you are right, if there is a portable way in Fortran of checking a NaN, we could do it at the level of solvers. So far I am not sure that it exists, dealing with NaN gives a rather fuzzy logics.

With best regards,

Jean-Michel Hervouet