Hello Matt, et al.<div><br></div><div>So maybe this was silly of me, but I decided to try to pursue integrating the cylindrical </div><div>coordinates with YTRayBase rather than with YTOrthoRayBase, not realizing that the </div>
<div>implementation wasn't fully there in yt-3.0. So I have updated PR #6 to include these </div><div>changes as well as a notably absent RaySelector class in geometry/selection_routines.pyx.</div><div><br></div><div>
When I do this, however, the _get_data_from_grid() method on YTRayBase never gets</div><div>called. This results in tracebacks and missing data when I try to do even simple things</div><div>like:</div><div><br></div><div>
<div><font face="'courier new', monospace">ray = pf.h.ray(E, F)</font></div><div><font face="'courier new', monospace">t = ray['t']</font></div></div><div><br></div><div>will throw:</div><div><br>
</div>
<div><div><font face="'courier new', monospace">Traceback (most recent call last):</font></div><div><font face="'courier new', monospace"> File "cylindrical_rays3.py", line 70, in <module></font></div>
<div><font face="'courier new', monospace"> t = ray['t']</font></div><div><font face="'courier new', monospace"> 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__</font></div>
<div><font face="'courier new', monospace"> self.get_data(key)</font></div><div><font face="'courier new', monospace"> 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</font></div>
<div><font face="'courier new', monospace"> fields = self._determine_fields(fields)</font></div><div><font face="'courier new', monospace"> 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</font></div>
<div><font face="'courier new', monospace"> finfo = self._get_field_info("unknown", fname)</font></div><div><font face="'courier new', monospace"> 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</font></div>
<div><font face="'courier new', monospace"> raise YTFieldNotFound((fname, ftype), <a href="http://self.pf">self.pf</a>)</font></div><div><font face="'courier new', monospace">yt.utilities.exceptions.YTFieldNotFound: Could not find field '('t', 'unknown')' in nif2013_hdf5_plt_cnt_0006.</font></div>
</div><div><br></div><div>Any ideas? Thanks in advance.</div><div><br></div><div>Be Well</div><div>Anthony</div><div><br></div><div><br><div class="gmail_quote">On Tue, Sep 11, 2012 at 1:07 PM, Anthony Scopatz <span dir="ltr"><<a href="mailto:scopatz@gmail.com" target="_blank">scopatz@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im">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><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 class="im"><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><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 class="h5">
<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></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 class="im"><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><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><span class="HOEnZb"><font color="#888888"><div>Anthony</div></font></span><div class="im"><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></div><br>
</blockquote></div><br></div>