Compilation problem using standard user routine

Questions and remarks about code_saturne usage
Forum rules
Please read the forum usage recommendations before posting.
PFERRO
Posts: 8
Joined: Mon May 27, 2019 4:49 pm

Compilation problem using standard user routine

Post by PFERRO »

Dear code_saturne user's,

I am facing a problem when trying to use standard user routines :
  • cs_user_extra_operations.c. : code_saturne stops at the compilation stage. Note that the routine is as provided by code_saturne, i.e empty.
  • Additional tests have been made with the cs_user_head_losses.c routine. In that case the standard routine is compiled but not called by the code during the CFD model solving process. In deed no change on the results are observed. Moreover, adding this line
    bft_printf(" I AM HERE");
    outside of the cell loop has no effect
  • The problem appears with code_saturne 6.0.2 as well as 6.0.4.
  • code_saturne has been installed on a fresh installation of ubuntu 18.04 LTS
code_saturne seems to complain due to C reading. At the installation step the C compiler is left by default:
compC /usr/bin/cc
mpiCompC /usr/bin/mpicc
Thanks in advance for your help.

Compilation error message
/home/user/Desktop/saturne/newCases/45/RESU/20200709-1200/src/cs_meg_boundary_function.c: In function ‘cs_meg_boundary_function’:
/home/user/Desktop/saturne/newCases/45/RESU/20200709-1200/src/cs_meg_boundary_function.c:49:17: warning: unused variable ‘f_id’ [-Wunused-variable]
cs_lnum_t f_id = zone->elt_ids[e_id];
^~~~
/home/user/Desktop/saturne/newCases/45/RESU/20200709-1200/src/cs_meg_initialization.c: In function ‘cs_meg_initialization’:
/home/user/Desktop/saturne/newCases/45/RESU/20200709-1200/src/cs_meg_initialization.c:47:17: warning: unused variable ‘c_id’ [-Wunused-variable]
cs_lnum_t c_id = zone->elt_ids[e_id];
^~~~
/home/user/Desktop/saturne/newCases/45/RESU/20200709-1200/src/cs_user_extra_operations.c:111:1: error: conflicting types for ‘cs_user_extra_operations’
cs_user_extra_operations(void)
^~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/user/Desktop/saturne/newCases/45/RESU/20200709-1200/src/cs_user_extra_operations.c:68:0:
/home/user/Code_Saturne/6.0.2/code_saturne-6.0.2/arch/Linux_x86_64/include/code_saturne/cs_prototypes.h:330:1: note: previous declaration of ‘cs_user_extra_operations’ was here
cs_user_extra_operations(cs_domain_t *domain);
Yvan Fournier
Posts: 4075
Joined: Mon Feb 20, 2012 3:25 pm

Re: Compilation problem using standard user routine

Post by Yvan Fournier »

Hello,

Could you post your user files ? It seems you may have tried to use a file from an older version of the code (in which the "domain" argument did not exist ?

Also, did you compile the code in all cases or do you have an Ubunti code_saturne package installed ? The Ubuntu package may be buggy (https://bugs.launchpad.net/ubuntu/+sour ... ug/1672585), so you need to remove it if you hve that installed.

Regards,

Yvan
PFERRO
Posts: 8
Joined: Mon May 27, 2019 4:49 pm

Re: Compilation problem using standard user routine

Post by PFERRO »

Dear Yvan,

Thank you for your quick answer. Please find attached a test case. This test case has not been built from an old case.
code_saturne has been compiled from source (using the python script).

Best regards,

Paulin
Attachments
testCase2.zip
(7.55 MiB) Downloaded 153 times
Yvan Fournier
Posts: 4075
Joined: Mon Feb 20, 2012 3:25 pm

Re: Compilation problem using standard user routine

Post by Yvan Fournier »

Hello,

The attached cs_user_extra_operations.c file seems to be from version 5.3.3, while the rest is code_saturne 6.0.x.

Could you re-base cs_user_extra_operations.c on version 6.0 ?

Regards,

Yvan
PFERRO
Posts: 8
Joined: Mon May 27, 2019 4:49 pm

Re: Compilation problem using standard user routine

Post by PFERRO »

Dear Yvan,

Thank you for your answer. In deed, using newer version of the routine make things easier. The compiler is now ok but routines are still not called during the CFD process (printf test).

Would you recommend to change Lunix distribution ? If it's the case what would be the best (free) distribution from your point of view ?

Best regards,

PF
Yvan Fournier
Posts: 4075
Joined: Mon Feb 20, 2012 3:25 pm

Re: Compilation problem using standard user routine

Post by Yvan Fournier »

Hello,

Could you try with version 6.0.4 instead of 6.0.2 first (there is a modification intended to help with this).

Also, could you post the output of "ldd" on the cs_solver file present in the execution directory during the computation (removed at the end, unless you use "initialize only" on the run setup in the GUI and start the code manually) ?

Regards,

Yvan
PFERRO
Posts: 8
Joined: Mon May 27, 2019 4:49 pm

Re: Compilation problem using standard user routine

Post by PFERRO »

Dear Yvan,

Using code_saturne 6.0.4 doesn't solve the problem. Please find below the result of ldd command on the cs_solver file :
linux-vdso.so.1 (0x00007ffe4e9e0000)
libcs_solver-6.0.so => /home/user/Code_Saturne/6.0.4/code_saturne-6.0.4/arch/Linux_x86_64/lib/libcs_solver-6.0.so (0x00007f5ec605e000)
libsaturne-6.0.so => /home/user/Code_Saturne/6.0.4/code_saturne-6.0.4/arch/Linux_x86_64/lib/libsaturne-6.0.so (0x00007f5ec4879000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5ec44db000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5ec40ea000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f5ec3ebb000)
libple.so.2 => /home/user/Code_Saturne/6.0.4/code_saturne-6.0.4/arch/Linux_x86_64/lib/libple.so.2 (0x00007f5ec3ca8000)
libcgns.so.3.4 => /home/user/Code_Saturne/6.0.4/cgns-3.4.0/arch/Linux_x86_64/lib/libcgns.so.3.4 (0x00007f5ec39df000)
libmedC.so.11 => /home/user/Code_Saturne/6.0.4/med-4.0.0/arch/Linux_x86_64/lib/libmedC.so.11 (0x00007f5ec36a2000)
libptscotch.so => /home/user/Code_Saturne/6.0.4/scotch-6.0.6/arch/Linux_x86_64/lib/libptscotch.so (0x00007f5ec3455000)
libscotch.so => /home/user/Code_Saturne/6.0.4/scotch-6.0.6/arch/Linux_x86_64/lib/libscotch.so (0x00007f5ec31bf000)
libgfortran.so.4 => /usr/lib/x86_64-linux-gnu/libgfortran.so.4 (0x00007f5ec2de0000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f5ec2bc3000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5ec29bf000)
libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20 (0x00007f5ec26cd000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5ec24ae000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5ec6467000)
libhdf5.so.103 => /home/user/Code_Saturne/6.0.4/hdf5-1.10.5/arch/Linux_x86_64/lib/libhdf5.so.103 (0x00007f5ec1ed0000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f5ec1b47000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5ec192f000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f5ec16ef000)
libopen-rte.so.20 => /usr/lib/x86_64-linux-gnu/libopen-rte.so.20 (0x00007f5ec1467000)
libopen-pal.so.20 => /usr/lib/x86_64-linux-gnu/libopen-pal.so.20 (0x00007f5ec11b5000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f5ec0fad000)
libhwloc.so.5 => /usr/lib/x86_64-linux-gnu/libhwloc.so.5 (0x00007f5ec0d70000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f5ec0b6d000)
libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f5ec0962000)
libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f5ec0758000)
Note that for the installation I have done the following things :
sudo apt-get install build-essential
sudo apt-get install cmake
sudo apt-get install python-qt4
sudo apt-get install python-qt4-dev
sudo apt-get install pyqt4-dev-tools
sudo apt-get install zlib1g-dev
In the setup file for 6.0.4
mpiCompCxx mpicxx
mpiCompC mpicc
Best regards,

PF
Yvan Fournier
Posts: 4075
Joined: Mon Feb 20, 2012 3:25 pm

Re: Compilation problem using standard user routine

Post by Yvan Fournier »

Hello,

I just remembered there is one last thing to check:

if you prepare the case and run in "initialize only" mode (same as for ldd) and check the "run_solver" script (with any text editor), you will either have a line containing the full path of cs_solver, or "./cs_solver".

In the first case, that would mean the script uses the wring executable (I have seen it in only one case, but in this case, the solution is quite different/simple). If you have "./cs_solver", it really means there is an issue with the user functions (though you may double -check, as the "print" statements might appear in the "listing" file or the terminal).

If this still fails, any other distribution should do, though I am most familiar with Debian and Arch besides Ubuntu (Debian at work, Arch at home), and have some experience with Red Hat or CentOS.

Best regards,

Yvan
PFERRO
Posts: 8
Joined: Mon May 27, 2019 4:49 pm

Re: Compilation problem using standard user routine

Post by PFERRO »

Hello Yvan,

I am not sure to understand your last message. I have copied below the run_solver script. What should be the line containing the path ?
#!/bin/bash

# Export paths here if necessary or recommended.
export LD_LIBRARY_PATH="/usr//lib":$LD_LIBRARY_PATH

export OMP_NUM_THREADS=1

cd /home/user/Desktop/saturne/newCases/45/RESU/20200710-1432

# Run solver.
mpiexec.openmpi -n 4 ./cs_solver --mpi $@
export CS_RET=$?

exit $CS_RET
Best regards,
PF
Yvan Fournier
Posts: 4075
Joined: Mon Feb 20, 2012 3:25 pm

Re: Compilation problem using standard user routine

Post by Yvan Fournier »

Hello,

Yes, this is the file i wanted to see.

Checking again the previous logs, did you test placing "bft_printf" in another file/function such as cs_user_parameters ?

Note that for cs_user_head_losses, the function is called once for each zone defined as having head losses (in the gui or in cs_user_zones). So if you did not define appropriate zones, and tag them for head losses, the behavior might be normal.

Regards,

Yvan
Post Reply