yt-3.0 PR #6 - underlying cylindrical ray tracer
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...
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@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...
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Mon, Sep 10, 2012 at 2:18 PM, Matthew Turk <matthewturk@gmail.com> wrote:
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.
If we decide to go down the alternate subclasses route, the coordinate_handlers should have references back to the appropriate YTDataContainers. This might be the most modular solution... [snip]
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.
Well, the rays can start from wherever. It is just that initial and final segment may or may not be included in the return values. This should be easy to fix but I agree isn't a high priority for the moment.
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?
That does make sense. Another, related issue may be that perhaps the intersection code with respect to theta may only be valid for small dtheta. This is something else to look into... [snip]
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.
I would prefer if you lead that discussion as you know the code base much better than I do ;). Thanks! Be Well Anthony
-Matt
Be Well Anthony
1.
https://bitbucket.org/MatthewTurk/yt.milestones/raw/7d64152de2e1/cylindrical...
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hello Matt, et al. So maybe this was silly of me, but I decided to try to pursue integrating the cylindrical coordinates with YTRayBase rather than with YTOrthoRayBase, not realizing that the implementation wasn't fully there in yt-3.0. So I have updated PR #6 to include these changes as well as a notably absent RaySelector class in geometry/selection_routines.pyx. When I do this, however, the _get_data_from_grid() method on YTRayBase never gets called. This results in tracebacks and missing data when I try to do even simple things like: ray = pf.h.ray(E, F) t = ray['t'] will throw: Traceback (most recent call last): File "cylindrical_rays3.py", line 70, in <module> t = ray['t'] 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__ self.get_data(key) 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 fields = self._determine_fields(fields) 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 finfo = self._get_field_info("unknown", fname) 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 raise YTFieldNotFound((fname, ftype), self.pf) yt.utilities.exceptions.YTFieldNotFound: Could not find field '('t', 'unknown')' in nif2013_hdf5_plt_cnt_0006. Any ideas? Thanks in advance. Be Well Anthony On Tue, Sep 11, 2012 at 1:07 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
On Mon, Sep 10, 2012 at 2:18 PM, Matthew Turk <matthewturk@gmail.com>wrote:
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.
If we decide to go down the alternate subclasses route, the coordinate_handlers should have references back to the appropriate YTDataContainers. This might be the most modular solution...
[snip]
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.
Well, the rays can start from wherever. It is just that initial and final segment may or may not be included in the return values. This should be easy to fix but I agree isn't a high priority for the moment.
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?
That does make sense. Another, related issue may be that perhaps the intersection code with respect to theta may only be valid for small dtheta. This is something else to look into...
[snip]
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.
I would prefer if you lead that discussion as you know the code base much better than I do ;). Thanks!
Be Well Anthony
-Matt
Be Well Anthony
1.
https://bitbucket.org/MatthewTurk/yt.milestones/raw/7d64152de2e1/cylindrical...
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Anthony, Sorry about the delay in replying. I'm trying to collect my thoughts, and it's also been a bit of a busy week. On Wed, Sep 12, 2012 at 4:34 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
Hello Matt, et al.
So maybe this was silly of me, but I decided to try to pursue integrating the cylindrical coordinates with YTRayBase rather than with YTOrthoRayBase, not realizing that the implementation wasn't fully there in yt-3.0. So I have updated PR #6 to include these changes as well as a notably absent RaySelector class in geometry/selection_routines.pyx.
Awesome, thanks! I will provide comments over on the PR as soon as I am able. In the past we've actually traversed grids directly, so we'll want to make sure that we have both grid and cell selection routines that work.
When I do this, however, the _get_data_from_grid() method on YTRayBase never gets called. This results in tracebacks and missing data when I try to do even simple things like:
ray = pf.h.ray(E, F) t = ray['t']
will throw:
Traceback (most recent call last): File "cylindrical_rays3.py", line 70, in <module> t = ray['t'] 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__ self.get_data(key) 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 fields = self._determine_fields(fields) 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 finfo = self._get_field_info("unknown", fname) 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 raise YTFieldNotFound((fname, ftype), self.pf) yt.utilities.exceptions.YTFieldNotFound: Could not find field '('t', 'unknown')' in nif2013_hdf5_plt_cnt_0006.
Any ideas? Thanks in advance.
Yup, this is one of the data-specific fields, or "container fields". _get_data_from_grid is now deprecated in 3.0, as it will all be handled by selectors. (And I think you're now officially the person who's done the most with 3.0 besides me! :) The way to do this is to do a container field, like what is done for the slices in _generate_container_field, although I want to move away from that for slices eventually. What you can do is get self._current_chunk.fcoords and then use the values returned to get a parametric distance from the starting point. -Matt
Be Well Anthony
On Tue, Sep 11, 2012 at 1:07 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
On Mon, Sep 10, 2012 at 2:18 PM, Matthew Turk <matthewturk@gmail.com> wrote:
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.
If we decide to go down the alternate subclasses route, the coordinate_handlers should have references back to the appropriate YTDataContainers. This might be the most modular solution...
[snip]
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.
Well, the rays can start from wherever. It is just that initial and final segment may or may not be included in the return values. This should be easy to fix but I agree isn't a high priority for the moment.
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?
That does make sense. Another, related issue may be that perhaps the intersection code with respect to theta may only be valid for small dtheta. This is something else to look into...
[snip]
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.
I would prefer if you lead that discussion as you know the code base much better than I do ;). Thanks!
Be Well Anthony
-Matt
Be Well Anthony
1.
https://bitbucket.org/MatthewTurk/yt.milestones/raw/7d64152de2e1/cylindrical...
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Thu, Sep 13, 2012 at 8:29 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Anthony,
Sorry about the delay in replying. I'm trying to collect my thoughts, and it's also been a bit of a busy week.
On Wed, Sep 12, 2012 at 4:34 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
Hello Matt, et al.
So maybe this was silly of me, but I decided to try to pursue integrating the cylindrical coordinates with YTRayBase rather than with YTOrthoRayBase, not realizing that the implementation wasn't fully there in yt-3.0. So I have updated PR #6 to include these changes as well as a notably absent RaySelector class in geometry/selection_routines.pyx.
Awesome, thanks! I will provide comments over on the PR as soon as I am able. In the past we've actually traversed grids directly, so we'll want to make sure that we have both grid and cell selection routines that work.
When I do this, however, the _get_data_from_grid() method on YTRayBase
never
gets called. This results in tracebacks and missing data when I try to do even simple things like:
ray = pf.h.ray(E, F) t = ray['t']
will throw:
Traceback (most recent call last): File "cylindrical_rays3.py", line 70, in <module> t = ray['t'] 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__ self.get_data(key) 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 fields = self._determine_fields(fields) 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 finfo = self._get_field_info("unknown", fname) 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 raise YTFieldNotFound((fname, ftype), self.pf) yt.utilities.exceptions.YTFieldNotFound: Could not find field '('t', 'unknown')' in nif2013_hdf5_plt_cnt_0006.
Any ideas? Thanks in advance.
Yup, this is one of the data-specific fields, or "container fields". _get_data_from_grid is now deprecated in 3.0, as it will all be handled by selectors. (And I think you're now officially the person who's done the most with 3.0 besides me! :)
haha ;) Good to know that this is deprecated though.
The way to do this is to do a container field, like what is done for the slices in _generate_container_field, although I want to move away from that for slices eventually. What you can do is get self._current_chunk.fcoords and then use the values returned to get a parametric distance from the starting point.
Ahh Ok. Well, I'll take a look at doing it that way when I get back to this in a week or so. Be Well Anthony
-Matt
Be Well Anthony
On Tue, Sep 11, 2012 at 1:07 PM, Anthony Scopatz <scopatz@gmail.com>
On Mon, Sep 10, 2012 at 2:18 PM, Matthew Turk <matthewturk@gmail.com> wrote:
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.
If we decide to go down the alternate subclasses route, the coordinate_handlers should have references back to the appropriate YTDataContainers. This might be the most modular solution...
[snip]
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.
Well, the rays can start from wherever. It is just that initial and
final
segment may or may not be included in the return values. This should be easy to fix but I agree isn't a high priority for the moment.
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?
That does make sense. Another, related issue may be that perhaps the intersection code with respect to theta may only be valid for small dtheta. This is something else to look into...
[snip]
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
wrote: 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.
I would prefer if you lead that discussion as you know the code base much better than I do ;). Thanks!
Be Well Anthony
-Matt
Be Well Anthony
1.
https://bitbucket.org/MatthewTurk/yt.milestones/raw/7d64152de2e1/cylindrical...
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (2)
-
Anthony Scopatz -
Matthew Turk