[solved] Issue Involving Paraview
 

Hello all,

I have installed OpenFOAM 1.6 today on fedora 12 and i am having a slight issue. It seems that when I want to see the mesh for the first tutorial I get this error;

[***@#### cavity]$ paraFoam
created temporary 'cavity.OpenFOAM'
/home/***/OpenFOAM/ThirdParty-1.6/paraview-3.6.1/platforms/linux64Gcc/bin/paraview-real: error while loading shared libraries: libssl.so.0.9.8: cannot open shared object file: No such file or directory

I searched for the libssl.so and i found that my computer has libssl.so.1.0.0 instead of the one being called for. I was wondering how I could fix this. I have used OpenFOAM before but never have had this issue.

Thanks

MT

Greetings MechE and welcome to the OpenFOAM forum.

Well, the solution is pretty simple, as long as the two library versions don't differ too much.

So, you need libssl.so.0.9.8 but have libssl.so.1.0.0, then just go to the folder where the existing version is and run this as superuser:It symbolically links the existing version to the version you need. As for superuser mode, either use "sudo" at the beginning of that line, or "su -" before it... I don't know if Fedora 12 comes with sudo pre-installed :(

Now, this should work, and if you do an "ls -l" on that folder, you might find other links between other library versions as well, since this is a somewhat common method in Linux. Nonetheless, if libssl.so has gotten an overhaul, like code and interface cleaning, then Paraview might crash when it needs ssl :( If that happens, you'll have to rebuild Paraview.

Best regards,
Bruno

Creating this symbolic link doesn't mess with the original; correct?

Exactly.
Otherwise I would've suggested to check the Software Manager in Fedora, and see if under libssl there was an option for choosing another version for it :cool:

This worked!!! Thank you very much!

I'm glad to hear/read it! And your welcome :)

I have a very similar problem in a different environment. I am trying to get paraFoam running on a remote machine that I don't have rights to mess with anything outside of my /home/user directory. The version on that machine is libssl.so.0.9.8e instead of libssl.so.0.9.8

I know sym-linking must be the answer, but I would need to create the link somewhere in my home directory. Is there a way for me to do this? Or do I need to recomplile ParaView?

Greetings Marco,

Assuming that the OpenFOAM installation is in your home folder, try something like this:
Where "/path/to/libssl.so.0.9.8e" is the path to your local libssl.so.0.9.8e ;)

Best regards,
Bruno

Hey Bruno, thanks for the reply. That resolved the libssl issue, but now there is a problem with Qt, so I need to recompile anyway.

I'm having trouble finding where the newly compiled qmake is, any ideas?

Hi Marco,

In the blog post link in my signature, there are a load of links to other threads about various issues pertaining building problems with OpenFOAM and other ThirdParty tools.... In other words, if you had picked up on the post "http://www.cfd-online.com/Forums/openfoam/74172-new-user-needs-help.html#post251889 #19", you would know that inside the folder to where Qt was built, there is a bin folder that should contain the binaries for Qt, including qmake ;)

Nonetheless, when in doubt, you can always use in Linux the find command :) :Best regards,
Bruno

Thanks Bruno, the links have been helpful. After reading through I think I have a better understanding of the build process. I'm down to a few problems with the makeParaview script. All of the configure seems to go well, but then there is a problem with one of the CMakeLists:

Looking in said directory, the file is clearly there. I didn't open it due to permissions, so I can't vouch for what is inside though.

Hi Marco,

What CMake version are you using? In my experience, for instance, ParaView 3.6.1 has only worked for me with CMake 2.6.4; with CMake 2.8.0, it made up some issues about something... so I simply went back to 2.6.4 :)

Another possibility is that one or more files are corrupt. It's been known to happen either files disappearing or being wrongly unpacked from the gtgz files, for some weird reason :( It's a lot of files, so it would also be strange if something didn't go wrong once in a while :D

Best regards,
Bruno

CMake 2.6.4 is running on one of the machines. I need to bootstrap cmake on the other, which is another issue entirely. I'll try re-extracting the ThirdParty tarballs and recompile, and barring that I'll download the sources for paraview 3.6.1 and try from there.

Trying the sources for paraview 3.6.2, as 3.6.1 failed to compile. There were some corrupted files (probably from improper extraction), but the next errors are compilation errors, complaints about syntax around VTK/common/CmakeFukes/vtkCommon.dir

Hi Marco,

Well, it almost seems like ParaView doesn't want to be built by your own hands ;)

OK, lets try another approach, but I'll need to know some things, if you can share the information:

• What Linux distribution are you using?
• What CMake version is installed on the machine you want it to work in?

Why do I ask these? Because there are a few possibilities to go on. For example:

• If CMake is >2.8.0, then you can build the latest ParaView 3.8.0.
• If your Linux distribution isn't too old, you can use the pre-built version of ParaView 3.8.0 from www.paraview.org. You can follow these instructions to install and adapt OpenFOAM to use the pre-built version, without needing further building. The instructions near the end of that blog post can also apply to the previous point.
• If CMake is too old, as well as the Linux version, then you should have read from the thread from the start, for that post I gave you the link a few posts back: New user needs help - And I advise you to read it thoroughly, because there are a lot of details spread all over the thread :rolleyes: I never got around to write a summary of that thread, since that thread has a lot of information that could be useful to someone...

There are a lot more possibilities, but writting them all down would be nearly insane :D

Best regards,
Bruno

Thanks Bruno. That almost did the trick. To confirm, I took all the steps you mentioned but replacing ParaView 3.6.1 with ParaView 3.6.2. ParaView launches and it appears it will work. but then there is an exception thrown by Qt, seems suspiciously like an out of bounds array on the name:

Since I have to run everything on this machine with batch scripts through TORQUE/MOAB, I can easily ask it to foamToVTK when I'm done. But that's slightly annoying. Do you think there an easy way out of this one?

Hi Marco,

Did you rebuild OpenFOAM's PV3FoamReader? Because it might be miss-linking to ParaView 3.6.2, when it expected to link to 3.6.1.

If the previous solution doesn't work, the final solution that comes to mind is somewhat simple: upgrade! I.e., build a new Qt version 4.6.x and ParaView 3.8.0 and edit the paraFoam script to use ".foam" instead of ".OpenFOAM"!
And this time you don't even need OpenFOAM's PV3FoamReader, because as of ParaView 3.8.0, it has an internal reader that can read OpenFOAM cases without the need to have OpenFOAM installed!
For example, you could share the case folders in a Linux cluster with a Windows machine; run OpenFOAM in the Linux cluster; and post-process directly remotely from Windows! All thanks to the updated/upgraded internal reader :) (versions <3.8.0 would only work with cases for OpenFOAM <1.2 if I'm not mistaken)

And you might be wondering: «but isn't OpenFOAM's reader more reliable?»
Answer: currently it isn't. The current internal reader has proven to be better, faster and more accessible than the official reader. That could change in the future, but right now, the internal reader in 3.8.0 and above is better that OpenFOAM's reader.

Good luck! Best regards,
Bruno

Bruno,

Thanks for the advice and help. I was finally able to get ParaView 3.8 to work with OpenFOAM 1.6. It was even easier than what you last mentioned, as I didn't have to rebuild anything.

1) Downloaded the binaries
2) Added the executables to my $PATH
3) Modified the paraFoam script as per your instructions

Works like a charm, and a lot faster and stable.

Again, many thanks!

Just an update on the situation, I've found that I can perform nearly all of the post-processing I need to except for the ability to make selections. Specifically I want to plot a selection over time, but after moving the cursor over the section I want to select, Paraview freezes and quits with a segmentation fault.

Has anyone else seen this kind of behaviour. It happens when I do "Select Cells On", but works fine for "Select Cells Through", however, I can't use this as my mesh moves and the selection changes in time.

Hi Marco,

Try using foamToVTK to generate the outputs in VTK format and see if the same problem occurs, when opening in ParaView the resulting VTK files.

If the same problem occurs, then it's a ParaView bug. If not, it's the plug-in's bug.

Best regards,
Bruno

Thanks Bruno. FoamToVTK is a little impractical with the setup I have going. After a little more digging, I found that it depends on the data fields I have loaded, some of which aren't calculated for all time steps. Therefore it seems like a plug-in bug.

Has anyone else used the vanilla ParaView 3.8.1 with OF 1.6, and if so what adjustments or tweaks have you had to make for it to work seamlessly? I like the stability of 3.8.1 in general and would like to use it as the default.

Hi Marco and Bruno,

@Marco: I see the problem with PV 3.8.1 (and only with 3.8.1, but not with 3.8.0 nor 3.9.0) too with a minor difference being I always see the problem regardless of what field I load. If we are discussing the same problem nonetheless, Merge Blocks should work.

@Bruno: In fact, ParaView is a complex system thus sometimes the problem is not so bisectional. In my case, by comparing git logs of the first significant occurrence of ParaView classes in the backtrace
between PV 3.8.0/3.8.1/3.9.0, we find a commit that is in PV 3.9
but is missing from PV 3.8.1. I didn't elaborate to do a cherry-pick test for this, but since the crash is not immediate but occurs after several seconds of lockup I suspect this is most likely what fixed the problem in PV 3.9. Indeed, if I run Select Cells after running Merge Blocks to convert the multiblock reader output to a single unstructured grid, it works as expected. One may conclude this is a reader bug since the problem does not occur with the VTK data (which is of unstructured type), but was (most likely) a ParaView bug.

Takuya

Hi Takuya,
:eek: I completely forgot that ParaView/VTK has multiple grid systems :( If I hadn't forgotten about it, I would have suggested that it could still be a bug in ParaView itself.
My apologies to you Takuya, for not fully thinking it through.

Best regards,
Bruno