Open nastasha-w opened 3 months ago
For the changing coordinate values, they are indeed being clipped here:
but I'm not sure why...
4964 should fix the error when the bbox is None.
For the changing coordinate values, they are indeed being clipped here:
but I'm not sure why...
Thanks for taking a look! That coordinate clipping seems weird, like something kind of hacky you put in to avoid other problems. Do you have any idea who might have written that?
I'd guess it was likely added to avoid a particle falling identically on the bounding box of the dataset (maybe to address some particle selection issue?). I think you're only seeing it manifest in this extreme way because you're overriding the bounding box with a value that's very different from the actual bounding box of the dataset - the bounding_box
parameter is not meant to be used as a subselection method and should always match the domain extent of the full dataset.
Ah, ok! As for the bounding box argument: I just copied it over from the arguments used in the image test. Maybe Tipsy wasn't formally run with a bounding box? I don't think you formally need to impose those in SPH, and for an isolated galaxy simulation, you wouldn't have the large-scale/low-resolution part to get the large-scale gravity right.
As for the bounding box argument: I just copied it over from the arguments used in the image test.
oh interesting! I'll go take a look at that to see if I can work out why.
Maybe Tipsy wasn't formally run with a bounding box?
Ya! I think that's right -- there's actually a comment in the TipsyDataset.__init__
that reads
# Because Tipsy outputs don't have a fixed domain boundary, one can
# specify a bounding box which effectively gives a domain_left_edge
# and domain_right_edge
but i'm still a bit confused by it. If you don't set a bounding box, it will go through and find the min/max of all the particle coordinate positions and calculate a corresponding bounding box (here). But it's really not clear to me what should happen if you specify a bounding box that is smaller than the extent of the particle spread... the current behavior is what you're seeing: the particles falling outside the specified bounding box are being clipped to the bounding box, which doesn't seem right to me but I might be missing some context.
@chrishavlin my instinct is that if the bounding box is too small, the code should just raise an error, rather than silently mangling the data. I've never worked with Tipsy data outside those tests for the SPH backend projections though, so I'd defer to someone more familiar with the dataset/simulation and typical underlying assumptions.
Ya, I agree with you -- raising an error or at least a warning would be ideal. I'll hit slack to see if anyone more familiar with Tipsy can weigh in.
@chrishavlin I checked and I don't think anyone actually responded to this on the slack channel. Do we want to go ahead with making the changes we favor, or just leave the issue open for documentation purposes in case it comes up in the future?
Bug report
Bug summary
For some reason, the Tipsy dataset (YT Hub) doesn't have the
("Gas", "smoothing_length")
or( "gas", "smoothing_length")
field available if I load it without abounding_box
argument. This is even though even though it's in the dataset'sds.field_list
. In addition, it seems like the position of at least one SPH particle depends on whatbounding_box
argument the dataset is loaded with.These issues first came up in the discussion of #4939.
Code for reproduction: missing
smoothing_length
What does work
Especially given that
('Gas', 'smoothing_length')
is listed inds.field_list
, I expecteddd[('Gas', 'smoothing_length')]
to return aunyt
array of smoothing lengths, just likedd[('Gas', 'x')]
returns aunyt
array of x-coordinates. However, if I load the same dataset with abounding_box
argument, I do seem to get results:I had to load the dataset without a bounding box first, otherwise I got a segfault like in #4961.
Code for reproduction: particle position depends on
bounding_box
Using the fact that the 'weird' particle seemed to be the one with the smallest (most negative) z-coordinate (these images):
It seems like the particle position is more specifically being 'clipped' to fall within the
bounding_box
. This particle has a large smoothing length (3645 kpc), so it should probably be included in the region selection based on these bounding boxes. However, I suspect that changing the particle's position is not intended behaviour.Version Information
yt
main
branch, 2024-08-12, 13:15 CST, commit https://github.com/nastasha-w/yt/commit/39a7563e64e8ec1e8d12ea3af2cc6da5354419d1)yt
installed withvenv
+pip
, using homebrew python.