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

Tue May 3 16:40:24 PDT 2016

On Tue, May 3, 2016 at 6:28 PM, Cameron Hummels <chummels at gmail.com> wrote:

> I didn't even know it was something that needed to be done until I tried
> last week, perhaps there are others who weren't aware this didn't work?
>
> Anyway, I'm OK on it not being a 3.3 blocker, but the other issue you
> filed should be a blocker for 3.3--updating the docs to indicate which
> frontends work for OAProjs and VR and invitation to devs to help make it
> work.
>

it is

>
> Cameron
>
> On Tue, May 3, 2016 at 3:56 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>
>>
>>
>> On Tue, May 3, 2016 at 5:51 PM, Cameron Hummels <chummels at gmail.com>
>> wrote:
>>
>>> I don't believe I can take this project on right now to make the VR
>>> interface work with particle-based and/or octree-based frontends.  I don't
>>> usually use these frontends, so I can't really justify it to myself to put
>>> a bunch of time in on it when there is little research benefit for me, and
>>> I've already got my plate full.  This may change in the future.  Perhaps
>>> one of the representatives of one of the affected frontends might be
>>> interested in taking this on to assure VR will work with their data?
>>>
>>>
>> Well, we've been waiting for a couple years now for someone to volunteer
>> to do that. I'll happily continue waiting, but I still don't think that
>> this should block 3.3
>>
>>
>>> Cameron
>>>
>>> On Mon, May 2, 2016 at 5:33 PM, Matthew Turk <matthewturk at gmail.com>
>>> wrote:
>>>
>>>> Hi Cameron,
>>>>
>>>> On Mon, May 2, 2016 at 7:21 PM, Cameron Hummels <chummels at gmail.com>
>>>> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Yes, it absolutely has.  When you asked me about this over private
>>>> message or public message on Slack a while back (I forget which) I sent
>>>> back information about how to do this.  I think it would be relatively
>>>> straightforward to implement.  You need to insert a couple "fake" levels in
>>>> the octree so that it is a BSP rather than the way it functions now, but
>>>> these cutting planes can be inserted at the existing cell refinement
>>>> divisions.  It would also be straightforward to implement a ray traversal
>>>> that natively worked with Octrees, which would only require mocking
>>>> PartitionedGrid objects and sorting the octs in the right order for the
>>>> traversal.  (This would result in an identical operation, I think.)
>>>>
>>>> My understanding is that when over_refine_factor > 1, it works for
>>>> particle data sets.  Desika had success with this.  I may no longer be
>>>> right.
>>>>
>>>> Even without any new development, I have not heard of anyone attempting
>>>> to debug why and where the segfault occurs.  My suspicion is that it's a
>>>> fencepost error that shows up because of the binary division in the
>>>> octree.  That would be a good first place to look.
>>>>
>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> I think this would be a great use of resources, but I don't think it
>>>> should block 3.3.  I do not know when I would be able to devote the time to
>>>> it; if someone else is willing to volunteer that time, I think it would be
>>>> great.  Would you be willing to put the time in to ensure that it could
>>>> happen?  If so, I think making it a blocker on 3.3 and setting a deadline
>>>> for it would be a good compromise; if it isn't done by that deadline, punt
>>>> until the next release.
>>>>
>>>> -Matt
>>>>
>>>>
>>>>>
>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Cameron Hummels
>>> NSF Postdoctoral Fellow
>>> Department of Astronomy
>>> California Institute of Technology
>>> http://chummels.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
>>
>>
>
>
> --
> Cameron Hummels
> NSF Postdoctoral Fellow
> Department of Astronomy
> California Institute of Technology
> http://chummels.org
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20160503/f937d25d/attachment.html>