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

[Anthony Scopatz]

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/20120911/2547e055/attachment.html>