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

[Matthew Turk]

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.

On Thu, Sep 6, 2012 at 8:08 PM, Anthony Scopatz <scopatz at gmail.com> wrote:
> Hello All,
>
> I am writing to let you know that I have (finally) built the
> underlying function for the cylindrical ray tracer which
> solves for the time, distance, location, and grid indices
> of the ray.  The reason that I opened a PR rather rather
> than just pushing is that I would appreciate some feedback.
> First note that you can play around with this functionality
> using the following ipython notebook [1], though you will
> also need 2D R,Z data to point it at.

This is awesome -- great work!  Thanks for doing this.  Last week at
the Community Code workshop, Prof Lamb spent some time discussing
Shadowgraphy in FLASH and I'm really excited to see this functionality
start pushing forward.

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

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

>
> The shape of the r, z and theta components as a function of t
> are all the same.  That is good news in that the algorithm is
> working.  However, not even the same number of cells are being
> picked up.
>
> This seems wrong.  But I can't figure out what is the cause, so I
> was hoping other sets of eyes could take a gander.  Additionally,
> all solutions that I could think of - such as adding the 'best' dtheta
> and then transforming back prior to returning - would break the
> 3D version of this function.
>
> 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.

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