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

Wed Sep 12 13:34:33 PDT 2012

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.

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.

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20120912/64281b23/attachment.htm>