Queued Service Observing with MegaPrime: Semester 2003A Report 08/07/03

A - Introduction

The Queued Service Observing (QSO) Project is part of a larger ensemble of software components defining the New Observing Process (NOP) which includes NEO (acquisition software), Elixir (data analysis) and DADS (data archiving and distribution). The semester 2003A was the first time MegaPrime was used for the NOP system. Due to some delays in the MegaPrime engineering and commissioning as well as some serious technical issues (no guiding system during the first few months, filter jukebox failures, NOP software issues), a lot of time could not be used for observations this semester. The last run of the semester was also almost completely lost to weather. For these reasons, the statistics on programs for 2003A are quite poor.

B - General Comments

Real observations in QSO mode did not really start before May (when guiding became available). The run in June was quite good but the last run almost completely lost to weather and terrible seeing. During QSO nights when seeing was good, long focus sequences were necessary to test adjustements in the optics of MegaPrime. At the time of writing, the overheads are still much larger than we would like. For instance, the auto-focus has not been implemented yet and the introduction of frequent focus sequences add up to at least 10% of overheads. Also, there are still some issues on the control software for the guiders and NOP which introduce additional time lost on the sky. These are beeing addressed so that efficiency on the sky should improve significantly in the next few months. In April and May, we experienced failures in the filter jukebox which resulted in several nights with only one filter available. Also, for the first 8 nights of run #5, only half of the mosaic was available, introducing huge overheads to complete observations for certain programs.

1. Technically, the entire chain of operation, QSO --> NEO --> TCS, is efficient and robust but several glitches remain to be fixed. This is a complex system and the time lost to glitches for 2003A was significant.

2. The QSO concept is sound. With the possibility of preparing several queues covering a wide range of possible sky conditions in advance of an observing night, a very large fraction of the observations were done within the specifications. The ensemble of QSO tools allows also the quick preparation of queues during an observing night for adaptation to variable conditions, or in case of unexpected overheads. The introduction of the CFHTLS with time constrained observations on the large-scale adds significant complexity to queue scheduling. Despite the fact that at the end, the balance between the Agencies was reasonable, and since QSO could not operate much during this semester, there are still a lot of unanswered questions regarding the scheduling of PI programs versus CFHTLS.

3. QSO is well-adapted for time-constrained programs. The Phase 2 Tool allows the PIs to specify time constraints. Two of the components of the CFHTLS have very restrictive time constraints. We can handle those easily if the weather is cooperative (of course!) although the introduction of time constrained observations on a large-scale adds up definitive complexity in the scheduling process.

4. Very variable seeing and non-photometric nights represent the worse sky conditions for the QSO mode. In 2003A, we had several "shapshot" programs available (programs requesting mediocre conditions) and we used them very frequently during the bad seeing conditions (notably in May and July). Unfortunately, we have very few programs requesting 1" and above for the next semester. The availability of Skyprobe and real-time measurements of the transparency is extremely valuable and regularly used do decide what observations should be undertaken.

5. Observations of moving targets is feasible in a queue mode. During the 2003A semester, we implemented a way of preparing observations for moving targets in our Phase 2 Tool (ephemeris tables). The process is a bit laborious but works really well. Non-sidereal guiding is not yet offered.

C - Global and Program Statistics

The following table presents some general numbers regarding the queue observations for 2003A (C, F, H, K, L, time, excluding snapshot programs):

Remarks:

• The fraction of time lost during QSO nights in 2003A due to weather is smaller than the global fraction usually lost for Mauna Kea. However, periods of bad seeing were very frequent and, worse of all, most of the time lost happened at the end of the semester, when the system had become more efficient...

• The time lost due to engineering, commissioning, and technical problems is, of course, very important this semester. The number given is also approximate because not everything could be taken into account.

• Statistics on the completeness of programs is very bad. This is, of course, not too surprising with about 60% of the time completely lost to technical issues and weather. Part of this, however, is also due to overheads being too large at the moment.

• About 90% of the observations conducted were found to meet the specifications. Most of the fraction of observations not validated is due to rapidly changing conditions...

D - Agency Time Accounting

Balancing of the telescope time between the different Agencies is another constraint in the selection of the programs used to build the queues. The figure below presents the Agency time accounting for 2003A. The top panel presents the relative fraction requested by the different agencies, according to the total I-time allocated from the Phase 2 database. The bottom panel represents the relative fraction for the different Agencies, that is, [Total I-Time Validated for a given Agency]/[Total I-Time Validated]. As showed in the plots, the relative distribution of the total integration time of validated exposures between the different Agencies was balanced at the end of the 2003A. Normally, we would like a better balance but with the circumstances of this semester, the final result is not too bad. However, we were not able to get data for the Taiwanese Agency this semester. Their unique program requests very good image quality (we contacted the PI but the IQ constraint remained) and this could not be achieved when we tried this program.

E - Additional Remarks

Our first semester with the queue mode with MegaPrime was a difficult one, mostly due to the time lost to engineering, commissioning, weather, technical problems and overheads. Even if the statistics are poor, we already have learned a great deal and a lot of progress was made in the second part of the semester. Improving efficiency remains a high priority and we are hopeful that 2003B will be much more productive on the science side.