code_saturne User's Forum

Hello,

I am working on a PBS cluster. The libraries being different on the frontend and computation nodes, I tried a cross-compiling installation.

Now,I don't understand how to link the two versions installed. In the .profile I have to link code_saturne
cspath=/Calcul/Apps2/saturne4.2.4/v214/code_saturne-2.1.4/arch/frontend/bin
##(adjust path to your system)
if [ -d $cspath ] ; then
export PATH=$cspath:$PATH
fi

I edited the code_saturne.cfg in
/Calcul/Apps2/saturne4.2.4/v214/code_saturne-2.1.4/arch/frontend/etc

[install]
### Select the batch system type and job template.
batch =PBS
###
### Define installation prefixes of alternate builds for compute tasks
### (parallel partitioning, solver).
### Either the absolute name or the base name of the installation prefix may
### be used (using the more concise base name assumes a consistent naming
### scheme, with builds installed side-by-side).
compute_versions =/Calcul/Apps2/saturne4.2.4/v214/code_saturne-2.1.4/arch/noeuds

###

But the path in the runcase file is
/Calcul/Apps2/saturne4.2.4/v214/code_saturne-2.1.4/arch/frontend/libexec/code_saturne/cs_solver --param calcul.xml --mpi $YACS_ARGS $@

I don't understand how to link the frontend and computation versions.

Best regards

Erwan

Hello,

I just tested this, and there seems to be a bug in the handling of alternative compute versions.
The bug only occurs if you use an absolute path, so since you seem to have a consistent naming scheme (which is recommended), you should be able to ignore the bug using:

compute_versions =noeuds

instead of:

compute_versions =/Calcul/Apps2/saturne4.2.4/v214/code_saturne-2.1.4/arch/noeuds

The fix has been commited (so it should apear in this night's Subversion mirror for versions 2.1, 2.2, and trunk), so the absolute path should work by the next release.

Also, note that alternate compute versions are useful for machines where the front-end nodes and compute nodes are different architectures (such as IBM Blue Gene's or possibly Cray XT's) but are not useful on most clusters (as long as installed libraries are consistent across compute and front-end nodes).

Thanks for the feedback, and Best regards,

Yvan