desihub / desitarget

DESI Targeting
BSD 3-Clause "New" or "Revised" License
18 stars 23 forks source link

select_targets can select north (south) targets for objects with south (north) photometry #821

Closed moustakas closed 3 months ago

moustakas commented 3 months ago

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:

  1. Gathered the Tractor photometry for these targets using desispec.io.photo.gather_tractorphot; and
  2. 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!

<Table length=25>
    TARGET_RA          TARGET_DEC          TARGETID
     float64            float64             int64
------------------ ------------------ -----------------
35.813700262224884 -5.206945199328692 39627658597767428
 35.95611507231263 -5.359925700877448 39627658601958684
 37.53560160975776 -4.511371192758242 39627676696188831
150.15391038279543 1.8945674771823369 39627835563838694
149.20043940392307 2.5159829263416227 39627847626657859
151.38949868826157 2.6027204998624245 39627847664405076
 149.6921862712477  2.892975597340467 39627859714641687
106.00075653648892  54.95950884025398 39633321159821042
105.75946082450504  55.14225192191247 39633324632703364
107.14453820974144  55.22266773697883 39633324645287048
106.18602683962725  55.56817690184516 39633328084619301
105.22266236194238  55.75898232607414 39633331507171632
108.30252293795569 55.844273985288034 39633331536531297
104.17873124885628   56.1161651740171 39633334904557083
104.30242744427088  55.93876986965283 39633334908748247
107.89623333467183  55.97002538469384 39633334942302972
109.46876774084396 55.877223289905885 39633334954887818
105.13664946129848  56.55590539431955 39633341665771821
105.51332906710496 56.413102795203805 39633341665775786
106.07870149933537  56.57395545784924 39633341674160813
 105.9658235825384 56.868503490813296 39633345012829156
 107.3815369968843 56.869245935774885 39633345025413416
108.14370703798735  57.09263335266234 39633348355689677
106.35063521164084   57.1923516752843 39633351639826525
 107.4796948308034  57.31286296338766 39633351648217151

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 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.)

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-L2500

It 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.

geordie666 commented 3 months ago

Addressed in #823 (with a unit test subsequently fixed in #814).