Question: expected behavior of center argument in slices of spherical datasets? about yt HOT 3 OPEN

Thanks for the detailed thoughts, @neutrinoceros ! And searching back through issues and PRs, I see now that there's been a lot of related discussion and attempts circling around this problem (should have searched a bit more before posting my question...). In any case, it does seem like a bigger refactor is needed... I do have more thoughts on this, will try to come back later today or tomorrow to type them up!

from yt.

Related to #4362

This has been a problem for as long as spherical coordinates have been supported. To me, the issue is primarily that the API, which was originally designed for cartesian coordinates only, is ill suited for non-cartesian geometries; in particular, specifying a {center, width} combo is ambiguous in spherical geometries: does it result in a spherical selection (possibly off-center), or does it really just select a slab in the data cube¹ ? what coordinates is center in ? native, or cartesian² ? is the width akin to a radius, a diameter, an azimuth, a latitude ? Combined with the fact that angular coordinates are, under the hood, represented as length dimensions, none of these questions have obvious answers to me.
So far, my approach has been very conservative, but I think we can't really beat this problem without a broader redesign of non-cartesian coordinates.

I think we'd need a couple fundamental changes:

• stop representing all coordinates as lengths. This means in particular that coord triplets returned by, e.g., ds.find_max, need to be tuples of scalar unyt_quantity³ instead of a single unyt_quantity (which cannot have more than 1 dimensionality)
• NormalPlot API:
  • elect a coordinate system (Cartesian or data-native) that the center. I don't think it matters much what we choose to support as long as it's explicit. I do have a slight preference for choosing data-native because it's a bit easier to convert to cartesian than the other way around, which might avoid some foot guns to users.
  • forbid passing a scalar width for non-cartesian geometries³: only triplets should be accepted (or pairs in 2D)
  • clarify, in docs, that center + width always selects a slab in data-native coordinates

from yt.

I wanted to mention two things -- the first is that I think we could absolutely explore a new method of designing these slices and whatnot.

The second is that we should explore how we could revive the "IndexArray" type that @jzuhone worked on a few years ago in unyt. This would be a big change, and we may decide it's too much. But the idea there is twofold -- one is to make all of the arrays used for indexing read-only -- which could be a huge performance increase in some areas of the code that constantly do conversions or checks that arrays are in code-length. But the other part is to make some types of arrays non-broadcastable along all dimensions, and allow for non-homogeneous units. (Making this a general purpose solution in unyt would likely be a lot harder than making it work in yt, to be clear. So it's also possible that we could implement it in yt for that one specific use case.)

from yt.