search

desihub / desisurvey

Code for desi survey planning and implementation
BSD 3-Clause "New" or "Revised" License
2 stars 7 forks source link

schedule.py should allow non-DESI tiles #82

Closed moustakas closed 3 years ago

moustakas commented 6 years ago

desisurvey.schedule assumes that all tiles have IN_DESI==1 (see here) but for Survey Validation mock-ups (and perhaps Survey Validation itself) it would be convenient if there was an option of using non-DESI tiles / pointings.

sbailey commented 6 years ago

The tiles file to use is specified in the desisurvey config.yaml file, which has a default of py/desisurvey/data/config.yaml, but can be specified via the --config-file option to surveyplan and surveyinit. You could create an sv-tiles.fits file with your custom tiles using IN_DESI=1 for all those tiles, and use a custom desisurvey config.yaml to point to that custom tiles file. If that file is in $DESIMODEL/data/footprint/ then you don't have to specify the path, otherwise (I think) you can put it anywhere if you include the full path in the desisurvey config.yaml file.

i.e. is the real requirement to be able to use IN_DESI=0 tiles in desi-tiles.fits, or rather is the requirement to be able to use arbitrary tiles files? I think the latter is more flexible and already supported (albeit via config file alternations rather than command line options). Does that provide the functionality that you need? (and if not, why not?)

moustakas commented 6 years ago

I understood all your comments, and indeed I'm using the --config-file option to surveyinit, surveysim, and surveyplan. Let me rephrase as a two-part question:

  1. Are the SV tiles / pointings going to be a part of the nominal $DESIMODEL/data/footprint/desi-tiles.fits file? My understanding was that -- eventually (but before the start of SV itself) -- they would be.
  2. If so, will those tiles have IN_DESI=1 or IN_DESI=0? If the former, then desisurvey.schedule will work as-is; if not, then we need the option of simulating observations of "non-DESI" tiles (assuming it will still be useful to do survey simulations, even when we're on-sky).
sbailey commented 6 years ago

For now I propose that we keep SV tiles out of desi-tiles.fits (i.e. a separate file) and use IN_DESI=1 so that we can point the config files at them and run with it. i.e. "IN_DESI=1" becomes a statement about footprint, not about main-survey vs. other programs.

Previously I had thought that we would then merge those tiles into desi-tiles.fits under a different PROGRAM name, but this thread highlights that that could be problematic if we retain IN_DESI=1 since we don't want the main survey to try scheduling them. Eventually survey* code could have an option for which PROGRAM values to consider, so that they could use the separate or merged tiles files.

dkirkby commented 5 years ago

I think we have converged on a workable solution. Specifically, SV will have its own tiles file satisfying:

The SV tiles will be specified at run time using the config tiles_tile option.

Any objections to closing this now?

schlafly commented 3 years ago

Closing this as we are now through SV.