Bad sub-volume plots for BoxLib/Maestro spherical data

[yt-fido]

Originally reported by: Adam Jacobs (Bitbucket: adam_m_jcbs, GitHub: Unknown)

---

When I try to plot an off-axis slice of a subset of BoxLib/Maestro spherical data (yt test dataset maestro_subCh_plt00248) I find that my data gets junked if the plot includes any regions outside of the subset. My understanding is that in yt the regions outside of the sub-volume should be white and the other data should be plotted as it is when the full dataset is plotted.

This issue feels similar to a previously resolved issue dealing with off-axis slices of spherical Maestro data (#955/off-axis-slices-returning-incorrect). I've attached code that produces the error as well as images of the output.

---

• Bitbucket: https://bitbucket.org/yt_analysis/yt/issue/960

[yt-fido]

Original comment by Nathan Goldbaum (Bitbucket: ngoldbaum, GitHub: ngoldbaum):

---

We now do a slightly better job of making a somewhat sensible image, but we're not intelligently choosing the colorbar scale. I'm going to punt this to 3.4 since it's a new feature.

[yt-fido]

Original comment by Nathan Goldbaum (Bitbucket: ngoldbaum, GitHub: ngoldbaum):

---

It's definitely a bug, we should (and can pretty easily, inside the plotting code) detect when stuff like this happens and avoid producing a crappy-looking plot.

[yt-fido]

Original comment by Adam Jacobs (Bitbucket: adam_m_jcbs, GitHub: Unknown):

---

Ah, yes. This gives me reasonable results as well. I still get some runtime warnings, but the plot is what I'm looking for. I'd consider this a good workaround, though the yt devs may or may not have interest in addressing the wonky default range choosing in this case. In my experiments that bad range choices don't happen until I include a region that's outside the sub-volume, so how these regions are treated may be the culprit.

[yt-fido]

Original comment by Nathan Goldbaum (Bitbucket: ngoldbaum, GitHub: ngoldbaum):

---

For some reason we're not choosing the colorbar range intelligently in the second example. The dynamic range must be really huge, probably due to a few pixels.

If I add sliceout.set_zlim('radial_velocity', -1e7, 1e7) when creating the second plot I get a reasonable result: