-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for partilcle bounding boxes in the snapshot meta-data #121
Comments
Just to be clear, the proposed numbers give, within each top level cell, the minimum and maximum positions of any particles? So:
If there are particles at the positions of the dots, and the xs, this would return the positions of the two particles marked with an x? |
It does not have to be the same particle that maximises x and y but otherwise, yes. It gives you the two corners of a parallelogram encopassing all the particles in the cell. The main goal is really to cover for the particles who have drifted out of the cell. |
Ok, sounds good. I think this makes sense to do, and using this data could be able to be implemented in I'm not sure we have much use for it, right now, though. I guess right now we're missing a handful of particles when we read spatially, and we could fix that, but that's not a really high priority thing (at least as far as I am aware). |
Well the point is that if you want to extract a halo in cell A, at the moment you don't know whether the particles in cell B next to it need to also be read. Now you can check that and decide not to read B. |
yeah, i guess at the moment when we do the overlap we assume that the bounding box is just the cell. how bad is this? |
Don't we also get the neighbouring cells to be safe since we don't know how much things could have drifted? |
No, we don't. But we probably should. John's new SO tool does this to make sure all particles are found, and when I did some early tests for this, I found a non-negligible fraction of particles that had drifted outside their top level cell. |
Ok. I have mixed the two. Then indeed, we should be more conservative in swiftsimio unless the bounding box data is found in the snapshot. |
To use this, we would need to know which top level cells are neighbours. That information is not available right now, is it? |
We know the centre and the size of each TLC as part of the meta-data. So it can be worked out. Or more info added on the SWIFT side if useful. |
For completeness, before the discussion gets lost: the cells are sorted in C ordering. So we can easily know who the neighbouring cells are. |
This SWIFT PR https://gitlab.cosma.dur.ac.uk/swift/swiftsim/-/merge_requests/1525 introduces particle bounding boxes in each top-level cell's meta-data. This can be useful to speed-up the reading of data if one know that it is unnecessary to read neighbouring cells.
Is the format proposed in the SWIFT PR sensible? Can swiftsimio exploit it or should I add something else to ease this?
The text was updated successfully, but these errors were encountered: