Hi,
yes, this error happens also from a session of ParaView, and I just reproduced it:
“cfd-user@localhost:~/OpenFOAM/OpenFOAM-8/my_cases/case2> paraview
I/O : uncollated
Segmentation fault (core dumped)”
With the same commands as in ParaFoam: “Pick Center” or “Select Cells On”.
I use ParaView 5.6.3.
When it happens the first time, then it is mathematical that it happens again every time you use those commands.
Thanks.
I finally have found the time to install it.
But I am getting some troubles in sort out this issue.
I have installed on a virtual machine OpenFOAM-8 and Paraview v5.6.3 packaged in a Linux OpenSUSE distribution.
Now, I updated Paraview with the newest version 5.9.0, as you suggested. I downloaded the source code, compiled it in the Third Party directory with makeParaview, and the installation was completed successfully.
Paraview v5.9.0 opens up properly when running the script paraview in the respective folders (by manually clicking on it or in a new terminal after I updated the .bashrc file with the proper environment variables).
But when in a shell terminal, where OpenFOAM is running, I type Paraview or ParaFoam this opens up again the version 5.6.3 of Paraview, and not the latest one installed in the same directory.
How can I link Paraview 5.9.0 to OpenFOAM to get the proper Paraview/ParaFoam working?
Thanks in advance for your help.
GL
How can I link Paraview 5.9.0 to OpenFOAM to get the proper Paraview/ParaFoam working?
This is an OpenFOAM question, not a ParaView one.
Why not using ParaView binary release from here:
https://www.paraview.org/download/
Yes, I know. But I already asked in others forums and so far could not get any response. I was wondering whether you have some precise procedures to pass me on how to link Paraview with OpenFOAM, to complete the process of installation.
From my side I tried differents things but without success.
I downloaded also the binary release, in another directory, and it looks working fine so far without the problems encountered with the 5.6.3 version mentioned above.
GL
This doesn’t make sense.
What are you trying to do ?
As described above,
"But when in a shell terminal, where OpenFOAM is running, I type paraview or paraFoam this opens up again the version 5.6.3 of Paraview, and not the latest one installed in the same directory.
How can I link Paraview 5.9.0 to OpenFOAM to get the proper Paraview/ParaFoam working?"
The best would be to have the possibility to choose between Paraview 5.6.3 and Paraview 5.9.0 (or whatever) when typing paraview/paraFoam within a shell terminal where OpenFOAM is running.
Can you help on this?
GL
Why do you want to run ParaView from the OpenFOAM terminal ? Just run ParaView from your system directly and access your OpenFOAM results.
Because this is what you normally do in a packaged distribution OpenFOAM+Paraview, where the PV4Foam reader module is integrated and set up to run the included Paraview version. My issue is how to “update” the PV4Foam reader module to run in general another Paraview version which does not come with OpenFOAM. This is what I meant with “complete the process of installation”: integration of a new Paraview version into an already existing OpenFOAM.
There are many instructions on the web, but often not precise and unique, therefore I can’t manage to do it so far.
Yes, to simplify my life, I can just run ParaView from my system directly and access OpenFOAM results, as you suggested.
GL
ParaView and OpenFOAM are two separate software and there is no reason for them to be packaged together.
@olesenm .
I noticed that in Paraview 5.9.0 the .vtk format has been updated to version 5.1: due to this change the routine in OpenFOAM surfaceFeatureConvert, by which we can convert from .vtk to .eMesh format, does not work anymore. The presence of new keywords as OFFSET, CONNETTIVITY, etc generates errors from this script.
Is it possible to save in 4.x .vtk (ASCII) format in Paraview 5.9.0?
Otherwise, do you know a workaround for that?
GL
Is it possible to save in 4.x .vtk (ASCII) format in Paraview 5.9.0?
This is being worked on.
do you know a workaround for that?
Use another format.
For your information the only file formats supported by the routine surfaceFeatureConvert, needed to create the eMesh files, are the following:
“Valid types: ( bdf eMesh featureEdgeMesh inp nas obj vtk )”
None of them are available in “Save Data…” or “Save Geometry…” in ParaView. In my knowledge the only way is through the .vtk version 4.x file format.
GL
Unfortunate. Converting from another format (eg: .vtu) to a 4.x .vtk using an old version of ParaView or VTK could be a solution until 4.x support comes back.
I wholeheartedly agree. Packaging them together may be convenient, but is pretty horrible. The real problem here is keeping up with the (minor?) changes in the VTK format, which has been discussed on another thread. The old legacy format was dead simple to parse, which is why lots of different software handled it. The update to vtkCellArray results in changes to the legacy format that takes time to catch up with.
EDIT: added an OpenFOAM issue to update the legacy reading.
Look more closely for Wavefront .obj format. It must be there - at least it is in my paraview.
I can only second that.
The OpenFOAM FAQ: Do I really need the paraview plugins?
In short, normally no reason for a regular OpenFOAM user not to just use the regular ParaView binaries.
@mwestphal (or @cory.quammen ?) - could you add the FAQ link somewhere in top-level sticky?
Would really like to wean people off of the idea that they need to build reader plugins for OpenFOAM. It just causes everyone lots of trouble, and it makes much more sense to concentrate efforts in improving the reader within VTK as required instead.
I can definitely add a FAQ entry for that !
Unfortunately I use OpenFOAM 8. Thx anyway.