The TJO – OAdM robotic observatory: the scheduler Josep Colomé*a, Kevin Casteelsa, Ignasi Ribasa, Xavier Franciscoa a Institut de Ciències de l’Espai (IEEC – CSIC) ABSTRACT The Joan Oró Telescope at the Montsec Astronomical Observatory (TJO – OAdM) is a small-class observatory working under completely unattended control, due to the isolation of the site. Robotic operation is mandatory for its routine use. The level of robotization of an observatory is given by its reliability in responding to environment changes and by the required human interaction due to possible alarms. These two points establish a level of human attendance to ensure low risk at any time. But there is another key point when deciding how the system performs as a robot: the capability to adapt the scheduled observation to actual conditions. The scheduler represents a fundamental element to fully achieve an intelligent response at any time. Its main task is the mid- and short-term time optimization and it has a direct effect on the scientific return achieved by the observatory. We present a description of the scheduler developed for the TJO – OAdM, which is separated in two parts. Firstly, a pre-scheduler that makes a temporary selection of objects from the available projects according to their possibility of observation. This process is carried out before the beginning of the night following different selection criteria. Secondly, a dynamic scheduler that is executed any time a target observation is complete and a new one must be scheduled. The latter enables the selection of the best target in real time according to actual environment conditions and the set of priorities. Keywords: robotic observatory, telescope control system, unattended operation, software, scheduler 1. INTRODUCTION The TJO – OAdM is a small-class observatory working under completely unattended control. It is located at an altitude of 1570 m in the Montsec mountain range, 50 km south of the central Pyrenees and 50 km north of the city of Lleida (Catalonia, Spain). It is endowed with a 0.8 m telescope, a classical 6.15 m dome, and a 2k × 2k back illuminated CCD camera. It is also equipped with a set of sensors and support devices to continuously monitor the environment and the system response. All this instrumentation is fully automated. 1 The observatory was designed to achieve a high level of robotic control. The latter is given by a reliable response to environment changes and by low human interaction to control any routine process or possible alarms. These two points establish the level of human attendance to ensure low risk at any time. Human attendance diminishes as robotization level increases, and that includes all the processes involved in observatory operations. The logical and physical architecture was designed and implemented to provide the capability of an automatic response to any triggered event. For a detailed description of the architecture and the other important packages involved in the system control, we refer the reader to the referenced documents1, 2. The scheduler represents a fundamental element to fully achieve an intelligent response at any time. Its main task is the mid- and short-term time optimization and it has a direct effect on the scientific return achieved by the observatory. In the following sections we present a description of the scheduler developed for the TJO – OAdM as well as the most important related packages. 2. GENERAL SCHEDULER DESIGN Scheduling is a task allocation issue, where the execution is conditioned by one or more constraints. Research in this field began in the mid-50s and has been developed in multiple areas3 given the horizontal nature of the applications. The classic problem of scheduling is the job-shop problem (JSP), where N ideal tasks must be assigned to M identical resources (machines, processors, etc.), while minimizing the total execution time. * [email protected] Studies on dynamic scheduling have been done in the recent years4. This case computes the best planning process while introducing new tasks or new constraints and / or a change in the status of the initial constraints. In most cases there is no single best approach to solve the planning system and, therefore, various mathematical algorithms should be considered5. Astronomical observations require specific conditions for each particular case, such as the instrument to use, the sky visibility or brightness conditions, the best time for the observation, etc. All this information, together with the scientific objectives, is included in the proposals that astronomers submit to the observatories, for observation time requesting. A priority is assigned to the approved proposals and this is used to select one of them in case other proposals could overlap in time. Observations of the proposals must be scheduled for execution under the specified conditions, once accepted and prioritized. This programming is carried out by the scheduler6, 7, this being a person skilled in the sorting criteria to apply, an automatic system based on the use of computer algorithms or a combination of both. Proposal scheduling for astronomical observations is an example of multi-objective problem, since different factors must be optimized: to maximize the scientific return, minimize the time between executions, tune the exposure time for each observation in terms of environmental conditions, etc. The solution to this problem is of inherent computational complexity: the number of solutions grows exponentially with the number of targets and there is no algorithm that can avoid the implicit or explicit enumeration of all solutions. Best scheduling of astronomical observations is included within the class of problems NP-hard. There are many mathematical tools to solve the scheduling issue: from simple heuristics to more complex genetic algorithms or neural networks. A.I.Gómez et al.8 published a good description of the problem and possible solutions. A different approach to solving the problem is given by T.Granzer9, who analyzes various solutions to use in robotic observatories. The advantages of using a dispatcher algorithm, based on the calculation of the merit function for each observation, are presented in comparison with queue or optimal scheduling. Dispatch scheduling is the one chosen to be used at the TJO – OAdM observatory for the short-term scheduling needs, as described in section 6. 2.1 Scheduler features The scheduler developed for the TJO – OAdM observatory has the following general features: Scheduling cycle: long, mid and short term Three scheduling levels are considered at the TJO – OAdM: long, mid and short term, the latter being responsible for the dynamic response of the system. The problem to be solved by the scheduler can consist of thousands of observations per cycle, although not all objects are visible at all times. The long-term planning defines the engineering tasks (maintenance and calibration) and the selection of proposals for the entire cycle (six months), based on factors such as visibility above the horizon or the moon phase, to compile the list of feasible operations to be executed. Oversubscription is permitted for the full cycle in order to ensure the complete use of available time. We plan to develop a long-term scheduler to be executed on simulation mode by the observatory staff and the TAC, although it is currently being performed by an expert user that takes into consideration the TAC approved proposals and the observatory maintenance plan. The mid-term scheduler selects the proposals suitable to be observed on the following night and it also performs an ordered list of observation blocks, using queue scheduling algorithms. The short-term or dynamic scheduler selects the next best candidate to be observed in almost real time. For a short-term planning proposals are divided into blocks of observation (the sum of them complete the entire proposal) to be executed during the actual night. The selection of an observation depends on external factors specified in the submitted proposal, and it is the scheduler who decides the best observation based on immediate factors. Not all observations are executed during the planned cycle as a consequence of using dynamic scheduling. The probability of a project to be carried out depends on its scientific priority, but also the conditions for execution. Such priority may vary over time; it may be greater as the conditions for observation become unfavorable. An extended description of the mid- and short-term scheduling implemented is given in the next sections. Fully integration of the scheduler in the general observatory control system The nominal working flow of the TJO – OAdM control system1,2 implies processes with human intervention (submission of proposals, proposal revision and verification, and data retrieval), and unattended ones. The unattended observation operation includes: observatory startup and power down routines; selection of targets (described in this document); hardware control for telescope, instrumentation and dome; data processing and storage; and, finally, housekeeping, hardware and software application monitoring and control. Several software applications perform most of these instrument and data flow control operations at the observatory. OpenROCS2 is the one that takes the role of the software infrastructure and it also controls all the necessary routines that implement responses to identified events and alarms, as well as all the applications running at the TJO – OAdM observatory. The software applications and OpenROCS compose a software suite designed to reach the complete robotization of the observatory. The scheduler is integrated in this suite and its routines are called every time their action trigger appears, according to the data flow management performed by the OpenROCS software. A particular software application, the proposal management tool, executes the storage in the database of all the proposal constraints regarding the observation pattern definition and the results of the observations acquired (reduction, analysis and quality control results, implemented in the data processing). It was designed and implemented in order to optimize the execution of the scheduler selection algorithms, as can be seen in the following section. Planning modes: manual, automatic and simulation The optimal use of mid- and short-term schedulers is usually obtained when combined with unattended operation. Thus, the sequence of tasks can toggle between observations of various proposals without the prejudice it would represent for the astronomer if he/she was at the observatory. Under unattended control, dynamic schedulers maximize the efficiency as the system response is faster and more standardized, optimizing the use of time of the observatory. Many robotic observatories do not incorporate this feature in the control system and run a static sequence of observations, which is aborted, but not modified, when environmental conditions change or there are errors in the system control. In this scheme, a variable priority policy is not applied and this does not optimize the scientific return of the instrument. Two examples of observatories that do apply dynamic schedulers are the Liverpool Telescope10 and the observatory STELLA9. Mid- and short-term at the TJO – OAdM are also executed automatically and are included in the observation manager module of the OpenROCS software suite. The use of dynamic schedulers opens also the possibility of integrating the observatory into telescope networks, such as the Heterogeneous Telescope Network11, which will be explored in the near future. Simulation mode is also provided to users in order to check the observation patterns of their proposal, to compute the required exposure time and evaluate its feasibility before submitting it to the observatory TAC. Different observation types considered The scheduler accommodates observations with a fixed starting time, as well as monitoring or periodic observations. It also takes into account the observation of unexpected phenomena that can alter the short-term planning. The different observation types considered are listed here: Generic targets are those that can only be described in terms of astronomical characteristics or general location on the sky. Separate targets should be defined and listed if the user plans to acquire observations at several locations within an extended object. A generic target must be specified with its Equatorial coordinates. A Fixed target can be specified by its name and coordinates, according to the catalogued values. Time-Critical or Phase-Critical Observations: proposals may request that TJO – OAdM observations be made at a specific date and time or phase, or within a range of specific dates or phases, when scientifically justified. Some examples of such cases are: astrometric observations, observing specific phases of periodic variable stars, monitoring programs, observations coordinated with observations by another observatory. Special Calibration Observations: data from TJO – OAdM observations are normally provided to the Principal Investigator (PI) after full calibration (raw images and master calibration frames are also supplied in case the PI expresses the need to repeat the process). Baseline calibrations include bias, long exposure darks and flat images taken at the beginning and at the end of the night. A set of standard stars is also observed on those nights in which a target that requires such calibrations is likely to be scheduled. Projects may need to include special calibration observations if the calibration requirements of the project are not addressed by the standard calibration program. A number of bias or dark images can be specified for each observation and they will be taken just before or after the science image. And in case predefined standard stars do not suit the user needs, different targets can be included as a proposal target. Any special calibration observations required must be included in the total request for observing time, and must be justified explicitly. Observing time distribution based on the use of Observation Blocks and Target Groups TJO – OAdM observing time is counted in terms of Observation Blocks (OBs). Each OB contains a series of one or more exposures on a target, using the same or a different filter and following a defined sequence pattern. OBs are grouped into larger units called Target Groups (TGs) that include all the OBs for a specific target according to the number of iterations and the scheduling requirements. A specific target can have several TGs. Finally, a whole project is composed of the sum of TGs for all targets in the proposal. The processes in a target OB contain the following components: telescope pointing; dome pointing; target science exposures; instrument overheads (i.e., the time required to read out the data); special calibration observations, which may be required if the accuracy provided by the standard calibrations is inadequate for the goals of the project, etc. OBs can be executed more than once towards the achievement of planned scientific objectives. 2.2 Block diagram The scheduler package is integrated in the main data flow scheme (see Fig. 1), and needs to interact with several modules in order to give a correct response any time it must compute a new planning. Figure 1. Data flow at the TJO – OAdM Once a user has entered the observation details in the database, through the web-based interface, and the observatory staff has validated the data, the scheduler takes these data into consideration when selecting the targets suitable to be observed during the coming night or when selecting the best target for the next image acquisition. The first process is performed by the mid-term scheduler routine, whereas the second one is done by the short-term or dynamic scheduler. Both mid- and short-term schedulers are described in the following sections. The next step after the target selection is the execution of the observation process, which ends with the image processing routines and the quality control. The latter decides whether the observation must be rescheduled or is deemed complete, and updates the database accordingly. Proposal and observation management, from the proposal submission to the data retrieval to user, including the scheduler routines, compose the optimal set-up to achieve the unattended control optimization. 3. PROPOSAL MANAGEMENT A description of how the system does the proposal management is given here: program preparation, databases, proposal submission, etc. Several concepts used are inspired from other projects with advanced tools for similar purposes12, 13. 3.1 Program preparation The following steps must be taken into account to calculate the resources required: 1. Define the pattern for an OB (instrument setup, number of exposures, exposure times, etc.) to execute on a target 2. Define the number of iterations and the scheduling requirements for each OB 3. Repeat steps 1 and 2 for each target or for the same target if different OBs are required 4. Compute the time required for target acquisitions and instrument overheads 3.2 User interface for proposal submission and data retrieval The only tool for the users to interact with the observatory is via a high-level software interface providing ways to access the database. A web-based proposal management tool through which the users can propose their science programs (phase 1), prepare the observations if the program is approved (phase 2) and retrieve their data products upon successful observation (phase 3) was designed and partially implemented. A short description is given below. 3.2.1 Users and calls for proposals Scientists from research institutions around the world can submit a proposal to the TJO – OAdM's Time Allocation Committee (TAC). There are biannual calls for proposals, which go out in March and September, four months before the start of the semester in which the observations are to be taken. The TJO – OAdM semester dates are: 1st February to 31st July (semester A) and 1st August to 31st January (semester B). 3.2.2 Phases for new proposal submission A new proposal is submitted in two phases. In Phase 1, the proposers submit a scientific justification and observation summary for peer review. The Telescope Allocation Committee (TAC) recommends a list of programs with associated priorities to the TJO – OAdM observatory for preliminary approval and implementation. In Phase 2, investigators with approved Phase 1 proposals must provide complete details of the observations in their proposed observing program. This allows the TJO – OAdM to conduct a technical feasibility review, and to schedule and obtain the actual observations. Programs are not approved fully until after submission of an acceptable Phase 2 program. After submitting the proposal, the PI receives the automatically created proposal code and password. Using them, he/she can access a specific web page which includes the information sent at this first phase and the submission status. The proposer can use this page to track the evolution of the proposal (TAC considerations, Phase 2 data, etc.) and to access the data and the images obtained. All this information is stored in the observatory database. This proposal web page is accessed through the Status and Results section of the observatory web page. Diagrams of the phase 1 and 2 roadmap submissions are shown in figures 2 and 3. Phase1 A high level step-by-step guide to the Phase 1 proposal is explained below: 1. Review the observatory constraints to determine if your observations are feasible (pointing constraints, bright object constraints, etc.). 2. Determine the required observing conditions to obtain the expected data precision. Sky brightness, seeing and photometric conditions must be specified. 3. Determine the observation type. 4. Determine any observation constraints that could impact scheduling: flexible or observations that can be carried out at any time during the semester when the conditions are appropriate; monitoring or observations of an object required at a regular interval; fixed or observations only to be carried out at a specified time; and, ephemeris or observation of a target at a particular phase of its periodic cycle. 5. Determine the required exposure times to complete the observations for the proposal, taking into account the following aspects: pointing and tracking performance of the TJO – OAdM; time required calculation, using the TJO - OAdM exposure time calculator to determine the exposure time of each target and adding the system overheads (acquisition time, time taken to slew the telescope and dome on target; readout time; time to take special calibration images). 6. Fill in the proposal information using the web page interface: general information, investigators, source data (targets), observing conditions and observing time request. 7. Submit the proposal. Phase2 Phase 2 and a final revision by the TJO – OAdM staff is the last step before delivering the proposal data to the TJO – OAdM scheduler system. Phase 2 is a transformation of an accepted Phase 1 proposal into a list of observations with the detailed information needed for implementation and scheduling of the science program. Once submitted, the Phase 2 process follows the scheme shown in Fig. 3. The phase completion requires the fulfillment of Phase 2 proposal form, using the user web page interface, according to the steps described below: 1. 2. Fill in the remaining proposal information and the general observation constraints. Define the observation strategy (or TG) for each target. A new TG code is generated every time a target is selected. More than one strategy is possible for the same target, just selecting it again. A whole project is finally composed of the sum of TGs for all targets in the proposal. Next steps specify a single TG: a) Select a target from the list of objects submitted in Phase 1. b) Select the instrument. c) Define the list of observations included in the OB: it creates pattern specifications for the target observation. It must include the following information for each entry: exposure, time, filter, binning, repeats (number of exposures), and priority (to prioritize inside the same OB). A set like that shall be added a non-limited number of times to complete all the required setups to fulfill the observations required. Once the OB is completed the user must specify if it must be executed as a Non-interruptible Sequence OB, which implies observations included in an OB must be done without gaps between them. Gaps between exposures may still be necessary to allow time for activities which are necessary to set up for the next exposure, such as readouts and reconfigurations. d) Define the number of iterations: times the OB must be done. e) Calibration images: the need of standard stars for absolute photometry must be also pointed out, in order to include this requirement as a scheduling constraint. Extra bias and darks images are permitted. The number of required images must be specified, and also the exposure time for the dark ones. f) Priority: it compares the TG to prioritize inside the same proposal. g) Define the scheduling requirements: no constraints, no scheduling constraints on the OB; between, range of dates or phases that all exposures defined in the OB must be observed within (multiple Betweens are possible); after observation by, any timing or phase requirements between OB and intended to capture repeated visits with spacing of multiple minutes, hours, days or greater. 3. Define links with other TG to identify which TG must be scheduled if the current one is scheduled too. The possible ways to do it are: non-Interruptible Sequence TG, once started it must continue until the last one is done; after observation by, enter any timing requirements between TGs (during the same night, time interval); no constraints. Figure 2. Phase 1 scheme. Figure 3. Phase 2 scheme. 3.2.3 Proposal validation The observation data are validated by the observatory staff before being considered by the mid-term scheduler routine. Validation includes the revision of the total time needed to perform all the TGs and other observation constraints defined during the second submission phase that must agree with the proposal characteristics approved by the TAC. 3.2.4 Proposal data retrieval All science and calibration data, as well as all the proposal related information, are placed in the TJO – OAdM database and accessible through the observatory web page. Science data become immediately available to the proposal PI (Phase 3), who is notified automatically by e-mail. On average, the science data from TJO – OAdM flow through the production pipeline and into the database within one day after observation by the telescope. 3.3 Proposal related data: storage in the observatory database The TJO – OAdM database (DB) is structured using the relational model and is based on MySQL. Different levels are defined according to the global control design and the specific applications that interact with each one. They are sorted from high (Proposal and Project) to low (Selection and Observation) level of human interaction: Proposal: it contains the general information of the proposal entered at the submission of Phase 1. Information to be included: proposal identifier, PI data, list of targets and scientific justification, date of submission, acceptance and finalization, and status. New entries are generated through the web user interface, a proposal identifier is automatically created, the acceptance date is updated manually after the submission to the observatory TAC and the date of finalization and status is updated automatically by the observatory control system. Project: specific information of the proposal entered at the submission of Phase 2 is entered on this level through the web-based interface. It includes the detailed list of TGs and OBs and the number of present successful observations. The latter is automatically updated by the observation manager, as described in the following section. Selection: table composed of a temporary list of targets extracted from the Project level according to their possibility of observation following defined criteria (positive height above horizon at some point during the night, night date included in the defined observation window, moon brightness fulfilling user requirements, etc.). This list is generated by the mid-term scheduler application and is used as input information for the shortterm scheduler, the last step of the scheduling process. Observation: the last level contains the entries generated by the application that manages Data Processing, executed after each new observation. There is an entry per observation that includes: target identifiers, date and time of observation, calibration and analysis status, storage directory and filenames, image quality report (file, photometry, etc.), error flags and image quality code. This table is used for the observation manager to update the level of a proposal completion and the status of each TG in the Proposal and Project levels, respectively. A project is finished when the number of successful observations is equal to the number of the required iterations. When all the projects included at the same proposal are executed, the proposal is considered as closed and a notification is automatically sent to the proposal PI. Several applications interact with the DB. In order to minimize errors while updating stored data, two mirrored DBs are installed in on-site and off-site server computers. The on-site DB is only updated by the control system, whereas the offsite one is the only accessible by users for proposal submission and data retrieval. The detailed description of this logical architecture is given in the referenced documents1, 2. 3.4 Proposal tool implementation A web-based submission tool is implemented and running. It can be accessed through the observatory web page. It is programmed using PHP, AJAX and MySQL queries for database interaction. 4. OBSERVATION MANAGER The observation manager is the responsible for performing all the tasks related to scheduling and involved in the observation process. It is invoked by two different applications (OpenROCS Events and Data Processing) and it executes the automatic scheduler routines and the database update when necessary. 4.1 OpenROCS Events The OpenROCS software manages the events generated by the system, including those controlling the routine operations. Two of these event cases trigger the execution of the mid- and short-term schedulers. The first one is the sunset time that is used as a reference to start several initialization processes. Actions triggered by this event are: hardware initialization (telescope, dome and CCD), routine to register a set of calibration images and pre-selection of science targets, performed by the mid-term scheduler. The event that triggers the execution of the short-term scheduler is the end of an image acquisition, and starts the selection of the next observation (science target or calibration frame). 4.2 Data processing and database update Data processing is executed any time a new image is acquired and the main purpose of the routine is reduction and analysis of the image (based on the ICAT pipeline14) for photometric and astrometric data extraction, image quality control, data archiving, final image storage and database registry (Observation level). The image quality control process executes an evaluation of four different aspects for each image file: file quality (size, header keywords), image photometric quality (star shape, instrumental magnitude, median FWHM), image astrometric quality (coordinate solutions and pointing errors), observation pattern (fulfillment of user constraints) and environment quality (weather and system conditions). Each one of the steps described is summarized in one digit and all together provide a four digit binary code that is included in the image header as an image quality descriptor keyword. This code is then used for the observation manager to modify the database, increasing the number of successful observations associated to the proposal TG and updating the proposal completion level. If the image quality is not sufficient, image data are also stored in the database, but the proposal information is not changed. The latter makes the scheduler routines take the proposal TG again into consideration when computing the best observation. 5. MID-TERM SCHEDULER The mid-term scheduler or pre-scheduler is responsible for selecting the TGs suitable for observation and also for planning night observations before the night begins. 5.1 Pre-scheduler: selection criteria The MySQL database (Project table) contains all TGs split in OBs, including both completed and pending ones. Those TGs that have not been completed are selected by the pre-scheduler (see Fig. 4) and the rest are skipped. The calibration frames are organized into a single proposal with three TGs, one for each image type (darks, bias, and flats in each filter). This proposal is always active and defines the standard set of calibration images to acquire at the beginning and end of the night. Additional calibration frames required by a particular proposal are treated in a different manner, as they are considered together with the associated science targets of that proposal. Science targets are organized into individual TGs based on project and OB definition (filter, exposure time, number of repetitions, etc.). Targets having fixed observing times that fall between sunset and sunrise are selected by the pre-scheduler, as well as all the Flexible targets (regardless of their visibility). Once selected, the list of targets is sorted to have a static queue that can be used any time if the dynamic scheduler cannot be executed. Figure 4. Interaction between the database (DB), the scheduler routines and the OpenROCS software. 5.2 Queue scheduling sorting factors and process In order to compute the queue schedule above mentioned, the pre-scheduler applies several sorting criteria. Observation window is the first computed parameter for the selection of TGs. Two different scenarios are considered: Targets with fixed starting times are programmed first and checks are performed to see if they have the required altitude and do not conflict with other fixed targets with the same priority. If there are conflicts, the first programmed target is given priority and the conflicting target discarded. Next, targets with flexible starting times fill in the gaps between the fixed targets. This part of the script starts at the starting time (sunset) and steps up in 1 minute intervals, determining if any targets can be observed at the given time and if they fit in the gaps between fixed targets. There are 10 priority levels and targets in level 10 are considered first. This window must be computed for those proposals that require monitoring programs, based on time or phase intervals. Airmass is another sorting factor. The altitude of each target is calculated at the current time step and at the end of its observation period. The target is considered to be setting if the starting altitude is higher than the setting altitude. Thus, targets which are setting at the beginning of the night are programmed first. Targets which are rising at the beginning of the night are considered setting when they straddle their maximum altitude (because their setting altitude is just below their rising altitude). Thus by considering setting targets first, most of the targets are programmed at their optimal altitudes. Next, the distance between the moon and the target is calculated and a determination of sky brightness is done based on lunar phase and altitude. A decision whether to consider the target is made based on its altitude, lunar distance and sky brightness compared to the user-defined requirements. Once a target is considered, an attempt is made to insert it into the gaps between the already programmed observations. If it is inserted successfully, the pre-scheduler goes on with the next target. If it cannot be inserted at the given time, an attempt is made on all consecutive time steps while the user defined observing requirements are still met. If the current time steps up to sunrise and the target still cannot be included, it is discarded. After all the targets have been considered and the night observing list has been determined, a file containing the observation sequence is generated fulfilling the TALON standard format and it is used to guide the unattended operation. If there is enough time remaining before the start of the first target, the calibration images are programmed first. The science targets are programmed next, followed by another round of calibration images at the end of the night. 5.3 Implementation at TJO The pre-scheduler action is triggered by an OpenROCS event (a predefined time before sunset). The action consists of three basic steps executed by the Python based pre-scheduler script (scheduler.py). The first step is reading the MySQL database. The second step is the target selection and the queue scheduling computation. A second Python routine, containing various astronomical and time-keeping calculations (astrocalc.py), is called many times by the pre-scheduler routine to do various calculations. Finally, once the target list has been created, the pre-scheduler routine calls the slsMaker2.3.c, the program that creates the telrun.sls file needed by TALON to execute the night observations in batch mode. After the pre-scheduler has finished, OpenROCS detects a new telrun.sls has been created and proceeds to execute the night observations. 6. SHORT-TERM SCHEDULER 6.1 Dynamic scheduler algorithm: dispatcher The approach chosen to solve the dynamic selection of the observation to schedule is the use of a dispatcher6. This shortterm scheduling is executed each time a target observation is over and a new one must be scheduled. It is done in real time according to current environment and user defined conditions. The application uses the observation list created by the pre-scheduler as input information and executes an algorithm that calculates the figure-of-merit of each object. The object with the highest merit value is then scheduled. A general definition of a merit function is: where fi(t) functions and their associated weight describe the different effects that contribute to increase or reduce the global merit m(t) per object. Among these effects, we consider: Observation conditions: height above the horizon, moon brightness and distance from the moon, best observation time in case observation is required not at the meridian crossing, required period between iterations, distance from previous target, proposal priority. Environment conditions: seeing, photometric quality. Proposal history: term to ensure a balance between the observation time spent with different proposals that have the same priority. 6.2 Sorting factors The sorting factors used by the dispatch scheduler are very similar to those described in section 5.2 for the pre-scheduler, with the addition of those factors that depend on the current observation conditions: seeing and photometric sky quality. The current seeing is determined from two inputs: the on-image seeing determined from the mean FWHM of stars in the previous images, and the direct seeing measurements obtained from the Robotic Differential Image Motion Monitor (RoboDIMM15) located in the observatory. On the other hand, the on-the-fly data processing described in section 4.2 gives a determination of the current photometric sky quality for the previous images. The seeing and the photometric sky quality values are compared with the user's requirements and a decision is made regarding whether to observe the target. Targets that require very good seeing and/or photometric sky quality will be given higher priority when these measured values fulfill the requirement. 6.3 Implementation at TJO At the present time the short-term scheduling is handled by the same queue scheduling routine used by the pre-scheduler. If for any reason the observations are interrupted throughout the night (due to weather, power cuts, etc.), the queue scheduler routine can be called when OpenROCS determines that conditions are right to resume observations. The MySQL database is then consulted and the rest of the night is planned based on the selection and sorting criteria explained in section 5. This works fine at present, but has important limitations: it is time consuming to compute a new schedule and the process does not take into account present seeing and photometric quality. Currently, the dynamic dispatch scheduler is under development and will be implemented in the near future. 7. CONCLUSIONS We have described the observation management performed at the TJO – OAdM through two main software packages: the proposal management tool and the observation manager. Other applications strongly linked to the observatory task planning have been briefly described: the OpenROCS control system, the data processing routine and the database. All these software tools implement the necessary structure to have a correct system behavior when scheduling the tasks to perform. Both the mid- and short-term schedulers used, which are key elements of the observation manager package, have also been described. The observatory is currently working with a simple queue scheduler for the dynamic response, which is not the optimal solution. The observatory will start offering observation time to the international community in the coming months and the number of submitted proposals can potentially grow fast. In this situation, the use of a queue scheduler would represent a big drawback. Because of that, efforts towards the implementation of a dispatch scheduler are ongoing. Acknowledgments: We wish to thank all those who have contributed to the development of this project. The OAdM16 project is supported by the Catalan government and owned by its local official institution: the Consorci del Montsec. Research institutes and universities have actively contributed with scientific and technical supervision and manpower to the development of the project: the Institute for Space Studies of Catalonia (IEEC), the University of Barcelona (UB), the Technical University of Catalonia (UPC), the Spanish Research Council (CSIC) and the Joan Oró Foundation (FJO). REFERENCES [1] Colomé, J., Ribas, I., Fernández, D., Francisco, X., Isern, J., Palau, X. and Torra, J., "OAdM robotic observatory: solutions for an unattended small-class observatory," Proc. SPIE 7019, 70192K-1 - 70192K-12 (2008). [2] Colomé, J., Francisco, X., Ribas, I., “The TJO – OAdM robotic observatory: the OpenROCS system and the dome control”, Proc.SPIE, in press (2010) [3] Verderame, P.M. et al.: “Planning and Scheduling under Uncertainty: A Review Across Multiple Sectors”, Ind.Eng.Chem.Res., vol.49, p.3993-4017 (2010) [4] Mora, M. et al.: “A survey on the dynamic scheduling problem in astronomical observations”, https://csrg.inf.utfsm.cl/twiki4/pub/ACS/SchedulingPaperIfipai/mmora-msolar.pdf [5] Pinedo, M.: “Scheduling: Theory, Algorithms, and Systems”, Prentice Hall, Englewood Cliffs (NJ); ISBN: 0137067577 (1995) [6] Swanson, K., Bresina, J., and Drummond, M.: “Robust Telescope Scheduling”, Proc. In i-SATRAS 94 (1994) [7] Johnston, M.D.: “Spike: AI scheduling for NASA's Hubble Space Telescope,” Sixth Conference on Artificial Intelligence Applications, v.1, p.184-190 (1990) [8] Gómez de Castro, A.I., Yáñez, J.: “Optimization of telescope scheduling: Algorithmic research and scientific policy”, Astronomy & Astrophysics, v.403, p.357 – 367 (2003) [9] Granzer, T.: “What makes and automated telescope robotic?”, AN, v.325, n.6-8, p.513-518 (2004) [10] Fraser, S.N., Steele, I.A.: “Robotic telescope scheduling: The Liverpool Telescope experience”, Proc. SPIE, v.5493, p.331-340 (2004) [11] HTN: http://www.telescope-networks.org/wiki/index.php/Main_Page [12] Liverpool Telescope: http://telescope.livjm.ac.uk/Info/PropInst/ [13] HST: http://www.stsci.edu/hst/proposing/docs/proposingOverview [14] Colomé, J., Ribas, I., “ICAT: a General Purpose Image Reduction and Analysis Tool for Robotic Observatories”, Astronomical Data Management, 26th meeting of the IAU, Special Session 6, (2006), SPS6, #11 [15] Aceituno, J.: “A new Robotic DIMM for Calar Alto Observatory”, CAHA Newsletter 04b, (2004) [16] OAdM: http://www.oadm.cat
© Copyright 2024