error when using user files for ALE

[eliberge]

Hello,

i am trying to use the ALE module on code_saturne 2.1.4.

When i add fortran user files, I have the following error in the listing :

Erreur système : Aucun fichier ou dossier de ce type

/home/eliberge/Bureau/saturnev-214/installer/code_saturne-2.1.4/src/base/cs_time_plot.c:341: Erreur fatale.

Erreur à l'ouverture du fichier "monitoring/probes_str_displacement_x.dat".


Pile d'appels :
1: 0xb656ce1c <bft_error+0x3c> (libbft.so.0)
2: 0xb66e924c <cs_time_plot_init_struct+0x124c> (libsaturne.so.0)
3: 0xb66e93fa <tpsini_+0x14a> (libsaturne.so.0)
4: 0xb676d11a <strhis_+0x912> (libsaturne.so.0)
5: 0xb667b8ef <caltri_+0x3d1f> (libsaturne.so.0)
6: 0xb6674282 <cs_run+0x722> (libsaturne.so.0)
7: 0xb6673a80 <main+0x240> (libsaturne.so.0)
8: 0xb5f07113 <__libc_start_main+0xf3> (libc.so.6)
9: 0x8050011 <> (cs_solver)
Fin de la pile

This error appears only using fortran user files, and it worked with older versions of code_saturne

Regards,

Erwan

[Jacques Fontaine]

Hello,

I can't compile your Fortran files. There were non-conforming tab characters (I think because of bad copy/paste...).
You can try to run your case with the attached proper Fortran file and check if there is still a problem.

Best regards,
JF

[eliberge]

Thank you,

but the probem stays the same. Perhaps I miss something ....

Please find in the attached file the result of the computation.

Regards,

Erwan

[Yvan Fournier]

Hello,

The "monitoring" directory is not created, so the file cannot be created. Checking the Subversion repository, this bug was fixed on Jan 24, while version 2.1.4 was tagged on Jan 13...

so the solution is to upgrade to the latest 2.1 version (2.1.6).

Best regards,

Yvan

[eliberge]

Hello,

Thank you. I can't acces to the bugtracker. What has changed with the last version (2.1.7). This version doesn't work on my PBS cluster. I have this error :

Traceback (most recent call last):
File "/Calcul/Apps2/saturne4.2.4/v2172/bin/code_saturne", line 49, in <module>
retcode = cs.execute()
File "/Calcul/Apps2/saturne4.2.4/v2172/lib64/python2.6/site-packages/code_saturne/cs_script.py", line 62, in execute
return self.commands[command](options)
File "/Calcul/Apps2/saturne4.2.4/v2172/lib64/python2.6/site-packages/code_saturne/cs_script.py", line 114, in run
return cs_run.main(options, self.package)
File "/Calcul/Apps2/saturne4.2.4/v2172/lib64/python2.6/site-packages/code_saturne/cs_run.py", line 201, in main
save_results=save_results)
File "/Calcul/Apps2/saturne4.2.4/v2172/lib64/python2.6/site-packages/code_saturne/cs_case.py", line 1702, in run
mpi_environment)
File "/Calcul/Apps2/saturne4.2.4/v2172/lib64/python2.6/site-packages/code_saturne/cs_case.py", line 1258, in prepare_data
n_procs_default)
File "/Calcul/Apps2/saturne4.2.4/v2172/lib64/python2.6/site-packages/code_saturne/cs_exec_environment.py", line 1199, in __init__
self.resources = resource_info(n_procs, n_procs_default)
File "/Calcul/Apps2/saturne4.2.4/v2172/lib64/python2.6/site-packages/code_saturne/cs_exec_environment.py", line 371, in __init__
if self.host_file[0] == '$':
AttributeError: resource_info instance has no attribute 'host_file'

It didn't happen with the 2.1.4 version.

Regard,

Erwan

[eliberge]

If i use the cs_execenvironment.py from the 2.1.4 version, it works.

Regards,

Erwan

[Yvan Fournier]

Hello,

There was a fix in 2.1.7 for the SGE batch system (whose directives syntax is a abomination, but unfortunately, some people seem to like/use it), and there seems a typo for other cases was added with the fix.

If you use the cs_exec_environment from 2.1.7, but simply replace self.host with self.hosts on line 371, do things work better as well ? This bug also occurs in 2.2.1 and trunk, but will be fixed in those.

In any case, it is difficult and costly to test all batch system/MPI type combinations, and as EDF tends to standardize on SLURM, we won't even have a cluster running PBS after September. I'll be happy using SLURM, which I prefer, or LoadLeveler, but we will rely on feedback from others to fix things we inadvertently break. Using a static Python analyzer would also help, but we have yet to test this.

Best regards,

Yvan

[eliberge]

Hello,

it works with self.hosts instead of self.host.

Thank you for your work.

Best regards,

Erwan