[Bf-committers] Fluid particles refactoring
jhkarh at gmail.com
Mon Feb 21 22:32:56 CET 2011
On Mon, 21 Feb 2011 04:53:46 +0200, Alex Fraser <adfries at vpac.org> wrote:
> We have been using the SPH solver for engineering simulations. In our
> experiments, we often vary the fluid interaction radius independently
> from the collision radius. For example, if the size of a hole in a
> container mesh changes, I might want to make the collision radius
> smaller. Then again, it might make sense to make the interaction radius
> smaller too, so that the particles still flow nicely through the hole.
> I suppose what I really want to do is change the resolution of the
> simulation without drastically changing the way the fluid behaves (e.g.
> double the number of particles, but maintain the same volume). If you
> can acheive this by changing the rest density at the same time as the
> interaction radius, I'm all for it. Will there be a way to find out what
> the interaction radius is, for the sake of writing reports? Also, what
> will the Advanced > Rest Length setting do?
Partly thanks to your comments and some other people I've slightly changed
my plan now and I do intend to include an interaction radius parameter in
the advanced section. However I'll also add an additional setting to
"multiply interaction radius with particle size", pretty much like the
current setting to "multiply mass with size". By default this option will
be on, so that it's easy and intuitive to start, but if you want to do it
the old way then that will be possible too.
In my current code the interaction radius is 4.0*particle size, which
seems to give quite natural results (this will include nearest neighbors
at distance 2*size and just barely the next ones at distance 4*size in the
sph calculation). The spring rest length is 2.0*particle size, and the
advanced "rest length" parameter is just a multiplier for that default
> One big challenge for us has been finding out how the parameters
> presented in the UI relate to physical quantities. The information
> doesn't seem to be available in the paper the Blender SPH code is based
> Perhaps the simulation in Blender is unphysical. We intend to implement
> a classical SPH algorithm, i.e. one without the double density
> relaxation, to perform further experiments with. We expect it will be
> more physically accurate (although perhaps lacking surface tension), and
> easier to make multi-threaded.
Yes the whole approach taken in the paper is pretty unphysical (or at
least not at all concerned with the physical quantities of fluids) and I
think in a sense that's good as it's designed to be nice system to play
with without having to check physical values from somewhere. Of course it
would also be nice to be able to do physically correct simulations, and
hopefully the changes I'll make will make it a bit easier to test other
sph implementations too.
More information about the Bf-committers