<div dir="ltr">Hi Matt,<div><br></div><div>If we could do that, it would be the cleanest and most effective solution.  When you have time, can you lay out how this can be done?</div><div><br></div><div>Thanks,</div><div>Britton</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 27, 2015 at 2:56 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>
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>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Oct 27, 2015 at 9:35 AM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> I have spent a while looking at the issue involving the derived quantities<br>
> and I have come up with a solution for some of them, but not all of them.  I<br>
> have pushed a couple changes to the PR that add a cell_volume and 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 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 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 as<br>
> little as possible outside of the ytdata frontend.  However, at this point,<br>
> there is no more room to maneuver.  The only solutions I can come up with<br>
> are ugly and would make it very difficult to smoothly swap in a proper 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 quantity<br>
> functions for this frontend only that use position fields appropriate for<br>
> the frontend.  The functions themselves would be simple to implement, but<br>
> because the derived quantity collection is added onto data container objects<br>
> and not dataset objects, I have no idea how one would do the swap.  For a<br>
> similar reason, I don't know how to simply not allow these problem cases 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 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>> wrote:<br>
>><br>
>> Hi John,<br>
>><br>
>> At the PR hangout, we discussed the possibility of eventually creating a<br>
>> method to extract subsets of AMR hierarchies that would include only grid<br>
>> patches that are at least partially contained within the data container.<br>
>> With them, we would also include the mask arrays to be applied to each grid<br>
>> patch such that you would only get the cells within the container.  However,<br>
>> this was deemed something that should not hold up this PR, but that 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 best<br>
>> thing as it would get this on front of users faster, especially since it<br>
>> contains a lot of other things that are fully working.  I may have missed<br>
>> some important parts of the discussion, but my memory faded a lot 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 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>
>>> <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 to<br>
>>> attend today’s PR hangout so anyone else who was more to add or to 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 3.<br>
>>> The main issue with the latter is that for non-gridded data containers (like<br>
>>> sphere, disk, etc.) created from grid datasets, we treat the new datasets as<br>
>>> “particle data”. For that reason there is an issue with calculating the<br>
>>> cell_volume properly. Without that, we cannot use the total_mass() quantity.<br>
>>> Given that we have the cell deltas in the dataset, we could have a special<br>
>>> derived field for the cell_volume.<br>
>>><br>
>>> There are other issues with some of the other derived quantities (e.g.,<br>
>>> weighted_average_quantity returning the wrong units), but I haven’t 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>
</div></div></blockquote></div><br></div>