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

Anthony Scopatz scopatz at gmail.com
Sun Sep 16 14:26:23 PDT 2012 

On Thu, Sep 13, 2012 at 8:29 AM, Matthew Turk <matthewturk at gmail.com> wrote:

> 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! :)


haha ;)  Good to know that this is deprecated though.


> 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.
>

Ahh Ok.  Well, I'll take a look at doing it that way when I get back to
this in
a week or so.

Be Well
Anthony



>
> -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
> >
> _______________________________________________
> 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/20120916/725ec673/attachment.html>

More information about the yt-dev mailing list