SWIFTSIM / HBTplus

HBTplus halo finder adapted for the FLAMINGO and COLIBRE simulations
0 stars 0 forks source link

Support particle splitting in SWIFT #44

Open robjmcgibbon opened 6 days ago

robjmcgibbon commented 6 days ago

Currently if a gas particle in a satellite is split then the particle with the new ID will not be assigned to the satellite as it will not be part of the subhalo source ID list. It will usually end up being assigned to the central subhalo since it is likely to be part of the FOF group. For FLAMINGO the particle information was not saved in the snapshots anyway, but we would like to have support for this for COLIBRE. For reference the particle splitting information we have from SWIFT is described at https://swift.strw.leidenuniv.nl/docs/Snapshots/index.html#particle-splitting-metadata

Victor and I have had a chat about how to do this. We came up with two options.

Option 1 - Preprocess the snapshots: We would write a script that takes in pairs of snapshots. The script would group particles based on their progenitor ID and current split tree. It would return a hashmap that records what every particle split into. For example if particle 0 at snapshot n-1 split into particles (0, 3, 4) at snapshot n, then the script would return the following hashmap {0: 3, 3:4}. We would then load this hashmap for each snapshot in HBT to determine if particle splitting has occurred.

Option 2 - Build trees within HBT: We can't think of a way to determine the particle splitting based on the information in a single snapshot. For example if particle 0 at snapshot n-1 splits into particles (0, 3, 4), but then particle 0 is destroyed before snapshot n, we have no way to determine that particles 3&4 should be associated with the satellite which particle 0 was part of. Therefore we would need to store the full particle splitting trees within HBT as we advance through the snapshots. We would need to save these trees to the restart files too. We could then traverse the trees to determine what splits each gas particle has undergone.

Victor and my preference would be for option 1, since we think it would be quicker to implement. It is probably not as clean as option 2, but has the advantage that it should be easier to adjust if we ever want to support particle splitting for other cosmological codes. For option 2 we would need to traverse the splitting tree for every gas particle at every snapshot, so we might need to build a hashmap in that case anyway.

jchelly commented 6 days ago

I've just been taking a look at the swift docs you linked to try to catch up. If I'm reading it correctly, I think that if a particle with a particular (ProgenitorId, SplitTrees, SplitCount) value exists in snapshot i, then any descendants of that particle in snapshot i+1 can be identified by checking for particles which have the same ProgenitorID, have an equal or greater SplitCount, and have the same the N least significant bits of their SplitTrees as the original particle (where N is the original particle's SplitCount in snapshot i). Particles where those least significant bits don't agree would be tree branches that split off before the earlier snapshot so they're not descendants.

I agree that this would be tricky to deal with in HBT, and it does seem like a good idea to figure out how do it in post processing first even if we want to make HBT do it later.

jchelly commented 6 days ago

Maybe a compact way to represent the splitting information would be to have a (current ID, progenitor ID) pair for each particle in the later snapshot which was created by splitting since the previous snapshot.