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
TARGETID
s in different realizations of the sky location files produced by versions1.1.0
and1.1.1
of thedesitarget
code. This was caused by a somewhat convoluted bug:BAD_SKY
sky 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.OBJID
propagates into theTARGETID
in the usual way.OBJID
, which produces a differentTARGETID
.io.read_targets_in_hp()
.set
ininfiles = 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.