[parsec-users] fluidanimate Cells2 and cnumPars2 bug?

Christian Bienia cbienia at CS.Princeton.EDU
Wed Feb 24 14:50:18 EST 2010

Hi Jim,


There is indeed a bug in fluidanimate that makes the program recompute the
first frame over and over again, as you and Milo pointed out correctly.
However, the issue is a little more complicated than simply swapping the
pointers to the cell arrays because if the fluid state is simulated for more
frames then the number of particles per cell can exceed the hard-coded limit
of 16 particles per cell that are currently supported by fluidanimate. (That
is the reason for the crash that Milo reported.)


We fixed the issues and have a significantly improved version of the program
that will be released with the next version of PARSEC. The new version also
includes some more features such as the possibility to visualize the fluid.







From: parsec-users-bounces at lists.cs.princeton.edu
[mailto:parsec-users-bounces at lists.cs.princeton.edu] On Behalf Of Jim
Sent: Wednesday, February 24, 2010 1:38 PM
To: 'PARSEC Users'
Subject: [parsec-users] fluidanimate Cells2 and cnumPars2 bug?


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/4fc68d13/attachment.html>

More information about the parsec-users mailing list