CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM

Particle-Locking in DieselFoam (parallel operation)

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   June 19, 2009, 05:34
Default Particle-Locking in DieselFoam (parallel operation)
  #1
Member
 
Richard Kenny
Join Date: Mar 2009
Posts: 59
Rep Power: 9
richpaj is on a distinguished road
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.
richpaj is offline   Reply With Quote

Old   June 29, 2009, 11:13
Default
  #2
Super Moderator
 
niklas's Avatar
 
Niklas Nordin
Join Date: Mar 2009
Location: Stockholm, Sweden
Posts: 693
Rep Power: 19
niklas will become famous soon enough
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
niklas is offline   Reply With Quote

Old   June 29, 2009, 22:10
Default
  #3
Member
 
Richard Kenny
Join Date: Mar 2009
Posts: 59
Rep Power: 9
richpaj is on a distinguished road
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".
richpaj is offline   Reply With Quote

Old   June 30, 2009, 03:47
Default
  #4
Super Moderator
 
niklas's Avatar
 
Niklas Nordin
Join Date: Mar 2009
Location: Stockholm, Sweden
Posts: 693
Rep Power: 19
niklas will become famous soon enough
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.
niklas is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Script to Run Parallel Jobs in Rocks Cluster asaha OpenFOAM Running, Solving & CFD 12 July 4, 2012 22:51
Segmentation fault when running dieselFoam or dieselEngineFoam in parallel francesco OpenFOAM Bugs 3 June 10, 2011 09:30
DPM UDF particle position using the macro P_POS(p)[i] dm2747 FLUENT 0 April 17, 2009 01:29
particle tracking mike CFX 3 April 17, 2006 00:05
Parallel Computing Classes at San Diego Supercomputer Center Jan. 20-22 Amitava Majumdar Main CFD Forum 0 January 5, 1999 13:00


All times are GMT -4. The time now is 07:32.