[cbcoutinho]

I'm having an issue with the OpenFOAM environmental variables when calling ParaView. I installed both OF 2.4.x and OF 3.0.x in my /opt/OpenFOAM directory, as well as the respective third party software for each version. I also set aliases for each OF version in my ~/.bashrc

Running either version of ParaView without calling the alias works fine, using either of the two lines:

user@hostname:~> /opt/OpenFOAM/ThirdParty-2.4.x/build/linux64Gcc/ParaView-4.1.0/bin/paraview

user@hostname:~> /opt/OpenFOAM/ThirdParty-3.0.x/build/linux64Gcc/ParaView-4.4.0/bin/paraview

If I set an alias (e.g. of24x, of30x), I get the following libGL errors:

user@hostname:~> of30x 
user@hostname:~> /opt/OpenFOAM/ThirdParty-3.0.x/build/linux64Gcc/ParaView-4.4.0/bin/paraview
AutoMPI: SUCCESS: command is:
 "/usr/lib64/mpi/gcc/openmpi/bin/mpiexec" "-np" "2" "/opt/OpenFOAM/ThirdParty-3.0.x/build/linux64Gcc/ParaView-4.4.0/bin/pvserver" "--server-port=57912"
AutoMPI: starting process server
-------------- server output --------------
Waiting for client...
AutoMPI: server successfully started.
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error: BadValue (integer parameter out of range for operation) 2
  Extension:    154 (Uknown extension)
  Minor opcode: 3 (Unknown request)
  Resource id:  0x0

Both versions of OpenFOAM were installed using the openSUSE instructions on the wiki. Can someone give me an idea of what's going on?

Cheers,
Chris

[wyldckat]

Greetings Chris,

Does this also happen when you don't have the automatic multi-core feature turned on in ParaView?

Best regards,
Bruno

[cbcoutinho]

Originally Posted by wyldckat

Greetings Chris,

Does this also happen when you don't have the automatic multi-core feature turned on in ParaView?

Best regards,
Bruno

Howdy Bruno,

I just checked both aliases and the behavior remains the same whether or not the multi-core option is set or not.

Cheers,
Chris

[cbcoutinho]

Is this a bug in OpenFOAM or is it an openSUSE issue? Should I post it in the bug report?

[wyldckat]

Greetings Chris,

Sorry, I'm rarely able to answer during the week days. I mostly only am able to answer on weekends and it's if I'm lucky enough to be able to do so

Simply reporting this as a bug report won't do us much good, because we haven't isolated yet the specific origin of the problem.

I've noticed that there is an inconsistency in the path you're using:

... ThirdParty-3.0.x/build/linux64Gcc/ ...

you're using the build folder, instead of the actual location where ParaView was installed, which is at the path given by any of the following commands (when OpenFOAM's environment is active):

which paraview
echo $ParaView_DIR/bin/paraview

Which in your case, should be something like this:

/opt/OpenFOAM/ThirdParty-2.4.x/platforms/linux64Gcc/ParaView-4.1.0/bin/paraview

/opt/OpenFOAM/ThirdParty-3.0.x/platforms/linux64Gcc/ParaView-4.4.0/bin/paraview

As far as I can figure out, the problem is very likely related with a shell environment change made by OpenFOAM's "bashrc" file, which is tampering with your installation of ParaView.
Please run the following command before you've activated the OpenFOAM 3.0.x shell environment:

ldd /opt/OpenFOAM/ThirdParty-3.0.x/platforms/linux64Gcc/ParaView-4.4.0/lib/paraview-4.4/libvtkGUISupportQt-pv4.4.so.1 > log.vtkQt.before

Then activate the environment for 3.0.x and run:

ldd $ParaView_DIR/lib/paraview-4.4/libvtkGUISupportQt-pv4.4.so.1  > log.vtkQt.after

Then please attach the files "log.vtkQt.after" and "log.vtkQt.before" to your next post. Although, you might have to ZIP the files file attaching... you can do that either interactively or by running:

zip log.vtkQt.zip log.vtkQt.after log.vtkQt.before

And then attach the file "log.vtkQt.zip"


The other thing I ask you is to start another terminal window/tab and run the following commands:

export > log.env.before
of30x
export > log.env.after

Then attach the files "log.env.before" and "log.env.after" to your post as well.

With these log files, I should be able to figure out what's happening.

Best regards,
Bruno

[cbcoutinho]

Howdy Bruno,

Attached are two zip files containing the outputs of those commands.

I really would like to understand the output in these files but I am at a loss. If I can help you with any more errors, please let me know.

Cheers,
Chris

[cbcoutinho]

Anyone able to take a look at this?

Cheers,
Chris

[wyldckat]

Greetings Chris,

Sorry, I did manage to take a quick look into the log files you've attached during the week, but only today did I finally manage to take a better look into solving one of the potential problems.

Based on the log files, my suspicion is that the problem is related to how CGAL was hacked into the build system, which relied on creating symbolic links from the folders where CGAL was actually installed, to the ones where OpenFOAM would look for them. But this potentially broke the search path, because libraries that were meant to show up at "/usr/lib64", were now appearing at where CGAL was installed, at the really long path into OpenFOAM's ThirdParty folder, e.g.:

/opt/OpenFOAM/ThirdParty-3.0.x/platforms/linux64Gcc/CGAL-4.7/lib/

I've tested a possible work around and I've updated the wiki pages accordingly:

• For OpenFOAM 2.4.0: https://openfoamwiki.net/index.php/I...2.4.0/openSUSE
• For OpenFOAM 3.0.x (and 3.0.1): https://openfoamwiki.net/index.php/I...3.0.x/openSUSE

Now, the problem here is that you already have a working build. Which means that we now need slightly different steps to repair the broken paths.
If I'm not mistaken, the following steps should solve the problem and hopefully they work the same for both OpenFOAM installations that you currently have:

1. Start a new terminal and activate the environment for the first OpenFOAM version you want to fix.
2. Run these commands, for repairing the broken paths and removing the current symbolic links for CGAL:
   

   foam
   sed -i -e 's/^\(cgal_version=\).*/\1cgal-system/' OpenFOAM-3.0.x/etc/config/CGAL.sh
   foam3rdParty 
   rm -r $CGAL_ARCH_PATH

3. Now close the current terminal, then start another new terminal and activate the same OpenFOAM version.
4. Next step is to run the following commands, for reconstructing the broken build path:
   

   foam
   mkdir -p $CGAL_ARCH_PATH
   mkdir -p $BOOST_ARCH_PATH

5. Now we need to clean up the build for the "foamy" meshers, depending on the OpenFOAM version:
   • OpenFOAM 3.0:

     wclean all applications/utilities/mesh/generation/foamyMesh

   • OpenFOAM 2.4:

     wclean all applications/utilities/mesh/generation/foamyQuadMesh
     wclean all applications/utilities/mesh/generation/foamyHexMesh

6. Now let's build what's missing in the current OpenFOAM version:
   

   ./Allwmake > log.make 2>&1
   ./Allwmake > log.make 2>&1

7. Inspect the file "log.make" to see if there are any errors.
8. As for ParaView, try using it now with the OpenFOAM environment active. If it fails, my guess is that it's best that you run the build command for it again

Hopefully these steps will solve the problem.

Best regards,
Bruno