Tile 9880, exp 175782 has contamination in petal 1. about desisurveyops

[araichoor]

if useful, I ve identified the relevant row in the FAINT_HPM.fits catalog: #109 (comment).

[schlafly]

Honestly, I think you discovered the issue and have pretty clear confirmation that it's what you expected. You checked every source in the MTL for the bug and found only the 4 cases Rongpu identified in the FAINT_HPM program.

That all hangs together pretty closely, so I'd go ahead and prevent these from getting observed via the override ledger.

[sbailey]

The b1 images for the exposure before and after look fine, which is further evidence that this is "contaminated by an intense light source" like a transient shutter failure rather than a CCD problem. Heads up @paulmartini ; this looks similar to the Z shutter light leaks from year(s?) ago.

@abhi0395 @akremin we should flag 20230410 exp 175782 camera b1 as bad and reprocess tile 9880.

[araichoor]

don t know if that s relevant, but it looks like FIBER=871 is right on a ~5 mag bright star.
https://www.legacysurvey.org/viewer/?ra=199.1887&dec=9.4233&layer=ls-dr9&zoom=13&catalog=tmpe_oib9y0

[abhi0395]

The b1 images for the exposure before and after look fine, which is further evidence that this is "contaminated by an intense light source" like a transient shutter failure rather than a CCD problem. Heads up @paulmartini ; this looks similar to the Z shutter light leaks from year(s?) ago.

@abhi0395 @akremin we should flag 20230410 exp 175782 camera b1 as bad and reprocess tile 9880.

Will take care of this, thanks!

[schlafly]

4/10 is supposed to be the night when I put in the nudges in the tile centers. If this is a stuck fiber, we'd expect it to have been nudged safely away starting on that night. Can we confirm that 871 is the problematic fiber and that it is a stuck fiber?

[dstndstn]

Looking at the fiberassign for that tile,
https://www.legacysurvey.org/viewer-desi/?ra=199.1881&dec=9.4210&layer=ls-dr9&zoom=13&tile=9880
I see that source has
RA,Dec 199.1938, 9.4242
sec:FAINT_HPM
Targetid: 2253417447686145

So does that mean it's a faint-high-proper-motion target?

I do see it indicated as a dark-time secondary target.

[araichoor]

yes, sorry, I saw that it was this FAINT_HPM secondary targets, but didn t report.
if useful, I guess all those targets are here: https://data.desi.lbl.gov/desi/target/secondary/main/indata/FAINT_HPM.fits.
and some brief doc here: https://data.desi.lbl.gov/desi/target/secondary/main/docs/HPM_SOUM.txt.
note that the star may have some proper-motion, one would have to check the ls-dr9 catalogs.

[schlafly]

@ameisner , I see your name in FAINT_HPM.txt. We had a problematic bright target a few nights ago that led to us throwing a spectrograph out of an exposure. Is this a case where a faint, high proper motion object was initially okay (i.e., no bright star on top of it), but happens to move over a really bright problematic star?

[dstndstn]

Oh, is it not the 5th mag star that is the target? It has ~400 mas/year proper motion... though I wouldn't call it "faint" :)

RA,Dec 199.1923, 9.4250
pmRA,Dec -335.5, 191.0 ± 0.2, 0.2 mas/yr, parallax 56.9± 0.1 mas
G 5.04, BP 5.34, RP 4.58
Source id: 3732539683617410816

[araichoor]

for completeness, here s the FAINT_HPM proposal: https://desi.lbl.gov/trac/raw-attachment/wiki/TargetSelectionWG/Secondary/SVcall/DESI_Faint_HPM_Stars.pdf

if useful, with looking at the FAINT_HPM.fits catalog mentioned above, this object there is:

>>> d = Table.read("FAINT_HPM.fitS")
>>> i = 62763
>>> d[i]
<Row index=62763>
            NAME             CLASS     RA      DEC     PMRA  PMRA_ERROR  PMDEC  PMDEC_ERROR REF_EPOCH OVERRIDE  GAIAG    BPRP     R       GR      RZ  
          bytes28            bytes6 float64  float64 float32  float32   float32   float32    float32    bool   float32 float32 float32 float32 float32
---------------------------- ------ -------- ------- ------- ---------- ------- ----------- --------- -------- ------- ------- ------- ------- -------
GJ 504 B                     HPM-BD 199.1938  9.4242  -336.7        0.6   190.6         0.4    2000.0     True      --      --      --      --      --

so it looks consistent with what Dustin reports for 5th mag star (~same proper-motion).

more generally, didn t we run a check that any secondary(-only) target is e.g. outside the bright star mask?

from desisurveyops.

[geordie666]

We did run a check, based on bright-star masks shifted to DESI mid-survey. This target is very bright though (likely even brighter than the bright-star masks). Plus, the high-proper-motion could have made it a corner case. I'll have to check why we didn't catch it. But, my guess is that stars as bright as fifth magnitude just weren't expected or accounted for in targeting.

I see in https://data.desi.lbl.gov/desi/target/secondary/main/docs/FAINT_HPM.txt that objects with "G not measured by Gaia" were included in the program, which seems problematic. The intention was likely "let's include any source that is too faint" but this might also have included sources that were too bright for Gaia.

[schlafly]

I felt like we worked pretty hard to cover extremely bright stars in the DESI LS bright star masks with unholy mixtures of Gaia + Hipparchos + ..., and that 5th mag isn't that bad. Anyway, let's let Aaron et al. dig in; at least we know that there's nothing new here, so we likely won't hit the next one for another year or so.

[rongpu]

I have a script that estimates the fiber flux (in DEcam griz bands) from nearby bright stars based on Gaia EDR3 (which I wrote as a check for a secondary program), although I never advertised it: https://github.com/rongpu/desi-examples/blob/master/misc/misc/estimate_fiber_flux_from_stars.py

I ran the script on this tile, and it predicts a fiber mag of ~15. So it could be bright enough to cause some cross-talking but not nearly enough to saturate an entire CCD. Note that the script does not correct for proper motions (and it should be trivial to add to the script), but according to the Gaia-reported PM the star is moving away from that fiber so adding PM won't make it any brighter.

[rongpu]

Actually, I think I made a mistake earlier, and this fiber indeed saturated the CCD. I was using the TARGET_RA/TARGET_DEC values in the fiberassign file without applying a correction with PMRA/PMDEC and REF_EPOCH (which is 2000.0 for this target). If I do correct for PM in the target RA/DEC, my script predicts 5 mag stellar flux, i.e. the fiber is directly on top of the star.

[ameisner]

Arjun really did all the work as far as target selection for this
program. I guess I can try to dig deeper into what mag(s) we tried to
use for this source such that it somehow ended up in the FAINT_HPM
category despite being extremely bright. My only idea for how to do
this would be looking at the FITS catalog files that define the target
list for this secondary program.

[ameisner]

Thanks, Anand. That is indeed very useful.

It's interesting that the target is listed with a name of GJ 504b, which is a giant exoplanet (https://en.wikipedia.org/wiki/Gliese_504_b). Based on this, my guess of what may have happened is that this object came in through the "UltraCoolSheet" list of known "brown dwarfs" (which maybe includes some giant exoplanets?), and that this is a close-in exoplanet found via high-contrast imaging such that we're effectively putting the DESI fiber on the bright host star GJ 504. I would need to look at the UltraCoolSheet more carefully to see what would be the best way to identify any other such cases.

[ameisner]

There are a total of 9 rows in the FAINT_HPM.fits file that have NAME column with either " b" or " B" in it:

{
NAME: "HD 984 B ",
CLASS: "HPM-BD",
RA: 3.5427000000000000,
DEC: -7.1990999999999996,
PMRA: 104.54000,
PMRA_ERROR: 0.15000001,
PMDEC: -67.910004,
PMDEC_ERROR: 0.059999999,
REF_EPOCH: 2000.0000,
OVERRIDE: "T",
GAIAG: NaN,
BPRP: NaN,
R: NaN,
GR: NaN,
RZ: NaN
}
{
NAME: "GU Psc b ",
CLASS: "HPM-BD",
RA: 18.146000000000001,
DEC: 17.065400000000000,
PMRA: 96.639999,
PMRA_ERROR: 0.13000000,
PMDEC: -100.70000,
PMDEC_ERROR: 0.11000000,
REF_EPOCH: 2000.0000,
OVERRIDE: "T",
GAIAG: NaN,
BPRP: NaN,
R: NaN,
GR: NaN,
RZ: NaN
}
{
NAME: "1RXS J034231.8+121622 B ",
CLASS: "HPM-BD",
RA: 55.632599999999996,
DEC: 12.272900000000000,
PMRA: 196.95000,
PMRA_ERROR: 0.12000000,
PMDEC: -9.1400003,
PMDEC_ERROR: 0.090000004,
REF_EPOCH: 2000.0000,
OVERRIDE: "T",
GAIAG: NaN,
BPRP: NaN,
R: NaN,
GR: NaN,
RZ: NaN
}
{
NAME: "51 Eri b ",
CLASS: "HPM-BD",
RA: 69.400599999999997,
DEC: -2.4735000000000000,
PMRA: 44.349998,
PMRA_ERROR: 0.23000000,
PMDEC: -63.830002,
PMDEC_ERROR: 0.18000001,
REF_EPOCH: 2000.0000,
OVERRIDE: "T",
GAIAG: NaN,
BPRP: NaN,
R: NaN,
GR: NaN,
RZ: NaN
}
{
NAME: "eta Cnc B ",
CLASS: "HPM-BD",
RA: 128.13249999999999,
DEC: 20.450199999999999,
PMRA: -46.330002,
PMRA_ERROR: 0.22000000,
PMDEC: -44.730000,
PMDEC_ERROR: 0.15000001,
REF_EPOCH: 2000.0000,
OVERRIDE: "T",
GAIAG: NaN,
BPRP: NaN,
R: NaN,
GR: NaN,
RZ: NaN
}
{
NAME: "VHS J125601.92-125723.9 b ",
CLASS: "HPM-BD",
RA: 194.00690000000000,
DEC: -12.958000000000000,
PMRA: 286.10001,
PMRA_ERROR: 1.3000000,
PMDEC: -189.30000,
PMDEC_ERROR: 1.6000000,
REF_EPOCH: 2000.0000,
OVERRIDE: "T",
GAIAG: NaN,
BPRP: NaN,
R: NaN,
GR: NaN,
RZ: NaN
}
{
NAME: "GJ 504 B ",
CLASS: "HPM-BD",
RA: 199.19380000000001,
DEC: 9.4242000000000008,
PMRA: -336.70001,
PMRA_ERROR: 0.60000002,
PMDEC: 190.60001,
PMDEC_ERROR: 0.40000001,
REF_EPOCH: 2000.0000,
OVERRIDE: "T",
GAIAG: NaN,
BPRP: NaN,
R: NaN,
GR: NaN,
RZ: NaN
}
{
NAME: "HN Peg B ",
CLASS: "HPM-BD",
RA: 326.11880000000002,
DEC: 14.768800000000001,
PMRA: 231.09000,
PMRA_ERROR: 0.10000000,
PMDEC: -113.13000,
PMDEC_ERROR: 0.10000000,
REF_EPOCH: 2000.0000,
OVERRIDE: "T",
GAIAG: NaN,
BPRP: NaN,
R: NaN,
GR: NaN,
RZ: NaN
}
{
NAME: "1RXS J235133.3+312720 B ",
CLASS: "HPM-BD",
RA: 357.89130000000000,
DEC: 31.456399999999999,
PMRA: 106.58000,
PMRA_ERROR: 0.059999999,
PMDEC: -87.760002,
PMDEC_ERROR: 0.039999999,
REF_EPOCH: 2000.0000,
OVERRIDE: "T",
GAIAG: NaN,
BPRP: NaN,
R: NaN,
GR: NaN,
RZ: NaN
}

[ameisner]

One other way to go about this would be to cross-match the faint HPM list with a bright star list e.g., from Gaia or otherwise, and throw out targets within some radius of sufficiently bright stars. I guess I would have thought the targeting pipeline might have applied such a generic test for all programs, but I don't actually know whether that's the case...

[schlafly]

Yes, we thought we did that as well, and will review. But let's borrow Stephen Bailey's belt and suspenders and address that separately from making sure that we don't explicitly ask for very bright stars.

[rongpu]

I ran my script on all targets in FAINT_HPM.fits, cross-matching them to all Gaia stars with Gaia_G<12. There are a few more very bright targets (including two more ~5th mag stars):

The full list below

            NAME             CLASS  TARGET_RA TARGET_DEC    gmag      rmag      imag      zmag  
---------------------------- ------ --------- ---------- --------- --------- --------- ---------
HD 984 B                     HPM-BD    3.5427    -7.1991 7.4693165 7.1685753  7.097807  7.114662
HD 1160B                     HPM-BD    3.9888     4.2511  7.029421 7.2546043 7.4351826 7.5963554
HD 19467B                    HPM-BD    46.827    -13.762 11.033345 10.842848 10.803183  10.91508
51 Eri b                     HPM-BD   69.4006    -2.4735  5.242012 5.1679916  5.203127 5.2759666
HD 49197B                    HPM-BD  102.3389    43.7591 7.4472847 7.1417046 7.0688667  7.084442
Wolf 359                     HPM-BD  164.1201     7.0145  14.15744 12.329529   9.95459  8.900223
HD 114762B                   HPM-BD  198.0827    17.5179 14.493727 14.225083 14.173457 14.150589
GJ 504 B                     HPM-BD  199.1938     9.4242  5.357727 4.9815445  4.879856 4.8766212
HD 130948BC                  HPM-BD  222.5667    23.9116  12.54781 12.294087 12.243654 12.245666
HIP 78530B                   HPM-BD  240.4811   -21.9804 7.1135435 7.2630386  7.406167  7.537137
GSC 06214-00210B             HPM-BD  245.4778   -20.7192 12.912583  11.73155 11.294771 11.101989
chi Cap E                    HPM-BD  317.1401   -21.1937  5.195528 5.4502354  5.646225 5.8233604
chi Cap F                    HPM-BD  317.1401   -21.1937  5.195528 5.4502354  5.646225 5.8233604
HR 8799b                     HPM-BD  346.8696    21.1343  6.010729 5.9379463 5.9736824   6.04681
HR 8799c                     HPM-BD  346.8696    21.1343  6.010729 5.9379463 5.9736824   6.04681
HR 8799d                     HPM-BD  346.8696    21.1343  6.010729 5.9379463 5.9736824   6.04681
HR 8799e                     HPM-BD  346.8696    21.1343  6.010729 5.9379463 5.9736824   6.04681

from desisurveyops.

[geordie666]

OK, I think I know what happened.

As promised, I masked all targets for bright stars. But, trying to be too clever, I first moved the masks representing the bright stars to positions indicative of "mid-DESI" (2023.0) The logic behind this choice was to catch cases where high-proper-motion stars moved in front of extragalactic sources.

However, when I then matched the targets to the masks, I didn't account for the potential proper motions of Galactic sources. In other words, I moved the masks to represent their proper motions (fine for xgal) but I did not move the associated stars themselves before masking (bad for non-xgal). So, then, some bright, high-proper-motion stars potentially wouldn't fall in their own masks!

I applied a healthily cautious masking radius of 5 arcseconds, so the issue we're discussing should only be a problem for stars with very large proper motions (~5 arcsec in the 7.5 years from 2015.5 to 2023.0).

My working hypothesis, then, is that we should only see this bug for 4 targets in Rongpu's list, above:

            NAME             CLASS  TARGET_RA TARGET_DEC    gmag      rmag      imag      zmag  
---------------------------- ------ --------- ---------- --------- --------- --------- ---------
HD 19467B                    HPM-BD    46.827    -13.762 11.033345 10.842848 10.803183  10.91508
Wolf 359                     HPM-BD  164.1201     7.0145  14.15744 12.329529   9.95459  8.900223
HD 114762B                   HPM-BD  198.0827    17.5179 14.493727 14.225083 14.173457 14.150589
GJ 504 B                     HPM-BD  199.1938     9.4242  5.357727 4.9815445  4.879856 4.8766212

If I've got my math correct, then the remaining targets in Rongpu's list will not have moved sufficiently far to have traversed the 5 arcseconds of the masking radius (or, rather, the mask won't have moved sufficiently far to slide off the target star).

To confirm this, I'm now going to spool through the MTL ledgers and check the hypothesis that only these 4 stars from Rongpu's list will be in the ledgers as potential targets, the others having been correctly removed.

If I'm correct about my bug, then it makes sense that this issue only arose for the HPM programs, because only high-proper-motion stars will be discrepant with their own mask at > 5 arcseconds.

from desisurveyops.

[schlafly]

Ah, great, that makes sense. Thanks Adam.

[geordie666]

One correction to my previous comment. Some of the REF_EPOCH values in the FAINT_HPM file are 2000.0, meaning that the corresponding bright star mask can have had 23 years to drift away from a bright star. All the sources in Rongpu's table have REF_EPOCH=2000.0.

In any case, I spooled through Rongpu's list and confirmed that the only problematic sources (the only ones that passed through masking and are present in the MTL ledgers) are:

            NAME             CLASS  TARGET_RA TARGET_DEC    gmag      rmag      imag      zmag  
---------------------------- ------ --------- ---------- --------- --------- --------- ---------
HD 19467B                    HPM-BD    46.827    -13.762 11.033345 10.842848 10.803183  10.91508
Wolf 359                     HPM-BD  164.1201     7.0145  14.15744 12.329529   9.95459  8.900223
HD 114762B                   HPM-BD  198.0827    17.5179 14.493727 14.225083 14.173457 14.150589
GJ 504 B                     HPM-BD  199.1938     9.4242  5.357727 4.9815445  4.879856 4.8766212

@schlafly: How would you like me to proceed? I can certainly use the override ledgers to "turn off" these four targets. But, maybe we want to check for slightly fainter sources too? For instance, it might be convenient if @rongpu ran his script to something like, say ~16th magnitude and then I cross-checked to see if any of those "fainter brighter" sources are scheduled to be observed?

from desisurveyops.

[geordie666]

I overrode the 4 problematic objects in the ledgers so I'm closing this issue.