basic bright object mask for mocks about desitarget

[forero]

This comes together with an update in mtl to set observing priority to zero for those targets with bright object bits set to IN_BRIGHT_OBJECT or NEAR_BRIGHT_OBJECT.

[apcooper]

The bright objects may not all be in the mocks in the first place. To keep the file size down I didn't include anything brighter than r=15 in the MWS mocks, I don't know about BGS.

This could also be taken from the real sky, e.g. Gaia?

[geordie666]

Given that this doesn't have to be precisely correct, just useful, I think we can choose r<X for the bright star mask, where X is chosen to return MWS stars at the correct density. So, the fact that there's a cut at r<15 is probably not an issue.

[sbailey]

We don't want to inadvertently mask the MWS mock targets, so I don't think we can just use a fake magnitude cutoff to get the right density. Making a mask from GAIA would be fine, albeit possibly a bit tedious. A fake catalog at the right mean density and some sort of galactic latitude variation would be fine too for the purposes of the December meeting.

[geordie666]

@sbailey @forero: I made some progress on the bright star mask over the weekend. If you checkout the "brightstar" branch on desitarget: https://github.com/desihub/desitarget/tree/brightstar then there are a couple of functions for extracting bright stars (or at least bright objects) from the sweeps and then mapping the distribution of stars as a function of magnitude.

The schema works something like this. First, extract all of the objects in the sweeps to a certain depth as follows (unless the kwarg rootdir is passed this defaults to the DR3.1 sweeps):

from desitarget import brightstar as bs
bs.collect_bright_stars('g',12.5,numproc=16,outfilename="brightstars-dr3-glt12.5.fits")

This will make a manageable file of things brighter than g < 12.5 in the sweeps. Parallelized across 16 process this takes about 5 minutes. I already made a couple of these files and put them in my home directory on NERSC, so you can use these to save some time:

brightstars-dr3-glt12.5.fits
brightstars-dr3-zlt12.5.fits

Then, you can generate a dictionary (at 1 degree resolution) of the number of bright stars per brick as a function of Galactic (l,b) as follows (again, this defaults to using information from the DR3 brick file in the absence of the rootdir kwarg):

ldict, bdict = bs.model_bright_stars('g',"~/brightstars-dr3-glt12.5.fits")

The ldict contains 360 values for each magnitude key (one for each of 0->1, 1->2, 2->3 etc.)
The bdict contains 180 values for each magnitude key (one for each of -90->-89, -89->-88, -88->-87 etc.)
The dictionary values, here, are the number of bright stars (at the key magnitude) expected in the brick.

So, in theory, this gives @forero a function that for real values of l and b can be used to assign an appropriate number of bright stars of a given magnitude per brick.

The last step is the exclusion radius. What function should we use to assign a mock source IN_BRIGHT_OBJECT at a certain distance from an l,b position? I suggest using the Tycho exclusion radius from Anderson et al. (http://adsabs.harvard.edu/abs/2012MNRAS.427.3435A), which is:

Radius = (0.0802BB) - (1.860*B) + 11.625 arcsin
Valid in the range 6 < B < 11.5 (I would not mask anything outside of that range)

I'd just swap the B (which is the B magnitude), here, for our z.

I think that's all the information people on the mocks side will need to have a stab at this. Unfortunately, I'm traveling for Thanksgiving this week...I won't be on the call on Tuesday and I'll only be in intermittent email contact through Tuesday (and not at all for the rest of the week after that).

[moustakas]

@geordie666 Now that #153 has been merged is it reasonable to close this issue?

[geordie666]

I think we still need to make things work in MTL before we close this...

[moustakas]

I think we still need to make things work in MTL before we close this...

@geordie666 how about now?

[geordie666]

@moustakas: I believe this works in MTL now, but are you actually setting the masking bits in the mocks? These bits:

https://github.com/desihub/desitarget/blob/master/py/desitarget/data/targetmask.yaml#L50-L52

If so, then, yes, I think we can close this.

[geordie666]

@moustakas, @forero: It's possible that we may never get around to providing a bright object mask for the mocks. In particular, we now mask the actual targets on MASKBITS rather than using the mask-making functionality in desitarget itself.

But, if this issue becomes relevant again, note that there are now masks for bright stars at NERSC in /global/cfs/cdirs/desi/target/masks/. The masks in these directories can be read using the desitarget.io.read_targets_in_hp() functionality, e.g.:

from desitarget.io import read_targets_in_hp
nside = 2
pixlist = [12, 14, 37]
hpdirname = "/global/cfs/cdirs/desi/target/masks/0.40.0.dev4055/maglim-12.0-epoch-2023.0/" 
masks = read_targets_in_hp(hpdirname, nside, pixlist)        

The masking itself can be achieved using desitarget.brightmask.mask_targets()

[moustakas]

Thanks, @geordie666. I'm OK with closing this ticket. I personally think the right path forward is to sample from the imaging files, as @michaelJwilson has prototyped in #620 (which was spun off from #608). This empirical approach will not only capture the diversity of the bright-star masks, but also other masks like large galaxies, globular clusters, and so forth.

If anyone else feels strongly please feel free to reopen this ticket (or to start a new, more focused one).