open TELEMAC-MASCARET The mathematically superior suite of solvers

I am using Window 7 on a 64bit machine, Python 2.7.3, gfortran4.7.2, 32bits (from www.equation.com/servlet), and opentelemac extracted from wingfortran32_V6p2. I am running telemac2d and found several issues:

• Similarly to many other users, to be able to run, I have to have the full path of runcode
“Python c:\opentelemac\v6p2\pytel\runcode.py telemac2d cas” instead of
“Python runcode.py telemac2d cas”

• My first trial was with Malpasset, and it would give #INF in the downstream portion of the model. I solved the problem by initializing to 0 the depth H in routine CORSUI. This is surprising because telemac2d is always very good at initializing variables (in case a compiler does not do it by default, such as the one I am using), except in this case.

• If I write on file 29, FORMATTED RESULTS FILE, it does not copy it back from the temp directory to my work directory, although the file T2DRFO is properly created in the temp. The last message is:
moving: result.slf
My work is done
without any mention of T2DRFO

• In many cases during quick initial trial runs, we run telemac, and check the results in Blue Kenue. We do not necessarily change the result file name. If a result.slf file is loaded in Blue Kenue, and we have a new run with the same result file name, it does not move the new RESULT FILE from the temp directory to the work directory.. The xxx.old file is created but the new file is not, with the message:

"uncontroled error from python:: It could not copy the output files back from the temporary directory:
c:\Temp\malpasset6.2\cas_gb_2.txt_2013-03-24-16h40min35s:
WindowsError(32, 'The process cannot access the file because it is being used by another process')"

This is something which did not happen with version 6.0 where the new run was completed and the result file created properly.

• The temp directory name, now, shows the time when it was created. This is much better than the process number. Very good idea. But the local time would be more useful than GMT time, for users outside the GMT time zone.

Thierry

Hello Thierry,

I'm not the best person to answer to your questions, but I will give a tentative answer and I hope that more skilled colleagues will round it off.
1-you have a 64 bit machine and (if I've well understood) you are using a precompiled version in 32 bit, which could be the origin of some of your troubles. The best way is to download the code through svn and to compile it on your machine
2- point 1 can solve the issue of calling the code with the path. Actually, you need to add the path of pytel in environment variables (in control panel -->advanced --> environment variables ) and thus, the command runcode.py will be recognized by the system
3-For the Malpasset case, it's strange that you have such problem. In the "official" validation case (downloadable from SVN) the CORSUI routine is called properly in CONDIN routine and H is initialized to 0. I recommand that you update your files (svn update).
4- The best way to write (additional) variables in the result file is the use of routine utimp_telemac2d (telemac2d/tel2d_v6p2/source) or by the use of routine preres_telemac2d (combined with routine nom_var and the use of private table). You can find an exemple of this use in the bumpflu validation case (011_bumpflu)
5- Point 4 could help solving issue 5.
6-your suggestion of adapting time is very relevant and we will see the possibility to implement it in the next release.

I hope that this is helpful
With my best regards

Riadh ATA

Hi Thierry,

A few complement to Riadh explanation.

• T2DRFO: It is no longer the case in the new version
• Blue Kenue: This has been solved in the next version

Thank you Yugi

When is the next version of Telemac scheduled to be released?
Thierry

Thank you Riadh.

Item 2-
I do have in my environment variable the paths to python27 and to pytel, and the command "runcode.py" is recognized.

But the command “python runcode.py telemac2d cas” gives the message:

python: can't open file 'runcode.py'

I have resolved the problem by creating a scrip called telemac2d.bat which contains the line (similar to what we had on version 6.0):
python c:\opentelemac\v6p2\pytel\runcode.py telemac2d %1 %2 %3 %4 %5

Item 3-
I am confused. I thought that the svn version, compared to the precompiled version, was providing only a new environment which allowed easier update of new upcoming versions of telemac. I thought that the quality and bugfixes of both svn and precompiled versions would be the same. It sounds like this is not the case. Could you please clarify this point?

Thierry

Hello Thierry,

The next release is expected for the end of the summer.
The precompiled version is provided in order to deal with very standard use of telemac. What we recommanded usully is to download the current version from svn and to check from time to time if there are any improvements or bugfixes (with svn update for instance).
I'm not absolutely sure that the precompiled version is always strictly synchronised with the latest svn version. I let my colleages Alain and Yoann correct or confirm may claims.

With my best regards

Riadh

Hi

About your problem with Python.
If you run with python runcode.py ... the file must be in the folder you run the command from.
If you run runcode.py the file just need to be in your path.
So i suggest you use the second one.

Yugi and Riadh

Thanks for your quick reply

Thierry