<div dir="ltr">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?<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cameron</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 2, 2016 at 4:26 PM, Nathan Goldbaum <span dir="ltr"><<a href="mailto:nathan12343@gmail.com" target="_blank">nathan12343@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>I'm moving some discussion from the comments in issue #1212 over to the mailing list:</div><div><br></div><div><a href="https://bitbucket.org/yt_analysis/yt/issues/1212" target="_blank">https://bitbucket.org/yt_analysis/yt/issues/1212</a><br></div><div><br></div><div>I wanted to check with the list since Cameron objected a bit in the issue discussion.<br></div><div><br></div><div>The issue Cameron identifies is pretty serious, but fully fixing it will require pretty substantial work - adding support for octree data to the AMRKDTree.</div><div><br></div><div>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:</div><div><br></div><div><a href="https://bitbucket.org/yt_analysis/yt/issues/1215" target="_blank">https://bitbucket.org/yt_analysis/yt/issues/1215</a><br></div><div><br></div><div>which will be fixed when yt produces a useful error message rather than seg faulting when trying to construct an AMRKDTree for unsupported data.</div><div><br></div><div>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.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Nathan</div></font></span></div>
<br>_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Cameron Hummels<div><span style="font-size:12.8000001907349px">NSF Postdoctoral Fellow</span></div><div><span style="font-size:12.8000001907349px">Department of Astronomy</span></div><div><span style="font-size:12.8000001907349px">California Institute of Technology</span><br></div><div><a href="http://chummels.org" style="font-size:12.8000001907349px" target="_blank">http://chummels.org</a><br></div></div></div></div>
</div>