In versions greater than v5.7 we have persistently experienced difficulty doing standard builds (non-superbuilds) on CLE. The main issue appears to be that, so far, our CLE systems have been unable to provide a working openmpi option, and so we are stuck with using cray-mpich. This trouble is likely related to the issue posted here as " issues of compiling v5.8.0 on nersc cori by cc and CC"
The last successful build that we have managed is v5.8.1 with python2.7. The build/install worked flawlessly. However, upon linking our simulation code to the v5.8.1 adaptor(s) the execution of paraview setup commands resulted in a segfault in python libraries. The workaround was to build the simulation code by referencing the extra library at /usr/lib64/libpython3.so. The ldd check on the simulation code then showed reference to libpython2.7.so, libpython3.so, and libpython3m.so in addition to the plethora of paraview libraries associated with the adaptor. I think that this imples that the python2 paraview build is not completely divorced from python3.
Fast forward to v5.9.0-RC2 and the trick for doing the standard build in v5.8.1 fails because python2 is not longer working.
So simplicity, let’s just refer to 5.9.0-RCs. FWIW, ParaView 5.8.1 built with Python2 does not depend on Python3 at all, so that requirement was coming from some other dependency either of ParaView or the simulation.
How are you building ParaView? Are you using superbuild? Are you directly building ParaView source? Are you using spack? What options did you turn on/off? Shared build? static build?
Is pvbatch or pvpython in your build working at all?
Okay. Builds for v5.9.0-RC2 have not succeeded so I must answer these questions with reference to v5.8.1.
These are all local standard builds, rather than superbuilds. So we are using a lot of local libraries. Not using spack for these builds. The executables pvpython and pvbatch are both working:
/users/bak> pvpython --no-mpi --version
paraview version 5.8.1
/users/bak> pvbatch --no-mpi --version
paraview version 5.8.1
/users/bak>
The paraview source comes in via git checkout v5.8.1, and displays the following status:
[tt-fey1 ParaView-v5.8.1]> pwd
/usr/projects/pv_dev/ParaView-v5.8.1
[tt-fey1 ParaView-v5.8.1]> git status
HEAD detached at v5.8.1
Untracked files:
(use “git add …” to include in what will be committed)
ThirdParty/catalyst/
nothing added to commit but untracked files present (use “git add” to track)
[tt-fey1 ParaView-v5.8.1]>
I am presently re-trying the build for v5.9.0-RC2 using the intel/19.0.4 compiler rather than gcc/8.3.0 and hoping for more success.
Ok, let’s wait till we have 5.9 build. The 5.8.1 info is no longer relevant so the fact that it is working doesn’t help much, I am afraid. If you get specific build failures with 5.9, post those and we can diagnose those.
Utkarsh: I have succeeded in building v5.9.0-RC2 on our linux platforms, where it is working as expected. Unfortunately I have not had the same success on our cray platforms - and I believe that the problem is one with the environment, which is a horrible rats nest of modules. So for the moment I believe the build issue is a local one. If I learn otherwise, I will appeal for some support. Thanks much, b.
Okay. Now I’m really ready for some help, and I think that you are the only one who can really do something on this.
I was mistaken in my last note on v5.9.0-RC2, which said it is working on Linux but not on Cray Linux. I’m now convinced that it is not working anywhere for us.
The main snafu is with getting a v5.9.0-RC2-compatible Python3. Our system builds for Python3, all across LANL, do not have numpy. Hence we need to load an optional module that does have it. When we use an optional module for Python3 the v5.9.0-RC2 will typically build and install and will produce a pvserver that remote-connects to the local client, and actually produces good pictures.
The rub is when we try to link our simulation code to the v5.9.0-RC2 libraries (and this is where the module confusion came in yesterday). In v5.8.1 we learned how to make sure that the simulation code and the v5.9.0/bin executables are referencing the same shared library for Python2. Using exactly the same method we are building v5.9.0-RC2 and linking to the simulation code (called Pagosa). The ldd check ensures that we are referencing the same python3 shared library in both v5.9.0-RC2 binaries as in Pagosa.
Unfortunately the very first reference to the coprocessing in Pagosa results in a segfault that seems to be associated with a FloatingPointExecption. I will attach a text file showing the first parts of the segfault, in case it suggests something to you.
By the way I’m quite sure that when we build/install/link v5.9.0-RC2 using the default system Python3, everything works great - except that when we do the client-server remote connection AND try to Annotate Global Data the server issues a message saying the numpy is missing from python3. If we avoid asking to Annotate Global Data everything else is fine, so far as I can see.
So somehow (I guess) there is a flaw in our module for python3, but I am at a loss as to see how to say what that flaw is. Does the attached segfault message suggest anything to you? Thanks for sticking with this for us. It is important.
By the way I’m quite sure that when we build/install/link v5.9.0-RC2 using the default system Python3, everything works great - except that when we do the client-server remote connection AND try to Annotate Global Data the server issues a message saying the numpy is missing from python3. If we avoid asking to Annotate Global Data everything else is fine, so far as I can see.
The Annotate Global Data Filter uses numpy. As you mentioned earlier, the default system python3 does not have numpy. That is why you see this error.
So seems like a numpy related issue. You can’t mix and match Python3 build with another Python3 build which is providing the numpy package of interest.
Three options:
ask system folks to provide numpy for the system python version.
use the same Python as the one used by the available numpy module for all builds (your sim, ParaView etc.)
Use ParaVIew superbuild to build ParaView. It can be made to use system Python and then told to build its own numpy. It should use system Python to do that
Thanks much for the expert guidance. We will explore them all. So far the FPE crash that I sent to you was the result of option 2 below. I’m pretty sure that the superbuild option (3) is what we have been doing for v5.8.1. However, I like option 1 the best…
There is actually an option 4. And this is what is now working on all platforms:
a) Do a standard build (non-superbuild) of paraview by referencing a numpy-compatible python3 module, which is badly needed by pvserver etc.
b) Build the sim code making sure that the environment variable PYTHONPATH points to the foregoing numpy-compatible python3, but override its libraries by specifying the system python3 shared object for linking the sim code. Evidently the sim code does not care about numpy, but it desperately cares about other libraries that are only properly cross-linked with the system python3.
I know that this approach is not very pretty, but it is, in effect, what we have been doing since v5.8.1, and fairly successfully. So until this method gets broken I’m afraid that it is what we shall have to do…
Bucky, what tasks are you trying to achieve? Any particular reason you are using Paraview 5.9.0-RC2? Are you trying to render images insitu with Pagosa?
Boonth: Very good question. Right now I’m just CoProcessing to produce output files, and then opening them in a ParaView Client-server connection to see what the simulation looks like as it is being performed. Soon I will graduate into making pre-specified views using more of the insitu CoProcessing capability, but I’m not quite there yet. Do you expect that making insitu views will be problematic?
If you are having errors about numpy not being found, then you would have the same error insitu if you try to use the Annotate Global Data Filter. That’s the only issue I can think of.