 |
|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass03/P9-10/
Дата изменения: Sat Aug 14 04:19:21 2004 Дата индексирования: Tue Oct 2 05:36:40 2012 Кодировка: Поисковые слова: п п п п п п п п п п п п |
k
Place, University Park,
Hilo, Hawaii, 96720
UKIRT and JCMT are traditional ground-based facilities that in recent years have shifted their operations from classical scheduling to a flexible queue-based system that maximizes the efficiency of the telescope by matching observations to current weather conditions.
This change was made without a corresponding increase in staffing; therefore the telescopes still operate under PI-staffed observing. The observer at the telescope is there to observe their own project provided the conditions are suitable and they remain within their time allocation; otherwise they observe another PI's project ``off the queue''.
Considerable amounts of software are required in order to support such an operational model effectively without jeopardizing the quality of the data taken in queue mode. This is even more so in the case of our particular model, in which no Phase II deadline is imposed, in order to allow PIs to modify their strategy throughout the semester in the light of incoming data. Management of communication and information flow is crucial in a regime where there are so many interested parties involved in data acquisition. These include but are not limited to the observer at the telescope, other PIs and their Co-Is at home whose projects may be observed, the staff contact for the project whose data is being taken, and the staff member providing support for that particular night, as well as the telescope operator in charge of the facility. Let's not forget also the potential archival user of the data once its proprietary period has elapsed, who has a vested interest in copious and correct metadata.
The software involved in managing this operational model falls under the umbrella of the Observation Management Project (OMP; Economou et al. 2002). In this paper we describe a vital component of the OMP, the OMP Feedback System which manages curation and access to a wide variety of information and services associated with individual projects as well as global views of operational statistics. See Figure 1 for an overview of how the Feedback system components fit into the OMP system.
Access for users to the information stored in the Feedback system is done via a web-interface to dynamically generated information. In terms of architecture, the Feedback system is made up of a Perl/CGI-based web-interface, a relational database where all data are stored, and Perl classes that provide methods for querying and updating that data. Thanks to the level of abstraction that the Perl classes provide, switching from a relational database to, say, an object-oriented database would be a relatively straight forward procedure.
All details concerning a project - TAG and queue information, contact addresses, etc. - are stored in the Feedback system as project data. After logging into the Feedback system, the user is taken to their Project Homepage where all important project data are displayed. In addition to being displayed for user reference, project data are used internally by the Feedback system as well, such as when the system looks up a PI's email address so that it can notify them when data have been obtained for their project. Like much of the OMP information, access is restricted to the PI and JAC staff and observers.
The details of a Minimum Schedulable Block (MSB) (the smallest unit of observation that can be scheduled on the telescope and which is equivalent to an ESO observation block (Chavan et al. 2000)) can be displayed by the Feedback system for quick assessment, though modifying these details is a task left to the Observing Tool.
The Feedback system plays s pivotal role in keeping track of an MSB's status. When an MSB is observed its status is updated to indicate which ones have been done (and any comments made by the observer as to how successfully) and which remain to be done. This information is visible to PIs through the Project Homepage, and is collated automatically when reports are generated.
The Obslog, or observation log, allows staff and observers to comment on individual observations. For example, if an observation is aborted the observer might use the observation log tool to flag it as bad and add a comment explaining why this was the case. The comment is thus permanently associated with the observation and an investigator would see the comment as part of their project night report.
Staff and observers use the Shiftlog tool to make narrative comments through the night on observing conditions and other events that are not associated with a particular data frame. The shift log comments are presented as part of the complete and project night reports, providing a running commentary on the night's notable activities. These, in conjunction with the obslog can provide valuable metadata for science archives (see e.g. Jenness et al. 2002).
When staff and observers encounter a fault they file a report in the fault system (also provided as part of the OMP framework) indicating what systems were affected, any projects affected, and any time lost. Once in the system discussion on the fault takes place until it is resolved and given a status of `closed.' If the fault has affected a project, that project's investigators can view the fault via the Feedback system and comment on the fault from there as well.
WORF (WWW Observing Remotely Facility) allows investigators to remotely view and examine raw and reduced data even while observing is still taking place (see e.g. Economou et al. 1996). Thumbnails are also generated on-the-fly for quick perusal.
At the end of each night staff use a tool to adjust or confirm the time spent on projects observed starting from automatic estimates provided by the OMP. This can be used to monitor the time spent on projects as well as the overall national queues over long periods of time, as well as in the nightly statistics. Projects that have ran out of time are weeded out automatically during observing.
The Feedback system can generate a report on-the-fly, based on a single or multiple nights, which incorporates time accounting data, Shiftlog and Obslog data, MSB status data, and fault data, and includes the possibility of including results from the automated data reduction pipeline (see e.g. Cavanagh et al. 2003). For staff, this report includes the aforementioned data for all projects, while PIs can access an abbreviated form that contains information pertaining only to their own project. These statistics presented in these reports are useful to staff on an end-of-night, as well as end-of-semester basis.
Before allowing users to access data, the Feedback system authenticates users through the web-interface by requiring them to login with a unique project ID and password (which the PI can share with collaborators). Staff have access to all projects via a single login ID.
The OMP Feedback System is in use at UKIRT and JCMT for all common user observing with all instruments. All OMP software is licensed under the GNU General Public License.
Cavanagh, B. et al. 2003 in ASP Conf. Ser., Vol. 295, Astronomical Data Analysis Software and Systems XII, ed. H. E. Payne, R. I. Jedrzejewski, & R. N. Hook (San Francisco: ASP), 237
Chavan, A. M., Silva, D. R., Boarotto, C., Canavan, T., Kemp, R., Giannone, G. 2000, Proc. SPIE, 4010, 81
Economou, F., Bridger, A., Daly, P. N. & Wright, G. S. 1996, in ASP Conf. Ser., Vol. 101, Astronomical Data Analysis Software and Systems V, ed. G. H. Jacoby & J. Barnes (San Francisco: ASP), 101, 384
Economou, F., Jenness, T., Tilanus, R. P. J., Hirst, P., Adamson, A. J., Rippa, M., Delorey, K. K. & Isaak, K. G. 2002, in ASP Conf. Ser., Vol. 281, Astronomical Data Analysis Software and Systems XI, ed. David A. Bohlender, Daniel Durand and T. H. Handley (San Francisco: ASP), 488
Jenness, T. et al. 2002, in ASP Conf. Ser., Vol. 281, Astronomical Data Analysis Software and Systems XI, ed. David A. Bohlender, Daniel Durand and T. H. Handley (San Francisco: ASP), 243