BUG: phi-slices in spherical geometries are glitchy

[neutrinoceros]

In this example, results are correct (or at least expected) with normal = "r" and normal = "theta", but the poloidal slice (normal = "phi") is full of glitches

import yt
import yt_idefix

ds = yt.load("tests/data/pluto_disk_planet/data.0010.vtk")
for normal in ("r", "theta", "phi"):
    p = yt.SlicePlot(ds, normal, "density")
    p.save("/tmp/", mpl_kwargs=dict(bbox_inches="tight"))

I note that this is currently our only spherical vtk dataset. A similar script using a spherical dataset with Idefix's dump format yields expected results

I think it's possibly a bug in yt itself, but I've never seen it with any other frontend so I'll inspect a bit further before I report upstream.

[neutrinoceros]

this may be a bug in the pixelizer that appears only at low resolutions (here we only have 16 cells in the latitudinal direction)

[xshaokun]

I note that this is currently our only spherical vtk dataset.

Just remind, there's another spherical vtk dataset for idefix tests/data/FargoMHDSpherical/data.0010.vtk", and it seems normal with 64 cells in the latitudinal direction

Therefore, I increased the resolution of theta direction to 64 cells for pluto_disk_planet, but it's glitchy too. It seems that low resolution is not the main reason.

[neutrinoceros]

Great ! Then that is almost certainly an actual frontend bug.

[neutrinoceros]

Okay this is almost definitely a bug in yt itself.

Running with yt 4.0.1 and yt_idefix 0.10

import yt
import yt_idefix

ds = yt_idefix.load("tests/data/pluto_disk_planet/data.0010.vtk")
p = yt.SlicePlot(ds, "phi", "density")
p.save("/tmp/", mpl_kwargs=dict(bbox_inches="tight"))

I get

so there are a number of issues in this image that are fixed in yt 4.0.2 but the pixelizer is apparently broken now. This is almost certainly on me since I wrote most of the patches for yt 4.0.2

I'll check to see if this image is reproducible with yt-4.0.1 and a modified version of yt_idefix 11.0 that accept yt 4.0.1

[neutrinoceros]

indeed, can reproduce this exact image using the old yt_idefix.load function, so this is def' a regression in yt 4.0.2 :(
I'll update yt_idefix to allow yt 4.0.1 again, and I'll try to fix this in yt itself later (it's a bit complicated to patch this up right now before the release is officially announced)

[neutrinoceros]

Still scratching my head over this before I report it upstream but I haven't found any other dataset where this bug shows up. A potentially key difference here is that the simulation box has a minimal latitude of precisely 0.

[neutrinoceros]

Fixed upstream with yt-project/yt#3782