Installing V2.2.1 on RedHat

[ChrisSig]

Hello,

I am trying to install Code Saturne V2.2.1 on Red Hat Enterprise Linux release 6.1. Versions of Python etc are all the defaults for this installation. I have installed the following packages to use with Code Saturne:

Med 3.0.4
CGNS 3.1.3-2
HDF5 1.8.8
Scotch 5.1.12 (not parallel)
OpenMPI 1.4.3

I know the above are all working ok because I have used them to build Saturne V2.0.4 which appears to work fine. However I would like to be able to use SYRTHES 4 and I think I need Saturne V2.2 to do this.

I have tried both the automatic Python installation and launching the configure script from the terminal myself. Using both methods, I have the same two issues:

1. Scotch is not recognised by the installer (all the scotch related messages at the end of running configure say "no")

2. I can launch the GUI and edit .xml files fine. However, when trying to run calculations, I get the following error messages:
"YACS_ARG=: Command not found.
SALOME_CONTAINERNAME: Undefined variable.
solver script exited with status 1."
I get these whether running with 1 or multiple processors. Looking at the code generated in run_solver.sh, I think something is wrong at the start under the heading "Detect and handle running under SALOME YACS module". The preprocessor log appears to show successful execution.

I am not sure what is going wrong in either case. I have attached my config.log and runcase.log files (the case I am running is the example 1-simple_junction with no modifications).

Chris

[Yvan Fournier]

Hello,

The issue with SCOTCH is due to a bug, which I just fixed. You may replace the configure file at the Code_Saturne root with the one attached (for the source fix, check the m4/sc_scotch.m4 file in the source code repository, at http://code-saturne.org/viewvc/saturne/ ... Version2_2 or http://code-saturne.org/viewvc/saturne/trunk).

For the issue relative to YACS_ARG and SALOME_CONTAINERNAME, could you post the "run_solver.sh" from your execution (temporary execution or RESU/<run_id>) directory? Which shell are you using?

Best regards,

Yvan

[ChrisSig]

Yvan,

Thanks for your quick response. I have attached the run_solver.sh, which is the script I believe to be wrong (I have zipped the file so I can post it). The header specifies csh, but the code looks to be bash. I use csh at the terminal.

Chris

[Yvan Fournier]

Hello,

The error is certainly due to the mix between csh and sh. Normally, the shell type used for the run_solver.sh is the one of the user when it is a Bourne shell variant (so as to be as close as possible to the user's settings), but it should be forced to "sh" when the user uses a C shell.

The forcing does not work due to a typo (sorry, we do not use C-shells very much, so this was not seriously tested; I will commit the fix today), but to correct it, simply edit file bin/cs_exec_environment.py, and at line 73, replace

Code: Select all

elif user_shell[-3] == 'csh':

with

Code: Select all

elif user_shell[-3:] == 'csh':

(missing colon).

You will the need to re-install the code, or edit the installed bin/cs_exec_environment.py file in <install_prefix>/lib/python_<python_version>/site_packages/code_saturne.

Regards,

Yvan

[ChrisSig]

Yvan,

Thank you again for your quick response. With this fix, the solver now runs in both single and parallel test cases (I also successfully compiled with scotch). I get an error message to the terminal at the end of the run as follows:

/home/ed03265/temp/1-simple_junction/case1/RESU/20120615-0957/run_solver.sh: line 10: module: command not found

However the calculation appears to run to completion, run_solver.sh is removed from the RESU directory so I cannot look at the code in this script after running it. I guess this is nothing to worry about?

Regards,

Chris

[Yvan Fournier]

Hello,

The warning about the module command should not be an issue.

Actually, when building Code_Saturne, the configure script tests the presence of the "module" command (environment modules), and if present, saves which modules are loaded (if any). This way, when running the code, the script may call "module purge", followed by "module load <module>" for all recorded modules.

This allows building different versions of the code side by side with different modules (for example different compiler versions), and ensuring the code uses the same environment when running as when it was built.

In cases where the user shell is too different from the shell used by configure (forced to /bin/sh), or when using very old versions of the "module" command (prior to the Python API), this may not work so well: the "module" command may have been found but not used.

I know Fedora Linux uses environment modules (as do some supercomputing clusters), thoug Debian and Ubuntu do not (at least by default), so I would not be surprised that your Red Hat system uses them also.

But in any case, if when you type "module list", you get an empty list, you can ignore the warning. If the list is non-empty an contains libraries relevant to the Code_Saturne build, you won't have issues as long as you do not run with modules different than those used at compilation time, and otherwise, you can always always force the initial environment back to the build environment using modules.

Also, if you ever need to look at files such as run_solver.sh that are removed after a correct run, you can use the "--initialize" and "--execute" options to "code_saturne run" (the default is equivalent to calling "--initialize --execute --finalize").

Regards,

Yvan