[yt-dev] Should support for octree data in the AMRKDTree be a blocker for 3.3?

[Cameron Hummels]

I wasn't entirely objecting to punting it, but I think it warrants
discussion here.  Until I tried to build some Off axis projections and VRs
for SPH data, I didn't realize that they weren't supported.  In fact, which
frontends are actually supported for doing VRs and OffAxisProjections?  If
Octtree-based code isn't, then that knocks out ART, ARTIO, and Ramses, and
without SPH, it knocks out Gadget, Tipsy, Gizmo, and Gasoline, which leaves
Enzo, Flash, and Athena?  Others?

I honestly don't have any idea how much work it would take to construct a
KDTree from octree data.  I figured this was in the realm of CS and would
probably have been solved elsewhere, but maybe not.

Anyway, I'm not trying to be too obstructionist here, just trying to have a
discussion, since there were at least 4 other issues filed regarding this
in the past, so it seems relevant for a lot of users.

Cameron

On Mon, May 2, 2016 at 4:26 PM, Nathan Goldbaum <nathan12343 at gmail.com>
wrote:

> Hi all,
>
> I'm moving some discussion from the comments in issue #1212 over to the
> mailing list:
>
> https://bitbucket.org/yt_analysis/yt/issues/1212
>
> I wanted to check with the list since Cameron objected a bit in the issue
> discussion.
>
> The issue Cameron identifies is pretty serious, but fully fixing it will
> require pretty substantial work - adding support for octree data to the
> AMRKDTree.
>
> I've gone ahead and marked it for version 3.4 - i.e. that it shouldn't be
> a blocker for the 3.3 release. I've also created issue 1215:
>
> https://bitbucket.org/yt_analysis/yt/issues/1215
>
> which will be fixed when yt produces a useful error message rather than
> seg faulting when trying to construct an AMRKDTree for unsupported data.
>
> I think that requiring someone to add support for octree data to the
> AMRKDTree before we release 3.3 is effectively delaying the 3.3 release
> arbitrarily far into the future, since no one is currently willing to work
> on that project. That would be unfortunate, because there's lots of cool
> stuff people have worked on that deserves a stable release.
>
> -Nathan
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>


-- 
Cameron Hummels
NSF Postdoctoral Fellow
Department of Astronomy
California Institute of Technology
http://chummels.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20160502/8b4fd63e/attachment-0001.htm>