yt
yt copied to clipboard
BUG: white box artefact produced in SlicePlot
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 a1bce43eeb6ad6d3dfe15db0acf2971c2053a93a)
- Other Libraries (if applicable):
Python 3.10 is system-provided.
I installed yt with: pip install git+https://github.com/yt-project/yt.git
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.
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 ?
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:
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)
I confirm that
-
I can reproduce the problem
-
offsetting the center hides the issue
-
projections do not suffer from this problem
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 https://github.com/yt-project/yt/issues/3828)
That said, it should be possible to mitigate the problem when inside then domain (rather than on the very edge of it).
Why can't this be fixed? (For instance, VTK handles this situation correctly.) How is the rendering implemented in yt?
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
https://github.com/yt-project/yt/blob/a1bce43eeb6ad6d3dfe15db0acf2971c2053a93a/yt/geometry/_selection_routines/slice_selector.pxi#L100-L102
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.