Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discard 18<G<19 STD_FAINT as std for Main BRIGHT tiles #411

Open
araichoor opened this issue Sep 25, 2021 · 4 comments
Open

Discard 18<G<19 STD_FAINT as std for Main BRIGHT tiles #411

araichoor opened this issue Sep 25, 2021 · 4 comments
Assignees

Comments

@araichoor
Copy link
Contributor

The current behavior is to consider at the same level STD_BRIGHT (16<G<18) and STD_FAINT (16<G<19) targets for Main BRIGHT and DARK tiles:

def default_main_stdmask():
"""Returns default mask of bits for standards in main survey.
"""
stdmask = 0
stdmask |= desi_mask["STD_FAINT"].mask
stdmask |= desi_mask["STD_WD"].mask
stdmask |= desi_mask["STD_BRIGHT"].mask
return stdmask

Quoting from @djschlegel :
The STD_BRIGHT,STD_FAINT behavior on the dark tiles in correct. Most standards are labeled as both. On the bright tiles, it appears we’re getting an identical distribution of standard stars — spanning r=[16,19] — which is 1 mag fainter than they should be. So… it appears the STD_FAINT-only stars at r=[18,19] are getting selected for the bright tiles, which was not the intention.

@araichoor
Copy link
Contributor Author

Copying here comment made on #410 by @schlafly:

"For the STD_BRIGHT vs STD_FAINT thing, I haven't fully understood if we're doing what we want. My sense is that we'd rather have brighter standards than fainter standards always. If such a change were made I don't think we'd want to get rid of STD_FAINT for BRIGHT; they're just a fall back if not enough standards are available.

In practice we're taking both with no priorities, but it's not obvious to me that we wouldn't like the faint ones on BRIGHT tiles if no bright ones were available."

@araichoor
Copy link
Contributor Author

Thanks for that input.
As you say, I think fiberassign does not know about priorities for the standards, those are just dealt with as a single set for the assignment.
So the options would be to either keep things as they are or remove the 18<G<19 STD_FAINT for the bright tiles (and backup also?).

What I could do:

  • first implement discarding STD_WD in the std counting;
  • then run for a set of bright tiles (100? or even one whole pass?) the fiber assignment with the current scheme, and with discarding the 18<G<19 STD_FAINT ones.
  • compare the two results.
    Would that make sense?

@djschlegel
Copy link

That would be great. If keeping only STD_BRIGHT delivers enough standards on all tile+petals, then we have a simple solution of just dropping STD_FAINT on the bright-time tiles. Otherwise, we're in a situation where the logic would need to be somewhat more complex since there are already priority considerations on the targets that get bumped. I suppose we would have to run through the loop of assignment of standard stars twice: first for STD_BRIGHT, then again for STD_FAINT.

@araichoor
Copy link
Contributor Author

Ok, so here is a report of that small exercise; happy to discuss that tomorrow.

Foreword:

  • STD_FAINT are 16 < G < 19;
  • STD_BRIGHT are a subsample of STD_FAINT, with 16 < G < 18;
  • In the main/bright catalogs, STD_FAINT-only all also are MWS_MAIN_BLUE; MWS_MAIN_BLUE has PRIORITY=1500, NUMOBS=2.

Method:
I did run for the 1427 bright pass=0, in_desi, tiles the fiber assignment, with rundate=2021-10-02T00:00:00+00:00.
Note that, as I m running with MTL, fiberassign will account for the MTL status of the already observed targets.
I used the code from #415, which discards the STD_WD from the standard counting.
I made two runs:

  • 16g19: "regular" one, with considering as standard STD_BRIGHT or STD_FAINT;
  • 16g18: "test" one, where I only consider STD_BRIGHT for standard (i.e. remove the 18<G<19 STD_FAINT).
    Files are here: /global/cscratch1/sd/raichoor/stdfaint/.
    If useful, I generated two "summary" files, with listing for each TILEID-PETAL the number of assigned STD_WD, STD_BRIGHT, STD_FAINT, BGS_BRIGHT, BGS_FAINT, MWS_BROAD, MWS_NEARBY, MWS_MAIN_BLUE: /global/cscratch1/sd/raichoor/stdfaint/stats-{16g18,16g19}.fits.

Results:
As expected, removing the 18<G<19 STD_FAINT from the standard counting boosts the number of assigned STD_BRIGHT from ~5 to ~10.
Here is a comparison plot (per TILEID-PETAL) for the assigned STD_BRIGHT:
tmp-std_bright
Though, there are 10% (resp. ~2%) of the TILEID-PETAL which have less than 10 (resp. 5) assigned STD_BRIGHT; their sky distribution:
tmp-sky-stdbright
Those regions in green are consistent with a lower density of STD_BRIGHT, e.g. here:
https://data.desi.lbl.gov/desi/users/adamyers/1.1.1/main/desitargetQA-dr9-bright-1.1.1/skymap-STD_BRIGHT.png

If one considers the assigned STD_FAINT, i.e. what will be used by the spectroscopic pipeline, the fraction of TILEID-PETAL with less than 10 assigned STD_FAINT drops to ~6% (covering the inner regions of the green dots above):
tmp-std_faint
However, I think that we should consider this last result carefully: because I think that those assigned STD_FAINT-only targets are getting a fiber because of their MWS_MAIN_BLUE status, as they have lost their "standard" status, and hence follow the rules of PRIORITY and NUMOBS; so it could be more like ~10% when several passes are already done.

In the current scheme (STD_BRIGHT, STD_FAINT as standards), 1% only of TILEID-PETAL have STD_FAINT < 10.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants