Compiling CodeSaturne for co-processing (ParaView, Catalyst)

All questions about installation
Forum rules
Please read the forum usage recommendations before posting.
Antech
Posts: 197
Joined: Wed Jun 10, 2015 10:02 am

Compiling CodeSaturne for co-processing (ParaView, Catalyst)

Post by Antech »

Hello.
I want to enable co-processing when calculating in Code_Saturne 4.0.2. I've read corresponding User's guide sections and configure's --help, but I haven't found a particular solution. Configure option --with-catalyst=/Path/To/ParaView4.3.1 doesn't work. How should I compile Code_Saturne to enable co-processing with live visualisation in ParaView?
Thanks.
Yvan Fournier
Posts: 4077
Joined: Mon Feb 20, 2012 3:25 pm

Re: Compiling CodeSaturne for co-processing (ParaView, Catal

Post by Yvan Fournier »

Hello,

What error do you obtain ?

Did you also read the installation manual ? Paraview needs to be compiled with specific options enabled, and those are listed in that manual (you might also need to source some LD_LIBRARY_PATH and PYTHONPATH values).

Regards,

Yvan
Antech
Posts: 197
Joined: Wed Jun 10, 2015 10:02 am

Re: Compiling CodeSaturne for co-processing (ParaView, Catal

Post by Antech »

Yvan Fournier
Saturne's configure (version 4.0.2) says that Catalyst files not found in specified location. This is from Saturne's installation manual (part 4.3.6):
For use with Code Saturne, the recommended solution is to build or use a standard ParaView build for interactive visualization
I use standard ParaView build. Is it needed to compile some additional libraries or to recompile ParaView? Sorry, I don't know much about Saturne compilation with Paraview's Catalyst.

Simple method "--with-package=/Path/To/Package/Install/Prefix" worked OK on other packages (med, scotch, cgns libraries e.t.c.), but these packages (libraries) was compiled from sources (directory structure is like /Progs/Package/build, /Progs/Package/source; Saturne's configure is targeted to "build" dir). ParaView 4.3.1 installed in binary form (just official binary archive).
Yvan Fournier
Posts: 4077
Joined: Mon Feb 20, 2012 3:25 pm

Re: Compiling CodeSaturne for co-processing (ParaView, Catal

Post by Yvan Fournier »

Hello,

2 lines just after one one you cite (in 4.3.6), you have an important addition, explaining that you need a second paraview build, for postprocessing.

You can also use a single build, but in this case, you will have graphical windows open during computation, and the code will only run using Catalyst output when connected to a graphical display (OK and possibly preferable for testing on a workstation, less OK for running on a cluster).

So I recommend following the recommendations in the rest of the paragraph in the installation guide.
It contains all the important info, except possibly required environment variables (for execution, not required at installation), which seem to be sometimes necessary, sometimes not (probably related to linker caching):
export PYTHONPATH=$PARAVIEW_PREFIX/site-packages/vtk:$PYTHONPATH
export PYTHONPATH=$PARAVIEW_PREFIX/lib/paraview-4.3/site-packages/paraview:$PYTHONPATH
export PYTHONPATH=$PARAVIEW_PREFIX/paraview-4.3/site-packages:$PYTHONPATH

export LD_LIBRARY_PATH=$PARAVIEW_PREFIX/lib/paraview-4.3:$LD_LIBRARY_PATH
You can place those definitions in your .profile or .bashrc file, but I prefer to place them in a specific file whose path is provided to Code_Saturne in the "rcfile" section of the code_saturne.cfg post-install file. I'd like to make this more automatic in the future, but since the paths depend not only on the ParaView prefix but also on its version, making it robust is not trivial...

But first, let's see if you can compile with the recommended ParaView build.

Best regards,

Yvan
Antech
Posts: 197
Joined: Wed Jun 10, 2015 10:02 am

Re: Compiling CodeSaturne for co-processing (ParaView, Catal

Post by Antech »

Hello. Thanks for you response.

Sorry, I misunderstood the Guide... If I get you right, there are two ways:
1. Use only screen rendering. It's OK on our cluster if it can work with VNC remote connection.
2. Use offscreen rendering with OSMesa.

Is it possible to use the first way with VNC? If yes, what should I do? What prerequisties to compile and what additional Saturne's configure options to use?

I'm now trying to understand what to do with cmake options from Installation guide :) for the second method (offscreen rendering).
Yvan Fournier
Posts: 4077
Joined: Mon Feb 20, 2012 3:25 pm

Re: Compiling CodeSaturne for co-processing (ParaView, Catal

Post by Yvan Fournier »

Hello,

I don't think using VNC will be a viable option, except for testing on a single node, because if the code is run in batch mode, the execution environment will probably not have an X11 "display". Add to that the the graphic cards are probably different on the front-end node and compute nodes...

There is a recent post on the ParaView web site explaining exactly how this can be worked around http://www.kitware.com/source/home/post/162, but it's not exactly simple (the advantage over using Off-Screen Mesa is probably getting better performance, as the GPU drivers are used in their case, but the setup is much more complex).

So I recommend using the Off-Screen Mesa option, although for testing on a workstation and familiarizing yourself with co-processing, using a single "standard+MPI+enable_coprocessing" ParaView install may be a good start.

Regards,

Yvan
Antech
Posts: 197
Joined: Wed Jun 10, 2015 10:02 am

Re: Compiling CodeSaturne for co-processing (ParaView, Catal

Post by Antech »

Yvan Fournier
if the code is run in batch mode, the execution environment will probably not have an X11 "display"
Yes, I forgot about this... OK, assuming "OSMesa" method. I've read some manuals and downloaded Mesa and ParaView sources. Now trying to compile (at the moment mesa's configure cannot find dri3proto on my laptop with CentOS 6.5 so I'm serching the solution).
Yvan Fournier
Posts: 4077
Joined: Mon Feb 20, 2012 3:25 pm

Re: Compiling CodeSaturne for co-processing (ParaView, Catal

Post by Yvan Fournier »

Hello,

If you have any luck, OSMesa should be available as a package under CentOS (it is at least for Debian, Ubuntu, and Arch Linux).

If you do not have administrator privileges, of course, you need to install it in a user account.
This is a a pain, as you've probably already guessed.

For my builds (where I have a user or project account, but no administrative privileges), assuming an ARCH environment variable defining an architecture subdirectory for multiple builds (which you can set for example to "CentOs", `uname`, or remove), and a PREFIX install subdirectory (in my case the project account path), I last used the following command for Mesa-10.4:

Code: Select all

export PATH=/usr/bin:/bin:/usr/local/bin # set minimal PATH
cd Mesa-10.4.0/
./configure --prefix=$PREFIX/opt/Mesa-10.4/$ARCH  --with-osmesa-bits=32 --disable-dri --enable-dri=no --disable-egl --with-gallium-drivers=no --enable-osmesa
make -j 4
make install
make clean
I am not sure GLU is important or not, so I also build it, to be safe...

Code: Select all

cd glu-9.0.0/
export PKG_CONFIG_PATH=$PREFIX/opt/Mesa-10.0/arch/calibre7/lib/pkgconfig
./configure --prefix=$PREFIX/opt/Mesa-10.0/arch/calibre7 --enable-osmesa --enable-shared --disable-static CFLAGS=-std=c99
make && make install && make distclean
For some older environments, even building OSMesa is a pain, due to missing environments. On Debian 6 systems, I also need to download and build util-macros, makedepend, and glproto (hopefully you won't need to bother with this).

Code: Select all

export PATH=$PREFIX/usr/arch/$ARCH/bin:$PATH
export PKG_CONFIG_PATH=$PREFIX/usr/arch/$ARCH/share/pkgconfig:$PREFIX/usr/arch/$ARCH/lib/pkgconfig:$PKG_CONFIG_PATH

cd util-macros-1.17_build/$ARCH
../../util-macros-1.17/configure --prefix=$PREFIX/usr/arch/$ARCH
make clean && make  && make install && make clean
cd ../..

cd makedepend-1.0.4_build/$ARCH
../../makedepend-1.0.4/configure --prefix=$PREFIX/usr/arch/$ARCH
make clean && make  && make install && make clean
cd ../..

cd glproto_1.4_build/$ARCH
../../glproto-1.4.16/configure --prefix=$PREFIX/usr/arch/$ARCH
make clean && make  && make install && make clean
cd ../..
Hope this helps.

Regards,

Yvan
Antech
Posts: 197
Joined: Wed Jun 10, 2015 10:02 am

Re: Compiling CodeSaturne for co-processing (ParaView, Catal

Post by Antech »

Yvan Fournier
I've built Mesa-9.2.0 successfully with options provided in ParaView instruction:
http://www.paraview.org/Wiki/ParaView_And_Mesa_3D
(I think modern version of Mesa will also compile on my laptop)
I don't know if it works correctly because I cannot compile ParaView-4.3.1...

Now I'm trying to compile ParaView but without success. I follow instructions in official manual:
http://www.paraview.org/Wiki/ParaView:B ... _libraries
But when running configure in ccmake for the first time I receive an error because default Qt version in CentOS 6.5 is 4.6.2 but current ParaView-4.3.1 requires Qt-4.7 minimum (4.8 recommended). Qt developement package requires several dependencies, and with only Qt-4.8.x libraries (without developement files) ParaView still doesn't see this Qt version (it's obvious that , at least, Qt headers are required for compilation). The problem is that our cluster is not connected to the internet for security reasons so it's useless to install Qt-4.8 developement package on a laptop while testing installation process (I can easily connect notebook to the internet). I cannot find a complete Qt-4.8.x offline installation so I decided for now to use the old version of ParaView for co-processing (possibly ParaView-3.12).
Yvan Fournier
Posts: 4077
Joined: Mon Feb 20, 2012 3:25 pm

Re: Compiling CodeSaturne for co-processing (ParaView, Catal

Post by Yvan Fournier »

Hello,

You don't need Qt for the OSMesa build of ParaView, so you should be OK (as long as you use a separate, "standard" build on a workstation with the co-processing script generator plugin).

In the section relative to ParaView in the Code_Saturne install doc, the option used to disable Qt is:
-DPARAVIEW_BUILD_QT_GUI=OFF
(though the other options are important too).

If you did not add this (and -DVTK_USE_X=OFF) the first time you ran ccmake, you won't be able to change that value, due to CMake's caching (or in any case, if commands are available to do this, I'm not an advanced enough user of CMake for this). So the solution is to completely remove your build directory, recreate it, and restart a clean build in that new, empty directory.

Good luck,

Yvan
Post Reply