[kryptomatrix]

Hello,
I did this on my Arch Linux machine:


git clone https://github.com/OpenFOAM/OpenFOAM-6
git clone https://github.com/OpenFOAM/ThirdParty-6


source OpenFOAM-6/etc/bashrc
cd ThirdParty-6
./Allwmake
./makeParaView




The last command produced linking errors.
See https://www.mediafire.com/file/ck5df...8/out.txt/file for the output of the last command

[olesen]

The easiest is to just download a binary pack from kitware and use the built-in OpenFOAM reader. I don't know why everyone thinks that they have to build it themselves.
https://develop.openfoam.com/Develop...raview-plugins

[kryptomatrix]

If I install paraview 5.8.1, and and run "$ paraFoam -builtin" in a case generated by OpenFOAM version 6, should this still work? Because I tried it and paraview thinks that the output of OpenfOAM6 is corrupt.

[olesen]

Originally Posted by kryptomatrix

If I install paraview 5.8.1, and and run "$ paraFoam -builtin" in a case generated by OpenFOAM version 6, should this still work? Because I tried it and paraview thinks that the output of OpenfOAM6 is corrupt.

This should work without problem, unless your files are indeed corrupt or you have lagrangian positions that are actually barycentric coordinates. Might need to pay attention if you happened to have used OpenFOAM with label-size 64 or single precision.

[kryptomatrix]

Originally Posted by olesen

This should work without problem, unless your files are indeed corrupt or you have lagrangian positions that are actually barycentric coordinates. Might need to pay attention if you happened to have used OpenFOAM with label-size 64 or single precision.

Thank, I will try that and open a new bug report if that happens.

you have lagrangian positions that are actually barycentric coordinates

This seems oddly specific. What's up with that?

[olesen]

Originally Posted by kryptomatrix

This seems oddly specific. What's up with that?

The contents of lagrangian positions information has changed a few times. Before OpenFOAM 1.4 it just contained x/y/z/cellid Information. From OpenFOAM 1.4-2.4 (approximately) it contained additional bits for which internal decomposed tet and fraction it contained (helps on restart for OpenFOAM). The reader thus has a toggle in its interface to handle the choice between things. In later versions of OpenFOAM, the internal handling changed radically and started using barycentric coordinates for the internal tracking. This is definitely a good thing, but raises the question about how downstream consumers deal with this change.
The org version made the decision to change the contents of the positions file to now have barycentric coordinates. There is no reasonable method for paraview to deal with this type of content. You (paraview in this case) would need to rebuild the entire volume mesh and perform the identical decomposition and coordinate calculations to determine the x/y/z position of the particle. Even if you manage to get all of this coded and these calculations done, it would mean that you would always need the volume mesh loaded to visualize particle motion!
The com version took a different approach. There the positions file contains x/y/z/cellid like previous versions, and the barycentric coordinates are written in a "coordinates" file. Downstream consumers such as paraview can easily read and process the "positions" file, quickly and easily independently of any volume mesh. The "coordinates" file is used by OpenFOAM for restart. If you really want to save diskspace, can disable writing of the "positions" with an etc/controlDict switch.
I clearly think that this approach is much better.
Probably need to add a mechanism to detect when the positions file actually contains barycentric coordinates etc and then simply reject these instead of giving an error, but then we would need to predict what different types of rubbish get called "positions" and this could be rather difficult.

[olesen]

Note, could also be that you have a large case in binary? In which case you could be hitting a buffer sizing issue (already patched in the vtk master, but didn't make it in time for the 5.9.0 release). If you suspect this, could try with foamFormatConvert to write as ASCII and load that. That particular bug is for binary only.

Could also try with OpenFOAM-v2012.