[bender.rodriguez]

Dear all, trying to compile OF 2.3.0 I am running into trouble.

OS: Scientific Linux 6.5
gcc: 4.9.1
openmpi: 1.8.2
python: 2.6.6

When following the instructions under Source Pack Installation on http://www.openfoam.org/download/source.php everything works fine.
Adding the -python flag to makeParaView4 it still works.

Problems began when I try compiling with

./makeParaView -python -mpi

and mpi fortran libraries were not found during configuration. After calling cmake manually with

-DMPI_Fortran_INCLUDE_PATH=$openmpi/include \
-DMPI_Fortran_LIBRARIES=$openmpi/lib/libmpi_mpifh.so

options the configuration process was successful. This points to an openmpi 1.8.2 installations on the system.

Now, when doing

make -j 8

it just stops without any problem description. The last line are:

  5%] Building C object VTK/ThirdParty/hdf5/vtkhdf5/src/CMakeFiles/vtkhdf5.dir/__/H5lib_settings.c.o
Linking CXX shared library ../../../lib/libvtkCommonCore-pv4.1.so
[  5%] Built target vtkCommonCore
Linking C shared library ../../../../../lib/libvtkhdf5-pv4.1.so
[  5%] Built target vtkhdf5
make: *** [all] Error 2

I suspect some problem with the hdf5 which is in the Thirdparty tarball. Any ideas on how I can get a more verbose error log? What might be wrong?

[wyldckat]

Greetings bender.rodriguez and welcome to the forum!

I want to try and reproduce the same error you're getting, while using CentOS 6.5 (which is basically the same as SL 6.5), but I need to know how exactly you installed GCC 4.9.1 and Open-MPI 1.8.2!?

Best regards,
Bruno

[bender.rodriguez]

Dear Bruno,

thank you very much. Any help is appreciated.

gcc was build with the following steps. $installdir is a variable pointing to a directory where all software gets installed. I am using modules environment to make different versions available when needed.

mkdir gcc-builddir
cd gcc-builddir
export LD_LIBRARY_PATH=$installdir/gmp-6.0.0/lib/:$installdir/mpfr/mpfr-3.1.2/lib/:$installdir/mpc/mpc-1.0.2/lib:$installdir/cloog/cloog-0.18.1/lib/:$installdir/isl/isl-0.12.2:$LD_LIBRARY_PATH
../gcc-4.9.1/configure --enable-languages=all --with-gmp=$installdir/gmp-6.0.0 --with-mpfr=$installdir/mpfr/mpfr-3.1.2 --with-mpc=$installdir/mpc/mpc-1.0.2 --with-cloog=$installdir/cloog/cloog-0.18.1 -prefix=$installdir/gcc-4.9.1 --disable-multilib
make -j 8
sudo make install

The dependencies for gcc were build previously. Would you like me to post the build steps of these as well? Most were straight forward configure, make, make install.

OpenMPI was build with the following command, after loading the prviously loaded gcc module.

module load gcc/4.9.1
cd openmpi-1.6.3
./configure --prefix= $installdir/mpi/openmpi/1.6.3-gnu_4.9.1 2>&1 | tee configure.log
make -j 8 2>&1 | tee make_j_8.log
make check 2>&1 | tee  openmpi-1.6.3_make_check.txt
sudo make install 2>&1 | tee make_install.log

It might be a good idea to write down all the dependencies and previously build libraries. From the top of my head these are:

• cmake 3.0.1
• qt 4.8.6
• CGAL 4.4

Should we approach this in a more organised way?

[wyldckat]

Hi bender.rodriguez,

I'm one of the main writers for these wiki pages: http://openfoamwiki.net/index.php/In...CentOS_SL_RHEL - so I tend to follow the step-by-step approach on those wiki pages.

Regarding the versions you've indicated, the one that most likely is to blame is CMake 3.0.1. ParaView 4.1.0 was released when the CMake 2.8.x series was running, therefore it's not very likely that it will build properly with CMake 3.0.x.

GMP 6.0.0 is also a reason of concern for me, because that sort-of implies that it's still the first major version of the 6.0 series, which might mean that unexpected big bugs can easily pop-up.

The other strange detail I'm seeing is that on the first post you mention Open-MPI 1.8.2, but on the second post you mention 1.6.3?


Either way, I'm going to try and test this myself this weekend in a virtual machine with CentOS 6.5, to determine if the problem is associated to GCC 4.9 or not.

----------------------------------

edit: I've tested and updated the installation instructions here: http://openfoamwiki.net/index.php/In...HEL#CentOS_6.5 - it now also includes instructions on how to build ParaView with both MPI and Python support. The steps that changed were only #2 and #17, namely the packages that need to be installed in #2; on #17 was the fix and the additional build options.

I didn0t have time to test with GCC 4.9.1, but I believe that if you can make sure the packages in #2 are all installed and then build ParaView 4.1.0 using the steps in #17, while using the software versions you're using of GCC et al.
If the build process fails, please provide the file "log.makePV" which should be available when makeParaView4 is finished, since it will tell us the complete story of why the build was not successful.

----------------------------------

Best regards,
Bruno

[bender.rodriguez]

Originally Posted by wyldckat

I'm one of the main writers for these wiki pages: http://openfoamwiki.net/index.php/In...CentOS_SL_RHEL - so I tend to follow the step-by-step approach on those wiki pages.

Thank you very much for the updated and very detailed instructions, Bruno. Because of your notes I was able to successfully compile OF 2.3.0 and Paraview with pvbatch. Following step-by-step was not always possible for me, because most of the time I could not use rpms and had to compile from source. The install is for a cluster with a module environment.

Originally Posted by wyldckat

Regarding the versions you've indicated, the one that most likely is to blame is CMake 3.0.1. ParaView 4.1.0 was released when the CMake 2.8.x series was running, therefore it's not very likely that it will build properly with CMake 3.0.x.

GMP 6.0.0 is also a reason of concern for me, because that sort-of implies that it's still the first major version of the 6.0 series, which might mean that unexpected big bugs can easily pop-up.

It worked with the mentioned versions. However, I am not sure any more, if they really got used during install. As it turned out OF seems to built most requirements during compilation from the ThirdParty directory and I am thus not sure which "onboard" versions were used.

Originally Posted by wyldckat

The other strange detail I'm seeing is that on the first post you mention Open-MPI 1.8.2, but on the second post you mention 1.6.3?

Finally I got it to work with 1.8.2, the patch you provided and:

WM_MPLIB=SYSTEMOPENMPI

I was not aware that you have to set that variable in order for OF to fully ignore the ThirdParty OpenMPI version. To be honest the build process with all the variables is still confusing to me. I am used to the configure and make approach. Is there a list of options like WM_MPLIB available other than going through all the scripts? An equivalent to configure --help?

Originally Posted by wyldckat

I didn0t have time to test with GCC 4.9.1

I used 4.9.1, this is what I am sure about. All the logs state that.

Would it be of any use if I provided in depth instructions for compiling the pieces of software I used?

[wyldckat]

Hi bender.rodriguez,

Originally Posted by bender.rodriguez

To be honest the build process with all the variables is still confusing to me. I am used to the configure and make approach. Is there a list of options like WM_MPLIB available other than going through all the scripts? An equivalent to configure --help?

In theory, you only have to look at 2 files in the "OpenFOAM-2.3.0" folder:

• etc/bashrc
• etc/config/settings.sh

Those two are more detailed than "configure --help" would be in a similar scenario.

Originally Posted by bender.rodriguez

Would it be of any use if I provided in depth instructions for compiling the pieces of software I used?

Well, there are several advantages if you do that:

1. There have been at least 3 people that have asked for such instructions. I honestly am never certain what to suggest to them, because it usually depends on what's already installed on the machines they are going to use.
2. Once the instructions are here on the forum and/or on the wiki, it's easier to reproduce the steps, diagnose if there is something missing or incorrectly defined. And better yet, it becomes easier to maintain something that already exists
3. Last but not least: you'll have a (revised) backup of the instruction steps you've used

Feel free to start a new section on the aforementioned wiki page, with the clear indication that it refers to an installation without root permissions. If you don't feel comfortable with the wiki language and prefer to use some other format, I can quickly handle the transfer of your format to wiki format, if you agree with the licensing that this wiki uses, namely GNU Free Documentation License 1.3

Best regards,
Bruno