In preparation for the JTM session on the scheduler requirements document the latest version is attached. To help make the session as efficient as possible please use the comments on this topic to indicate specific requirements that you would like to have discussed during the session.
Attached Scheduler Requirements v4.2.0.pdf (1.5 MB)
2.1.1—Why pause if the telemetry goes down? Why not alert but keep processing the observing queue?
2.1.6.4.2—The numbers of 30 arc minutes resolution and 0.1 mag rms seem unrealistic (and unnecessary?) for sky brightness monitoring.
Same for transparency. No way you can get 0.05 mag rms from an all-sky camera on 30’ scale.
Current all-sky camera has 5’ pixels. So in every 6x6 pixel block, you need enough stars to measure transparency with 0.05 mag precision? We don’t have that many stars, and they are not at very high SNR. Most close to 0.1-0.2 mag errors. Those errors might come down with a better photometry pipeline, but not much.
2.3.8: The cost function makes it hard to predict what’s coming next. I think we’ll want a real observing queue: DM will want it, aux telescope will want it, follow-up observatories will want it.
2.3.14: I think we need dithering now. We’re probably going to want different dithering strategies for the DD fields compared to the rest of the survey, so we need the science groups looking at that soon.
General question:
How are we going to use this to schedule the commissioning camera?
2.1.6.2 “The latency of forecasts should be limited by the forecast data sources, with typical cadence of once per 30 or 60 minutes.” What is the rationale for 30-60 mins (is this based on historical data). Is 30-60 mins in conflict with the definition of “normal” for the rest of the section
2.1.6.2.3, 2.1.6.2.4, 2.1.6.2.6 (e.g. Precipitable Water Vapor) are these data available based on current instrumentation
2.1.6.3.3 “Specification: The external wind speed, direction, RMS and peak values, and the dome interior
wind speed, shall be available to the Scheduler. Input latency – urgent.” what do we mean by urgent
2.1.6.4.2 All-sky Sky brightness. Same comment as above (0.1 mag rms does not seem feasible given current models so we need to understand want drives this requirement). If we normalize the sky model to camera data what is the rms
2.1.6.4.3 All-sky Transparency. Same as above 0.05 mag rms and 30 arcmin resolution needs justifying as it doesnt seem possible with current systems
2.2.4 Survey progress Add effective exposure time to the metric
2.3.4.3 The rank equations should be listed as an “example” of a simplified version
2.5.2 we say transfer of algorithms is required but not transfer of code (between opsim and the scheduler). I can see a reason that you might want to fall back to the algorithm transfer but I think we should have as the primary requirement that the code be transferable (not clear what an algorithm module is)
All sky transparency updates - @yoachim will provide realistic all-sky values.
Need to update ICD with DM (LSE-72?) - Sandrine
Followup with DM about 20s advance notice - @connolly
Followup with the community about advance notice required?
Discuss how much can the operator intervene in the scheduler? Should this intervention be through OCS directly? Or do we add interface to scheduler?