Compiling CodeSaturne for co-processing (ParaView, Catalyst)

[Antech]

Yvan Fournier
Qt 4.6.1 It's default in CentOS 6.5. I will now try to run a calculation with Catalyst...

Update
======

I ran test simulation with Catalyst and it doesn't work properly. Calculation itself runs OK, but there are problems with Catalyst. I defined one writer for it (every iteration) and assigned (added) it to Fluid domain. Script Catalyst.py (simple co-processing) is in case's DATA directory. But when I run the calculation I get lots of errors, there are actually only two types of them:

Error №1
======
Traceback (most recent call last):
File "", line 104, in
File "Catalyst.py", line 3, in
from paraview import coprocessing
File "/Programs/ParaView-4.3.1/build-catalyst/lib/site-packages/paraview/simple.py", line 40, in
import lookuptable
File "/Programs/ParaView-4.3.1/build-catalyst/lib/site-packages/paraview/lookuptable.py", line 21, in
from math import sqrt
ImportError: /usr/lib64/python2.6/lib-dynload/mathmodule.so: undefined symbol: PyExc_ValueError

Error №2
======
Traceback (most recent call last):
File "", line 2, in
NameError: name 'Catalyst' is not defined

I can say nothing about second error because there is no even a file name... The first is related to math functions. But I tried the following in python's command prompt:

Code: Select all

>>>from math import sqrt
>>>a=sqrt(5)
>>>print(a)
2.2360679775

It imports and works.

What' wrong now?

Light version of the case archive is in attach. There are no mesh and results (I think they are not needed but I can upload if neccesary).

(Sorry, I still install programs in build dirs except Catalyst config of ParaView. I just didn't know that there should be not just out-of-source build but also out-of-build install so now it's quite time consuming to rebuild all neccesary programs).

Thanks for your attention.

[Yvan Fournier]

Hello,

This is an error I never encountered...

To run with Catalyst, did you add environment variables, as I mentioned in a earlier post:

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

Also, in your backtrace, it stills seems you are using the build directory for ParaView, and not the install directory. This might also be a part of the problem.

Regards,

Yvan

[Antech]

Yvan Fournier
Possibly I'm wrong but it seems that the problem is more complicated than PATH e.t.c.
I implemented your additions to PYTHONPATH and LD_LIBRARY_PATH in a shell script and sourced it. Now paths are as follows:
[antech@AntechPC ParaView-4.3.1]$ echo $PYTHONPATH
/Programs/ParaView-4.3.1/install-catalyst//paraview-4.3/site-packages:
/Programs/ParaView-4.3.1/install-catalyst//lib/paraview-4.3/site-packages/paraview:
/Programs/ParaView-4.3.1/install-catalyst//site-packages/vtk:
[antech@AntechPC ParaView-4.3.1]$ echo $LD_LIBRARY_PATH
/Programs/ParaView-4.3.1/install-catalyst//lib/paraview-4.3:

If I browse the filesystem I can find relevant python scripts in following directory:
/Programs/ParaView-4.3.1/install-catalyst/lib/paraview-4.3/site-packages/paraview
/Programs/ParaView-4.3.1/install-catalyst/lib/paraview-4.3/site-packages/paraview
The first string is a copy from echo $PYTHONPATH and the second is a copy from pwd while in ParaView's site-packages python scripts dir (I verified with ls that simple.py and lookuptable.py from error message are there).

About install/build dirs. I don't know what's wrong . It's definitely install-catalyst dir (for ParaView) in configure options for Saturne "catalyst" build, I checked it in the script used to run configure (it's in my previous posts) and in the Makefile.

So I decided to perform some "digging" of this error. I see that my Catalyst.py begins to execute, then some ParaView python scripts start, then error itself occures in:
/usr/lib64/python2.6/lib-dynload/mathmodule.so
And it cannot find symbol PyExc_ValueError. Very strange because it's an internal python error code symbols (if I get it right) and should not be related to third-party paths. Internet search gave the following:
https://bugzilla.redhat.com/show_bug.cgi?id=874874
http://bugs.python.org/issue4434
Although this problem was not approved as bug, it exists. But I don't understand how can I fix it in this case with ParaView. Can you help me? Or should I ask it on ParaView mailing list?

I tried to change paths to Paraview's build dir. It didn't help. It's strange that I can run ParaView's Python command prompt both from install and build dirs and sqrt imports from math successfully. But when it's done from Paraview's scripts ran by Catalyst the error occures...

[Yvan Fournier]

Hello,

Just to check, did you compile both Code_Saturne and ParaView using shared libraries ? (it is the default for both Code_Saturne and ParaView).

Looking at the bugtracker issues you linked to, I'm not sure I can do much, except recommend building Python in a user path (or, for example, using the build from SALOME), and building Paraview with that interpreter (you don't need to change anything on the Code_Saturne side f you do that, as the Python interpreter used externally by Code_Saturne and internally by ParaView can be independent)

Before you do that, to try shorter tests, you may first try:

adding /usr/lib64/python2.6/lib-dynload to your LD_LIBRARY_PATH.

If this does not work, you can try running:
python-config --ldflags

and adding its output to LDFLAGS="<output>" for the Code_Saturne configuration.

You may also try adding it as well as to ParaView link flags, but I'm not sure either will be enough.

I have not encountered this issue on Debian-based or Arch-Linux-based systems, so I guess it is specific to the way the Python library is built/packaged (which is why I hope building your own interpreter would solve the issue, even though it means reinstalling Python, which is much faster to compile than ParaView.

Another option might be to do the reverse: compile both ParaView and Code_Saturne as static libraries (--disable-shared for Code_Saturne). In this case, Catalyst is not used as a plugin by the code, but linked directly, whether you use it or not. This mode has not been tested recently, though it has been used for debugging before, and I'm not sure it would solve the Python issue, though...

In all, I believe compiling your own Python (2.7) interpreter (using defaults, except for a "--prefix" option and rebuiding ParaView with that (trying to update your build, not cleaning the cache for a first try) is your best (and cleanest) bet, unless adding /usr/lib64/python2.6/lib-dynload to your LD_LIBRARY_PATH is enough to solve the issue.

Good luck,

Yvan

[Antech]

Yvan Fournier
Unfortunately, trick with LD_LIBRARY_PATH didn't help. I checked that this path is correct by typing:
ls $LD_LIBRARY_PATH
There was the only Python directory in this variable so ls showed it's contents. Then I ran Code_saturne from the same terminal window and launched test simulation with catalyst, it showed up the same errors. Actually, libpython2.6.so that contains missing symbols is not in lib-dinload directory (it's in python2.6/config) so, IMHO, it's logical that there was no effect. I tried to set LD_LIBRARY_PATH to /usr/lib64/python2.6/config (checked with ls) but still no effect.

Then I decided to recompile ParaView with Python 2.7.10 that I built and installed into /Programs/python-2.7.10/build (it doesn't make .so by default so I added the --enable-shared option to configure). Python 2.7.10 itself works if only I set LD_LIBRARY_PATH=/Programs/python-2.7.10/build/lib (otherwise it does not find it's shared library libpython.2.7.so, Python 2.7 from SALOME 7.6 has the same behavior). OK, I set LD_LIBRARY_PATH, Python 2.7 works and I try to configure ParaView 4.3.1 with ccmake. But when I change Python options (directories) from defaults to my Python 2.7 paths, ccmake says that my Python version is 1.4. The same result with arbitrary incorrect path to python executable that indicate that ccmake probably has some problems running python from custom location. Paths was copied from the file manager to avoid typos. They are set in ccmake as folows:

PYTHON_EXECUTABLE /Programs/python-2.7.10/build/bin/python
PYTHON_EXTRA_LIBS /Programs/python-2.7.10/build/lib
PYTHON_INCLUDE_DIR /Programs/python-2.7.10/build/include/python2.7
PYTHON_LIBRARY /Programs/python-2.7.10/build/lib/libpython2.7.so
PYTHON_UTIL_LIBRARY /usr/lib64/libutil.so

(Exact copy from console)
I tried to set executable to python, python 2 and python2.7 (they connected with symlinks). No effect, it "finds" python-1.4 .

I posted the question about issue with python and PyExc... symbol to ParaView mailing list but it's still no answers (they answered to my previous posts very quickly).

Update
=======
I played a bit with settings and ParaView configured successfully! I don't know what was wrong (IMHO settings was slight different but correct). It's now compiling, I will update this post when there will be new results...

Thanks for your support.

[Yvan Fournier]

Hello,

Here again, I strongly recommend configuring Python with "--prefix" and running "make install" after "make". The requirement for LD_LIBRARY_PATH might disappear when you do that.

In any case (assuming you used --prefix=/Programs/python-2.7.10/install, to have an installation side-by-side with your build), try:

export PATH=/Programs/python-2.7.10/install/bin:$PATH
export LD_LIBRARY_PATH=/Programs/python-2.7.10/install/lib:$LD_LIBRARY_PATH

Then run ParaView's Cmake (you might have caching effects in this case, so re-running a clean install might be safe).

You should have the "correct" Python build for ParaView after that.

Regards,

Yvan

[Antech]

Yvan Fournier
I strongly recommend configuring Python with "--prefix" and running "make install" after "make".
I did it this way (I just didn't mention it because it's usual), but the installation was in build dir (I know it's not very good but it worked OK with many programs). There was errors about some python modules after make, but I decided to proceed with make install. If it will be OK with LD_LIBRARY_PATH I will remake Python to have three separate dirs: source, build and install.

I updated my previous post, ParaView is being built with python 2.7.10, I will answer when I will get new results...

Yvan, Saturne started normally with new ParaView (I didn't recompile Saturne) but an access violation error occured on calculation start . Call stack starts with this:

Code: Select all

  1: 0x7f25da15a213 <PyInt_FromLong+0x53>            (libpython2.7.so.1.0)
   2: 0x7f25bec52f21 <PyVTKClass_vtkAbstractArrayNew+0x61> (libvtkCommonCorePython27D-pv4.3.so.1)
   3: 0x7f25bec53109 <PyVTKAddFile_vtkAbstractArray+0x19> (libvtkCommonCorePython27D-pv4.3.so.1)
   4: 0x7f25bed962fe <real_initvtkCommonCorePython+0x3e> (libvtkCommonCorePython27D-pv4.3.so.1)
   5: 0x32ef6ea855 <_PyImport_LoadDynamicModule+0xc5> (libpython2.6.so.1.0)
   6: 0x32ef6e8895 <>                               (libpython2.6.so.1.0)
   7: 0x32ef6e8b55 <>                               (libpython2.6.so.1.0)
   8: 0x32ef6e916d <>                               (libpython2.6.so.1.0)
   9: 0x32ef6e9ed4 <PyImport_ImportModuleLevel+0x44> (libpython2.6.so.1.0)
  10: 0x32ef6cf70f <>                               (libpython2.6.so.1.0)
<...>

Full call stack is in listing file (see attach).

[Yvan Fournier]

Hello,

In you call stack, python 2.6 appears, so it seems the dynamic linker still mixes Python 2.6 and 2.7 (which probably explains the crash).

Are you sure you also exported LD_LIBRARY_PATH when executing the code ?

As Code_Saturne generates a script to run the executable, it might "lose" part of your sourced environment variables. Just to make sure, for testing, could you export your LD_LIBRARY_PATH and PATH additions for Python 2.7 in your .profile file ?

In your case,

export PATH=/Programs/python-2.7.10/build/bin:$PATH
export LD_LIBRARY_PATH=/Programs/python-2.7.10/build/lib:$LD_LIBRARY_PATH

If this is not enough, you may try also, "export LD_PRELOAD=...", which has highest priority, but for which you must find the exact path to the python2.7.so file (not just its directory).
Probably: export LD_PRELOAD=/Programs/python-2.7.10/build/lib/libpython2.7.so

Regards,

Yvan

[Antech]

Yvan Fournier
Hello and thanks for suggestions. I thougth that python2.6 in call stack is due to Saturne's calls and it should be normal as you mentioned above... I will try to implement you advice as soon as possible, but now I have to take time for other important work...

Update
=======
I tested your recent suggestions. Unfortunately it doesn't work... If I don't set LD_PRELOAD in my profile I still get python 2.6/2.7 mixing in the same error output. If I set LD_PRELOAD (it's enough to just export in terminal) Saturne fails to start with GUI:
Error: Unable to import PyQt4.QtCore or PyQt4.QtGui modules.
Please check your PyQt4 installation.
There is probably an incompatibility of my PyQt4 (4.6.2) and Python 2.7.10. Should I update PyQt4 and SIP too?

[Yvan Fournier]

Hello,

To solve this last issue, a cleaner solution would be to set LD_PRELOAD or LD_LIBRARY_PATH only when Code_Saturne has started, so it does not interfere with its own Python.

There is a way to do this, using the <code_saturne_prefix>/etc/code_saturne.cfg (or ~./code_saturne.cfg) file. If you have no such file, copy <code_saturne_prefix>/etc/code_saturne.cfg.template to <code_saturne_prefix>/etc/code_saturne.cfg.

Edit that file, and uncomment the "rcfile" entry, and define the path a a text file there.
Then place the LD_PRELOAD, LD_LIBRARY_PATH, ... variables in that file.

This way, this "sub-environment" will be used by the solver executable (which the links with Catalyst), but not by the other Code_Saturne scripts.

I will have very limited network connectivity next week, so I hope this will work, because I won't be on thus forum much next week.

Regards,

Yvan