[parsec-users] fluidanimate Cells2 and cnumPars2 bug?

Jim Dempsey jim at quickthreadprogramming.com
Wed Feb 24 13:38:20 EST 2010

I have been looking at fluidanimate with an eye towards reducing the number
of (or eliminating) critical sections. In performing this investigation I've
noticed two issues. These issues had been reported earlier by Milo Martin
He mentioned his fix wasn't correct, but he may have subsequently corrected
the problem. 
The Cells2 and cnumPars2 are built at file load time and never changed
As Milo pointed out, RebuildGrid is essentially performing a Reset Grid to
initial values. IOW no advancement is occurring (particles are "vibrating"
so to speak). 
>From my cursory look at the code, it seems like the author's intentions were
for Cells2 and cnumPars2 to contain the prior state  (i.e. read-in initial
state and from integration step 2 onwards, the post AdvanceParticles state),
and then to be used by RebuildGrid for preparing the grid for the next
integration step. 
To fix this (which I haven't done as of this writing) either
  AdvanceParticles has to advance Cells into Cells2 (and copy new cnumPars
to cnumPars2)
  AdvanceFrame needs to add a new function CopyCellsAndcnumPars() following
Not only were the initial states (p, v, hv) not updated but also the
proximity pairs counts in cnumPars2 was not updated so the local particle
density could not change.
After I examine this a bit further, I will try to report back my findings.
(bug/noBug, if bug - bug fix)
It might be an interesting diagnostic to display the particles during
integration using a relatively small set of particles. Coding errors
(assuming this is an error) would quite easily be identified. Although this
might not catch all errors in coding the fluid dynamic formulas.
Jim Dempsey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/parsec-users/attachments/20100224/c676d85e/attachment.htm>

More information about the parsec-users mailing list