I have a few questions in using merger trees in IllustrisTNG catalog data.
1.Why are some subhalos (galaxies) not in tree? What does it mean when a subhalo is not in any merger tree?
Warning, empty return. Subhalo  at snapNum  not in tree. ( in TNG300-1, I used sublink trees and set onlyMDB=True, i.e. tracing the main descendant )
2.Why some onlyMDB=True branches are longer or shorter than expected? From my understanding, when I extract tree for a subhalo with onlyMDB=True at a certain snapshot should have length of ( 99 - SnapNum ), however, some of them are longer than that. Here's an example:
basePath = 'sims.TNG/TNG300-1/output/'
merger_tree = il.sublink.loadTree(basePath, 57, 1039323, fields=['SnapNum','SubfindID'],onlyMDB=True)
There's another weird thing where the ['SnapNum'] list from a merger tree can skip one snapshot. Here's an example:
basePath = 'sims.TNG/TNG300-1/output/'
merger_tree = il.sublink.loadTree(basePath,57,853,fields=['SnapNum','SubfindID'],onlyMDB=True)
--> [99 98 97 95 94 93 92 91 90 89 88 87 86 85 84 82 81 80 79 78 77 76 75 74 73
72 71 70 69 68 67 66 65 64 63 62 61 59 58]
Apparently 96, 80 and 60 are missing from this list.
3.What happen when a galaxy is merged? For example, if I select a galaxy (or subhalo) at snapshot 60 and extract its merger tree using onlyMDB=True argument, then if it merges with other subhalo at later snapshots, will the merger tree end at that snapshot?
Thank you for your attention!
Some short answers:
(1) If the tree algorithm couldn't find a descendant (or progenitor), then this subhalo has no connections through time, so won't "exist" in the tree. This could happen for various complex reasons, I would typically expect for very low mass subhalos, or difficult merger scenarios.
(2) This is per the documentation: "this is the single main branch only if this subhalo lies on the MPB of its z=0 descendant, otherwise it is its full descendant sub-tree containing its z=0 descendant as the first entry."
So this big return represents the "full" tree, and somewhere in it you'll find the requested subhalo, but the situation is too complex for a simple "MDB" to make sense.
(3) Mergers are encapsulated in the "full tree" information, and I would suggest to think through the schematic diagram in the merger tree documentation (and the 'count_mergers' example). The MPBs or MDBs are, by definition, not showing this information. If you are following these main branches, then mergers will be coming in along a smaller branch, which is the combined into the main branch.
Thanks for clarifying!
I have some further questions about identifying merger events using sublink merger trees. I was tracking satellite galaxies around central galaxies through snapshots by waling along main descendant branch in their merger trees, and I want to account for those which merged into the central galaxy.
Here's how I look for merged satellite galaxies:
--First I selected satellite galaxies which have a full merger tree even with onlyMDB=True in the il.sublink.loadTree() function (based on the previous answers, this should give me satellites that did not survive from being merged into bigger galaxies).
--Then I look for IDs of those satellites in the full merger tree of central galaxies (within field=['SubfindID'])
--If I can find them, I count them as merged with the central galaxy at some point.
So my question is: Is this how I am supposed to do it ? Or, does it do things I expect it to do?
I know that numMergers() function (python) does give me number of mergers the galaxy had, but no information about individual merger event was provided. Would you suggest me modify this function to make it also return the IDs of merging galaxies?
Take a look at this different discussion thread Streamlined access to API data. There we were discussing a "simple merger tree" which gives you (i.e. for a particular central), a list of all mergers it had, along with the snapshot where they happened, and the subhalo ID of the merger. You can look at the code for ideas, or else use this functionality as is (now implemented in the API).
I am using the functions from illustris_python in Jupyter notebook right now, can I use it along with API functions?
Or maybe I can just copy and paste the function and import it?
From previous comments, if I look for onlyMDB branch in a subhalo's merger tree and get back a full merger tree, that means it's not on the main progenitor branch of its descendent at z=0, I suppose this means it merged into a bigger halo at some time. I know if I look into merger tree of its parent halo, I will find it. However, since I cannot easily identity the parent halo, can I know when a small galaxy merged into bigger one based on the merger tree I extracted using the small one's subfindID?
I tried to look into the full merger tree that is returned, I did find the ID of the specific subhalo I asked for, but apparently sometimes not at the correct snapshot, for example:
>>> basePath = './sims.TNG/TNG100-1/output'
>>> tree = il.sublink.loadTree(basePath, 72, 34259, fields=['SnapNum','SubfindID'],onlyMDB=True)
>>> ind_in_tree = np.where(tree['SubfindID']==34259)
 -->(supposed to be 72)
Yes you're exactly right about the onlyMDB. Thus I would do as you say, in this case just look through the entire "full" tree to find your particular subhalo, then look at the Descendant link.
A few questions:
For tracking satellites through snapshots, how do I parse the full merger tree exactly for galaxies that merged at sometime where onlyMDB does not work? When I call illustris_python.loadTree(), I get a long list for each parameter (e.g. SubhaloMass, SubfinID,SnapNum, etc.), how would I get the tree structure from there? For example, I wanted to look at when and where a smaller galaxy is considered merged into another bigger galaxy, how would I do that?
I tried to walk down the tree toward descendants from the small galaxy selected at a certain snapshot: First I extracted the full merger tree using loadTree() function and go through the list of SnapNum one by one, my guest is that if the SnapNum suddenly changes by a lot, that means it goes into another subtree and that's when the galaxy I am tracing merged. is this the descendant link you mean?
I would look at the numMergers() function, it's an example of how to use the full tree structure. In particular, you can see how the fpIndex is created, which tells you where in the list (of any parameter) to go next.
The numMergers() function show how many mergers a particular subhalo has experienced before a certain snapshot.However, I want to know when a galaxy will merge into a bigger galaxy at a later time, do I need to modify the function to make it work for the purpose?
P.S. The definition for full merger tree is the merger tree of the subhalo's z=0 descendent? If I don't specify onlymdb or onlympb argument, I get the subtree for that subhalo, is that correct?
A "full" merger tree also exists for any subhalo at a z>0 snapshot, i.e. going backwards in time from that point.
As you say, you can always go down to the z=0 descendant, and then get this "full z=0 rooted tree".
The information you're after is definitely inside, you just need to locate the original subhalo and then follow it forward in time.