Phase 1 Proposal Submission for Semester 2008A Updated 08/02/07 |
Table of Contents |
1) The QSO Project
The main concept behind the queue observation scheme with ESPaDOnS is to perform observation programs only during sky conditions or time constraints required to meet their science goals, as defined by the investigators. This can only be achieved if the programs are all grouped together in a database and are selected appropriately according to a set of constraints, rules and sky conditions. Programs are then carried out by a well trained, local team of observers in a service mode (i.e. investigators are not present at the observatory).
During 1999, CFHT has started a project to implement the necessary software and to review all the issues for achieving a queue/service observing mode with its CFH12K mosaic camera. This Queued Service Observations (QSO) Project has been developed in parallel to other projects necessary for the data acquisition (NEO), processing and analysis (Elixir), and archiving and distribution (DADS). The necessary software tools for proposal submission (Phase 2), selection of programs, management of the observations and execution of the observations have all been developed within the QSO Project. Most of these software components are for internal use only except for two obvious exceptions: Poopsy, proposals submission tool developed and maintained at CADC, and PH2, a Web based tool developed and maintained by CFHT for the second tier of proposal submission (see below).
The QSO mode has been used
for CFH12K
for over 200 nights between January 2001 and January 2003.
Since
the semester 2003A, MegaCam has been operated in the queue mode and
starting in 2005B, observations with WIRCam have been entirely
conducted under QSO as well. The spectropolarimeter ESPaDOnS has
been used for several years at CFHT and has produced spectacular
science. However, ESPaDOnS will strongly benefit from QSO as well since
a good ensemble of programs need specific time constraints to be
successful. The success of highly ranked programs also remains at the
mercy of the weather under the classical mode. For those reasons,
ESPaDOnS will be operated under QSO starting at the semester 2008A,
with an automated pipeline also available to produce fully processed
data.
This tutorial explains how the phase 1 proposal submission should be
prepared for this new mode of operations with ESPaDOnS.
NOTE: For all technical information on ESPaDOnS, please refer to this page.
2) Document Outline
This document presents the information for submitting a QSO proposal with ESPaDOnS for the semester 2008A. A complete description of the submission process with Poopsy and an outline of what will have to be done following the TAC evaluation for the second phase, planned for January, 2008, are included. A few QSO Rules used for the selection of the programs are presented and some other issues related to the QSO programs are also discussed.
For more information about the submission of your ESPaDOnS QSO proposal(s), contact the QSO Team.
B - Applying for ESPaDOnS Time
1) Programs: Q or not Q?
Starting at the semester
2008A, the QSO mode is the ONLY mode
of operation for the ESPaDOnS. So,
the classical mode is NOT offered for ESPaDOnS for 2008A.
2) Types of QSO Programs
Many types of programs can
benefit from the queue observing mode. Programs requesting
excellent or exceptional
sky conditions, surveys, short- or long-term monitoring,
target-of-opportunity programs, are all well suited for the QSO
mode. Also, contrary
to the classical mode, it is now possible to submit very short programs
necessitating only a few hours of observations. Programs
scientifically
valuable during bad sky conditions are also possible. During the
submission
phase with Poopsy (Phase 1), you are asked to specify what type of
programs
you are submitting for the QSO mode. These types of programs are
defined below:
For ESPaDOnS programs in the queued service observing mode, two submission phases are necessary. The first phase (Phase 1) is done through CADC Poopsy and consists in a general description of the program used for the evaluation by the Time Allocation Committee (TAC). This is the "normal" submission procedure for all proposals requesting time at CFHT. The second phase (Phase 2) is requested for ALL the ESPaDOnS queue programs for which telescope time has been allocated by the TAC. As described below, it is done prior to an observing semester (with a few exceptions) through an entirely new Web based tool developed at CFHT. During this phase, all the information necessary for the local staff to perform the observations is entered by the investigators and stored in a database at CFHT.
The PH2 tool is installed on the Web server at CFHT and a replicated, backup version is available at the CFHT summit.
C - Phase 1: Instructions for Proposal Submission with Poopsy
The current version of Poopsy, now available for the proposals for 2008A, allows investigators to send proposals for the queue mode. A section has been created which includes some information necessary for TAC evaluation, and for the QSO Team in the preparation of the queue database. Below, we review the questions related to QSO proposals as introduced in this version of Poopsy.
1- Are you applying for a queue program with ESPaDOnS? (Run Info Section)
As explained above, the queue mode is the only mode of observation for ESPaDOnS for 2008A. Answer "Yes" and complete the Queue Section.
2- Indicate the type of queue observing program: Regular, Target-of-Opportunity, Snapshot (Run Info section)
These three types of programs have been reviewed earlier.
3- Indicate a global image quality (IQ) constraint describing your program ? (Run Info section)
The main concern of the queue
mode is to observe targets under sky conditions required to meet the
science goals
defined for each program. During Phase 2, the investigators will
have
to define precisely observational constraints for their project.
However,
it is important that a global image quality for each program is defined
during
Phase 1 as well. An efficient queue can only be achieved if the
database
contains programs requesting a wide range in constraints, especially on
the
image quality, and the TAC will strongly consider the choice of image
quality
indicated here for the overall selection of the queue programs.
|
|
IQ 1.0" |
|
1.0" < IQ 1.5" |
|
IQ > 1.5" |
|
For your information, the table below gives
the
average weather statistics for Mauna Kea. Note that the "A"
semester is usually more affected by bad weather; time lost during the
first few
months
of the winter can reach level of 50% and even more.
|
|
Usable Nights |
|
Lost to Weather |
|
Usable Photometric Nights |
|
4- How many hours are required for this queue program for this semester ? (Run Info section)
A significant difference between the classical and queue modes is the way the observing time is accounted. In a classical mode, nights are usually requested and the total time asked includes the different operational overheads. In a queue mode, the time requested is in HOURS, and might or might not include overheads. For queue programs for the semester 2008A, you can follow these directives:
i)- You must request HOURS of observations. If the total time of your program is fractional (e.g. 32.4 hr.), please indicate so (.4 hr in a queue mode is possible).
ii)- In your calculation of integration
time, ONLY the readout time for the CCD should be
included. This depends on the readout speed selected
(no binning is offered) for each exposure and additional operational
overheads: fast (40 sec), normal(60
sec), slow(85 sec). Of course, to acquire one Stokes
parameter in
polarimetry mode, 4 exposures are needed; calculation should be done
accordingly. The appropriate value is automatically charged at the
phase 2 level.
iii)- Slewing and acquisition SHOULD NOT be accounted for in your calculations. Detailed instructions regarding the calibrations are given in the next section.
5- Scheduling
Constraints: (Run Info section)
Several program with ESPaDOnS need specific
dates and times for the observations to be carried out. This
information can be precisely defined during the phase 2 period but it
is important to include such constraints here because it can
significantly influence the scheduling of the instrument on the sky.
6- How many additional HOURS would be requested to complete this project ? (General Info section)
Note: For the
Phase 1, the Moon options are used to help us
evaluate
the best periods for a scheduling a queue observing period covering as
many
programs as possible. The influence of the Moon on the spectra acquired
through the narrow optical fiber is very small.
7- Other Instrument
Description: (Instrument section)
ESPaDOnS is an instrument that has 3 Observing
Modes, all offered in QSO mode:
* spectroscopy 'star + sky' mode, R=68,000
* spectroscopy 'star only' (no sky), R=80,000
* spectropolarimetry, linear or circular
polarization, R=68,000
There are also 3 CCD readout modes offered in QSO mode, with different
gains, readout noises, and readout times. The "XSlow" mode will not be offered in QSO
mode.
Please indicate which observing mode(s) and readout
mode(s) are expected to be used for the proposed program.
One of the main advantages of the queue mode scheme is the possibility to share calibrations between a set of programs. To achieve this, a calibration plan has been defined and will be carried out regularly by the queue/service observers. This plan includes the necessary "detrend" frames for removal of the instrument signatures (bias, flat-fields) and wavelength and Fabry-Perot calibrations. More details can be found on the Upena pipeline page.
For the semester 2008A, you can consider the following situations:
1- No programs under any circumstances are allowed to request "detrend", wavelengh and Fabry-Perot calibrations during Phase 1 or Phase 2. These calibrations are exclusively handled by the QSO Team.
2- If your program requires observing spectrophotometric standards (or any other photometric calibrator), you must include these observations in your program. No systematic photometric, spectroscopic or polarimetric calibrations will be done by the QSO Team with ESPaDOnS.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Most of all the snapshot programs will be accepted
so a given percentage does not make sense
Important Note: Telescope time is scheduled for A + B programs. Programs below the normal evaluation cut-off are generally C and S programs and are considered for overfilling the queue database. There is, of course, a good chance for these programs to get some data especially if the conditions requested are realistic and take advantage of poor sky conditions. Final choice of C programs is left to the QSO Team, after revision of the actual constraints imposed by the A+B programs.
F - The ESPaDOnS Exposure Time Simulator
An important component in the preparation of the proposals during Phase 1 and 2 of all the queue mode programs instituted around the world is the availability of a exposure time simulator. Since the investigators are not present during the observations, it is crucial for the QSO observers to know that if the observations are undertaken during sky conditions requested, the science goals should be reached because the proposers have verified that using a robust exposure time simulator. It is not always easy to judge the science merit of an exposure frame and this is better accessed by quantitative evaluation.
An exposure time simulator for ESPaDOnS has been developed by Jean-Francois Donati. A Web based interface for the simulator is available here. Note that the space of parameters available in the simulator is much larger than the options offered by QSO. It is strongly recommended to use the simulator during Phase 1 and Phase 2 of the queue programs with ESPaDOnS!
G- Other Issues1) Communication and Night reports
The QSO Team has integrated a Email communication system inside PH2 ("HelpDesk") that allows the investigators to send request to the Team during the Phase2. This system is also available during the semester through PH2. It includes several discussion forums, and keeps tracks of all the communication related to the QSO mode for each program identified by its runID. Even if a bit cumbersome, using the Helpdesk is much preferable that using a normal email system. It ensures that everybody related to the observing process is informed,
After each observing night, a report detailing what observations were performed is available on the CFHT Web site. These reports include the observations groups executed and the sky conditions at the time of the observations. This does not mean that your data will be immediately available (see below). The goal of these reports is to inform the community of the progress of the queue and, in particular, the current status of your program.
Current global statistics for a semester are also available on the QSO Web page.
2) Data Evaluation
As part of the data quality control assessment, all data taken will be automatically processed and calibrated by the Elixir Team. Data evaluation will be done in two steps: during the observation by the Service Observer ("on-line" evaluation) and, during and after the data processing. This last step is very involving and represents one of the reasons why data cannot be distributed immediately after a QSO run, unless specifically justified during the Phase 2 period. If the observations are judged satisfactory, the queue database is then updated by the Queue coordinator.
3) Data Distribution
Data distribution (raw and processed data) will be ensured by the DADS Team. Our goal is to be able to distribute the data to the PI of each project (or another member if specified during the Phase 2) and the relevant calibrations at the period specified during the phase 2 (e.g. after a QSO run, at the end of the program, end of semester). Due to the heavy workload, it might not be possible to send the data to the investigators during an observing run. However, for certain types of programs (e.g. TOO) where looking at the data as soon as possible is important, this will be possible under the supervision of the Queue coordinator.
4) Proprietary Period
A special procedure is taking place regarding the proprietary period for data obtained with ESPaDOnS in the QSO mode. By default, the proprietary period of QSO data extends to 1 year + 1 month starting at the end of the QSO semester. For instance, data taken for the 2008A semester (February 1st - July 31st) will have a default release date set to 08/31/2009. If an extension is requested in Poopsy and approved by TAC, a new date will be set for this program through the QSO system. The release date for the data is indicated in the fits headers by the keyword REL_DATE. This system applies only to QSO data. For snapshot programs, the proprietary time is 3 months following the end of the semester.
5) The QSO Team
|