CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)
-   -   Error in particle mapping using AMR in DPMDyMFoam (https://www.cfd-online.com/Forums/openfoam-solving/225537-error-particle-mapping-using-amr-dpmdymfoam.html)

jairoandres March 30, 2020 18:38

Error in particle mapping using AMR in DPMDyMFoam
 
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::particle::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 August 8, 2020 15:48

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 January 5, 2021 22:42

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 January 6, 2021 15:00

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 February 7, 2021 02:44

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 February 8, 2021 09:12

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 February 8, 2021 09:13

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

ljj February 16, 2021 11:34

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 February 16, 2021 11:36

Quote:

Originally Posted by ljj (Post 796343)
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 February 20, 2021 07:44

Quote:

Originally Posted by jairoandres (Post 796344)
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 March 16, 2021 14:43

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: https://www.cfd-online.com/Forums/op...mppicfoam.html

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 June 15, 2021 16:11

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::particle::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::particle::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::particle::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.


All times are GMT -4. The time now is 01:57.