Repository navigation
Full descendant info - #240
Open
robjmcgibbon wants to merge 4 commits into
Open
robjmcgibbon wants to merge 4 commits into
robjmcgibbon wants to merge 4 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
SOAP currently only stores the HBT DescendantTrackId, which is useless. It's only set once a subhalo has disrupted, but by then the subhalo isn't included in the SOAP catalogue.
This PR redefines
SOAP/DescendantIndexto points to the descendant in the next SOAP catalogue even if the subhalo disrupted/merged.SOAP/DescendantTypewill tell you the fate of the subhalo.These will be computed automatically for any new SOAP catalogues. I have added a scrip to recompute them for existing catalogues, so we can patch COLIBRE.
While implementing this I found a bug. SOAP catalogues are spatially sorted, so we have to determine the cell each subhalo lives in. In one place this was done in units of
snap_length, and in another inswift_cmpc, which differ very slightly. This can lead to a subhalo being assigned to a different cell, so its progenitor/descendant index then points to the wrong subhalo. This affects 2 subhalos (across all snapshots) in L25m5, so it probably happens more often in the larger catalogues. It will be fixed when we recompute the indices using the new script.