Code_Saturne (6.1.0) with Salome (9.4 Ubuntu 1804) building.

All questions about installation
Forum rules
Please read the forum usage recommendations before posting.
Post Reply
pici1251
Posts: 9
Joined: Wed May 20, 2020 11:11 am

Code_Saturne (6.1.0) with Salome (9.4 Ubuntu 1804) building.

Post by pici1251 » Mon Jun 08, 2020 2:58 pm

Hi to everybody.
I did many attempts to build CS6.0.2 with Salome ( in my machine, I installed Salome-Meca2019.0.3, SALOME-9.3.0-UB18.04-SRC and SALOME-9.4.0-UB18.04-SRC; all are working properly), using in turn each of Salome installed, but without any fortune.
Reading around this forum, where I found many different experiences, so I decided to try with newest CS6.1.0 and, finally, I was able to join together cs6.1.0 with SALOME-9.4.0-UB18.04-SRC.
I decided to use the Ubuntu version of Salome because SalomeMeca.19.0.3 Universal Version isn’t so Universal!.
For the moment, for me is enough to have cs6.1 embedded in Salome9.4. In a future, I will try with Code_Aster too.
I needed some preliminary steps, but I have to say that a complete installation of cs6.0.2 was already completed (without Salome) and it is working fine, so, all of prerequisites are already installed in my Ubuntu System, residing in /opt directory.
Another general annotation: because my /opt directory has 777 rights, it is not requested to use 'sudo'.

Step 1: I started using a Salome Shell, as suggested in various posts.

Step 2: I launched a configuration step with these options, using these commands:

Code: Select all

>cd /home/pici/Scaricati/CodeSaturne/code_saturne-6.1.0
>mkdir  code_saturne-6.1.0_build
>cd code_saturne-6.1.0_build
>mkdir prod_2
>cd prod_2
>source configura.sh
content of configura.sh:

Code: Select all

SRC_PATH=/home/pici/Scaricati/CodeSaturne
INSTALL_DIR=/opt/Code_Saturne/6.1.0
CS_OPT=/opt
#
#
$SRC_PATH/code_saturne-6.1.0/configure --disable-option-checking \
 --prefix=/opt/Code_Saturne/6.1.0 \
 --with-salome=/opt/SALOME-9.4.0-UB18.04-SRC \
 --with-hdf5=/opt/SALOME-9.4.0-UB18.04-SRC/BINARIES-UB18.04/hdf5 \
 --with-cgns=/opt/SALOME-9.4.0-UB18.04-SRC/BINARIES-UB18.04/cgns \
 --with-med=/opt/SALOME-9.4.0-UB18.04-SRC/BINARIES-UB18.04/medfile \
 --with-scotch=/opt/scotch-6.0.6/arch/Linux_x86_64 \
 --with-metis=/opt/SALOME-9.4.0-UB18.04-SRC/BINARIES-UB18.04/metis \
 --with-parmetis=/opt/parmetis-4.0.3/arch/Linux_x86_64 \
 --with-salome-gui=/opt/SALOME-9.4.0-UB18.04-SRC/BINARIES-UB18.04/GUI
I tried using something like –with-hdf5=salome , but it didn’t work at all.

Step 3: make : anything was right.

Step 4: make install: it exited with some error, just at last part of the execution.
The error was very strange: somewhere there is a call to a python executable that isn’t in /opt/SALOME-9.4.0-UB18.04-SRC directory, while ‘make install’ is searching for a directory named:

/volatile/salome/jenkins/workspace/Salome9_UB18/SALOME-9.4.0-UB18.04/INSTALL/Python/bin/python

In effect, I don’t have this path in my machine, but perhaps it exists in mr. Jenkins machine! ;)

The solution is easy to say (but a little bit hard to do): I located any occurrence of this directory name in /opt/SALOME-9.4.0-UB18.04-SRC/BINARIES-UB18.04 source code and I changed it redirecting installation to the one of the correct Python path.

Step 5: again make install: now all is perfect.

Step 6: first test: in a new salome shell window, I wrote:

Code: Select all

>/opt/Code_Saturne/6.1.0/bin/salome_cfd
It works fine; now I will use this for my Code_Saturne investigations.

I hope to be of help for other users.
Best Regards, many thanks and ciao
Piero

Attached files:
/opt/SALOME-9.4.0-UB18.04-SRC/BINARIES-UB18.04/omniORB/bin/omniidl (modified)
/opt/SALOME-9.4.0-UB18.04-SRC/BINARIES-UB18.04/PyQt/bin/pylupdate5 (modified)
/opt/SALOME-9.4.0-UB18.04-SRC/BINARIES-UB18.04/PyQt/bin/pyrcc5 (modified)
/opt/SALOME-9.4.0-UB18.04-SRC/BINARIES-UB18.04/PyQt/bin/pyuic5 (modified)
Attachments
omniidl.7z
omniORB/bin routine
(1.64 KiB) Downloaded 8 times
routines.7z
PyQt/bin zipped routines
(381 Bytes) Downloaded 8 times
Piero
hw: AMD Ryzen Threadripper 1900X 8-Core Processor × 8 - 64GB Ram
OS: Ubuntu-Mate 18.04 (preferred) + Windows 10Pro (needed)

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

Re: Code_Saturne (6.1.0) with Salome (9.4 Ubuntu 1804) building.

Post by Yvan Fournier » Mon Jun 08, 2020 8:33 pm

Hello,

Thanks for your geat feedback, and for helping others on this forum :-). Here are a few additional details:
  • I have had the same issue as you with paths based on the build (Jenkins) machine, but not updated by the installer; I should file a bug report, but so far, I have simply renamed directories manually (which works but is a pain, and does not solve the issue for others).
  • It is a pain that EDF and CEA and OpenCascade have 2 different installers. This was not synchronized in the beginning of the project, and I do not know the history, and requirements may differ, but as a developer for a builds on top of that platform, it is a pain...
  • We have completely dropped the "universal" version, as it was indeed not so universal.
    The main developer for the EDF SALOME build system (yamm) is quite busy on another project, and has very little time for maintenance of this system, but a lighter system (SCBI) is under test; hopefully we'll have something simpler soon.
  • On another aspect, SALOME 9.5 should try to use more native packages on different Linux distributions, when tool and library version ranges allow.
  • The --with-hdf5=salome, --with-med=salome, and --with-cgns=salome options may work or not, depending on whether the SALOME build contains those libraries or uses externel packages (in /opt).
    Also, they did not work with CAS (CEA/OpenCascade) builds, due to differently named variables, but I fixed this a few weeks ago, so this should work in the next maintenance release
  • In any case, you can use prerequisites from outside SALOME with the SALOME build of code_saturne, though using the same version numbers is recommended (for example, if you use a more recent version of MED in code_saturne than in SALOME, code_saturne will be able to read meshes generated by SALOME, but PARAVIS will not be able to read the more recent MED files; the other way around is worse, if you use SALOME for meshing).
Best regards,

Yvan

pici1251
Posts: 9
Joined: Wed May 20, 2020 11:11 am

Re: Code_Saturne (6.1.0) with Salome (9.4 Ubuntu 1804) building.

Post by pici1251 » Tue Jun 09, 2020 11:28 am

Hi Yvan,
thank you for your precise explanations.
For my future, I want to link CS to Salome-Meca (to test fluid-structure implementation = FSI): is it possible to build by scratch Salome-Meca 19? I was not able to find source codes. Obviously, I will write the same answer also in Code-Aster Forum.
Last question: to implement FSI , must I use Salome-Meca or could I try with Code-Aster stand-alone?

Again many thanks
Piero
Piero
hw: AMD Ryzen Threadripper 1900X 8-Core Processor × 8 - 64GB Ram
OS: Ubuntu-Mate 18.04 (preferred) + Windows 10Pro (needed)

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

Re: Code_Saturne (6.1.0) with Salome (9.4 Ubuntu 1804) building.

Post by Yvan Fournier » Tue Jun 09, 2020 11:58 am

Hello,

I am not familiar enough with the build system of Salome or salome_meca, so I usually take a binary build of salome_meca, and install code_saturne on top of that (a code_aster developer could probalby do it the other way around, building code_aster on top of salome_cfd).

To implement FSI with code_aster:
  • using code_saturne 6.0 or older, you will need salome_meca
  • using code_saturne 6.1 or later, you can use code_aster standalone, but you will need to complete some work in progress...
You may find another thread on this forum where I tried to help another user with salome_meca, and we were not able to run an FSI test case with salome_meca 2019, due to an apparent regression in salome_meca or code_aster. The same test case runs OK in salome_meca 2017, and I have not tested the 2018 version.

As the coupling was obsolete, and would have been broken by future code_aster changes anyways, I changed all the communication parts in code_saturne 6.1. The code is complete, though untested, but needs corresponding changes on the code_aster side. Those changes could actually probably be limited to writing some Python code in the code_aster script so as to set boundary condition values and read displacements, but requires good knowledge of the available code_aster functions, and my experience with code_aster is much too limited for me do do this efficiently, so this needs a bit of work on the code_aster side, and I do not know when the developers expect to look into this.

Best regards,

Yvan

Post Reply