<div dir="ltr"><div>I was about to send this one:</div><div><a href="http://paste.yt-project.org/show/6000/">http://paste.yt-project.org/show/6000/</a><br></div><div><br></div><div>Incidentally, it may be better to do this from changeset, 754e08c17816, which precedes my adding of a ytdata-specific cell_volume function.  In that case, even this is suitable:</div><div><a href="http://paste.yt-project.org/show/6001/">http://paste.yt-project.org/show/6001/</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 27, 2015 at 3:05 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Britton,<br>
<br>
Yes -- in fact, I am going to try adding it to your PR.  Is there a<br>
notebook or script that demonstrates how to make the setup fail as-is?<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Oct 27, 2015 at 10:04 AM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>> wrote:<br>
> Hi Matt,<br>
><br>
> If we could do that, it would be the cleanest and most effective solution.<br>
> When you have time, can you lay out how this can be done?<br>
><br>
> Thanks,<br>
> Britton<br>
><br>
> On Tue, Oct 27, 2015 at 2:56 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br>
>><br>
>> Hi Britton,<br>
>><br>
>> I've thought about this a bit, and I think this can be addressed.  In<br>
>> the ytdata frontend, we should be able to make it recognize the index<br>
>> fields; if we can't, we are overdue for having coordinate handlers<br>
>> check things out.  There should be logic that prevents derived fields<br>
>> overriding on-disk fields, so if there is an on-disk field that<br>
>> presents "index" it should work.<br>
>><br>
>> On Tue, Oct 27, 2015 at 9:35 AM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>><br>
>> wrote:<br>
>> > Hi all,<br>
>> ><br>
>> > I have spent a while looking at the issue involving the derived<br>
>> > quantities<br>
>> > and I have come up with a solution for some of them, but not all of<br>
>> > them.  I<br>
>> > have pushed a couple changes to the PR that add a cell_volume and<br>
>> > cell_mass<br>
>> > field specific to YTDataContainerDatasets that makes use of their "dx",<br>
>> > "dy", and "dz" fields.  As of now, the following derived quantities<br>
>> > work:<br>
>> > - min location<br>
>> > - max location<br>
>> > - extrema<br>
>> > - bulk velocity<br>
>> > - total mass<br>
>> > - weighted average quantity<br>
>> > - weighted variance<br>
>> > - total quantity<br>
>> ><br>
>> > The ones that don't work are:<br>
>> > - spin parameter<br>
>> > - center of mass<br>
>> > - angular momentum vector<br>
>> ><br>
>> > The final three all don't work for the same reason, which is that they<br>
>> > require access to the "index" position fields.  Unfortunately, these<br>
>> > cannot<br>
>> > be overridden for reasons that have to do with the _determine_fields<br>
>> > function.  I have made a point during this development process to alter<br>
>> > as<br>
>> > little as possible outside of the ytdata frontend.  However, at this<br>
>> > point,<br>
>> > there is no more room to maneuver.  The only solutions I can come up<br>
>> > with<br>
>> > are ugly and would make it very difficult to smoothly swap in a proper<br>
>> > AMR<br>
>> > hierarchy when we get around to creating one and doing this properly.<br>
>> ><br>
>> > The last thing I can think of would be to swap in special derived<br>
>> > quantity<br>
>> > functions for this frontend only that use position fields appropriate<br>
>> > for<br>
>> > the frontend.  The functions themselves would be simple to implement,<br>
>> > but<br>
>> > because the derived quantity collection is added onto data container<br>
>> > objects<br>
>> > and not dataset objects, I have no idea how one would do the swap.  For<br>
>> > a<br>
>> > similar reason, I don't know how to simply not allow these problem cases<br>
>> > to<br>
>> > be called, or to fail in a clean way for them.<br>
>> ><br>
>> > If anyone has any ideas, I would love to hear them.<br>
>> ><br>
>> > Britton<br>
>> ><br>
>> > On Mon, Oct 26, 2015 at 10:12 PM, John ZuHone <<a href="mailto:jzuhone@gmail.com">jzuhone@gmail.com</a>> wrote:<br>
>> >><br>
>> >> No worries—the main issues now are the tests (which don’t run under<br>
>> >> Python<br>
>> >> 2) and Python 3.<br>
>> >><br>
>> >> Tomorrow I’ll point you at the head that I’ve been making changes on to<br>
>> >> address these.<br>
>> >><br>
>> >> On Oct 26, 2015, at 6:09 PM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>><br>
>> >> wrote:<br>
>> >><br>
>> >> Hi John,<br>
>> >><br>
>> >> At the PR hangout, we discussed the possibility of eventually creating<br>
>> >> a<br>
>> >> method to extract subsets of AMR hierarchies that would include only<br>
>> >> grid<br>
>> >> patches that are at least partially contained within the data<br>
>> >> container.<br>
>> >> With them, we would also include the mask arrays to be applied to each<br>
>> >> grid<br>
>> >> patch such that you would only get the cells within the container.<br>
>> >> However,<br>
>> >> this was deemed something that should not hold up this PR, but that<br>
>> >> could<br>
>> >> eventually subbed in to fill in any gaps in functionality created by<br>
>> >> treating the grid data like particles.  We decided that patching the<br>
>> >> existing machinery with a frontend-specific cell_volume field was the<br>
>> >> best<br>
>> >> thing as it would get this on front of users faster, especially since<br>
>> >> it<br>
>> >> contains a lot of other things that are fully working.  I may have<br>
>> >> missed<br>
>> >> some important parts of the discussion, but my memory faded a lot<br>
>> >> faster<br>
>> >> than I thought it would.<br>
>> >><br>
>> >> I probably won't have much time to work on this until Friday, but I'll<br>
>> >> try<br>
>> >> to play around with the derived quantities when I can.<br>
>> >><br>
>> >> Britton<br>
>> >><br>
>> >> On Mon, Oct 26, 2015 at 9:45 PM, John ZuHone <<a href="mailto:jzuhone@gmail.com">jzuhone@gmail.com</a>> wrote:<br>
>> >>><br>
>> >>> Hi all,<br>
>> >>><br>
>> >>> Matt asked someone to send a quick note about the current issues<br>
>> >>> regarding the ytdata frontend PR:<br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> <a href="https://bitbucket.org/yt_analysis/yt/pull-requests/1788/adding-ytdata-frontend" rel="noreferrer" target="_blank">https://bitbucket.org/yt_analysis/yt/pull-requests/1788/adding-ytdata-frontend</a><br>
>> >>><br>
>> >>> I’m sending it because I’m working on it currently, but I was not able<br>
>> >>> to<br>
>> >>> attend today’s PR hangout so anyone else who was more to add or to<br>
>> >>> correct<br>
>> >>> should chime in.<br>
>> >>><br>
>> >>> Currently, there are 3 issues, from most important to least important:<br>
>> >>><br>
>> >>> 1. Tests don’t work<br>
>> >>> 2. Doesn’t support Python 3<br>
>> >>> 3. Derived quantities don’t work<br>
>> >>><br>
>> >>> I’m currently working on 1 and 2, and there have been some ideas about<br>
>> >>> 3.<br>
>> >>> The main issue with the latter is that for non-gridded data containers<br>
>> >>> (like<br>
>> >>> sphere, disk, etc.) created from grid datasets, we treat the new<br>
>> >>> datasets as<br>
>> >>> “particle data”. For that reason there is an issue with calculating<br>
>> >>> the<br>
>> >>> cell_volume properly. Without that, we cannot use the total_mass()<br>
>> >>> quantity.<br>
>> >>> Given that we have the cell deltas in the dataset, we could have a<br>
>> >>> special<br>
>> >>> derived field for the cell_volume.<br>
>> >>><br>
>> >>> There are other issues with some of the other derived quantities<br>
>> >>> (e.g.,<br>
>> >>> weighted_average_quantity returning the wrong units), but I haven’t<br>
>> >>> been<br>
>> >>> able to diagnose them yet.<br>
>> >>><br>
>> >>> I’m working on some changes that will need to be merged into Britton’s<br>
>> >>> fork eventually to address at least 1 and 2.<br>
>> >>><br>
>> >>> Best,<br>
>> >>><br>
>> >>> John<br>
>> >>><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>
>> >><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>
>> >><br>
>> >><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>
>> ><br>
>> ><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>
>> _______________________________________________<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>
><br>
><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>
_______________________________________________<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>
</div></div></blockquote></div><br></div>