Paraview unable to read lagrangian data (openFoam)

Hi all,

I am currently using:

  • OpenFoam 5x
  • Paraview 5.4.0

I am getting an error message every time I try and load files created in openFoam which uses the sprayFoam solver. The error is:

"ERROR: In /home/ubuntu/OpenFOAM/ThirdParty-dev/ParaView-5.4.0/VTK/IO/Geometry/vtkOpenFOAMReader.cxx, line 8285 vtkOpenFOAMReaderPrivate (0x558b15bd67f0): Error reading line 20 of /home/calvin/OpenFOAM/calvin-v1906/run/NozzlePipe3DCase/1e-05/lagrangian/sprayCloud/positions: Expected punctuation token ')', found 0"

The error seems to be with paraview reading the “positions” folder in the results. Does anyone know why this error is occurring and how I could fix it?

Thanks!

Cal

Please try with our latest release, 5.8 : https://www.paraview.org/download/

Hey thanks for the suggestion. I have installed the new version but I receive an error message when opening
Screenshot from 2020-01-30 16-10-58

Do you know what these errors mean?
Also I am using ubuntu 18.04.3 LTS via virtualbox

Thanks!

ParaView with OpenGL backend is not supported by the OpenGL version provided by virtualbox.
You can use it with mesa backend.

with 5.8RC1, that would be the following line :
paraview-mesa paraview

Hey Thanks I am able to run the new version now

1 Like

Hi,

I am getting the same error with 5.8 and 5.7 on windows. Is there a work around that anyone knows off?
Solver used was Openfoam7, I might just have to foamToVTK it.

@mwestphal Additionally we may wish to have a sticky FAQ (for the OpenFOAM question).

The problem (and confusion) originates from an internal OpenFOAM change to use barycentric coordinates in its lagrangian framework.

In the openfoam.com version:

  • The positions file contains tuples of (x,y,z, cellId). This file is generally ignored by OpenFOAM (in favour of the coordinates file), but is readable by ParaView. The format is consistent with what older versions of OpenFOAM generated.
  • The coordinates file contains the barycentric coordinates. This is used for OpenFOAM restarts but not by ParaView.

In the openfoam.org version:

  • The positions file was changed to contain the barycentric coordinates (identical contents to the openfoam.com coordinates file). Cannot be read by ParaView.

It is probably not realistic to expect support for the openfoam.org positions file. This would require shadowing the volume mesh in order to define the cells, additional tet decomposition of the volume cells, additional barycentric calculations to determine the corresponding x,y,z positions.

Available options, in any order of preference:

  • use the openfoam.com version that generates a positions file that can be read by ParaView.
  • use foamToVTK or foamToEnsight to convert the lagrangian fields only.

Thanks for the explanation @olesenm

Thanks for the information, it is very helpful.

Would it not be beneficial to add both the openfoam readers into paraview?

Perhaps too much detail in the explanation, but essentially the original positions file (and the one that openfoam.com continues to generate), is fully supported by ParaView. The problem is that the .org version now populates that same filename with completely different contents (the barycentric coordinates) in a format that is non-trivial to support. Perhaps a KitWare guy might wish to weigh in with comments about how much development time and memory overhead would be involved to support barycentric coordinates (implementing all of the aforementioned steps). I see this as an upstream problem, not a ParaView problem.

I now fully understand the difference. Remember both openfoam versions have their own readers. The org version is on their Github and built into their version of paraFoam. It is not then just a matter of adding it into paraview?

The openfoam.com version is also readily available as a module, but adding any of them is not a solution since they are built using OpenFOAM components (in addition to being serial-only). We’ll ignore licensing questions (GPL vs BSD) and concentrate on the technical.

In the OpenFOAM reader plugins, the OpenFOAM infrastructure is used to read in mesh, lagrangian etc and then a conversion is done to transcribe them into VTK formats. This means that the volume mesh exists at least twice in memory (first as an OpenFOAM mesh, second as a VTK mesh), which gives them more overhead than the native ParaView/VTK reader. The handling of lagrangian particles in those reader plugins uses that OpenFOAM infrastructure, which means that they can readily convert to x,y,z positions (since they always have the corresponding volume mesh in OpenFOAM format).

If you want to replicate this in the native reader, you are back to the entire business of always reading in a volume mesh, performing the decomposition etc. This is quite a lot of coding and overhead to solve the problem of the .org version only.

You could try with OpenFOAM-1912, which will be largely compatible with the .org version. If you have an existing lagrangian simulation, you can simply rename the positions files to coordinates and perform a restart.
Without a restart, you could rename positions to coordinates before using foamFormatConvert, which should generate the positions file in the known format.

However, the fastest will still be to use foamToVTK. In the OpenFOAM-1912, you would use

$ foamToVTK -no-boundary -no-internal
# or 
$ mpirun -np N foamToVTK -no-boundary -no-internal -parallel

to convert lagrangian only.

@Quefrency : For the Kiware side of things, we do not integrate these different readers for different reasons :

  • We can’t “just” integrate it, we would have to clean, reorganize and even, as @olesenm stated, redesign part of it to make it more VTK-like
  • These readers depends on OpenFOAM, we can’t add OpenFOAM as a dependency, even in the superbuild, for licensing reasons, so that would be a big design changes on these readers.
  • This work would cost money and ressources, and so far, nobody as been willing to pay/do it
  • Once integrated, it become our responsibility to make sure it works with all type of dataset, new versions of OpenFOAM, etc.

The current reader is already complex enough and has it’s own oddities. We are incrementally improving it though.

However, with the existence of project like paraview-plugin-builder, It would probably be possible, for a third-party to produce OpenFOAM readers plugin that can be loaded in the ParaView release.

Thanks for the detail explanation of the different readers. It is very help for me to decide which version to use going forward.

I think I will have to move over to the .com version to have better compatibility with paraview.

I think I will open the .org results with parafoam and save the data through parafoam to vtk, to have the data in the most up-to-date vtk format. From the best of my knowledge openfoam7 is still using the legacy vtk format in foamToVTk while .com has updated the foamToVTK utility.

In short, and I agree with @olesenm, that I show get any openfoam data into VTK for the best user experience with paraview.

@mwestphal that for your explanation as well, it is much appreciated.

Thanks again!

The openfoam.com foamToVTK still supports the legacy format (with the -legacy option), but people usually use the newer formats. It can generate multi-block vtm, vtu, vtp with accompanying time-series (json) files. The XML formats are the inline versions (ascii or base64 encoded binary). No support for using internal file compression or the appended formats (raw binary or base64) since this did not fit well with how the files are being generated internally.