code_saturne User's Forum

Deal all,
 
I've just installed UBUNTU 11.10 on a new machine and Ive seen that it was feasable to install Code_Saturne 2.02 thanks to "Ubuntu software center". I've tried this and installation seems to be fine.
I've tried to run a case that I prepared on another machine (and ran succesfully previously) and I noticed that my user routines are not "used" with Code Saturne installed thanks to "Ubuntu software center" even if it is writen that compilation/link is OK (If I run a case that not needs user routines, things are going well). If introducing volontary a bug in my routines, I have a error return from Code_Saturne, which means that the compilation step is not skipped...
Did someone already faced this problem? Have you any suggestions in order to solve it?
Regards.
Julien

Hello,

I tested this tonight, and reproduced the problem, which seems quite subtle, and probably a packaging issue.

I have somewhat detailed diagnostics, but no final explaination, so we will need to report this to the Debian/Ubuntu package maintainers.

I basically got this far :

if I add a function in usini.f90, and call it, running "nm cs_solver" in the temporary execution directory shows the added function, but it is never called (i.e. the reference file seems called first)

If I build the kernel with the following configuration;

../../ncs-2.0/configure --prefix=/usr --with-mpi=/usr/lib/openmpi

then install it (overwriting the Ubuntu code-saturne-bin package), then user subroutines work normally (using the same user version of usini1.f90, just relinking with:

gcc -o /home/yvan/tmp_Saturne/tu.CASE1.02142302/cs_solver *.o -L/usr/lib -lsaturne -Wl,-export-dynamic -Wl,-Bsymbolic-functions -O -lfvm -lcgns -lmedC -lhdf5 -lm -lfvm_coupl -lmei -lbft -lz -lmpi  -lxml2 -lblas  -L/usr/lib/gcc/i686-linux-gnu/4.6.1 -L/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu -L/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../../lib -L/lib/i386-linux-gnu -L/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/i686-linux-gnu/4.6.1/../../.. -lgfortran -lm -lquadmath   -ldl

(adust temporary directory for our case, but the rest is exactly what is used by the Ubuntu package, as determined by the compile.log)

If I reinstall the Ubuntu code-saturne-bin package, which overwrites /usr/lib/libsaturne.so*, an a few other files which have not relevance at this stage, then the bug appears again.

I compared a 2.0.4 "vanilla" (unmodified) version of Code_Saturne to a 2.0.2 "Ubuntu (Debian) version, but the switch from 2.0.2 to 2.0.4 should have no impact here (none of the changes between 2.0.2 and 2.04 are expected to relate to this; I would suggest a packager to debug the issue base on a 2.0.4 just to be sure, but I beleive the problem is more subtle, and related to linker issues)

Here are the outputs of "objdump -x /usr/lib/libsaturne.so"  (packaged and vanilla) versions. The output of "ldd /usr/lib/libsaturne.so" on both versions is also almost the same (only adresses change).

I also added the modified usini1.f90 I tried, which should result in the code exiting with message "active" being output.

Note that I ran "strip /usr/lib/libsaturne.so" on the vanilla version to reduced the differences (otherwise, objdump had an additional section), but this did not seem to affect the bug (the stripped vanilla version did not exhibit the bug, while the packaged version did), so I am out of options to explain this bug.

We will transmit these notes to the Code_Saturne packager, and hopefully get information.

I also ran into an initial additional bug; I had both OpenMPI and MPICH2 packages installed, and the /usr/lib/lbmpi.so points to /etc/alternatives/libmpi.so, which seems to depend on the installation order of mpich2 and OpenMPI, while both have different dependencies, but this is a secondary bug (uninstalling then reinstalling MPICH2 solved this one).

Best regards,

  Yvan

Here are the object dumps: