open TELEMAC-MASCARET The mathematically superior suite of solvers

Hello all,

The problem first occurred in my current project where I am chaining TOMAWAC with ARTEMIS as it is done in test case chwac1. I apply this chaining in all of my latest projects, but since v7p2r0 it doesn't work and the model crashes with no hint to the source of the problem. So I decided to run the test case chwac1 to verify that it is not my model that has a chaining configuration problem.
So, chwac1 crashes with the following output (in scalar):

I am running a new installation with mingw-64 6.3.0 and and the latest MSMPI/METIS/LAPACK/SCALAPACK/MUMPS libraries, so that was a concern at the beginning but I have checked with other test cases and they work perfectly (bj78, btwi) in scalar or parallel (direct solver and MUMPS).
Can anyone verify it works on their system (v7p2r0 installation).

Best Regards,
Costas

Hello Costas,

Can you try with the trunk on the test case chwac1 and on your problem ?

Please let us know.

Sébastien.

Well, the trunk is giving errors when compiling NESTOR, so I have avoided using it at this stage. I will give it a go and report.
Costas

Also, please note that we are currently re-coding the coupling mechanism with TOMAWAC (we have not merged that part yet to the trunk), and will provide scripts to transform SWAN output into TOMAWAC output, so that ARTEMIS could be chained with either.

We are hoping to complete this before the end of March.

Sébastien.

First attempt with a parallel configuration gives a similar error:

I cannot compile the scalar-debug configuration I used in the v7p2r0 tag because of the NESTOR issue. However, I suspect it is not a scalar/parallel problem.
Maybe this can be attributed to the re-coding of the chaining mechanism you mentioned. What would be (approximately) a late revision of the trunk I could use until you complete the re-code?
Costas

You need to add (for now) the option -cpp in your cmd_obj for NESTOR to compile on the latest revisions of the trunk. We are trying to find another solution for v7p3, but -cpp should work.

We have not yet touched anything in the trunk to do with the coupling (we are making our developments in a separate branch, which will be validated first before the merge with the trunk). So the latest trunk is your friend.

Also, the (nightly) automated validation of the system runs chwac1, but only in scalar mode it seems - and there is probably a reason for this. I will investigate running it in parallel as well.

Sébastien

I tried this flag but it doesn't seem to work. I tried it in "cmd_obj_c" as well but it nothing. What does it do? Is it for gcc or Intel?
Costas

The (gfortran) flag force a compiler scan for compiler directive. We have so far tried to distinguish those files with compiler directives (upper case extension .F) form those without (lower case extension .f).

With the arrival of NESTOR and a fancy way to create interface, this is not possible anymore and we therefore have to force the scan for all files (with that flag). You have a different flag for Intel, or Intel may do the scan by default.

Sébastien.

Can you show us your screen output for your compilation (and your config files ?)

I though that using update instead of clean would do for NESTOR since it failed previous compilation. But after your explanation I though a clean compilation is needed.
It takes more time with the -cpp flag, but it appears NESTOR compiles and compilation continues to the rest of the modules. I will post the full output if anything goes wrong.
Thank you for your help.
Costas