[Yt-dev] The DTFE Method

[Matthew Turk]

Hi Chris,

Thanks for your thoughtful comments.

On Tue, May 3, 2011 at 2:29 PM, Christopher Moody
<juxtaposicion at gmail.com> wrote:
> Hi all,
> I've been looking at this paper closely and here are my initial thoughts:
>
> - It's unclear to me how the code treats the smoothing length in SPH particles (I don't think it does.) I thought it'd be cool if tried to maintain a minimum S/N, like a 3D version of this http://www-astro.physics.ox.ac.uk/~mxc/idl/#binning .
> - It calculates the interpolated values of fields and gradients, but it'd be hard to calculate stuff like the velocity dispersion or higher moments.
> + You can sample at arbitrary points, which I guess would be the centers of the adaptive mesh
> + Already parallelized, and it seems ready to use as an external reference
>
> Personally, the inability to calculate the velocity dispersion is a serious drawback. Perhaps if it returned the particle IDs that belong to every tessellation, then we could define a field that is a function of those particles, and not some aggregate field estimate. Their method implements the CGAL libraries to do the tessellations (which is where the Boost dep comes in from) - I'm not sure what their DTFE method adds to CGAL.

Interesting point.  I suppose that the DTFE is mainly the
implementation of the smoothing kernel?

>
> So the choices are:
> 1. qhull and voro++ have few dependencies.
> 2. DTFE seems marginally better than CGAL, and has the same Boost problem. It is the only OpenMP option though.

Good point.  While yt is not currently OpenMP parallelized, this is on
the radar.  (Specifically, utilizing recent efforst by Cython.)  I
think we might benefit from some cost/benefit analysis, though -- is
the cost of having only MPI-parallel (manually parallelized, by us)
worth the benefit of not relying on Boost+CGAL?  If so, perhaps Voro++
could be a good route to go.  qhull would also be an interesting
mechanism, moving forward.

But, again, these only provide the tesselation step -- on top of that,
we will still need to apply a meshing operation.  And this is a
stopgap that is necessary for now.

Thinking longer term, I am not certain that this method of gridding
SPH is going to be sustainable.  It could potentially keep us set for
a while -- couple years even -- but I think long term we will need
better conceptual separation between geometry and quantities.  Right
now everything is assumed to be a regular mesh, which enables very
fast locating of data and construction of visualizations.  However,
we'll probably need to move to a generalized architecture for data
point selection for a "3.0" release.  We will need to implement some
of this for spherical coordinates, as well.

This would essentially mean separating out geometry from the data
objects.  As it stands, we utilize geometric selection as defined by
the hierarchy (mesh?) for most of the data objects, and I think we
could extend this, but we would need to be careful.  This would likely
be easily applied to the 3D data types, but 2D datatypes I could see
being challenging for particle-based systems.

But, that's getting a bit off-track.  Suffice it to say, I think we
could stage our development of SPH/particle support into both
making-it-look-meshed and accessing-it-natively.

What do you think, Chris?  Could we just grab voro++ and have a shot
at the gridding of SPH particles?  Gabe is also listening in, I think,
and he has substantial experience with SPH particles and might have
feelings on the right way to proceed.

-Matt

>
> chris
> On Tuesday, May 3, 2011 at 1:31 PM, Matthew Turk wrote:
> Okay, okay, I missed that it uses Boost. But there's also Voro++:
>>
>> http://math.lbl.gov/voro++/
>>
>> which to my reading does not use Boost. It could be another
>> contender, although it does not perform the identical operationset as
>> DTFE.
>>
>> -Matt
>>
>> On Tue, May 3, 2011 at 1:10 PM, Stephen Skory <s at skory.us> wrote:
>> > > uses Boost. -10000000.
>> >
>> > Seconded. Is there anything not awful that uses the name Boost? Boost
>> > Mobile? Boost Energy Drinks?
>> >
>> >
>> > --
>> > Stephen Skory
>> > s at skory.us
>> > http://stephenskory.com/
>> > 510.621.3687 (google voice)
>> > _______________________________________________
>> > Yt-dev mailing list
>> > Yt-dev at lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> _______________________________________________
>> Yt-dev mailing list
>> Yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>