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