[yt-dev] yt-3.0 PR #6 - underlying cylindrical ray tracer

Matthew Turk matthewturk at gmail.com
Thu Sep 13 06:29:33 PDT 2012 

Hi Anthony,

Sorry about the delay in replying.  I'm trying to collect my thoughts,
and it's also been a bit of a busy week.

On Wed, Sep 12, 2012 at 4:34 PM, Anthony Scopatz <scopatz at gmail.com> wrote:
> Hello Matt, et al.
>
> So maybe this was silly of me, but I decided to try to pursue integrating
> the cylindrical
> coordinates with YTRayBase rather than with YTOrthoRayBase, not realizing
> that the
> implementation wasn't fully there in yt-3.0.  So I have updated PR #6 to
> include these
> changes as well as a notably absent RaySelector class in
> geometry/selection_routines.pyx.

Awesome, thanks!  I will provide comments over on the PR as soon as I
am able.  In the past we've actually traversed grids directly, so
we'll want to make sure that we have both grid and cell selection
routines that work.

>
> When I do this, however, the _get_data_from_grid() method on YTRayBase never
> gets
> called.  This results in tracebacks and missing data when I try to do even
> simple things
> like:
>
> ray = pf.h.ray(E, F)
> t = ray['t']
>
> will throw:
>
> Traceback (most recent call last):
>   File "cylindrical_rays3.py", line 70, in <module>
>     t = ray['t']
>   File
> "/home/scopatz/.local/lib/python2.7/site-packages/yt-3.0dev-py2.7-linux-x86_64.egg/yt/data_objects/data_containers.py",
> line 196, in __getitem__
>     self.get_data(key)
>   File
> "/home/scopatz/.local/lib/python2.7/site-packages/yt-3.0dev-py2.7-linux-x86_64.egg/yt/data_objects/data_containers.py",
> line 423, in get_data
>     fields = self._determine_fields(fields)
>   File
> "/home/scopatz/.local/lib/python2.7/site-packages/yt-3.0dev-py2.7-linux-x86_64.egg/yt/data_objects/data_containers.py",
> line 372, in _determine_fields
>     finfo = self._get_field_info("unknown", fname)
>   File
> "/home/scopatz/.local/lib/python2.7/site-packages/yt-3.0dev-py2.7-linux-x86_64.egg/yt/data_objects/data_containers.py",
> line 354, in _get_field_info
>     raise YTFieldNotFound((fname, ftype), self.pf)
> yt.utilities.exceptions.YTFieldNotFound: Could not find field '('t',
> 'unknown')' in nif2013_hdf5_plt_cnt_0006.
>
> Any ideas?  Thanks in advance.

Yup, this is one of the data-specific fields, or "container fields".
_get_data_from_grid is now deprecated in 3.0, as it will all be
handled by selectors.  (And I think you're now officially the person
who's done the most with 3.0 besides me! :)  The way to do this is to
do a container field, like what is done for the slices in
_generate_container_field, although I want to move away from that for
slices eventually.  What you can do is get self._current_chunk.fcoords
and then use the values returned to get a parametric distance from the
starting point.

-Matt

>
> Be Well
> Anthony
>
>
> On Tue, Sep 11, 2012 at 1:07 PM, Anthony Scopatz <scopatz at gmail.com> wrote:
>>
>> On Mon, Sep 10, 2012 at 2:18 PM, Matthew Turk <matthewturk at gmail.com>
>> wrote:
>>>
>>> Hi Anthony,
>>>
>>> Sorry for the delay in replying.  I'm still pondering the right way to
>>> handle things that are specific to coordinate-systems.  There are a
>>> handful:
>>>
>>> * Pixelization
>>> * Ray tracing (single ray, ortho and non-ortho)
>>> * Volume rendering
>>> * Ghost zone generation (interpolation, specifically)
>>>
>>> There are probably others, too.  For ray-tracing I could see value in
>>> either supplying alternate subclasses of YTDataContainer objects or in
>>> abstracting out the bare minimum of routines necessary and putting
>>> those in coordinate_handler.
>>
>>
>> If we decide to go down the alternate subclasses route, the
>> coordinate_handlers
>> should have references back to the appropriate  YTDataContainers. This
>> might
>> be the most modular solution...
>>
>> [snip]
>>
>>>
>>> >
>>> > The first question I have is that the rays, unless they begin
>>> > or end on a cell boundary, do not include the start or stop
>>> > points.  This seems like the correct behavior to me, but is
>>> > this consistent with the rest of yt?
>>>
>>> Hmm, in the past we'd allowed rays that started inside cells to
>>> reflect the partial traversal that entails.  I don't think modifying
>>> this behavior should be too big a deal, but that's a refinement for
>>> later.
>>
>>
>> Well, the rays can start from wherever.  It is just that initial and final
>> segment may or may not be included in the return values.  This should
>> be easy to fix but I agree isn't a high priority for the moment.
>>
>>>
>>> > The second, weirder point is as follows.  For 2D R,Z data,
>>> > the cell crossings that are calculated *should* be rotationally
>>> > invariant.  Take p1 and p2 to be two points in r, z, theta s.t.:
>>> >
>>> > p1 = (r1, z1, theta1)
>>> > p2 = (r2, z2, theta2)
>>> >
>>> > Then the ray should pass through the same cells if instead
>>> > we take q1 and q2 as:
>>> >
>>> > q1 = (r1, z1, theta1 + dtheta)
>>> > q2 = (r2, z2, theta2 + dtheta)
>>> >
>>> > for any constant dtheta and r1, z1, theta1, r2, z2,  and theta2
>>> > at the same values in p1 and p2.  However, this does not seem
>>> > to be the case.  Play around in the notebook and you'll see what
>>> > I mean.
>>>
>>> I am also getting this result, which I agree is weird for this data.
>>> It should be invariant.  My only thought is that perhaps there's an
>>> issue of rotational invariance we didn't think about when we designed
>>> the system initially.  One thought is that the boundary conditions are
>>> *necessarily* important for this data, since a chord running through
>>> the concentric circles that constitute the cells will potentially run
>>> outside 0..2pi unless BCs are taken into effect.  This is particularly
>>> true because the initial theta that all of these are set to is pi
>>> (since left edge is 0, right edge is 2pi).  I think this would
>>> correlate with a maximum difference at 0 or 2pi and a minimum
>>> difference at pi for the initial theta that gets perturbed.  Does that
>>> make sense?
>>
>>
>> That does make sense.  Another, related issue may be that perhaps
>> the intersection code with respect to theta may only be valid for
>> small dtheta. This is something else to look into...
>>
>> [snip]
>>
>>> > I don't think either of the above are deal breakers, but I would like
>>> > to
>>> > hear other people's thoughts.  I will work on integrating this with the
>>> > rest of yt-3.0 next week.
>>>
>>> Awesome!  Perhaps we should have a discussion here about how best to
>>> organize coordinate handlers.  I can lead that, if you'd like.
>>
>>
>> I would prefer if you lead that discussion as you know the code base much
>> better than I do ;).  Thanks!
>>
>> Be Well
>> Anthony
>>
>>>
>>>
>>> -Matt
>>>
>>> >
>>> > Be Well
>>> > Anthony
>>> >
>>> > 1.
>>> >
>>> > https://bitbucket.org/MatthewTurk/yt.milestones/raw/7d64152de2e1/cylindrical_rays2.ipynb
>>> >
>>> >
>>> > _______________________________________________
>>> > 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
>>
>>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>

More information about the yt-dev mailing list