Anand noticed that a small number of skies could have discrepant TARGETIDs in different realizations of the sky location files produced by versions 1.1.0 and 1.1.1 of the desitarget code. This was caused by a somewhat convoluted bug:
The discrepancies correspond to BAD_SKY sky locations that have been flagged by the masking routine because they are near a bright star (NEAR_BRIGHT_OBJECT).
The masking routine, it turns out, assigns an OBJID (BRICK_OBJID) on the basis of the order in which a target is matched to a mask.
This OBJID propagates into the TARGETID in the usual way.
The actual bug is that the masks are not always read in the exact-same order. If the masks are read in a different order, then the targets are matched in a different order, which produces a different OBJID, which produces a different TARGETID.
The culprit that causes the masks to be read in a different order is this line of code in io.read_targets_in_hp().
The set in infiles = set([filedict[pix] for pix in filepixlist]) is unordered, potentially changing the order in which targets/masks are read in a non-reproducible fashion.
This PR resolves this bug by sorting the problematic set.
This PR is likely to be non-controversial. Sorting the set will potentially change the order of output targets/masks, but these were unordered anyway. I'll merge in a few days.
Anand noticed that a small number of skies could have discrepant
TARGETIDs in different realizations of the sky location files produced by versions1.1.0and1.1.1of thedesitargetcode. This was caused by a somewhat convoluted bug:BAD_SKYsky locations that have been flagged by the masking routine because they are near a bright star (NEAR_BRIGHT_OBJECT).OBJID(BRICK_OBJID) on the basis of the order in which a target is matched to a mask.OBJIDpropagates into theTARGETIDin the usual way.OBJID, which produces a differentTARGETID.io.read_targets_in_hp().setininfiles = set([filedict[pix] for pix in filepixlist])is unordered, potentially changing the order in which targets/masks are read in a non-reproducible fashion.This PR resolves this bug by sorting the problematic set.
This PR is likely to be non-controversial. Sorting the set will potentially change the order of output targets/masks, but these were unordered anyway. I'll merge in a few days.