BUG: white box artefact produced in SlicePlot

[BenWibking]

Bug report

Bug summary

A white box is inexplicably plotted on top of a SlicePlot.

Code for reproduction

The dataset that reproduces this is here: https://cloudstor.aarnet.edu.au/plus/s/eWh5FxbrqaLaj09

import yt
ds = yt.load('plt99000')
p = yt.SlicePlot(ds, "z", ("boxlib", "scalar"), buff_size=(1000,1000))
p.show()

Actual outcome

Expected outcome

The data can be plotted correctly using VisIt:

Version Information

• Operating System: Rocky Linux 8.5
• Python Version: 3.10
• yt version: main (commit a1bce43)
• Other Libraries (if applicable):

Python 3.10 is system-provided.
I installed yt with: pip install git+https://github.com/yt-project/yt.git

[welcome]

Hi, and welcome to yt! Thanks for opening your first issue. We have an issue template that helps us to gather relevant information to help diagnosing and fixing the issue.

[neutrinoceros]

Hi Ben, thanks for reporting.
This is likely a selection bug, resulting in no data being plotted at this particular location, rather than a white box being over plotted.
This is reminiscent of another bug that was recently fixed but only affected particle datasets, while boxlib is grid-only, right ?
Just as a sanity check, can you confirm wether this can be reproduced with yt 4.0.2 ?

[BenWibking]

Oh that makes more sense. Boxlib/AMReX does support particles, but my dataset does not have any.

In yt==4.0.2, using the gas density instead (to avoid the vmin/vmax bug in 4.0.2), I get the same issue:

[neutrinoceros]

Excellent, thanks for checking. I wouldn't be surprised if this was due to the default slice plane (at z=0) being exactly at the interface between two blocks, resulting in none of them being selected.
Maybe you'd get the correct result by just offsetting the slice plane a bit, e.g.

center = ds.arr([7.7125e+19, 7.7125e+19, 7.7125e+19*1.01], 'code_length')
p = yt.SlicePlot(ds, "z", ("boxlib", "scalar"), center=center)

If my hunch is right, you should also not see this problem with a ProjectionPlot.
(I'd test these myself but right now my network is too weak to get the dataset)

[neutrinoceros]

I confirm that

• I can reproduce the problem

• offsetting the center hides the issue
  

• projections do not suffer from this problem

[neutrinoceros]

So we still need to confirm that we understand why this happens, but if I am correct then I'm not too hopeful that this can be fixed (see #3828)

That said, it should be possible to mitigate the problem when inside then domain (rather than on the very edge of it).

[BenWibking]

Why can't this be fixed? (For instance, VTK handles this situation correctly.) How is the rendering implemented in yt?

[neutrinoceros]

Let me rephrase that: I don't currently know how this could be fixed, because it's supposed to work already. Normally when a slice plane lands right on the edge of two blocks, the left one is selected and the right one isn't. This is where this rule is defined

yt/yt/geometry/_selection_routines/slice_selector.pxi

Lines 100 to 102 in a1bce43

	if left_edge[self.axis] - grid_eps <= self.coord < right_edge[self.axis]:
	return 1
	return 0

[BenWibking]

Just wanted to check on this. We can workaround by offsetting the slice plane, but it's an obstacle for new users.

Also: I've only noticed this happening for output files that don't include ghost cells. Not sure if that gives any clue as to what's going on.