Public Data Access Overview / Discussion Forum

Hello TNG team,

I've been trying to plot the evolution of some galaxies at snapshot 20 by finding their z=0 subfind IDs through their MDBs, then using those current IDs to look backwards with the MPB (code below). However, the MPBs are not returning the same information (ex. SFR) and IDs as I originally located (i != IDs from MPB at snap 20), and I'm not sure why. Maybe it has to do with the length of those MDB Snap Num arrays?
Clarification on anything I'm overlooking would be much appreciated!

Thanks so much!
Abby

Edit: This method worked properly for the fourth galaxy in the set, which added to my confusion

Just to clarify, you select a subhalo at some redshift z>0, and follow its MDB to z=0. Then, you load the MPB of this subhalo, and according to this, the progenitor of the z=0 subhalo differs from the originally selected object?

I would say this is OK. Imagine a binary merger at z=1. Both of the subhalos which are merging will have the same MDB, as they combine to form the same z=0 object. However, the MPB of the z=0 subhalo must choose between these two (if you are using SubLink, it will choose the branch with the most massive history).

Exactly! That makes sense - I’ll include an image of the merger tree using now_id (z=0 ID) for one of the galaxies below. Clearly the quenched galaxies around z=4 didn’t have the most massive histories. Thank you for clearing that up!

Since I want to study the characteristics and evolution of these quenched galaxies, would you suggest plotting (ex. radius, SFR) with their MDBs alone? And would inputting their originally located (snapshot 20) subfind IDs into the snapshot catalogue return the accurate information for snapshot 20?

Thank you so much!
Abby

Yes you can select subhalos at snapshot 20, and use all information about them from the catalog there.

You can then follow their Descendants (e.g. MDB) to see how they would evolve towards z=0. An important part of the analysis would be, if you plot e.g. M*(t), to disentangle when the stellar mass is changing just because the galaxy is secularly evolving, and when it is changing because there was a merger.

Just keep in mind, a subhalo has a unique descendant, but it can have one or more progenitors.

Sounds good! Do you have any tips on how to differentiate between organic stellar mass growth and growth via mergers?

Thank you!!
Abby

This is usually called in-situ vs ex-situ, and is usually analyzed in the other direction (starting at z=0). For instance, in Rodriguez-Gomez+16. This is a per-star particle based analysis, but more generally, for any galaxy property, you can take a subhalo at a given redshift and consider all its progenitors. What comes from the most massive could be considered the direct evolution, while whatever comes from the other progenitors would be a merger contribution.

That makes sense - thank you for your help!

Hello again! I've made plots of mass and SFR vs time by combining data from the MDB and MPB of each galaxy in the sample set (instead of tracking the IDs to z=0 and looking backwards like before). However, this data doesn't seem to line up properly, and it looks like an issue with the MDB.

The MDBs for most of the galaxies are returning huge arrays with way too many snap numbers, so maybe these MDBs correspond to entire trees instead? Even truncating those arrays to the first 79 values results in the inconsistent graphs below, though. Once again, the fourth galaxy in the sample is the only one with the correct number of snapshots between z=4.18 and z=0 in its MDB (maybe because it's the largest progenitor of its z=0 descendant galaxy? I'm not sure.).

I've also been wondering if the size of the galaxy circles on the merger trees generated by TNG correspond to galaxy stellar mass. If so, is there a reason why so many rows of galaxies in those merger tree branches shrink in size (like in the tree image above in this thread)?

Thanks so much!
Abby

(1) The default "MDB" return is documented as

"retrieve only SubLink [main] descendant branch(es) (towards lower redshift for this subhalo) (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)".

I think this explains the different between small vs huge returns. You could parse the large returns into a single descendant per snapshot (i.e. what isn't done by default), but this won't just be the first N entries.

(2) The shrinking mass as a subhalo goes forward in time is a classic signature of an infalling satellite, pre-merger. As a satellite accretes it will be stripped, both due to physical (tidal) and non-physical (limitations of Subfind) reasons.

I see what you mean - thank you for the clarification! I didn't realize how drastic the effects of stripping were!

In order to parse those huge trees into one descendant per snapshot, should I just locate the most massive descendant at each snapshot within those MDB returns? That would probably make the graphs above line up how they're meant to, but I want to make sure that that method would produce accurate shortened MDBs for the galaxies that don't lie on the MPB of their z=0 descendants.

I truly appreciate your feedback and assistance here - I'm really enjoying TNG (but clearly have much to learn)!

Thanks!
Abby

A subhalo has only one descendant, so as long as you don't need to run this code too many times (i.e. make it fast), you should be able to:

(i) start at the subhalo of interest
(ii) look at DescendantID
(iii) find the SubhaloID which matches
(iv) record the SubfindID and SnapNum of that subhalo
(v) loop

If you write a little python script to do this, from a loaded "full MDB" or even a "full tree", you could post it here, I'm sure it would interest others.

Hello again, and thank you so much for your help! I've written a little Python script (below) mirroring the steps above, but I'm still a bit confused on step (ii); the DescendantID array is just as long as the SubhaloID one. In this case, indexing the SubhaloID array using the descendant IDs will still return an array much too large to be a "true MDB". Any clarifications on my misunderstanding of the role of DescendantID would be much appreciated!

You want to follow, one at a time, entries in these arrays. By following a sequence of DescendantID's, you will traverse (and so record) only a subset. Perhaps it is more clear to say "look at DescendantID[i].