BACKUP ToOs

[jbanovetz]

I have made changes to desitarget so that if there are nearby and bright ToOs, these ToOs can be ingested and we can get the ToO spectra.

The changes I made are to include the BACKUP program in the ToO.py file and to add the BACKUP ToOs to the targetmask.yaml under the bgs_mask.

I ran this through fba_launch and was able to successfully assign the BACKUP ToOs to a tile. The command I used was

fba_launch --doclean n --dr dr9 --dtver 2.2.0 --fba_use_fabs 1 --forcetileid y --gaiadr gaiadr2 --goaltime 60.0 --goaltype BACKUP \
--ha -12.820331882448016 --hdr_faprgrm backup --hdr_survey main --lookup_sky_source gaia --margin_gfa 0.4 \
 --margin_petal 0.4 --margin_pos 0.05 --mintfrac 0.85 --mtltime 2026-06-25T20:04:30+00:00 --pmcorr n \
--pmtime_utc_str 2026-06-26T07:36:43+00:00 --program BACKUP --rundate 2026-06-20T17:00:55+00:00 --sbprof PSF \
--sky_per_petal 40 --sky_per_slitblock 1 --standards_per_petal 10 --steps tiles,sky,gfa,targ,scnd,too,fa,zip,move \
--survey main --tiledec -17.5 --tileid 46163 --tilera 148.357 --try_too_all --worldreadable  --log_stdout \
--outdir $BACKUP_TOO_DIR

And the TOODIR used was: /global/cfs/cdirs/desi/users/banovetz/ToO_desitarget_test

[coveralls]

coverage: 40.675% (-0.01%) from 40.685% — ToO_Backup into main

[geordie666]

I think the code will currently fail for the reason stated in my 3rd review comment. Please update the code and test that select_too proceeds to completion.

Please also update the doc/changes.rst file to document this PR.

[geordie666]

Let's set UNOBS for BACKUP_TOO_HIP at the standard "very high" priority value of 9500 in case we ever add additional BACKUP targets at higher priority. For example, there are currently secondary targets (WDs) in the backup program that have an UNOBS priority of 1998.

[geordie666]

You're missing a space after a comma.

[geordie666]

I think the code will fail, here, because bitname will be, e.g., BACKUP_TOO_LOP and sMx is the mask of secondary bits. Because we have to store BACKUP_TOO_LOP in mMx (the mask of MWS bits) sMx[bitname] is not defined.

I tested the code by adding this line to a mock-up of the ToO-input.ecsv file:

350.555538   0.404432 0.000000 0.000000 2000.0 XH/AP FIBER LO BACKUP 61219.42268462 61249.42268462 2999999999

And did, indeed, trigger such a failure. So, I think you need some extra lines indicating which bit mask to query to retrieve the BACKUP_TOO bits.

[jbanovetz]

Thank you are the review and the catch! I forgot to rerun select_too once I changed the mask to BGS. I have made the changes and checked with both select_too and fba_launch and it works as intended. One question I have is do I also need to make a change to this line (450):

outdata[dcol] = dMx["SCND_ANY"]

since the BACKUP ToO is technically not a secondary? This is more of a bookkeeping issue so please let me know if I should change it to dMx['BGS_ANY'].

[geordie666]

Oh, yes, excellent point. That should indeed be changed to

outdata[dcol] = dMx["BGS_ANY"]

We might want to check with @dylanagreen (if you didn't already) as to whether fiberassign will still find ToOs with the BGS_ANY bit set instead of the SCND_ANY bit. But, yes, formally you should make that update to BGS_ANY.

[geordie666]

On further review, I don't think this approach will work for fiberassign because we currently don't write out BGS_TARGET to the ToO-fiber.ecsv and ToO.ecsv files.

I think perhaps the cleanest solution, then, is to instead put these new bits directly in the desi_mask and associated DESI_TARGET column instead of using BGS_TARGET. Perhaps as bits 41 and 42?

[jbanovetz]

Thanks for looking at it again! I will give that a try locally and report back!