Hello All, <div><br></div><div>I am writing to let you know that I have (finally) built the </div><div>underlying function for the cylindrical ray tracer which </div><div>solves for the time, distance, location, and grid indices </div>


<div>of the ray.  The reason that I opened a PR rather rather </div><div>than just pushing is that I would appreciate some feedback.</div><div>First note that you can play around with this functionality</div><div>using the following ipython notebook [1], though you will </div>


<div>also need 2D R,Z data to point it at.</div><div><br></div><div>The first question I have is that the rays, unless they begin</div><div>or end on a cell boundary, do not include the start or stop </div><div>points.  This seems like the correct behavior to me, but is </div>


<div>this consistent with the rest of yt?</div><div><br></div><div>The second, weirder point is as follows.  For 2D R,Z data,</div><div>the cell crossings that are calculated *should* be rotationally</div><div>invariant.  Take p1 and p2 to be two points in r, z, theta s.t.:</div>

<div><br></div><div>p1 = (r1, z1, theta1)</div><div>p2 = (r2, z2, theta2)</div><div><br></div><div>Then the ray should pass through the same cells if instead </div><div>we take q1 and q2 as:</div><div><br></div><div><div>

q1 = (r1, z1, theta1 + dtheta)</div><div>q2 = (r2, z2, theta2 + dtheta)</div></div><div><br></div><div>for any constant dtheta and r1, z1, theta1, r2, z2,  and theta2</div><div>at the same values in p1 and p2.  However, this does not seem </div>

<div>to be the case.  Play around in the notebook and you&#39;ll see what </div><div>I mean.  </div><div><br></div><div>The shape of the r, z and theta components as a function of t </div><div>are all the same.  That is good news in that the algorithm is </div>

<div>working.  However, not even the same number of cells are being </div><div>picked up.  </div><div><br></div><div>This seems wrong.  But I can&#39;t figure out what is the cause, so I </div><div>was hoping other sets of eyes could take a gander.  Additionally, </div>

<div>all solutions that I could think of - such as adding the <i>&#39;best&#39;</i> dtheta</div><div>and then transforming back prior to returning - would break the </div><div>3D version of this function.</div><div><br></div>

<div>I don&#39;t think either of the above are deal breakers, but I would like to </div><div>hear other people&#39;s thoughts.  I will work on integrating this with the </div><div>rest of yt-3.0 next week.</div><div><br>
</div>
<div>Be Well</div><div>Anthony</div><div><br></div><div>1. <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></div>


<div><br></div>