Do all subhalos have a descendant at interim snapshots?
Jacob Morgan
12 Jan '23
I naively constructed a tree file for subhalos I am interested in, but now I think I may have problems. I made these trees by selecting subhalos I wanted at some snapshot, then doing
sub = tng.get(sub['related']['sublink_descendant'])
in a loop until reaching snapshot 99, a la the tutorial. Then I find the subfindID at snapshot 99, and request the tree from there, giving me the full tree past/future. Then I just compiled the different trees together in a dictionary, like so:
1) make dictionary of properties
2) each property is an array of subhalos, ie, I have 3500 halos, so my entries are all 3500 long
3) each entry in the array is the history of that property for that subhalo. So my_dict['SubhaloPos'][0] tells me the history of the position of the first subhalo in my list.
4) I can now easily access past properties of my chosen subhalos by finding a lookback index and just doing: subhalo0_old_pos=my_dict['SubhaloPos'][0][lookback_index]
However! here's the problem: while doing unrelated debugging, I realized that when following the descendant with sub['related']['sublink_descendant'] from my snapshot up to snapshot 99, snapshot 85 is skipped! The next descendant after 84 is in snapshot 86.
Does this throw a wrench in my plans for easily indexing like a describe above? Basically, if snapshot 85 is missing, then my lookback_index value changes (ie, lookback_index=15 should show me data from snapshot 84, but if 85 is missing then that index is really showing me data from snapshot 83).
I guess what I need to know is: 1) If there's not a descendant at snapshot 85 for some subhalo, does that mean the merger tree holds no values at snapshot 85? 2) When looking at the tree for some subhalo, how do I know which values line up with which snapshots if some of them do not have descendants at interim snapshots?
Thank you for your time!
Dylan Nelson
14 Jan '23
Hi Jacob,
Yes the merger trees can "skip" a snapshot, this is important - the actual subhalo of relevance may not exist for a brief moment of time, e.g. during pericenter passage of a merger event. But we would like to be able to trace it through this time, so the trees search across snapshot gaps.
Then, in general, the properties of the tree will skip a snapshot. This is why it is important to always use the SnapNum field, i.e. not to assume what snapshots each entry of a tree correspond to, but to actually use the snapshot numbers in the tree. These can have missing values.
A common post-processing step, which you could do, would be to search for any gaps, and interpolate your values of interest across those gaps, such that you have always complete trees of equal size, to make further analysis simpler.
Ah, I was afraid of that. I like the idea of interpolating, but as you mentioned snapshots may be skipped during a merger-- since you've helped me out on other comments (thanks by the way!) you may recall, I'm looking for mergers along the main progenitor branch. I do this basically by looking for large changes in mass.
What do you think about the possibility of a merger that causes this skipping, but when the subhalos are found again after the masses are similar?
Also, is there a way to use the built-in merger finding function, but only look back to a specific snapshot?
Dylan Nelson
15 Jan '23
If a tree has a skipped snapshot, and the subhalo before and after has similar mass, then it is not a merger, but perhaps a fly-by and/or near passage.
The idea was that the numMergers() function can be adapted as you like, e.g. back to a certain snapshot or redshift would be possible.
I naively constructed a tree file for subhalos I am interested in, but now I think I may have problems. I made these trees by selecting subhalos I wanted at some snapshot, then doing
in a loop until reaching snapshot 99, a la the tutorial. Then I find the subfindID at snapshot 99, and request the tree from there, giving me the full tree past/future. Then I just compiled the different trees together in a dictionary, like so:
1) make dictionary of properties
2) each property is an array of subhalos, ie, I have 3500 halos, so my entries are all 3500 long
3) each entry in the array is the history of that property for that subhalo. So my_dict['SubhaloPos'][0] tells me the history of the position of the first subhalo in my list.
4) I can now easily access past properties of my chosen subhalos by finding a lookback index and just doing: subhalo0_old_pos=my_dict['SubhaloPos'][0][lookback_index]
However! here's the problem: while doing unrelated debugging, I realized that when following the descendant with sub['related']['sublink_descendant'] from my snapshot up to snapshot 99, snapshot 85 is skipped! The next descendant after 84 is in snapshot 86.
Does this throw a wrench in my plans for easily indexing like a describe above? Basically, if snapshot 85 is missing, then my lookback_index value changes (ie, lookback_index=15 should show me data from snapshot 84, but if 85 is missing then that index is really showing me data from snapshot 83).
I guess what I need to know is: 1) If there's not a descendant at snapshot 85 for some subhalo, does that mean the merger tree holds no values at snapshot 85? 2) When looking at the tree for some subhalo, how do I know which values line up with which snapshots if some of them do not have descendants at interim snapshots?
Thank you for your time!
Hi Jacob,
Yes the merger trees can "skip" a snapshot, this is important - the actual subhalo of relevance may not exist for a brief moment of time, e.g. during pericenter passage of a merger event. But we would like to be able to trace it through this time, so the trees search across snapshot gaps.
Then, in general, the properties of the tree will skip a snapshot. This is why it is important to always use the
SnapNumfield, i.e. not to assume what snapshots each entry of a tree correspond to, but to actually use the snapshot numbers in the tree. These can have missing values.A common post-processing step, which you could do, would be to search for any gaps, and interpolate your values of interest across those gaps, such that you have always complete trees of equal size, to make further analysis simpler.
Ah, I was afraid of that. I like the idea of interpolating, but as you mentioned snapshots may be skipped during a merger-- since you've helped me out on other comments (thanks by the way!) you may recall, I'm looking for mergers along the main progenitor branch. I do this basically by looking for large changes in mass.
What do you think about the possibility of a merger that causes this skipping, but when the subhalos are found again after the masses are similar?
Also, is there a way to use the built-in merger finding function, but only look back to a specific snapshot?
If a tree has a skipped snapshot, and the subhalo before and after has similar mass, then it is not a merger, but perhaps a fly-by and/or near passage.
The idea was that the numMergers() function can be adapted as you like, e.g. back to a certain snapshot or redshift would be possible.
Got it, thanks again!