As part of this work, we're using the set of ~19,000 objects observed as part of sv1 with VI redshifts. However, we want to focus on the subset of those (~9000) objects which would have been observed as part of the main survey.
Initially, we simply matched the sample to the catalogs in /global/cfs/cdirs/desi/target/catalogs/dr9/1.1.1/targets/main/resolve/{dark,bright} and that worked fine.
However, for reasons that I don't recall, I decided I wanted more control over the results and instead:
Gathered the Tractor photometry for these targets using desispec.io.photo.gather_tractorphot; and
Ran desitarget.cuts.select_targets myself.
However, this procedure results in 25 ostensibly "main-survey" targets which are not in the dr9/1.1.1 target catalogs. Bad!
Looking at the first object in the list above, that object has PHOTSYS='S'. When you pass a catalog containing just this object to select_targets, it is not selected as a main-survey target. Specifically, cuts.set_target_bits sets
south_cuts = [True] because there are no PHOTSYS='N' values in the input catalog. Then, downstream, this object doesn’t pass any of the south targeting bits (whether BGS is otherwise) and so it doesn’t become a main-survey target.
However, when you pass a catalog which contains a mix of both north and south values of PHOTSYS, you get south_cuts = [False, True], which is fine. However, the first object in the list above happens to pass the BGS_FAINT_NORTH targeting cuts, even though its photometry is exclusively from the south! (I haven't checked, but presumably a similar issue is going on with the rest of the objects.)
Off-list, @geordie666 and I have been tracking down a nefarious, confusing bug which we finally think we understand.
This came up in the context of the Y3 template work (see https://github.com/desihub/rrevaluator and https://github.com/desihub/redrock/issues/279).
As part of this work, we're using the set of ~19,000 objects observed as part of sv1 with VI redshifts. However, we want to focus on the subset of those (~9000) objects which would have been observed as part of the main survey.
Initially, we simply matched the sample to the catalogs in
/global/cfs/cdirs/desi/target/catalogs/dr9/1.1.1/targets/main/resolve/{dark,bright}
and that worked fine.However, for reasons that I don't recall, I decided I wanted more control over the results and instead:
desispec.io.photo.gather_tractorphot
; anddesitarget.cuts.select_targets
myself.However, this procedure results in 25 ostensibly "main-survey" targets which are not in the
dr9/1.1.1
target catalogs. Bad!What's doubly-strange is that when you pass these objects individually to
select_targets
, they are not selected as main-survey targets. Double-bad!It took a while to track down, but here's what's going on:
The issue ultimately arises here: https://github.com/desihub/desitarget/blob/main/py/desitarget/cuts.py#L2392-L2396
Looking at the first object in the list above, that object has
PHOTSYS='S'
. When you pass a catalog containing just this object toselect_targets
, it is not selected as a main-survey target. Specifically,cuts.set_target_bits
setssouth_cuts = [True]
because there are noPHOTSYS='N'
values in the input catalog. Then, downstream, this object doesn’t pass any of the south targeting bits (whether BGS is otherwise) and so it doesn’t become a main-survey target.However, when you pass a catalog which contains a mix of both north and south values of
PHOTSYS
, you getsouth_cuts = [False, True]
, which is fine. However, the first object in the list above happens to pass theBGS_FAINT_NORTH
targeting cuts, even though its photometry is exclusively from the south! (I haven't checked, but presumably a similar issue is going on with the rest of the objects.)In other words, when applying the targeting cuts, there’s no consideration in
cuts.set_target_bits
for whether the photometry came from the north or the south--- https://github.com/desihub/desitarget/blob/main/py/desitarget/cuts.py#L2484-L2500It turns out that, in production, this doesn’t matter because the sweep files only ever have one value of
PHOTSYS
.However, we should either fix this or, at minimum, raise an exception if the input value(s) of
PHOTSYS
are not unique.