Public Data Access Overview / Discussion Forum

Hi all,

My goal is to obtain halo mass, stellar mass, and star formation rate of the parent subhalos and black hole properties such as the merger time, mass, accretion rate, and separation before merging. I cross-matched the particle data in TNG50-1 to the BH details+mergers catalog using the PartType5 BH IDs. I obtained the id_in and id_out and now I want to find information about their respective subhalos to extract the information in the snapshot before merging.

To obtain the parent halo of a BH ID, I used the following reference: https://www.tng-project.org/data/forum/topic/274/match-snapshot-particles-with-their-halosubhalo/

However, when running the function, the return val provides the same ID for both BH ID in and BH ID out. Why is this happening? Also, is val the SubhaloID? And if not, how can I find the SubhaloID?

inverseMapPartIndicesToSubhaloIDs([108750914467, 112254842703], SubhaloLenType, SnapOffsetsSubhalo)

The result is: [7583452, 7583452]

I downloaded the groupcat and offset files for a test snapshot (in this case snap = 33) and then assigned the corresponding information for SubhaloLenType and SnapOffsetsSubhalo. Below are how I defined these:

SubhaloLenType = il.groupcat.loadSubhalos(f"{project_path}TNG50-1/output", 33, fields = ["SubhaloLenType"])

with h5py.File(f"{project_path}TNG50-1/postprocessing/offsets/offsets_033.hdf5", "r") as f:
    SnapOffsetsSubhalo = f["Subhalo/SnapByType"][:]

The function I'm using is the following:

def inverseMapPartIndicesToSubhaloIDs(indsType, SubhaloLenType, SnapOffsetsSubhalo, debug=False, flagFuzz=False):

    """ For a particle type ptName and snapshot indices for that type indsType, compute the
        subhalo ID to which each particle index belongs. 
        If flagFuzz is True (default), particles in FoF fuzz are marked as outside any subhalo,
        otherwise they are attributed to the closest (prior) subhalo.
    """
    gcLenType = SubhaloLenType[:,5]
    gcOffsetsType = SnapOffsetsSubhalo[:,5][:-1]

    # val gives the indices of gcOffsetsType such that, if each indsType was inserted
    # into gcOffsetsType just -before- its index, the order of gcOffsetsType is unchanged
    # note 1: (gcOffsetsType-1) so that the case of the particle index equaling the
    # subhalo offset (i.e. first particle) works correctly
    # note 2: np.ss()-1 to shift to the previous subhalo, since we want to know the
    # subhalo offset index -after- which the particle should be inserted
    val = np.searchsorted( gcOffsetsType - 1, indsType ) - 1
    val = val.astype('int32')

    # search and flag all matches where the indices exceed the length of the
    # subhalo they have been assigned to, e.g. either in fof fuzz, in subhalos with
    # no particles of this type, or not in any subhalo at the end of the file
    if flagFuzz:
        gcOffsetsMax = gcOffsetsType + gcLenType - 1
        ww = np.where( indsType > gcOffsetsMax[val] )[0]

        if len(ww):
            val[ww] = -1

    if debug:
        # for all inds we identified in subhalos, verify parents directly
        for i in range(len(indsType)):
            if val[i] < 0:
                continue
            assert indsType[i] >= gcOffsetsType[val[i]]
            if flagFuzz:
                assert indsType[i] < gcOffsetsType[val[i]]+gcLenType[val[i]]
                assert gcLenType[val[i]] != 0

    return val

Yes the return is the subhalo ID. It seems plausible that both reside in the same subhalo at the time of the merger.

You could verify by loading the IDs of the BHs that belong to that subhalo ID, and confirming it has both, at that snapshot.