I am working on some analysis utilising TNG-50 data from prior studies. I have TNG-50 data at various redshifts (z= 1.0, 0.7, 0.5, 0.2 and 0.0) that characterise galaxies (subhaloes) on galaxy types (disc, barred, barred with boxy/peanut central bulge). I am investigating the evolution of these galaxies across redshift so I am interested in the merger tree history to connect the galaxies thereby allowing investigation of how other variables may influence the galaxy type. My initial analysis has developed the merger tree links using the descendent (and progenitor) data i.e. desc_sfid/desc_snap (and prog_sfid/prog_snap).
I have used the API tool to generate this information. This has allowed the connection of the subhalo IDs at e.g. snapshot 84 (z=0.2) and 99 (z=0) ..... I have completed the analysis across the full redshift range. I recognise that this may be an oversimplification of the merger tree analysis but I am a distance learning student (at UCLAN) and do not have access to the large computing power that may be required to download some of the larger merger tree information. To give a feel for the size of my analysis the data I have is ~600 disc galaxies at each redshift (z = 1.0, 0.7, 0.5, 0.2, 0.0) with subsets for the barred, boxy/peanut categories.
Before continuing with the work I want to test how 'realistic' the merger tree might be is using just the desc_sfid data trails. The actual merger tree is likely more complex than the one I have developed. Is there any way someone could provide guidance as to whether this is a reasonable approach or should I tackle the analysis from a different angle .... if so, what approach might that be ? Many thanks.
Dylan Nelson
18 Dec '24
These links in the API are for the main progenitor. If you are interested in tracking a galaxy through time, this is what one would typically use, so this is perfect.
What are you are missing are the "other" progenitors, i.e. all the galaxies that merge into this galaxy. If you wanted to analyze merger events in particular, you may need to use the full trees. (Note that you can download the "full tree" of a specific subhalo using the API, you don't have to download the entire merger tree set of the whole simulation).
The descendant link is the same as you find in the full trees. Each subhalo has exactly one descendant, so there is no ambiguity.
John Blowers
18 Dec '24
Thanks Dylan. I assume the Sublink tree is the one I should use for my purposes (versus LHaloTree) ?
Dylan Nelson
18 Dec '24
For the majority of cases they will give the same results, but yes we are typically using SubLink more commonly.
I am working on some analysis utilising TNG-50 data from prior studies. I have TNG-50 data at various redshifts (z= 1.0, 0.7, 0.5, 0.2 and 0.0) that characterise galaxies (subhaloes) on galaxy types (disc, barred, barred with boxy/peanut central bulge). I am investigating the evolution of these galaxies across redshift so I am interested in the merger tree history to connect the galaxies thereby allowing investigation of how other variables may influence the galaxy type. My initial analysis has developed the merger tree links using the descendent (and progenitor) data i.e. desc_sfid/desc_snap (and prog_sfid/prog_snap).
I have used the API tool to generate this information. This has allowed the connection of the subhalo IDs at e.g. snapshot 84 (z=0.2) and 99 (z=0) ..... I have completed the analysis across the full redshift range. I recognise that this may be an oversimplification of the merger tree analysis but I am a distance learning student (at UCLAN) and do not have access to the large computing power that may be required to download some of the larger merger tree information. To give a feel for the size of my analysis the data I have is ~600 disc galaxies at each redshift (z = 1.0, 0.7, 0.5, 0.2, 0.0) with subsets for the barred, boxy/peanut categories.
Before continuing with the work I want to test how 'realistic' the merger tree might be is using just the desc_sfid data trails. The actual merger tree is likely more complex than the one I have developed. Is there any way someone could provide guidance as to whether this is a reasonable approach or should I tackle the analysis from a different angle .... if so, what approach might that be ? Many thanks.
These links in the API are for the main progenitor. If you are interested in tracking a galaxy through time, this is what one would typically use, so this is perfect.
What are you are missing are the "other" progenitors, i.e. all the galaxies that merge into this galaxy. If you wanted to analyze merger events in particular, you may need to use the full trees. (Note that you can download the "full tree" of a specific subhalo using the API, you don't have to download the entire merger tree set of the whole simulation).
The descendant link is the same as you find in the full trees. Each subhalo has exactly one descendant, so there is no ambiguity.
Thanks Dylan. I assume the Sublink tree is the one I should use for my purposes (versus LHaloTree) ?
For the majority of cases they will give the same results, but yes we are typically using SubLink more commonly.