[richpaj]

Particle-Locking in DieselFoam (parallel operation)

Recently, we experienced the situation where a particle appeared to be 'locked'
at a particular site in the mesh under consideration with the result that the
associated spray computation was completely stalled (as denoted by the final message
"Evolving Spray").

Closer inspection of the mesh at the relevant point revealed that the site coincided
with the common vertex of several tetrahedra and, additionally, lay in
the vicinity of the interface between two processor patches.

There then resulted an infinite loop in which the particle was continuously registered
for "transfer" between two processor patches at the end of each update
in the spray (cf. CCloud.C).


In order to circumvent the situation then, it was decided to (approximately) return the particle to its
position at the end of the previous (CFD) timestep, perturb that starting point and then
recompute the trajectory. More precisely, all the characteristic values of the particle
should be returned to their initial values but, given that this is likely to be a rare eventuality
no significant error is expected by not doing so, at present.

I wonder if this has been observed before? Or if a simpler solution exists to this problem?

Regards,

Richard Kenny.

P.S.. The working mesh is "fixed" and nothing at present can be done about that,
furthermore checkMesh records no holes in the mesh.

[niklas]

Hi,

I've experienced this problem as well sometimes, I have a fix for it but you can try this solution if you want (should work although I havent tried it)

Check src/lagrangian/basic/Particle/Particle.C

http://repo.or.cz/w/OpenFOAM-1.5.x.g...5;hb=HEAD#l391

and search for these lines.

391 if (trackFraction < SMALL)
392 {
393 position_ += 1.0e-6*(mesh.cellCentres()[celli_] - position_);
394 }

change 1.0e-6 to something bigger...like for instance 1.0e-2

[richpaj]

Many thanks for your reply. As it happened, I had already tried your suggestion
before but by using a factor of "1e-05". Clearly I should've been bolder.

Having said that am not entirely sure the above would've helped, a diagnostic
message I inserted into the code at the time was telling me that that face was in fact warped
cf. the if-block starting with

if (lambdaMin > 0.0)
{
...

in Particle.C.

Does your other fix involve another type of particle adjustment? In the event, I simply
reset the starting point for the particle at the beginning of the associated CFD timestep.

Unfortunately, haven't been able to test how generally effective this approach might be since no similar
instances of "locking" have been observed...... despite computing a time interval
that is almost 3 times that of the initial "locking interval".

[niklas]

The 1.0e-6 works for almost all meshes, but in some cases it is too small,
it all depends on how warped the faces are.
The drawback with this tracking algorithm is that instead of losing particles, it can
end up in infinte loops.
Holes in the mesh is certainly a problem, but for the tracking I would say that overlapping is
just as big a problem.

my 'fix' was simply to add a counter of how many times you have to move the particle and
once you reached a number of 10, it would move it with a factor of 1.0e-1 instead.
so you start out nice and then you move it more if it doesnt work.
In principle the same thing you have done.

For sprays i dont consider this a big problem, there are so many other factors playing a bigger role than moving a few parcels out of thousands 1/10 of a cell width,
but there are also other applications to consider that are affected by this where this is
unacceptable.