schedule.py should allow non-DESI tiles about desisurvey

[sbailey]

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]

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]

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]

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

• IN_DESI = 1 for all tiles to schedule.
• all tiles assigned to program = DARK / GRAY / BRIGHT.
• arbitrary pass numbers (but all tiles in a pass must the same program).

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

Any objections to closing this now?

[schlafly]

Closing this as we are now through SV.