[jairoandres]

Dear all

I am using a velocity gradient-based AMR criteria under the DPMDyMFoam solver (OpenFOAM V1912). The simulation consists of solid particles introduced into a confinement through a coaxial jet. It works fine and postprocessing shows good results. However, after several iterations (+10000) (long enough for some particles to exit the domain), the simulation crashes with the following error:

ExecutionTime = 12298.74 s ClockTime = 12308 s

Courant Number mean: 0.0093041779 max: 0.96458841
deltaT = 5e-05
Time = 1.6232

Selected 94 split points out of a possible 43041.
Unrefined from 441930 to 441272 cells.
[1]
[1]
[1] --> FOAM FATAL ERROR:
[1] "Particle mapped to a location outside of the mesh" when tracking from centre (0.028415721 -0.44624185 0.090168445) of cell 54248 to position (0.027997367 -0.44822535 0.091582116)
[1]
[1] From function void Foam:article::locate(const vector&, const vector*, Foam::label, bool, const Foam::string&)
[1] in file particle/particle.C at line 450.
[1]
FOAM parallel run exiting
[1]
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.


It is clear the error is produced after the refining/unrefining process is done. Because the mesh keeps changing, I am not sure about the exact location of that cell, but I am almost positive it represents an internal cell located near (downstream) the particle injector.

This zone is subjected to a lot of refinement / unrefinement. My best guess is that after the unrefinement, the particle mapping algorithm does not know the cell was refined. However, I am not sure if the particle locations can be corrected in the same way fluxes are in the dynamicMeshDict.

Have you got any ideas to fix this error?

[jairoandres]

new update on this, the cell is a wall-boundary cell and the error occurs when openFoam maps the particle after the cell is unrefined. It might be related with the mapping of the particle position in the new cell. The cell is a hexahedral and is an elongated box (2:1) relation. In order to keep running the case I had to decrease the threshold for unrefinement. After some iterations, I increased the unrefining threshold again and the case kept working well. If the threshold is increased again, the same error reappears. Is more evident if more parcels are atomized.

[ljj]

Dear jairoandres,

I meet the same question,but I couldn't understand ''decrease the threshold for unrefinement''.Cloud you please tell me how to keep running the case.Thanks a lot.

[jairoandres]

Hello, I meant to decrease the target value for refinement, so refined cells are not unrefined as often. The error appears to be related to a weakness in the Baryocentric particle tracking in OpenFOAM, retracking the particles outside of the domain when the unrefined element shape is a bit rough. I've read the release notes of OpenFOAM V2012 and they mention the following on the fixes:

Lagrangian: Improved particle tracking on moving meshes
This release includes several improvements to particle tracking on moving mesh cases. These cases would often fail in earlier versions due to:

particles crossing AMI patches;
particle-wall interactions; and
fragility of the barycentric tracking (ported from openfoam.org)

I will be checking that version soon enough. Let me know if you do it first and you are able to fix the error.

You can check it out in https://www.openfoam.com/releases/op...an-moving-mesh.

[ljj]

Hello,

Thanks for your reply. I tried to decrease the target value for refinement, the error still appear.But when I didn't use dynamic refinement, my case would keep running.

[jairoandres]

I can now confirm you is a bug in OpenFOAM. I've posted the issue present in the previous OF version, with the solution I found (basically reverting to OF V8 code). According to Mattijs, " the code was indeed checking the old cell label instead of the found one". Therefore you have to modify particle.C and recompile to make it work (or use OpenFOAM v8).

This is the bug report with fix:
https://develop.openfoam.com/Develop.../-/issues/1992

[jairoandres]

As particle is a global class, I suppose this issue was present in all Lagrangian solvers with DyM capability

[ljj]

It seems a random error,because only some cases reported the error.Thank you very much for your approach to fix it,Iwill try.

[jairoandres]

Originally Posted by ljj

It seems a random error,because only some cases reported the error.Thank you very much for your approach to fix it,Iwill try.

It is not a random error. It shows itself when the cell containing the particle is unrefined.

[ljj]

Originally Posted by jairoandres

It is not a random error. It shows itself when the cell containing the particle is unrefined.

I modified the particle.C according to your method, but the error also occured.

[jairoandres]

What error msg are you getting? The same one than me? "Particle mapped to a location outside of the mesh"?

I fixed the error doing these things:

1) Recompiling according to the instructions above
2) Applying the modifications suggested here: strange stuck particles on the rebound wall in MPPICFoam

I tracked the mapping error in particle.C and concluded it only applied to very small particles getting stuck in a cell that was getting refined (or near one).

[jairoandres]

If the error persists, do the following:

- Use OpenFOAM8, as the error does not occur there (tested).
- Supress the fatalErrorInFunction in particle.C. I did the following modification:

// If we are here then we hit a boundary
if (boundaryFail)
{

// FatalErrorInFunction << boundaryMsg << exit(FatalError);
WarningInFunction << boundaryMsg.c_str()
<< " Particle mapped to a position outside the mesh "
<< " when tracking from centre " << mesh_.cellCentres()[celli_]
<< " of cell " << celli_ << " to position " << position
<< endl;

}

So now it informs me about the problematic parcels, for example:
--> FOAM Warning :
From void Foam:article::locate(const vector&, const vector*, Foam::label, bool, const Foam::string&)
in file particle/particle.C at line 490
Particle mapped to a location outside of the mesh Particle mapped to a position outside the mesh when tracking from centre (-0.097298774 -2.7766543 -0.016508863) of cell 261589 to position (-0.09914252 -2.774333 -0.012070063)
--> FOAM Warning :
From void Foam:article::locate(const vector&, const vector*, Foam::label, bool, const Foam::string&)
in file particle/particle.C at line 490
Particle mapped to a location outside of the mesh Particle mapped to a position outside the mesh when tracking from centre (-0.065778139 -2.7695135 -0.073571944) of cell 256783 to position (-0.065387604 -2.7707525 -0.07491915)
--> FOAM Warning :
From void Foam:article::locate(const vector&, const vector*, Foam::label, bool, const Foam::string&)
in file particle/particle.C at line 490
Particle mapped to a location outside of the mesh Particle mapped to a position outside the mesh when tracking from centre (-0.087467724 -2.6772054 -0.097611269) of cell 238163 to position (-0.084117035 -2.6812271 -0.097412273)

So the error is presented in 3 out of 60000 parcels when doing a big refinement in the grid. In minor refinements, usually, no problems are presented. Sometimes the same problematic parcels present errors again. I can live with this error as I don't have time to study the differences between OpenFOAM8 and OpenFOAM 2012. The problematic parcel ID can be also printed.

[richardt]

Greetings,

I want to thank the author of this post for providing information about the mentioned issue, it was really helpful for me and I am using the modifications proposed in the bug report.

I have one extra question, since the author is using Adaptive Mesh Refinement with a lagrangian solver.

I was wondering if you ever had issues with the function "kinematicCloud.storeGlobalPositions()" while using the collidingCloud with the pairCollision collisionModel, Adaptive Mesh Refinement, and DPMDyMFoam.

I am working with a VOF-LPT approach and I want to include inter-particle collisions into my framework. My mesh size to particle size ratio is really close to one, so I guess a deterministic model would suit me better, at least for diluted cases.

However, when I try to activate the collisionModel while using Adaptive Mesh Refinement, I cannot access the kinematicCloud.storeLocalPositions() anymore. My solver works normally when I use "collisionModel none;".

The error I get is:

--> FOAM FATAL ERROR:
Global positions are not available. Cloud::storeGlobalPositions has not been called.

From function void Foam::Cloud<ParticleType>::autoMap(const Foam::mapPolyMesh&) [with ParticleType = Foam::CollidingParcel<Foam::KinematicParcel<Foam:: particle> >]
in file ../../../IVT41_src/IVT_basic_realSize_std_collidingCloud_2/lnInclude/Cloud.C at line 352.

FOAM exiting

I am using OF1812.

[jairoandres]

Hi Richard,

Its been a while but I don´t remember having any issue with such function. The solver only blew when mapping the particle positions to the new geometry after mesh adaptation.

I partially resolved this, which is explained in this bug report: https://develop.openfoam.com/Develop.../-/issues/1992

However, part of the problem was due to the particle locating itself physically outside of the mesh, as I explain here:
https://develop.openfoam.com/Develop.../-/issues/2289

My workaround was not allowing near-wall cells containing particles to be refined/unrefined.

So in short, particle positions were always available.

Have you tried using a simplified case, and print those positions on screen to see if the error is general (function use) or just happens with some particles?

Regards,

Jairo

[jairoandres]

By the way, is that a customized solver? if not, does it still ocurr in the latest version of OpenFoam?

[richardt]

Thank you very much for the quick reply, Jairo!

It is a customized solver based on the VOF interFlow solver from the TwoPhaseFlow library. I have also included some particle force and patch interaction models, so my intermediate library is also customized. I will test it with the latest OF version compatible with the TwoPhaseFlow library, OF2112, but I have to recompile the libraries and solvers.

The error happens when the solver tries to adapt the mesh in the first time-step, before the particles are injected. It is weird that it does not work only when the "collisionModel" is active.

I have based my solver's tracking on the DPMDyMFoam implementation, so I was expecting it to work with AMR.

P.S.: Your suggestions for the modifications in the particle::locate function helped me to avoid the particles being located outside the mesh, and it works fine while refining cells near the boundary with particles inside. Thank you for that!

I will attach the section of my script where I included the storeGlobalPositions() function. It is before the mesh.update() function.

while (runTime.run())
{
#include "readDyMControls.H"
#include "CourantNo.H"
#include "alphaCourantNo.H"
#include "setDeltaT.H"

++runTime;

if(overwrite)
{
runTime.setTime(runTime.value() - runTime.deltaTValue(), 1);
runTime.writeAndEnd();
}

Info<< "Time = " << runTime.timeName() << nl << endl;

// Store the particle positions
kinematicCloud.storeGlobalPositions();

mesh.update();

if (mesh.changing())
{
advector->surf().mapAlphaField();
alpha2 = 1.0 - alpha1;
alpha2.correctBoundaryConditions();

...

[jairoandres]

I`ve just checked my simulations and I did not use a collision model for the sprayCloud.

[richardt]

Oh, I see.

I have made a simple test for particles inside a container with a certain inlet velocity from a patch using DPMDyMFoam and the collisionModel: pairCollision and it did not worked with AMR either. I refined the U.air magnitude and U.air gradient fields.

I will test it in OF2112.

Thank you for your time!

Best regards