open TELEMAC-MASCARET The mathematically superior suite of solvers

Hello,

I just compiled the latest version of Telemac (release 2843) on a Windows 7 - 64-bit PC. I initially tried compiling the software with g95 (Perl), but I was only able to compile a scalar version. I was not really surprised since there is a comment in the systel.ini file about the g95 version not being tested. As a second attempt, I tried compiling Telemac with Intel Fortran compiler. I was able to compile the software completely (scalar and parallel) under Perl (and later Python). However, the problem is that any simulation that is launched goes on idle at the first or second iteration. For instance, I tried to run simulations that were running fine under T2D v6.1 (installed from a Windows installer) but these simulations turned to idle at t=10s (e.g. the first iteration). The computer is definitely doing something, but I'm not sure what exactly: all CPUs are working at maximum capacity (the simulation is still running), but nothing changes in the dos window, even after reducing the value of the 'listing printout period' to 100 (which is small for this simulation). See the .log files for the simulation output. I have also attached the .ini and .cfg files. I added a .txt extension to the .ini file in order to attach it to this message.

I have also attached a file that contains all the steps that I followed during the installation process (see telemac-win7.txt). Section 'Configuration #2' corresponds to my first attempt (with g95/Perl) whereas section 'Configuration #3' corresponds to my second attempt (with Intel Fortran 11.1 and Perl/Python). The steps comprised in the section 'Always required' were accomplished in both cases.

Let me know if you have an idea on what might be the problem. At this point, I'm not sure where to look. At least, if there was an error message, I would have a hint...

Yannick

Hi,

Thanks for all the info.
I cant see anything wrong in your files.
You clould try to run the case with the following line in the case file:
DEBUGGER = 1
It should give you more information on where the code is idling.

Hope it helps,
Yoann

Hello Yoann,

Thank you for your recommendation. I enabled the debugger, which produced much more output, but I'm still not sure why my simulation is turning to idle. I can count 99 "BOUCLE 701 ISOUSI" sections between iterations 0 and 100 and 64 "BOUCLE 701 ISOUSI" sections after iteration 100. In other words, the program stops working at iteration 164, but without officially crashing inelegantly. It looks as if the code was stuck in a 'while (true)' loop. I will take a look at the source code tomorrow. Also, I will compile v6.1 to verify whether the same problem happens.

Yannick

Hello,

This is puzzling. I wonder whether it is worth trying the latest version of the main trunk. Can you send us a case (inputs) which does not work for you in v6p2 ?

Thanks,
Sebastien.

Hello Sebastien,

I made further testing using both v6p1 and v6p2, compiled using exactly the
same procedure, but I obtained slighlty different behaviours between the
versions in the scalar mode. However, no simulation completed successfully under
the parallel mode for both versions.
In v6p1, the problem seems to come from partel.exe.
In v6p2, the numerical simulations that are able to complete slow down
considerably between iterations 163 and 166. I initially thought that the
application was frozen but it is not. After this, there are no more fluxes at
the three liquid boundaries (NA M3/S).

The case that I used for these tests is the confluence validation case (#17) for
Telemac2D. The only modification that I made was to disable the t2d_confluence.f
fortran file declared in the .cas file.

Previously, I was able to launch this valication case within v6p1, but
installed from a Windows installer that was previously available in the download
section (the executable file that I have is dated from 2011-11-29). With this
version, the validation case works fine, even with multiple processors. I also
created a case derived from case #17 (with sediment transport enabled) and
it works great in v6p1 (again, installed from the Windows installer).

I have attached the .sortie and configuration files used in my tests. I have
also attached the validation case, even if it is available.

I initially tried to compile and use v6p1 in Ubuntu 11.04 (last year), but
at the time, there was a problem with the parallel mode (and I needed it to
obtain high spatial and temporal resolutions). Since I was a little bit in the
rush, I then installed the pre-compiled v6p1. But, now I would like to be able
to compile the application in order to modify the Sisyphe module.

Let me know if you have any hint about what is wrong with my configuration.

Regards,

Yannick

Hello,

It looks like it is something wrong with your MPI library (not compile with same compiler, etc something else).

To see if v6p1 works, can you copy the executable of PARTEL from your working v6p2 into your v6p1 -- just so it passes that step and to check what TELEMAC does in v6p1 once the files have been split. (alternatively, you can also copy the partel.f from v6p2 to v6p1 and recompile under v6p1).

Thanks,
Sebastien.

For PARTEL on Windows or Ubuntu, make sure you use METIS 5 (it used to be METIS 4). Note that if you can go back to Ubuntu, that one should be piece of cake ... easier than Windows install / compilation.

Sebastien.

Also, following on our Canadian colleague Martin Serrer's comment and a separate thread, can you try a different test with optimisation /O2 (instead of /Ot) ? You need to recompile it all (with -m "clean system" under python).

Hope this helps,
Sebastien.

Hello Sebastien,

The situation has slightly improved in the last two days. My v6p1 installation
now works fine (with Perl and Python), in both the scalar and parallel modes,
after using the partel.f file from v6p2.

I confirm that I'm using Metis 5b, which I downloaded from Telemac web site. I'm using the same libmetis.a file (renamed to libmetis.lib) for v6p1 and v6p2. Since v6p1 works fine, I assume that the problem encountered in v6p2 must not be due to the Metis library.

I was able to launch a simulation with two processors after updating the
parameter mpi_cmdexec from:
mpi_cmdexec: C:\mpich2\bin\mpiexec -wdir <wdir> -n <ncsize> <exename>
to
mpi_cmdexec: C:\mpich2\bin\mpiexec -localonly -wdir <wdir> -n <ncsize> <exename>
but I still obtain a problem which starts around iteration #161.

I tried replacing /Og by /O2 in the parameter cmd_obj (and recompile with the 'clean system' option), but I did not notice any difference.

The only problem left happens when I use 2 processors (with Perl or Python).
In the confluence case, the fluxes at the boundaries should be:
0.150 m3/s (bound. #1), 0.035 m3/s (bound. #2) and 0.070 m3/s (bound. #3). The
volume in the domain is approximately 2.28 m3 until iteration #161. Then, it
suddenly rises to 360 m3 (iteration #162), to 0.1524609E+13 m3 (iteration #163), to 0.5637249E+29 m3 (iteration #164) and to 0.4246835E+62 m3 (iteration #165). That's a massive amount of water for this poor tiny flume. After this iteration, the volume of water goes to NA, probably because my computer does not deal with larger values, and input and output fluxes then go to NA. I'm not sure what triggers this water accumulation. I will take a closer look at it.

Again, I attached the log files.

Yannick

Hello,

The most probable is that the model is unstable for some reason, like time step too high, giving infinite velocities, but why it would work in scalar mode ? Or you have a specific Fortran file that is not parallel compatible ?

Regards,

JMH