Possible mismatch between longitude values/indices between Meridional_Slices, GridInfo, and Equatorial_Slices/Shell_Slices

[illorenzo7]

Some background: I am making some routines to plot 3D cutouts from the different "Slices" data and finally am seeing how Meridional_Slices, Equatorial_Slices, and Shell_Slices connect. Sorry @feathern if I am reinventing the wheel!

I think there is a problem with the range in which longitude is measured (either (0, 2pi) or (-pi, pi)) and different classes assume different ranges.

Anyway it seems the current situation is this:

GridInfo says "phi" = [0, .... 2pi) (ascending order)
Meridional_Slices say "phi" =(2pi, .... 0] (descending order) and "phi_inds" is ALSO in descending order

Meridional_Slices is thus consistent with GridInfo, but it would imply that the actual phi array is indexed in ASCENDING order, which is opposite to radius and theta. That's fine, but it should maybe be mentioned somewhere (or maybe I missed it). It's convenient, because then phi is positive left to right (x axis) and theta is positive south to north (y axis).

Then there are Shell_Slices/Equatorial_Slices. They seem to be consistent with each other (i.e. flows at the same phi index are continuous), but not with the Meridional_Slices. I.e., a Meridional_Slice at phi_ind = 185, will not be continuous with an Equatorial_Slice at index 185 in the phi part of the array.

I think what happened is that Shell_Slices/Equatorial_Slices implicitly assume the phi array that describes the slice is in the order
[-pi ,.... , pi)

If you assume that, then all the flows seem continuous, at least in my spherical cutout projections!

Obviously, the zero-point of longitude is arbitrary, but it should be the same for all data outputs.

Note that the Equatorial_Slices class has a phi attribute, in the range 0 to 2pi and this seems wrong.

To make everything consistent (and to definitely not change anything about how the code outputs or how the user inputs anything), what I'd propose is to edit the Equatorial_Slices and Shell_Slices classes to roll all the arrays in the phi direction by nphi/2. And add a "phi" attribute (in the range 0 to 2pi, same as the other classes) to the Shell_Slices class, which it currently lacks. This would bring everything into consistency with Meridional_Slices. Meridional_Slices and Point_Probes (I think) are the only place where the user can choose specific longitudes to output. I haven't worked at all with Point_Probes, but I assume they are consistent with Meridional_Slices. Anyway, I think this fix would effectively make the Meridional_Slices set the zero-point of longitude for everyone.

Probably more confusing than it needed to be! Lmk if I am just going crazy, since that's possible too :)

[feathern]

Hi @illorenzo7 ,

I dug into this a bit this morning, but I don't see any problems at first pass. Have a look at the attached images where I compared Equatorial_Slices, Meridional_Slices, Shell_Slices, and Point_Probes against each other. Everything seems to be in agreement, and when I print the phi values of everything but Shell_Slices (which doesn't have that attribute for some reason), they are in agreement. Here's a Google drive link to the data and python code that I used to make those plots.

https://drive.google.com/drive/folders/11HlUn1MEUdyXnyCOXK-Yc7ktpmrs93b9?usp=sharing

One thing that comes to mind is that I used meridional_indices and point_probe_phi in my outputs. I DID NOT use meridional_indices_nrm and point_probe_phi_nrm. If you are using the normalized coordinates, then I suggest:

1. Try my notebook to make sure you still see a problem.
2. If you do still see a problem, run with explicit indices like I did, and see if the problem persists.
3. If the problem goes away, then we know its an issue with how the normalized phi coordinates are being handled, and we can go from there.

From what I am seeing now, we definitely don't want to roll the arrays by nphi/2. I suspect if there's a bug, it's something more subtle.

-Nick

[feathern]

Note also that I didn't use the grid_info file at all. That may also be a source of inconsistency, but if so, then we need to revise the grid_info file. As far as I can tell, the grids and data stored in the output files are consistent. I just uploaded grid_info as well, in case you want to look at that.

[illorenzo7]

@feathern Sorry! This was a false alarm on my part. I was "rolling" arrays for a specific projection routine I was writing and got confused (to plot, it helps to have everything in the range (-pi, pi) and I subtracted one factor of pi inconsistently.) Anyway, the details don't matter: I checked all this (using my output, which specified meridional_indices_nrm) and all the data I output was consistent amongst equatorial, meridional, and shell slices.

Also, I believe everything is consistent with the grid_info file. Which for the record, means that the outputs treat the phi array as ranging from 0 to 2pi (times (n_phi - 1)/n_phi), in INCREASING order of the index. Maybe we should note that somewhere in the documentation, since it's a different convention than the other arrays.

But anyway, all this was a late-night false alarm on my part! Feel free to close.