1 / 25

ORAC Scheduler

ORAC Scheduler. Joint Astronomy Centre March 1999. Goals and Scope. Create optimum short (“nightly”) and long term (semester) schedules for UKIRT To be available to UKIRT Staff, visiting observers and the UKIRT Time Allocation Group. Astronomer at home. Database of Observations.

keefe-allen
Download Presentation

ORAC Scheduler

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ORAC Scheduler Joint Astronomy Centre March 1999

  2. Goals and Scope • Create optimum short (“nightly”) and long term (semester) schedules for UKIRT • To be available to UKIRT Staff, visiting observers and the UKIRT Time Allocation Group

  3. Astronomer at home Database of Observations Database of Plans Instrument Telescope ORAC in Use ORAC-OT Prepares the observations ORAC-ST Plan the Observing ORAC-DR Reduce the data Selects next observation ORAC-OCS Astronomical data acquired Execute the Observation ORAC-OCS Astronomer at home with data Coordinates and controls

  4. UKIRT Scheduler - Requirements Introduction • Tools to aid visiting observers to plan and carry out their observations efficiently using queues. • Tools to aid UKIRT staff handle flexibly scheduled programmes • programmes that require better than average conditions - seeing, 20mm transparency, etc. • priority of programmes • Tools to aid the allocation and long term scheduling process for flexible and “classical” programmes / blocks of time • e.g . Engineering nights, wide-field survey nights • Detailed plans for flexible scheduling at UKIRT still tbd in some areas

  5. General Scenario • At PATT meetings some Strategic Scheduler functions are available to assist the allocation process • All observers prepare Programs and Observations using the ORAC-OT (UKIRT version of Gemini OT) and submit to a database at UKIRT. • Programs in database are updated with “completion information” by appropriate modules in OCS - Chooser or people (DBMS) • Observation Scheduler uses the relevant information in the Programs together with current or predicted observing conditions to draw up a time ordered queue of observations for a night / a few nights. Can be used by remote users in advance of their run or at UKIRT. • Checks for problems, allows user to change plan creation parameters • When in use at the telescope Observation Scheduler can execute the plan if requested to do so.

  6. Preparation of Observing Plans • Use a series of hierarchical criteria to determine which observations to put into a time ordered queue for a given night. • Observing Plan • Allow user to narrow the search by pre-selection of programs/types of program, and exclusion of programs/observations • Allow user to change weighting of criteria • Identify and check adequacy of calibrations • Schedule grouped and chained observations together/sequentially • Can generate plan for a few nights using same criteria weights and predicted conditions. • Plan and the parameters used to create it to be stored - database or local disk.

  7. Queue Scheduled Observing • Able to read and use real conditions to update the plan • User may over-ride any of the conditions • Scheduler will pass to the Chooser the name of the next Observation to carry out. • Status of progress through the queue available at all times • Scheduler monitors conditions and time and warns of changes / getting behind. • User may recalculate plan at any time e.g. in response to changed conditions, to create a new “current plan”. • Chooser may be set back to “manual” at any time

  8. Strategic, longer term • Observation Scheduler to calculate plans for a few consecutive nights • using same conditions and parameter weights • Observation Scheduler able to calculate night by night plans for longer periods on assumption that “scheduled observations” are completed • Strategic Scheduler use similar hierarchical rules to calculate “Semester Plan” - timescales ~ months • classical programmes, engineering nights, observing plans, blocks of flexible nights • level of detail ~ 1 night • Strategic Scheduler can track “loading” of semester with classical and flexible allocations - based on “phase 1” information • Strategic Scheduler must allow some events to be on fixed nights

  9. Other • User can only schedules Programs and Observations s/he is authorised to use

  10. Major Functions • Construct an optimum schedule of Observations for a night’s observing • Construct an optimum schedule of Science Programs or Observing Plans for a longer period (weeks, months, a semester) • To notify the user of any problems in the Schedule • To allow the user to modify the algorithms used to construct the schedules via the use of weighted parameters • To provide , on request, the next observation to be executed

  11. Definitions • Observation Definition: A definition of an Observation that is useable by the ORAC-OCS. Will typically contain: • Description of telescope target(s) and positions • Description of Instrument configuration • Information about Scheduling • A sequence of frames to acquire • Science Program: A hierarchical description of the Observations making up a complete programme. Describes many Observation Definitions. Created by the Observing Tool.

  12. Definitions • Observing Plan: A list of Observation Definitions that makes up a Plan for a night’s observing. Created by the Scheduling Tool. • Semester Plan: A list of Observing Plans or Science Programs that makes up a long-term Schedule for the telescope. Created by the Scheduling Tool.

  13. Context • Interacts with the User (Staff Astronomer) who may modify parameter values and weights and request plans • Interacts(at the telescope) with the environmental system to monitor current conditions • Interacts with the Observation Database to: • Get the results of queries regarding Science Programs • Store and maintain Observing Plans • Store and maintain Semester Plans • Interacts with the ORAC-OCS to provide the next observation to execute

  14. Basic Design I The following modules provide the major building blocks of the Scheduling Tool: • The GUI - Interacts with the user to provide the interface to all the functionality • Information Handler - handles weights and parameter values, both input by the user and taken from the environmental monitoring system • Query Handler - deals with queries on the Observation Database, interface to the ODB Management System

  15. Basic Design II • Sanity Checker - Checks that Programs and Plans make sense, e.g. calibration frames are there, possibly standards can be identified. • Program Handler - Handles Programs and Plans • Queue Handler - Handles current Observing Plan and requests for Observations. • Scheduling Engine - Actually calculates the schedules

  16. UKIRT Scheduling Engine • Don’t invent another one if possible • Reuse an engine if we can, developing just an interface to it • Reimplement a proven algorithm Thus the intention will be to examine current systems, judge how well they meet UKIRT’s requirements, and how difficult they might be to integrate into the ORAC system. A decision on the direction will be the result of this process

  17. Existing Schedulers I • SPIKE: HST Scheduler • Comprehensive, powerful, proven. • Large, probably overkill, written in lisp (CLOS) • APTs and ATIS: Various available. • Proven • Dispatch rather than optimum; usually suitable for single instrument telescopes; ATIS not completely compatible • NASA-AMES UKIRT Prototype: • Extension of ATIS dispatch scheduling? • Has been used at UKIRT with some satisfaction. C & Perl.

  18. Existing Schedulers II • Gemini: • Algorithm looks appropriate, perhaps a little overkill • To be in Java, but doesn’t exist • ESO VLT: • Uses SPIKE. ESO-modified algorithms, tcl/TK interface (to be Java?) • If SPIKE is choice then should examine • Liverpool Telescope: • Dispatch scheduler, could be extended to optimum? • Algorithm looks appropriate. Java. Some code in prototyping

  19. Observation Database: Introduction • Database itself and the tools required to maintain and use the database • Store Science Programs containing Observation Definitions • Store Observing Plans and Semester plans • Allow authenticated queries to be performed on the documents in the database • May need to be extended to include proposals, but this is not currently included

  20. Requirements • Users may submit and retrieve Programs (through OT) • Accessible to all UKIRT staff, but authenticated - users only see their own Programs • UKIRT staff control which Programs are “active” - available for use • Programs may be added at any time • Completion status of Observation Definitions to be added by the Chooser, or changed by UKIRT staff • User interface to provide graphical/statistical information on completion status of Programs • Old Programs to be kept in database • TAG chairman to have access to completion status for flexibly scheduled Programs

  21. Proposed Concept • Use a commercial database management system • Divide database into areas for : • Pre-active, Active, Retired Science Programs; Observing Plans; Semester Plans • Programs in Active area are available to Chooser, and Scheduling Tool - for observing / creation of Observing Plans and Semester Plans • Programs in Active area are updated with status information, and may be interrogated to track progress • Tools will be needed to : • Allow UKIRT staff to browse database and modify areas • to provide reports on the various areas • to allow Programs and Plans to be moved between areas • possibly a server to support access / queries

  22. Choice of commercial system • Relational Database • Advantages : • Better known / widespread commercial use • Already supported at the JAC (Sybase) • Disadvantages : • Science Programs, Observing and Semester Plans are Objects - not naturally suited to storing in tables: • Store classes as tables - but likely to result in complex queries • Extract all Observation Definitions and store as separate entities, but problematic for relating Observations to their Programs and for reconstructing Programs for export.

  23. Choice of commercial system • Object Oriented Database : • Advantages : • Fits naturally into OO paradigm used in the tools • Provides persistent store for the objects • Disadvantages : • Not yet commercially “big” • Standard query language still in development (but nearly there) • JAC has no experience of them

  24. Choice Issues • Interface issues suggest OO system would be best approach. Should examine ODMG work and implementations. • Pragmatic issues may over-ride this: • post delivery support • JAC has already invested in Sybase • UKIRT and JCMT may want to use same system • Need detailed consultation with JAC and technical evaluation of some specific commercial systems. • Plans in astronomy are split: • Gemini , LT plan to use OO • ESO VLT use Sybase and store some Objects using it

More Related