BUG: Order of Cylindrical Coordinates for Athena++ Incorrect about yt HOT 6 OPEN

It might be worth checking that we're using the ds.coordinates.axis_name dict wherever we need to; that's a potential source of problems in the selection and pixelization routines. (i.e., assuming that 0 == r, 1 == theta, 2 == phi, rather than using the axis_names to map)

from yt.

Hi @forrestglines, thank you for reporting. I think this is reasonably decoupled with #4790 so feel free to open a PR with your fix at any point !

from yt.

Hi @forrestglines, thank you for reporting. I think this is reasonably decoupled with #4790 so feel free to open a PR with your fix at any point !

Thanks for the input! This issue with coordinates is the same issue I encountered developing the Parthenon backend. The two data formats (and the AthenaPK code) are extremely similar so I'd like the frontends to behave similarly. I see two options preferable options to fix both:

1. We go with Geometry.CYLINDRICAL and change axis_order for both Athena++, as I do in #4801, and for Parthenon as I originally did in #4323

2. We make both Athena++ and Parthenon use Geometry.POLAR and we fix #4790.

I'm a bit inclined to go with the first option to keep Athena++ as Geometry.CYLINDRICAL and have Parthenon match that solution. I'll still help out to debug #4790.

from yt.

It might be worth checking that we're using the ds.coordinates.axis_name dict wherever we need to; that's a potential source of problems in the selection and pixelization routines. (i.e., assuming that 0 == r, 1 == theta, 2 == phi, rather than using the axis_names to map)

Thanks @matthewturk! This is a suggestion for implementation for the selection and pixelization routines and what's likely causing issues in #4790, right? In this issue I'm having the trouble that yt by default uses r == 0, z == 1, theta == 2 for cylindrical dataset when Athena++ cylindrical datasets are r == 0, theta == 1, z == 2.

Does the fix in #4801 look congruent with yt standards/expectations? It only changes the assumptions about Athena++ cylindrical dataset but hopefully no other assumptions in the code.

from yt.

I see two options to fix both:

I don't think those options should be mutually exclusive: if using Geometry.CYLINDRICAL works for you and avoids the current bugs with Geometry.POLAR, that's a reasonable thing to do as a workaround, and we can always switch both frontends to use the more correct solution (POLAR) once known issues are addressed. What do you think ?

from yt.

I don't think those options should be mutually exclusive: if using Geometry.CYLINDRICAL works for you and avoids the current bugs with Geometry.POLAR, that's a reasonable thing to do as a workaround, and we can always switch both frontends to use the more correct solution (POLAR) once known issues are addressed. What do you think ?

I think this is the right solution, this is good enough for both frontends. When the issues with POLAR are addressed we can switch both frontends.

from yt.