CFD Online Discussion Forums - [Other] Writing the old 'positions' file in Lagrangian solvers as of OpenFOAM 5.x

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Community Contributions (https://www.cfd-online.com/Forums/openfoam-community-contributions/)

- - [Other] Writing the old 'positions' file in Lagrangian solvers as of OpenFOAM 5.x (https://www.cfd-online.com/Forums/openfoam-community-contributions/219060-writing-old-positions-file-lagrangian-solvers-openfoam-5-x.html)

Writing the old 'positions' file in Lagrangian solvers as of OpenFOAM 5.x

I've seen this asked here on the forum at least a couple of times in the past, but I haven't gone looking for those threads yet.

Essentially the problem is that ever since the barycentric positions were implemented in OpenFOAM-dev and released in OpenFOAM 5.x (OpenFOAM Foundation), it hasn't been possible to load the Lagrangian data into ParaView when using the internal reader, namely with the file extension ".foam", for example if you open the case with this command:

Code:

paraFoam -builtin

To work around this issue, there are at least three possibilities:

Use OpenFOAM's standard reader for ParaView, namely with the file extension ".OpenFOAM".
- Although this doesn't work when ParaView is not built in the same Operating System as OpenFOAM.
You can export the Lagrangian clouds into VTK files by running:

Code:

foamToVTK -fields '()' -noInternal -excludePatches '(".*")'
Or use the new alternative with a function object that I've finished working on an hour or so ago: https://github.com/blueCFD/lagrangia...unctionObjects
- For OpenFOAM 5.x, see the respective branch and instructions there: https://github.com/blueCFD/lagrangia...ects/tree/OF5x
- For blueCFD-Core 2017: https://github.com/blueCFD/lagrangia...eCFD-Core-2017

If you are using OpenFOAM from OpenFOAM.com (ESI-OpenCFD), you do not need these methods, because they support the old and new formats as follows:

Old format is written to "positions".
New format is written to "coordinates".

Quote:

Originally Posted by wyldckat (Post 738871)

Or use the new alternative with a function object that I've finished working on an hour or so ago: https://github.com/blueCFD/lagrangia...unctionObjects
- For OpenFOAM 5.x, see the respective branch and instructions there: https://github.com/blueCFD/lagrangia...ects/tree/OF5x
- For blueCFD-Core 2017: https://github.com/blueCFD/lagrangia...eCFD-Core-2017

If you are using OpenFOAM from OpenFOAM.com (ESI-OpenCFD), you do not need these methods, because they support the old and new formats as follows:

Old format is written to "positions".
New format is written to "coordinates".

Hi Bruno,

I am facing a problem with your tool (this is the same post I wrote in blueCFD github).

I am tryingto use the function with coalChemistryFoam (OF8), so maybe this coalCloud class is not recognised in the script (only MPPIC, colliding, spray and reacting multiphase). But actually this latter is included to form the coalCloud.

In my case positions.orig are properly written in processorx/lagrangian/coalCloud1 but when reconstructing they do not reconstruct.

Trying to reconstruct and then running postProcess -dict system/positionConvertDict gives me this error:

Code:

Executing functionObjects   --> FOAM FATAL ERROR:    



   request for kinematicCloud coalCloud1 from objectRegistry region0 failed 



    available objects of type kinematicCloud are 0()    



   From function const Type& Foam::objectRegistry::lookupObject(const Foam::word&)





 const [with Type = Foam::kinematicCloud]   

 

  in file /opt/openfoam8/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 211. 



 FOAM aborting

position conversion accuracy

Hi Bruno,

I am trying to use your function object on OF7 to convert barycentric to old positions for a coaxial nozzle flow. The code has compiled with no error but when I do the postprocessing the conversion moves the particle elsewhere.
AS you can see the particles are injected in the core nozzle but in the converted position visualization there are particles in the secondary exhaust.

Attachment 84987
Attachment 84988

So I'm trying to see what causes the deviation from the exact positions.
Thanks
Negar

Quote:

Originally Posted by uosilos (Post 797922)

Code:

Executing functionObjects   --> FOAM FATAL ERROR:    



   request for kinematicCloud coalCloud1 from objectRegistry region0 failed 



    available objects of type kinematicCloud are 0()    



   From function const Type& Foam::objectRegistry::lookupObject(const Foam::word&)





 const [with Type = Foam::kinematicCloud]   

 

  in file /opt/openfoam8/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 211. 



  FOAM aborting

I have the same problem when I want to generate the positions.orig file as post-processing with the sprayFoam solver. It's frustrating because parallelization accelerates my simulations with droplets. I think the program is not detecting the cloud type and using kinematicCloud as default. If anyone knows a solution about this, it would be great, please let us know.

Thanks,
Luis.

Quote:

Originally Posted by lf.lopez18 (Post 817656)

Is running with one of the openfoam.com versions an option? There you continue to have positions (xyz) and coordinates (barycentric), which makes it simple to post-process in paraview.

Quote:

Originally Posted by olesen (Post 817839)

Is running with one of the openfoam.com versions an option? There you continue to have positions (xyz) and coordinates (barycentric), which makes it simple to post-process in paraview.

Unfortunately, the server I use and my custom solver are in OF5 (.org), so it would be difficult to change it. Despite this, I solved the problem by adding the following text in file "OpenFOAM-5.x/src/lagrangian/intermediate/parcels/Templates/KinematicParcel/KinematicParcelIO.C" in these lines:

Line 222:

Code:

IOField<vector> positions_orig(c.fieldIOobject("positions_orig", IOobject::NO_READ), np);

Line 239:

Code:

positions_orig[i] = p.position();

Line 255:

Code:

positions_orig.write(valid);

It is possible that in other versions the lines are different. This will generate a "positions_orig" file in cartesian coordinates, which can be reconstructed from decomposed results. To change the file in barycentric coordinates to cartesian, I use a similar code as the functionObject posted by wyldckat:

Code:

find -name positions | while read line; do mv $line $line.coord; mv $line_orig $line; done

find -name positions | while read line; do sed -i -e 's=^\(.*object.*\)positions_orig;=\1positions;=' $line; done