Tipsy Frontend BUG?: oddities with smoothing lengths/positions and bounding box #4963
Comments
neutrinoceros
added
bug
api-consistency
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 |
|
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. |
oh interesting! I'll go take a look at that to see if I can work out why. |
Ya! I think that's right -- there's actually a comment in the 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. |
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_boxargument. 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 what
bounding_boxargument the dataset is loaded with.These issues first came up in the discussion of #4939.
Code for reproduction: missing
smoothing_lengthWhat does work
Especially given that
('Gas', 'smoothing_length')is listed inds.field_list, I expecteddd[('Gas', 'smoothing_length')]to return aunytarray of smoothing lengths, just likedd[('Gas', 'x')]returns aunytarray of x-coordinates.However, if I load the same dataset with a
bounding_boxargument, 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_boxUsing 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
ytmainbranch, 2024-08-12, 13:15 CST, commit nastasha-w@39a7563)ytinstalled withvenv+pip, using homebrew python.The text was updated successfully, but these errors were encountered: