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. 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? 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. 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. Be Well Anthony 1. https://bitbucket.org/MatthewTurk/yt.milestones/raw/7d64152de2e1/cylindrical...