BAD_SKY avoid known bright Gaia targets

[sbailey]

BAD_SKY locations should avoid bright Gaia targets to avoid accidentally saturating the CCD. Exact cuts could be magnitude dependent but shouldn't be nearly as large as our brightstar masking for science targets (which cut out large amounts of area). As a placeholder, let's do something like:

Avoid gaia_g_mag<12 stars by at least 5 arcsec.

i.e. get at least a few PSF widths off of the peak, and then further tune based upon commissioning studies of how bright we can tolerate.

[geordie666]

For fear that this is a solution looking for a problem, can somebody track down a case where:

1. This occurs. I believe that the imaging surveys should be seeding all Gaia/Tycho stars. So, that there are Gaia/Tycho stars without a blob is a mystery to me. Perhaps this occurs in bricks that failed during processing or for stars that cross brick boundaries?

2. The proposed solution would provide a BAD_SKY location that did not leave a hole in which no fiber could be allocated. As (if?) we need to allocate all of the fibers, I suspect that cutting 10 arcsec diameter holes across the survey footprint would be problematic for fiber allocation.

[geordie666]

Thinking about this some more, perhaps this is really a request to set the BRIGHT_OBJECT and/or IN_BRIGHT_OBJECT bits for sky locations, and then, rather than creating a shifted BAD_SKY location, simply, instead, acknowledging that there's nothing to be observed at such BRIGHT_OBJECT and/or IN_BRIGHT_OBJECT locations?

[sbailey]

Fair enough to do the check that this is a real-world problem before spending much coding time on it. Let's wait until the full DR8 is out and the final proposed tiling footprint is ready.

The motivation is for cases where we are hanging off the edge of the footprint or otherwise in regions that don't have imaging data, and thus have a regular grid of BAD_SKY locations that could randomly land on something bright, and not wanting to unnecessarily saturate the CCDs. This is somewhat different than (IN_)BRIGHT_OBJECT masking.

Tiles at low galactic latitude that only partially overlap the imaging footprint are most likely to have this problem. Having secondary not-too-bright Gaia targets in those regions is an even better solution than just moving BAD_SKY areound.

[geordie666]

@sbailey: This has mostly been addressed in #625. I see two outstanding issues:

1. I still haven't come up with a good way of determining the correct radius at which to avoid bright stars for sky locations. I've implemented your suggestion (Avoid gaia_g_mag<12 stars by at least 5 arcsec) but there could be a more optimal choice. There is now a straightforward function (desitarget.brighmask.radii()) that can be simply altered to implement a new radius-magnitude relationship.

2. There are many stars in our footprint with proper motions greater than a few arcseconds. Over the course of a 5-year survey, such stars will move beyond the limits of a mask that has a 5 arcsecond radius. I see two solutions. One would be to pre-define a mask with "trails" that cover these stars over a 5-6 year period. This would remove usable area, though. The other solution (which I think would be my preferred choice), would be to run new sky files on a cadence of every 3 months or so.

I'll leave this issue open until 1. and 2. have been addressed. But, feel free to make suggestions and I can adopt your choices in a follow-up PR.

[sbailey]

I think (1) could be studied by using the existing dither data + Eddie's analysis of where the stars actually were to understand the contamination of a fiber N arcseconds away from a magnitude M star. But we need to find someone to do the analysis. If the dither data isn't sufficient, we need to clearly define what data are needed so that they can be obtained during recommissioning and be prepared for a rapid analysis.

For (2), updating the skies file every 3 months seems overkill, but straightforward without requiring any code changes right now. Let's let this one simmer a bit while the basic fiberassign strategy gets sorted out; our choice might be different if we are running fiberassign nightly vs. every 2 weeks or more.

[geordie666]

I did talk to @schlafly about (1) a little but offline, and he suggested that the dither data was probably insufficient for this purpose. @schlafly recommended convolving the GFA profile with possible seeing values instead. @schlafly also noted that @julienguy had basically shown that sky subtraction is good to ~2%, so suggested setting the radius as that where the flux from a star of a given magnitude is 2% of the brightness of the sky. I'm putting words in @schlafly's mouth, here (!) but I may as well record his helpful suggestions for posterity.

[schlafly]

For what it's worth, it's not really that I think the dither data is insufficient. It's more that the dither data says that a Moffat profile with beta = 3.5 is a good fit to the PSF, which is also what Aaron finds in his GFA analysis. And I don't think there's any other relevant information to be had from the dither analysis.

IIRC Rongpu finds that very far from the star (tens of FWHM) that a power law index for the flux profile more like -3 is appropriate, at least in the imaging surveys. For extrapolating very far from the stars, it might be worth looking at GFA images of very bright stars. For that purpose the dither data would indeed be insufficient.

[geordie666]

@rongpu: Is this something you could look at? Namely, within the radius of a DESI sky fiber, at what distance from a source will the flux drop to ~2% of the sky background? The ultimate goal would be a radius-magnitude relationship to force "blank" sky locations to have to be a certain distance from a bright star.

Given your expertise in studying the flux profile of the PSF in the imaging surveys, it seems like something you might be set up to look at. This isn't urgent, so I'm not asking you to drop everything. But, this would be useful to have on the timescale of a few months.

[rongpu]

Note that I had looked into this in [desi-data 5498], where I did see in some of the observed sky fibers stellar flux from nearby bright stars. We can (should?) still implement some bright star mask for the sky fibers, although I'm not sure if it should be implemented in desitarget or in desispec.

[geordie666]

Thanks, Rongpu. I think it's likely too late to implement this in desitarget, now. There's active work in fiberassign to assign sky fibers "on-the-fly" to optimize assignments, so that might be the correct place to shift this discussion. We can certainly revisit this issue if people decide we need to update the input list of sky catalogs from desitarget.