In v1.1.0 there was a single object in a single healpixel that @evevkovacs discovered had a NaN for a bulge-to-total ratio. This was unexpected because previous nearly-identical runs had no NaNs. We identified this object as having um_source_galaxy_has_fit = False, and so it seems likely that we just got unlucky by one of our MC generators happened to create a rare out-of-bounds value. For purposes of the roman_rubin_2023 mock, we agreed to simply delete this row. But in future we should fix the root issue.
We've noticed that fbulge_tcrit=0.05 for this galaxy, which is the same value as SED_params['t_start'] set at this location in constants.py.. I'm still not sure why this leads to a NaN, but the disk/bulge decomposition should be made robust to this, or at least to raise an exception rather than silently returning NaN.
In
v1.1.0there was a single object in a single healpixel that @evevkovacs discovered had a NaN for a bulge-to-total ratio. This was unexpected because previous nearly-identical runs had no NaNs. We identified this object as havingum_source_galaxy_has_fit = False, and so it seems likely that we just got unlucky by one of our MC generators happened to create a rare out-of-bounds value. For purposes of theroman_rubin_2023mock, we agreed to simply delete this row. But in future we should fix the root issue.We've noticed that
fbulge_tcrit=0.05for this galaxy, which is the same value asSED_params['t_start']set at this location in constants.py.. I'm still not sure why this leads to a NaN, but the disk/bulge decomposition should be made robust to this, or at least to raise an exception rather than silently returning NaN.