<div class="gmail_quote">On Thu, Sep 13, 2012 at 8:29 AM, 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 Anthony,<br>
<br>
Sorry about the delay in replying. I'm trying to collect my thoughts,<br>
and it's also been a bit of a busy week.<br>
<div class="im"><br>
On Wed, Sep 12, 2012 at 4:34 PM, Anthony Scopatz <<a href="mailto:scopatz@gmail.com">scopatz@gmail.com</a>> wrote:<br>
> Hello Matt, et al.<br>
><br>
> So maybe this was silly of me, but I decided to try to pursue integrating<br>
> the cylindrical<br>
> coordinates with YTRayBase rather than with YTOrthoRayBase, not realizing<br>
> that the<br>
> implementation wasn't fully there in yt-3.0. So I have updated PR #6 to<br>
> include these<br>
> changes as well as a notably absent RaySelector class in<br>
> geometry/selection_routines.pyx.<br>
<br>
</div>Awesome, thanks! I will provide comments over on the PR as soon as I<br>
am able. In the past we've actually traversed grids directly, so<br>
we'll want to make sure that we have both grid and cell selection<br>
routines that work.<br>
<div><div class="h5"><br>
><br>
> When I do this, however, the _get_data_from_grid() method on YTRayBase never<br>
> gets<br>
> called. This results in tracebacks and missing data when I try to do even<br>
> simple things<br>
> like:<br>
><br>
> ray = pf.h.ray(E, F)<br>
> t = ray['t']<br>
><br>
> will throw:<br>
><br>
> Traceback (most recent call last):<br>
> File "cylindrical_rays3.py", line 70, in <module><br>
> t = ray['t']<br>
> File<br>
> "/home/scopatz/.local/lib/python2.7/site-packages/yt-3.0dev-py2.7-linux-x86_64.egg/yt/data_objects/data_containers.py",<br>
> line 196, in __getitem__<br>
> self.get_data(key)<br>
> File<br>
> "/home/scopatz/.local/lib/python2.7/site-packages/yt-3.0dev-py2.7-linux-x86_64.egg/yt/data_objects/data_containers.py",<br>
> line 423, in get_data<br>
> fields = self._determine_fields(fields)<br>
> File<br>
> "/home/scopatz/.local/lib/python2.7/site-packages/yt-3.0dev-py2.7-linux-x86_64.egg/yt/data_objects/data_containers.py",<br>
> line 372, in _determine_fields<br>
> finfo = self._get_field_info("unknown", fname)<br>
> File<br>
> "/home/scopatz/.local/lib/python2.7/site-packages/yt-3.0dev-py2.7-linux-x86_64.egg/yt/data_objects/data_containers.py",<br>
> line 354, in _get_field_info<br>
> raise YTFieldNotFound((fname, ftype), <a href="http://self.pf" target="_blank">self.pf</a>)<br>
> yt.utilities.exceptions.YTFieldNotFound: Could not find field '('t',<br>
> 'unknown')' in nif2013_hdf5_plt_cnt_0006.<br>
><br>
> Any ideas? Thanks in advance.<br>
<br>
</div></div>Yup, this is one of the data-specific fields, or "container fields".<br>
_get_data_from_grid is now deprecated in 3.0, as it will all be<br>
handled by selectors. (And I think you're now officially the person<br>
who's done the most with 3.0 besides me! :) </blockquote><div><br></div><div>haha ;) Good to know that this is deprecated though.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The way to do this is to<br>
do a container field, like what is done for the slices in<br>
_generate_container_field, although I want to move away from that for<br>
slices eventually. What you can do is get self._current_chunk.fcoords<br>
and then use the values returned to get a parametric distance from the<br>
starting point.<br></blockquote><div><br></div><div>Ahh Ok. Well, I'll take a look at doing it that way when I get back to this in </div><div>a week or so.</div><div><br></div><div>Be Well</div><div>Anthony</div><div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Matt<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Be Well<br>
> Anthony<br>
><br>
><br>
> On Tue, Sep 11, 2012 at 1:07 PM, Anthony Scopatz <<a href="mailto:scopatz@gmail.com">scopatz@gmail.com</a>> wrote:<br>
>><br>
>> On Mon, Sep 10, 2012 at 2:18 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi Anthony,<br>
>>><br>
>>> Sorry for the delay in replying. I'm still pondering the right way to<br>
>>> handle things that are specific to coordinate-systems. There are a<br>
>>> handful:<br>
>>><br>
>>> * Pixelization<br>
>>> * Ray tracing (single ray, ortho and non-ortho)<br>
>>> * Volume rendering<br>
>>> * Ghost zone generation (interpolation, specifically)<br>
>>><br>
>>> There are probably others, too. For ray-tracing I could see value in<br>
>>> either supplying alternate subclasses of YTDataContainer objects or in<br>
>>> abstracting out the bare minimum of routines necessary and putting<br>
>>> those in coordinate_handler.<br>
>><br>
>><br>
>> If we decide to go down the alternate subclasses route, the<br>
>> coordinate_handlers<br>
>> should have references back to the appropriate YTDataContainers. This<br>
>> might<br>
>> be the most modular solution...<br>
>><br>
>> [snip]<br>
>><br>
>>><br>
>>> ><br>
>>> > The first question I have is that the rays, unless they begin<br>
>>> > or end on a cell boundary, do not include the start or stop<br>
>>> > points. This seems like the correct behavior to me, but is<br>
>>> > this consistent with the rest of yt?<br>
>>><br>
>>> Hmm, in the past we'd allowed rays that started inside cells to<br>
>>> reflect the partial traversal that entails. I don't think modifying<br>
>>> this behavior should be too big a deal, but that's a refinement for<br>
>>> later.<br>
>><br>
>><br>
>> Well, the rays can start from wherever. It is just that initial and final<br>
>> segment may or may not be included in the return values. This should<br>
>> be easy to fix but I agree isn't a high priority for the moment.<br>
>><br>
>>><br>
>>> > The second, weirder point is as follows. For 2D R,Z data,<br>
>>> > the cell crossings that are calculated *should* be rotationally<br>
>>> > invariant. Take p1 and p2 to be two points in r, z, theta s.t.:<br>
>>> ><br>
>>> > p1 = (r1, z1, theta1)<br>
>>> > p2 = (r2, z2, theta2)<br>
>>> ><br>
>>> > Then the ray should pass through the same cells if instead<br>
>>> > we take q1 and q2 as:<br>
>>> ><br>
>>> > q1 = (r1, z1, theta1 + dtheta)<br>
>>> > q2 = (r2, z2, theta2 + dtheta)<br>
>>> ><br>
>>> > for any constant dtheta and r1, z1, theta1, r2, z2, and theta2<br>
>>> > at the same values in p1 and p2. However, this does not seem<br>
>>> > to be the case. Play around in the notebook and you'll see what<br>
>>> > I mean.<br>
>>><br>
>>> I am also getting this result, which I agree is weird for this data.<br>
>>> It should be invariant. My only thought is that perhaps there's an<br>
>>> issue of rotational invariance we didn't think about when we designed<br>
>>> the system initially. One thought is that the boundary conditions are<br>
>>> *necessarily* important for this data, since a chord running through<br>
>>> the concentric circles that constitute the cells will potentially run<br>
>>> outside 0..2pi unless BCs are taken into effect. This is particularly<br>
>>> true because the initial theta that all of these are set to is pi<br>
>>> (since left edge is 0, right edge is 2pi). I think this would<br>
>>> correlate with a maximum difference at 0 or 2pi and a minimum<br>
>>> difference at pi for the initial theta that gets perturbed. Does that<br>
>>> make sense?<br>
>><br>
>><br>
>> That does make sense. Another, related issue may be that perhaps<br>
>> the intersection code with respect to theta may only be valid for<br>
>> small dtheta. This is something else to look into...<br>
>><br>
>> [snip]<br>
>><br>
>>> > I don't think either of the above are deal breakers, but I would like<br>
>>> > to<br>
>>> > hear other people's thoughts. I will work on integrating this with the<br>
>>> > rest of yt-3.0 next week.<br>
>>><br>
>>> Awesome! Perhaps we should have a discussion here about how best to<br>
>>> organize coordinate handlers. I can lead that, if you'd like.<br>
>><br>
>><br>
>> I would prefer if you lead that discussion as you know the code base much<br>
>> better than I do ;). Thanks!<br>
>><br>
>> Be Well<br>
>> Anthony<br>
>><br>
>>><br>
>>><br>
>>> -Matt<br>
>>><br>
>>> ><br>
>>> > Be Well<br>
>>> > Anthony<br>
>>> ><br>
>>> > 1.<br>
>>> ><br>
>>> > <a href="https://bitbucket.org/MatthewTurk/yt.milestones/raw/7d64152de2e1/cylindrical_rays2.ipynb" target="_blank">https://bitbucket.org/MatthewTurk/yt.milestones/raw/7d64152de2e1/cylindrical_rays2.ipynb</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" 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" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>><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" 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" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br>