[amirhosseintaran]

hi everyone !
i would be very glad if you help me with this problem !
when i set the nEquivalentParticles in the constant folder to 1e9 , the problem occurs .

"
--> FOAM Warning :
From function void Foam:article::locate(const vector&, const vector*, Foam::label, bool, Foam::string)
in file particle/particle.C at line 512
Suppressing any further warnings about particles being located outside of the mesh.
"

i did not change anything in the solver and everything except the mesh particles are the same as wedge15Ma5.

Thanks anyway for your help.
Bests .

[ano]

Hello Amirhossein,


I get the same error sometimes, but it depends on the geometry. I get it for small wedges and non-orthogonal cells.


I normally change the geometry to get rid off it, but that may not be possible for all cases and is not very satisfying.


Unfortunately I also do not know the cause. When I tried to look into it, I found that particles outside cells should be moved along the trajectory between the particle and the cell centre until they are inside the cell again. Before the code looks whether the particle is in a bounding box (a box containing the cell whose edges are parallel to x,y,z ). I guessed it could be connected this bounding box, but never looked more into it.


Did you loose your particle, next to a sharp corner of your computational domain?

[amirhosseintaran]

Dear ano ,
thanks for your reply ,

about that problem , i noticed that when i changed the particle numbers ( no matter more or less than 5e12) it happens !!!!
i myself do not know why !
but now its running successfully with nEquivalentParticles = 5e12
but its not totally good for me because i need more particles .
Do you have any ideas about that ?

bests.
Amir .

[ano]

Dear Amir,


Could you give me a nEquivalentParticles number where a particle gets lost? I tried with 1e11 and 1e12 but nothing happened. I also tried 1e9, but stopped after a short time, since a calculation with 140 mio particles is rather time consuming for a testcase.



I used OF5 for the test. Which version are you using?

[amirhosseintaran]

Dear ano ;
i use OF5 too. first i tried with 1.68e11 .. then tried every number with order of 11 and 10 and 9 .
with these numbers the soloution crashed .
can i have your mail and we talk about this over there ??
i could send some of my files over there for you .

bests
Amir.

[ano]

Dear Amir,

I run now with 1e9 particles per parcel and everything was fine. Since we both use the same tutorial, I guessed that perhaps the difference could be that I use OF5.x and you perhaps 5.0?

I looked into the git log and found this commit:

commit 371762757dbe3cd38a3841a547a9bc8c1aff0b85
Author: Will Bainbridge <http://cfd.direct>
Date: Fri Apr 28 08:03:44 2017 +0100

Lagrangian: Rewrite of the particle tracking algorithm to function in
terms of the local barycentric coordinates of the current tetrahedron,
rather than the global coordinate system.

Barycentric tracking works on any mesh, irrespective of mesh quality.
Particles do not get "lost", and tracking does not require ad-hoc
"corrections" or "rescues" to function robustly, because the calculation
of particle-face intersections is unambiguous and reproducible, even at
small angles of incidence.

...

They made some other minor changes for the lagrangian class in July 2017. Both should be included in the OF5.0 release (which was shortly thereafter). Nevertheless, could you try the newest version of OpenFoam to see whether it works?


CFD direct describe the barycentric particle tracking roughly on their website.

PS: I think that this is an important issue for any dsmcFoam user and since I still hope that someone answers who knows more on this topic, I would like to keep it in the forum.

[amirhosseintaran]

Dear ano ,
i know what you are saying exactly but the difference is my geometry and due to this difference my cells number are different !
what is the geometry you are talking about that is ok with 1e9 ?

[ano]

You said in your first post everything in your case except the particles number would be the same as in wedge15Ma5.


So I used this as a test case, however, what cfd direct promises for the new OF versions sounds like it should work with any geometry. So you could try the newest OF versions first. And in case it is still not running upload your case here.


If you want to stay with the old OF versions: Look whether you have small wedges (or highly non-orthogonal cells) and try to eliminate them from your geometry.

[amirhosseintaran]

Dear ano
at first i said except mesh !
i mean i changed the geometry to something else in my case !
anyway thanks for your help !
do you have any reference that explain what is nEquivalentParticles ?
i think my problem is lack of understanding about this parameter.
thanks.
Amir.

[ano]

Dear Amir,


sorry, I had problems to understand the two sentences one after the other without punctuation.



nEquivalentParticles is just the number of representative particles. Instead of solving for all molecules, nEquivalentParticles are represented by only one particle. That saves a lot of computational cost.



Your mesh probably has sharp corners as mentioned before and on these you lose the particles. By reducing the number of nEquivalentParticles you increase the computational particles and therefore change the probability of this happening. But if it happens for a certain geometry it will certainly happen for any nEquivalentParticles. Spending time in changing nEquivalentParticles is useless and not the problem you have.


Try either to use a newer OF version or change your geometry in a manner to avoid sharp corners/wedges.
But I have the feeling this endless loop doesn't help either of us...

[ano]

Dear Amir,

Sorry, I had problems to understand the two sentences one after the other without punctuation.

nEquivalentParticles is just the number of representative particles. Instead of solving for all molecules, the number of nEquivalentParticles are represented by only one particle. This representation makes the simulation much faster.

Your mesh probably has sharp corners as mentioned before and on these you lose the particles. By reducing the number of nEquivalentParticles you increase the computational particles and therefore change the probability of this happening. But if it happens for a certain geometry it will certainly happen for any nEquivalentParticles. Spending time in changing nEquivalentParticles is useless and not the problem you have.

Try either to use a newer OF version or change your geometry in a manner to avoid sharp corners/wedges.
But I have the feeling this endless loop doesn't help either of us...

[NES81]

I understand this is ~4 years to late, but I was having the same warning. Everything was working ok, but very early in the meshing phase I was seeing this warning of particle initialised outside of mesh, which was concerning. I think the issue was that my "locationInMesh" value was on an edge of the block mesh. My block mesh has 2x2x2 mm cells, so cell edges would be on even values.

Original snappyHexMesh value:
locationInMesh (-.01 0 0); /meters

updated snappyHexMesh value:
locationInMesh (-.011 0 0); /meters

all warnings went away, by simply moving the locationInMesh value off a cell edge.

Hope this may help someone in the future.