I'm trying to use the SubhaloParent field from the Subfind subhalo group catalogue to find the parent subhalo of a particular subhalo in TNG100 (SubhaloID = 121972 in snapNum = 99).
My current understanding of the SubhaloParent field is that if you take a mass-sorted (highest-to-lowest) list of all the subhalos in the subject subhalo's FoFGroup (which can be identified using SubhaloGrNr) the subhalo at index=SubhaloParent is the parent subhalo.
Here's the code I'm using to do this:
#%% Imports and Settings
# Imports
import numpy as np
import illustris_python as il
# Target Subhalo Index (ShInd)
targ_ShInd = 121972
# snapNum target subhalo is in
targ_snapNum = 99
# Filepath to where snapshot files are
basePath = '../../output/'
#%% Load groupcat data
ShGroupCat_data = il.groupcat.loadSubhalos(basePath,
targ_snapNum,
fields=["SubhaloMass", "SubhaloGrNr", "SubhaloParent"])
# Put ^ into arrays
ShMass = ShGroupCat_data["SubhaloMass"]
ShGrNr = ShGroupCat_data["SubhaloGrNr"]
ShParent = ShGroupCat_data["SubhaloParent"]
ShInd = np.arange(len(ShMass))
# Required info on target to identify parent
targ_parent = ShParent[ShInd==targ_ShInd][0]
targ_GrNr = ShGrNr[ShInd==targ_ShInd][0]
# Find all subhalos in target group, and order by mass
targGroup_ShInd = ShInd[ShGrNr==targ_GrNr]
targGroup_Mass = ShMass[ShGrNr==targ_GrNr]
targGroup_MassSort_LH_Ind = np.argsort(targGroup_Mass)
# (^ sorts low-to-high, flip for ease in finding x highest)
targGroup_MassSort_HL_Ind = targGroup_MassSort_LH_Ind[::-1]
targGroup_MassSort_HL_ShInd = targGroup_ShInd[targGroup_MassSort_HL_Ind]
# Get ShInd of parent from given mass-sorted index
parent_ShInd = targGroup_MassSort_HL_ShInd[targ_parent]
I've previously used code equivalent to this to find the parent subhalos of several other subhalos, and at-least at first glance the results obtained in those cases appeared reasonable (i.e. very similar centres of mass, plotting the locations of stars in each subhalo made the target appear as a "lump" within the apparent parent, etc). But for this specific target (meaning ShInd = 121972 in snapNum = 99), the supposed parent doesn't seem correct: the target and its apparent parent are located 100s of kpc from each other (with each having a half-mass radius >~100x smaller than that distance). As such, I can only assume I've misunderstood how to use the SubhaloParent field properly (or my code is wrong in some other way).
Are there perhaps any caveats to using SubhaloParent that I may not be aware of (which are perhaps why this code doesn't seem to be working)? Maybe that sub-subhalos are supposed to be excluded when counting down the mass-sorted subhalo list, or something similar? The SubhaloParent value in this instance is 57, which seems quite large (when I've used this code for other subhalos, this value has always been no bigger than ~5) - perhaps that's why I've not had any issues before now (if the issue is that I shouldn't be counting certain subhalos).
Dylan Nelson
4 Oct
In general, we use SubhaloParent rarely, because "sub-subhalos" in the TNG simulations are not common and not commonly considered.
Perhaps you can clarify what you are trying to do?
Harley Brown
4 Oct
Hi Dylan,
I'm happy to provide some additional context to my work.
I am investigating galaxies infalling into clusters in the TNG100-1 simulation and ultimately want to study the build up of the intracluster light (ICL) in these clusters - assessing the differing ICL contributions of galaxies with various masses on infall, of the differing mechanisms for liberating stars from galaxies, etc. While in general sub-subhalos (and beyond) are rare in TNG100 (a quick check of the subhalo group-catalogue suggests ~3% of subhalos), in clusters they seem more common. For example, >10% of the subhalos within the virial-ish radius (r_200) of the cluster that SubhaloID=121972 (the subhalo I mention in my original post) is in have SubhaloParent > 0. In some of the other clusters I am looking at this fraction goes beyond 20%. So I'm currently in the process of deciding how I will be handling these objects in my upcoming work.
I'll confess that why I'm looking into SubhaloID=121972 specifically has been something of a tangent while I'm familiarising myself with the simulation and how to use it properly. It's part of a population of strange subhalos I've noticed that:
1) are virtually exclusively composed of star particles and gas (no DM or BHs) but are also fairly massive (total masses as high as order 10^10 sol_mass)
2) have >0 (and often seemingly quite high) star-formation rates
3) are often sub-subhalos (or beyond)
4) can usually be followed through >10 snapshots back from z=0 using the baryonic merger trees while keeping all the above properties, and
5) oddly, often have SubhaloFlag=1 - meaning they should be considered a 'galaxy' or 'satellite' of cosmological origin
From having looked into a few other objects like this already, at-least some of these objects seem to be just be star-forming knots that are part of a larger galaxy: A good example of this is SubfindID=121920 [in snapnum=99] - here are some quickly thrown together scatter plots showing the stars of it (and its progenitors) and the parent subhalo (as identified using equivalent code to that in my original post - the coordinates indicated are relative to the centre of the cluster it is in and are not for the entire simulation box):
snapNum=87
snapNum=93
snapNum=99
These objects present a bit of a conundrum since - if I want to assess the ICL contribution of each infalling galaxy - it seems incorrect to classify this star-forming knot and the parent subhalo as two different galaxies. I haven't yet decided how I want to handle these objects (I was only partway through an initial investigation of a handful of these as test-cases when I ran into my issue with SubhaloID=121972), but if I do decide I want to develop some routine for identifying star-forming knots like that seen above and bundle them in together with their parent subhalo as a single infalling "galaxy", I will require some method of actually identifying the parent subhalo correctly - which my code above seems to not do in the case of SubhaloID=121972.
I'd like to not have to resort to some crude method of parent Subhalo identification based on e.g. looking for more massive subhalos which the target falls within a certain radius of, especially since the SubhaloParent field seems to exist for this exact purpose - I just don't seem to currently follow how to use it properly.
Do you not think the SubhaloParent field can be used for this?
Dylan Nelson
4 Oct
I agree that these would be best considered as simply parts of their parent subhalos. You could simply say that the current behavior of Subfind of occasionally identifying fragments or sub-pieces of subhalos as sub-subhalos is undesirable, and correct for this.
Of course there could be some problem in SubhaloParent, but not as far as I know. The specific case you mention doesn't seem to be problematic, TNG100-1 snapshot 99 subhalo ID 121972 has position [52840.242, 71142.21 , 41799.56 ] and its parent index 57 i.e. global index 121863+57 has position [52838.918, 71141.26 , 41800.223].
Harley Brown
4 Oct
Hi again Dylan,
The code from my original post finds SubfindID=121922 to be the supposed parent, instead of SubfindID=121863+57=121920 (close, but off by 2) so it does seem the issue is with my code rather than SubhaloParent.
My previous understanding (which the code from my original post is based on) was that the SubhaloParent field returned the (local) index of the parent in a mass-sorted (highest-to-lowest) list of all the subhalos in the subject subhalo's FoFGroup (accessible via SubhaloGrNr), with my code using the SubhaloMass field for the masses of the subhalos (reading back over the data specification again for this, the note attached to this field - that "particle/cells bound to subhaloes of [a] Subhalo are NOT accounted for" - could be a potential explanation for my issues here).
I note that you phrased the parent SubhaloID you found in terms of what I recognise to be the SubhaloID of the FirstSubhalo of the target's FoF Group plus the target's SubhaloParent value. Is this how the SubhaloParent field is actually supposed to be used? I.e. Find the FoFgroup of the target (probably via SubhaloGrNr), take the FoF Group's FirstSubhalo SubfindID (probably from GroupFirstSub), then just add to that ID whatever the value in the target's SubhaloParent field is to get the parent's SubfindID?
Dylan Nelson
5 Oct
Yes that's correct. The language "third most massive" in the description of SubhaloParent is misleading, I will change that. It should instead just say "third (in order)".
I'm trying to use the SubhaloParent field from the Subfind subhalo group catalogue to find the parent subhalo of a particular subhalo in TNG100 (SubhaloID = 121972 in snapNum = 99).
My current understanding of the SubhaloParent field is that if you take a mass-sorted (highest-to-lowest) list of all the subhalos in the subject subhalo's FoFGroup (which can be identified using SubhaloGrNr) the subhalo at index=SubhaloParent is the parent subhalo.
Here's the code I'm using to do this:
I've previously used code equivalent to this to find the parent subhalos of several other subhalos, and at-least at first glance the results obtained in those cases appeared reasonable (i.e. very similar centres of mass, plotting the locations of stars in each subhalo made the target appear as a "lump" within the apparent parent, etc). But for this specific target (meaning ShInd = 121972 in snapNum = 99), the supposed parent doesn't seem correct: the target and its apparent parent are located 100s of kpc from each other (with each having a half-mass radius >~100x smaller than that distance). As such, I can only assume I've misunderstood how to use the SubhaloParent field properly (or my code is wrong in some other way).
Are there perhaps any caveats to using SubhaloParent that I may not be aware of (which are perhaps why this code doesn't seem to be working)? Maybe that sub-subhalos are supposed to be excluded when counting down the mass-sorted subhalo list, or something similar? The SubhaloParent value in this instance is 57, which seems quite large (when I've used this code for other subhalos, this value has always been no bigger than ~5) - perhaps that's why I've not had any issues before now (if the issue is that I shouldn't be counting certain subhalos).
In general, we use
SubhaloParentrarely, because "sub-subhalos" in the TNG simulations are not common and not commonly considered.Perhaps you can clarify what you are trying to do?
Hi Dylan,
I'm happy to provide some additional context to my work.
I am investigating galaxies infalling into clusters in the TNG100-1 simulation and ultimately want to study the build up of the intracluster light (ICL) in these clusters - assessing the differing ICL contributions of galaxies with various masses on infall, of the differing mechanisms for liberating stars from galaxies, etc. While in general sub-subhalos (and beyond) are rare in TNG100 (a quick check of the subhalo group-catalogue suggests ~3% of subhalos), in clusters they seem more common. For example, >10% of the subhalos within the virial-ish radius (r_200) of the cluster that SubhaloID=121972 (the subhalo I mention in my original post) is in have SubhaloParent > 0. In some of the other clusters I am looking at this fraction goes beyond 20%. So I'm currently in the process of deciding how I will be handling these objects in my upcoming work.
I'll confess that why I'm looking into SubhaloID=121972 specifically has been something of a tangent while I'm familiarising myself with the simulation and how to use it properly. It's part of a population of strange subhalos I've noticed that:
1) are virtually exclusively composed of star particles and gas (no DM or BHs) but are also fairly massive (total masses as high as order 10^10 sol_mass)
2) have >0 (and often seemingly quite high) star-formation rates
3) are often sub-subhalos (or beyond)
4) can usually be followed through >10 snapshots back from z=0 using the baryonic merger trees while keeping all the above properties, and
5) oddly, often have SubhaloFlag=1 - meaning they should be considered a 'galaxy' or 'satellite' of cosmological origin
From having looked into a few other objects like this already, at-least some of these objects seem to be just be star-forming knots that are part of a larger galaxy: A good example of this is SubfindID=121920 [in snapnum=99] - here are some quickly thrown together scatter plots showing the stars of it (and its progenitors) and the parent subhalo (as identified using equivalent code to that in my original post - the coordinates indicated are relative to the centre of the cluster it is in and are not for the entire simulation box):
snapNum=87
snapNum=93
snapNum=99
These objects present a bit of a conundrum since - if I want to assess the ICL contribution of each infalling galaxy - it seems incorrect to classify this star-forming knot and the parent subhalo as two different galaxies. I haven't yet decided how I want to handle these objects (I was only partway through an initial investigation of a handful of these as test-cases when I ran into my issue with SubhaloID=121972), but if I do decide I want to develop some routine for identifying star-forming knots like that seen above and bundle them in together with their parent subhalo as a single infalling "galaxy", I will require some method of actually identifying the parent subhalo correctly - which my code above seems to not do in the case of SubhaloID=121972.
I'd like to not have to resort to some crude method of parent Subhalo identification based on e.g. looking for more massive subhalos which the target falls within a certain radius of, especially since the SubhaloParent field seems to exist for this exact purpose - I just don't seem to currently follow how to use it properly.
Do you not think the SubhaloParent field can be used for this?
I agree that these would be best considered as simply parts of their parent subhalos. You could simply say that the current behavior of Subfind of occasionally identifying fragments or sub-pieces of subhalos as sub-subhalos is undesirable, and correct for this.
Of course there could be some problem in SubhaloParent, but not as far as I know. The specific case you mention doesn't seem to be problematic, TNG100-1 snapshot 99 subhalo ID 121972 has position [52840.242, 71142.21 , 41799.56 ] and its parent index 57 i.e. global index 121863+57 has position [52838.918, 71141.26 , 41800.223].
Hi again Dylan,
The code from my original post finds SubfindID=121922 to be the supposed parent, instead of SubfindID=121863+57=121920 (close, but off by 2) so it does seem the issue is with my code rather than SubhaloParent.
My previous understanding (which the code from my original post is based on) was that the SubhaloParent field returned the (local) index of the parent in a mass-sorted (highest-to-lowest) list of all the subhalos in the subject subhalo's FoFGroup (accessible via SubhaloGrNr), with my code using the SubhaloMass field for the masses of the subhalos (reading back over the data specification again for this, the note attached to this field - that "particle/cells bound to subhaloes of [a] Subhalo are NOT accounted for" - could be a potential explanation for my issues here).
I note that you phrased the parent SubhaloID you found in terms of what I recognise to be the SubhaloID of the FirstSubhalo of the target's FoF Group plus the target's SubhaloParent value. Is this how the SubhaloParent field is actually supposed to be used? I.e. Find the FoFgroup of the target (probably via SubhaloGrNr), take the FoF Group's FirstSubhalo SubfindID (probably from GroupFirstSub), then just add to that ID whatever the value in the target's SubhaloParent field is to get the parent's SubfindID?
Yes that's correct. The language "third most massive" in the description of SubhaloParent is misleading, I will change that. It should instead just say "third (in order)".