Queued Service Observations for ESPaDOnS Phase 2 Proposal Submission Tutorial Updated 11/24/2008

• The QSO Project
• The Phase 2 Proposal Submission
• Document Outline

• PH2: Purpose
• Some PH2 Notes
• The PH2 Interface
• The Concept of Observation Blocks
• The Observation Groups
• A Word on Data Format and Observing Modes with ESPaDOnS
• A Word on the Calibrations
• PH2: Recent Changes
  • Non-sidereal tracking
  • HelpDesk discontinued

• Accessing PH2
• Navigating within PH2
• Program Selection
• Program Details
• Program Constraints
• Fixed Targets
• Ephemeris
• Finding Charts
• Instrument Configurations
• Constraints
• Observation Blocks
• Observation Groups
• OG Scheduler
• Summary
• HelpDesk
• Logout

• Night Reports
• Data Evaluation
• Data Distribution
• The QSO Team

A - Introduction [B - Overview] [C - Detailed Tutorial] [D - QSO rules] [E - Other issues] [TOC]

1) The QSO Project

The main concept behind the queue observation scheme is to perform programs only during sky conditions required to meet their science goals, as defined by the investigators. This can 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. Each night, several queues composed of different programs are prepared to cover diverse sky conditions and constraints. Observations are then carried out by a well trained, local team of observers in a service mode.

During 1999, CFHT 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 Observing (QSO) Project has been developed in parallel with other projects necessary for the data acquisition (NEO), processing and analysis (Elixir), and archiving and distribution (DADS). The software tools required for proposal submission, selection of programs, database management, 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, the proposal submission tool developed and maintained at CADC, and PH2, a Web based tool implemented and maintained by CFHT for the second tier of proposal submission (see below).

Starting in January 2001, queue observations were performed with the CFH12K camera for about 220 nights. By reaching good statistics on completeness, image quality requirements, Agency time balancing, and by meeting time constraints requirements for several programs, the QSO mode has been quite successful. Since 2003, all of the observations with MegaPrime have been conducted under the QSO mode. Starting with the semester 2005B, observations for WIRCam, the new wide-field near-IR imager, have also been done through the QSO system. Now, it's time for ESPaDOnS! One of the main advantage of integrating ESPaDOnS within QSO is the frequent time critical observations required for several science programs. Other than to be able to handle priorities under sky conditions better than in classical mode, QSO is particularly well adapted for this kind of time constraints.

The tutorial describes a version of PH2 developed specifically for observations with ESPaDOnS. Following the evaluation of the different Time Allocation Committees (TAC), the successful proposals have received a certain amount of telescope time, a grade and a rank, and are now ready to prepare detailed observations, the Phase 2 submission period.

2) The Phase 2 Proposal Submission

The Phase 2 submission for proposals accepted for the semester 2009A extends over a period of a few weeks. The two important dates to remember are given in the table below:

Please take these points into consideration:

• It is very important that the Phase 2 deadline is respected. Diverse issues must be examined by the QSO Team prior to the semester regarding the information provided by the investigators during the Phase 2 (e.g. target positions, guide star availability, time constraints). The telescope schedule will be prepared only after PH2 is closed.
• Even if PH2 is straightforward, preparation of QSO observations can be time-consuming. We strongly recommend that you prepare your observations during the Phase 2 well ahead of the deadline. This will allow you (and us!) to make sure that mistakes have been avoided. Also, if a problem occurs, the QSO team will have enough time to react and find a solution.
• PH2 is available from the CFHT HQ Web site (http://qso.cfht.hawaii.edu:2001/Instruments/Queue/PH2/). A backup site, located at the summit, is also available: (http://qso2.cfht.hawaii.edu:2001/Instruments/Queue/PH2/). The CDS site has now been retired. However, to ensure data integrity, only one session with the same user ID is allowed at the same time.

This document presents the complete information for the second submission Phase of the QSO proposals accepted for ESPaDOnS. A general description of the Phase 2 tool is first presented in the section B. It includes a broad overview and, maybe more important, a description of the strategy behind the tool itself: the creation of the observation blocks, subsequently leading to the observation groups, the entity scheduled at the telescope. A brief discussion on the calibrations is also provided. The tool is simple enough that this overview might be sufficient for users accessing PH2 for the first time. Quick help files are also available from the button in PH2. Of course, there are substantial differences between the versions used for the different instruments at CFHT. A much more detailed tutorial is presented in Section C. For a complete description of the Phase 2 tool and other issues related to the Phase 2 submission, please refer to this section. Finally, the last two sections include some discussions already presented in the tutorial for the Phase 1 submission but still very relevant to the preparation of the observations during the Phase 2.

If you require more information about the Phase 2 submission, contact the QSO Team.

B - Overview of the Phase 2 Tool (PH2) [A - Introduction] [C - Detailed Tutorial] [D - QSO rules] [E - Other issues] [TOC]

1) PH2: Purpose

The Web based Phase 2 tool (PH2) has been developed for one main purpose: allowing the investigators of accepted QSO proposals to prepare a full description of their observations and to store this information in a database, accessible to the CFHT QSO Team. Observations to be carried out are extracted from this database during the QSO observing nights. PH2 represents then the key element in the QSO mode scheme. This is where the investigators tell the observers what observations should be done, and how (and sometimes when they should be done.)

PH2 is flexible enough to accommodate many kinds of queue programs (but not all of them...) while remaining relatively simple to use. It is also constantly a work in progress. We hope to introduce more options in the future versions to add more versatility. And, of course, suggestions are always welcome!

2) Some PH2 Notes

Some important characteristics of the actual version of PH2 for the general user are:

• PH2 is compatible with Netscape, Internet Explorer, and Firefox browsers. We highly recommend the Firefox browsers. Due to the recent prolific development of browsers on several platforms, we cannot support all of them. Browsers on Unix, Linux and Windows platforms are usually the most reliable for working with PH2. PH2 now works also with the Safari version 3 browsers.
• Except for one optional tool, PH2 does not include any Java code. It is entirely developed around JavaScript and the ColdFusion language. There are some differences in the way the PH2 code is handled between the different browsers but all functionality should be preserved.
• For all of the accepted QSO proposals, the most relevant information entered in Poopsy during the Phase 1 is transferred to the PH2 database and is available for the user. So, if you have entered your targets in Poopsy, you won't have to do it again in PH2! The possibility to upload a specifically formatted ASCII file instead of typing everything by hand for the targets is also provided in PH2.
• VERY IMPORTANT: There is a time-out of 2 hour for inactivity periods (that is, between "save" activations) recorded on the server. A window reminds the user of this 2 minutes before the expiration of the session. This is to ensure that in case of a problem (e.g. local crash), you can always come back later and log in again with your user ID. So, save your work frequently! If you cannot access PH2 due to this but immediately must do so, send us an email and we will correct the situation.
• Of course, during the Phase 2 period allocated by CFHT, you can access PH2 at all time and as many times as you want. All your work is saved in the database so you do not have to finish everything at once... Also, there is no "submit" button: when you're satisfied with the preparation of your observations (for instance, what you see in your program summary), that's all there is to it!
• PH2 allows the observations of moving targets (e.g. Solar System objects) by entering targets ephemeris. Starting with semester 2009A, PH2 also offers non-sidereal tracking; "non-sidereal guiding" with the ESPaDOnS guiding camera is possible if the target is not extended. Programs with moving targets can be complex so do not hesitate to contact us during the preparation of your observations.
• There is the possibility to define "user dithering patterns" in PH2. However, this practice is not recommended because it can result in severe difficulties during the data reduction. Only use the nonstandard dithering patterns when necessary, or if you are already very familiar with data analysis of MegaPrime observations.
• Due to some difficulties in tracking the sizing activity applied to a browser window from PH2, we recommend that you size PH2 to the maximum allowed by your screen at the beginning of the session (before logging in) and keep it that way. All the necessary scroll bars have been implemented for navigating within the browser frames.

The typical schematic presentation of the PH2 interface is shown below:

HINT: You can change the size of all the frames inside PH2 by dragging their side with the mouse.

• Navigation Menu: The left frame is a navigation menu, presented with buttons with the names of the different sections of PH2. The button corresponding to the current form goes from blue to white.
• Top Frame: When present, it displays diverse passive information (e.g. list of target names). For two sections of PH2, however, the user must select diverse entries from several lists in order to create the observation blocks or groups (see below).
• Middle Frame: This frame presents the different tables for the targets, instrument configurations, etc. The maximum number of rows displayed at once is 5 (restrictions due to the speed of JavaScript) but buttons allow to navigate through different pages inside this frame. At the bottom of each table, a series of buttons allows the manipulation of the data entry in the table. The purpose of each button can be seen if the mouse is placed directly on it. The main function of some of the most important buttons is illustrated in the table below.
• Bottom Frame: This frame includes the buttons for saving the data to the database and a help button. The purpose of each button can be seen if the mouse is placed directly on it. The main function all the buttons is illustrated in the detailed tutorial.

4) The Concept of Observation Blocks

The entire architecture of PH2 and its database is based on the concept of Observation Block (OB). As illustrated below, an OB is formed of one (and only one) target, one (or many) instrumental configurations, and one (and only one) constraint.

The idea behind PH2 consists in several tables where the user can define these targets, instrumental configurations and constraints. Each row of these tables receives a unique label so each target, configuration or constraint is an unique entity. In other words, for example, one instrumental configuration defined only once might be subsequently used numerous times for observing different targets during the creation of the OBs.

Important: Since it is easier to schedule short observations at the telescope in a QSO mode, there is a limit of 2 hours (7200 seconds) for the total integration time of one individual observation block. PH2 will remind you if this time is exceeded...

The following four main steps lead to the creation of these observation blocks with ESPaDOnS:

i) Targets: When this section is selected, a table with several entry fields is presented (see below). The user can then define all the targets in the program by adding the appropriate rows to the table. Pointing coordinates can be entered in the table or grabbed from the Aladin tool. When the "Save" or "Proceed" buttons are pressed, this information is automatically saved in the database.

ii) Instrument Configurations: A table is presented for this section and the user can define all the instrument configurations (e.g. observing mode, readout, Stokes parameter, exposure time) planned to be used for observing the targets of the program (see below). Remember: The same configuration may be used for different targets over and over again so you might have to define it just once!

iii) Constraints: Finally, the last ingredient required for the creation of an OB is the constraint. These requirements for the observation (e.g. seeing, airmass) can be entered in a table similar to the one below. Again, one constraint may be used several times for different observations.

iv) Observation Blocks: Here you are! It is now time to associate all the above individual "entities" to create the observation blocks. This is very easy to do. You must first select one (or several) targets in your list (mouse click), then create a list of instrumental configuration(s) by selecting one or several of them (can be ordered with the arrows in the list), and finally, select one constraint. By clicking on the "Create OB" button, you add automatically one (or several) row(s) to the table of Observation Blocks. The creation of the OBs can be done very quickly if many targets used the same configurations and constraints because these remain selected after creating an OB. Very Important: The number of configurations that can be linked within an OB is unlimited; however, we recommend to keep the OBs as simple as possible to avoid additional overheads. You are almost done...

5) The Observation Groups

In principle, all the information entered in the tables above and used for the OBs would be enough for the operation of the QSO mode. However, to add more flexibility to PH2, we have introduced the concept of Observation Groups (OG). The OG will be the unit actually scheduled at the telescope and executed by the QSO Team So, it is necessary to fill the observation group form! The interface to prepare the groups is illustrated below. Three different types of groups are available, as illustrated below:

• Single OB (1OB): In this case, a group is only constituted of one single OB. If this is what is needed, all the groups can be created from all the OBs defined earlier by clicking on the "Quick Create OG" button. This is the recommended approach for the QSO mode.
• Sequence (SOB): It is possible to create sequence of OBs, that is, to link different OBs that should be executed successively, under the same constraint. Contrary to the individual OBs, a sequence can include different targets. However, since this procedure can introduce additional overheads in telescope slewing time, so we do not recommend sequences unless necessary for the program. The limit of 2 hours of total integration time remains also valid for a SOB.
• Monitoring (MOB): If an OB must be observed several times at a regular period, a monitoring observation group including this OB can be defined. There is a window on the right (no showed) that allows the user to define the period (P), the number of iterations (N) and the minimum number of iterations acceptable. Note that is not possible to define monitoring parameters for sequences of OBs. A new tool, the OG scheduler, is also available now and described in the detailed tutorial.

I-Time Accounting. An important aspect of the Observation Groups form is the accounting of the integration time (I-Time). This calculation is presented in the third frame and is automatically updated when an OG is created. The total readout time for the OBs, and the total I-time for the monitoring OG (N(iter) x I-Time (OB)) are automatically taken into account. If the "I-time left" becomes negative, a warning is displayed and the OG(s) created cannot be saved in the database.

The preparation of your observations is now completed! There are also other options available for the observation groups (e.g. time constraints, relational execution link, OG scheduler); that can be particularly helpful for some ESPaDOnS programs; information can be found in the detailed section below. A summary of the information saved into the QSO database is also available and can be sent by e-mail to the user.

6) A word on observing modes and data format with ESPaDOnS

ESPaDOnS has essentially two different observing mode: Spectroscopic (with or without sky) and Polarimetric. For the spectroscopic modes, the data produced consist in individual files (that is, independent odometer numbers) where the intensity (I) is established against wavelength. For the polarimetric mode, individual files are also produced. However, for a given Stokes parameter, 4 different files are generated. QSO will not produce data cubes with ESPaDOnS. For both modes, exposures can be repeated according to the number of sequences (N_seq) defined by the user within PH2. The table below gives a summary. The total I-time is automatically calculated in PH2, according to the mode selected.

7) A Word on the Calibrations

To process the ESPaDOnS data, a calibration plan has been developed by the QSO Team. The idea is to take all the necessary calibrations to reduce the data, on a nightly basis. This plan includes the necessary detrend frames for removal of the instrument signatures (bias, flat-fields) and for calibrating the spectra (ThAr, Fabry-Perot). For ESPaDOnS, you can consider the following situations:

1. No programs under any circumstances are allowed to request "detrend" calibrations, including wavelength calibrations, during Phase 1 or Phase 2. These calibrations are exclusively handled by the QSO Team. It is, in fact, not possible to define detrend calibrations through PH2 for the general users...
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.

8) PH2: ESPaDOnS and Recent Changes

For the current semester, these changes were made:

• Non-sidereal tracking is now offered for ESPaDOnS:
  • Select the appropriate option in the Program Constraint form:
    
  • Give at least 3 sets of coordinates per moving target in the Ephemeris form:
    
  • Select the appropriate non-sidereal option when creating your OB:
    
  • Contact the QSO Team if you have any question!
• The HelpDesk has been discontinued. To contact the QSO Team, please send an email to qsoteam -=at=- cfht.hawaii.edu

C - PH2: A Detailed Tutorial [A - Introduction] [B - Overview] [D - QSO rules] [E - Other issues] [TOC]

1) Accessing PH2

Accessing PH2 is limited to users having received confirmation of telescope time in the QSO mode with ESPaDOnS for a given semester. Before accessing PH2 through an User ID/Password system, some characteristics of PH2 should be known:

• PH2 can be accessed either from the CFHT HQ Web server or a backup site located at the summit. The database is replicated in real-time. The CDS site has now been retired.
• To preserve data integrity, only one user with the same UserID is allowed at the same time. This is valid for both PH2 sites, since the verification is done through the replicated database.
• PH2 is compatible with Netscape, Internet Explorer, Safari and Firefox browsers. It is usable with the version 4 of these browsers but we highly recommend the Firefox browsers. Netscape 4 on Unix will work well except for a bug of the browser (nothing we can do about it!) affecting the OB selection in the OG form. Depending on the speed of your connection, it can take up to 30 seconds to upload a page in PH2. If your are filling up a long list of entries in a table, Save your work regularly!
• IMPORTANT: There is a time-out of 2 hour for inactivity periods recorded on the server. A window reminds the user of this 2 minutes before the expiration of the session. This is to ensure that in case of a problem (e.g. local crash), you can always come back later and log in again with your user ID. Beware: No "save" is performed if your session has automatically timed out. Save your work regularly!
• Of course, during the Phase 2 period allocated by CFHT, you can access PH2 at all time and as many times as you want. All your work can be saved in the database so you do not have to finish everything at once... Also, there is no "submit" button: when you're satisfied with the preparation of your observations (as seen in your program summary), that's all there is to it!
• Due to some difficulties in tracking the sizing activity applied to a browser window from PH2 (upon resize, the modifications to the current form might be lost), we recommend that you size PH2 to the maximum allowed by your screen at the beginning of the session (before logging in) and keep it that way. All the necessary scroll bars have been implemented for navigating within the browser frames.

Access to PH2 is done through this small window:

• User ID: The User ID is the same one that was used for Poopsy during the Phase 1, or was provided to you by e-mail by the QSO Team. If you used PH2 before, it's the same User ID as before. If you do not remember it, please contact the QSO Team (not CADC!).
• Password: The Password is the same one that was used for Poopsy during the Phase 1, or was provided to you by e-mail by the QSO Team. If you used PH2 before, it's the same password as before. If you do not remember it, please contact the QSO Team (not CADC!).

The left frame of PH2 is the Navigation Menu. The user can easily go from one page to the other by just clicking on the appropriate button. The button corresponding to the form currently opened becomes white with blue fonts.

HINT: It is highly recommended to navigate through PH2 with the menu buttons instead of the normal browser buttons. Activity in the different forms is monitored so using the PH2 buttons ensure that all the data are saved before moving to another section of the tool.

The navigation buttons and their corresponding pages are described below.

Button	Corresponding Page
	First page of PH2 (Login). UserID and Password required.
	Program Selection Page, for multiple programs under the same User ID
	Page describing the QSO program, the investigators (PI) and the TAC evaluation.
	General Constraints and Information for the program. Depending on the answers, some options will be made available in the subsequent pages. Includes also a complete section for the distribution of the data.
	Page containing the table used to define all of the targets used in the creation of the observation blocks
	Page containing the table used to define all of the targets for which coordinates are changing with time (ephemeris). Only accessible if requested in Program Constraints page
	Page used to define finding charts. Not mandatory and only accessible from the navigation menu.
	Page containing the table used to define all of the instrument configuration (e.g. observing mode, Stokes parameter, exposure time) used in the creation of the observation blocks
	Page containing the table used to define all of the sky constraints entering in the creation of the observation blocks.
	Page allowing the creation of the observation blocks from the lists of targets, instrumental configurations and constraints defined in the previous pages.
	Page allowing the creation of the observation groups (e.g. sequences) from a list of observation blocks. The I-time used for the program is also calculated and compared to the time allocated by TAC. Time constraints and REEL can be accessed here, if requested.
	Optional tool that can be used to define a set of specific dates and times to execute one or a series of OGs.
	Page describing all the observations prepared with PH2 and stored in the database for a specific program.
	Page containing diverse forums related to the support of PH2 and the QSO mode. E-mail communication system available for contacting the QSO Team.
	Logging out of PH2 (needs confirmation).
	Opens the quick help files for PH2, containing information on the diverse parameters of the PH2 forms.
	This document! Detailed overview and general description of PH2 and how to use it.

3) Program Selection

This page allows the selection of your program for your session::

This page can be opened at all time; it is possible to work on several programs at the same time without having to log out from PH2. The programs are first sorted out according to the semester (pull-down menu) and then are identified by the runID, instrument and title. Be careful: always make sure that you are editing the right program for the right instrument! For your convenience, the runID and instrument is shown on all the PH2 forms. Note: Following recommendations by the Time Allocation Committee, it is possible that a program was split into different programs with some specific I-time and grade/rank. If it's the case, the program with the higher ranking will keep the same runID as assigned during Poopsy Phase 1 but the other programs will be assigned a different runID by the QSO Team. When you click on "proceed", the version of PH2 you will need (MegaCam vs WIRCam vs ESPaDOnS) is loaded.

HINT: It is necessary to first select a program and click on the "Proceed" button before being able to navigate through the other pages of PH2.

Button	Function
	Open the help files to the current page.
	Save the content of the current page in the QSO database and open the next form.

4) Program Details

This page presents information regarding the program, the investigators, and the TAC evaluation:

• Program Title: This is the program title as entered with Poopsy during the Phase 1 proposal submission period (or through the TOO form). This field cannot be edited. The program title is available to the QSO Team at all time during the observations.
• Program Abstract: This is the abstract of the program, as entered during the Phase 1 proposal submission period (or through the TOO form). This field cannot be edited. The program abstract is available to the QSO Team at all time during the observations.
• Investigators:
• PI: Name of the Principal Investigator for this program. It cannot be changed.
• Institute: Current working institution of the PI. It must be up-to-date.
• Phone: The current hone number of the PI. It must be up-to-date and include the area code.
• Fax: The current Fax number of the PI. It must be up-to-date and include the area code.
• E-mail: The current e-mail address of the PI. The email address must be up-to-date and accurate. This is the main contact resource used by the QSO Team for communication with the PI!
• Program Information:
• RunID: Identification number for your QSO program and instrument for which it is assigned. This number is defined during the Phase 1 submission process and is attached to all of the QSO programs. It is important to remember your runID to communicate with the QSO Team and also to monitor the progress made on your program using the night reports. The first three digits indicate the semester, the letter indicates the Agency and the last two digits is the number assigned by Poopsy or the QSO Team.
• Agency: Agency for which this telescope time has been assigned, as specified during the Phase 1. The values are CNRS (F), NRC (C), UH (UH), KAO (K), NTU (T), Opticon (O), Large Programs (P), CFHT (D-time).
• Program Type:The type of the program, as requested in Phase 1 or as assigned by the TAC. Three types are possible: Regular, Target-of-Opportunity (TOO), and Snapshots. The specific definitions of these programs is given in the Phase 1 tutorial.
• TAC Grade: Grade assigned to your proposal by the Time Allocation Committee (TAC) for your Agency. Four grades are possible "A: must do", "B: prioritized"; "C: best effort"; "S: snapshot". The corresponding priorities of these program grades are highest, good, medium and lowest, respectively. Grades C and S are considered for "overfilling" the queues (that is, these programs would not have received any time in a classical mode). See Phase 1 submission tutorial for more information.
• TAC Rank: Rank of your proposal within your program grade, assigned by the TAC. See Phase 1 submission tutorial for more information.
• I-time: The total integration time allocated for your QSO program by the TAC. This time is automatically calculated during the preparation of your observation groups and cannot be exceeded. The "readout time" and additional overheads are calculated automatically for each individual exposures within an observation block.



Button	Function
	Open the quick help files to the current page.
	Cancel all the modifications done to the current page and reload data stored in the database.
	Save all the modifications done to the current page in the database and reload current page.
	Save the content of the current page in the QSO database and open the next form.

5) Program Constraints

This page requests some important information regarding your QSO program. Depending of some of the answers you provide here, options will become available in the subsequent pages of PH2. This page is divided into several sections:



• Monitoring: If your program requires several executions of the same observation spread over a specific period, monitoring is required and you should indicate so here. Monitoring is defined as executing an observation for a certain number of iterations, N_iter, within a specific period, P. A date for the first observation can be specified but is not obligatory. These parameters can be entered in the observation groups form. Repeating an observation block for a certain number of times but without a specific period is not considered monitoring. At present, it is not possible to have monitoring for sequences of observation blocks (SOB), only individual blocks.
• Time Constraints: It might happen that some of your observations will have to be performed within certain dates and times. If this is the case, you can indicate so here. The options will then be available in the OG form. Note that time constraints are the most demanding constraints on a queue system. Use only if science depends on it!
• REEL: This is an option in PH2 that allows the user to create specific links between observation groups. In short, we can resume the REEL concept as: " if OGx is observed and validated, then observe OGy within a certain opportunity window". The REEL are a powerful way to prepare specific sequence of observations, if science requires to do so. REEL must be used only if necessary, not for instance in the context "the object should be observed with this filter because it was observed with this other filter first".
• Moving Targets: If your targets (or some of them) have changing coordinates with time (e.g. comet), you can define their ephemeris in a special table located further in PH2. To access it, you must indicate so here.
• OG Scheduling: Some programs with ESPaDOnS require that the OGs are observed at precise dates and times during the semester. For instance, a target can be observed at 20 different dates and times, all valid. The OG Scheduler tool allows the PI to define a list of dates and times. This is an optional tool, only for specific programs requesting special time constraints.



• Program Comments: It is important that the investigators transmit any comments that they judge useful for the QSO Team in their endeavor to carry out the observing program. This space is reserved for general comments on the program. These comments will be available at all time during the preparation of the queues and while performing the observations. If you have any special constraints, requirements, etc., they can be included here.

HINT: Do not be shy in this section! Examples of valuable comments include: "Observations to be done in photometric conditions only"; "Thin cirrus acceptable"; "Dark time requested but 20% Moon at more than 45 degrees is acceptable"; "Observe high priority groups first", etc. We use these comments all the time. The more we know, the better!



• Calibration Comments: It is important that the investigators transmit any comments that they judge useful for the QSO Team in their endeavor to carry out the observing program. As explained above, the QSO team will execute a calibration plan on a nightly basis to make sure that all data can be appropriately reduced. However, feel free to indicate any specific requests here regarding calibrations, if needed.



• S/N Comments: It is important that the investigators transmit any comments that they judge useful for the QSO Team in their endeavor to carry out the observing program. This space is reserved for comments on the expected S/N for your targets. The observing team will have the measured S/N for each spectrum and can use this information as guideline to make sure that the signal meets the requirements. Values of S/N for the different orders can be obtained using the ESPaDOnS exposure time simulator. We strongly encourage to include some values in this comments field!



• Libre-Esprit Options: The reduction pipeline is based on the Libre-Esprit package. Several options are possible for the data reduction. The user should consult the Libre-Esprit tutorial for a description of these options.



• Data Distribution: CFHT is offering only one option for the data distribution: network distribution. Your raw and processed data will be placed in a special HTTP site at CFHT for downloading over the network. The Upena Team is responsible for doing the data reduction and ensuring that data, raw and processed, are available by noon the following day. The PH2 options offered are irrelevant for ESPaDOnS.



• Data Distribution Recipient: Only one copy of the data will be distributed. By default, the PI will receive the files, unless an "alternate" person is selected.

6) Fixed Targets

This page represents the first step toward the creation of the observation blocks. This is where the user defines all the targets of the program and their precise pointing coordinates. The main section of this page is composed of a table and a few buttons for the manipulation of the entry fields:



HINT: The maximum number of rows displayed at once is five. The "Next Page", "Previous Page" buttons can be used to navigate between the different pages. The blue hyperlinks FT# represent the first row of each individual pages and can also be used for moving quickly from a page to another.

• Top Row:
• RunID: Identification of the program you are currently working on.
• Table Status: List of the current rows and the total number of configurations already defined in the current table.
• Instrument: Link to the ESPaDOnS Web page.
• Table (1):
• Label:The label identifies a row in the table. The fixed targets are simply identified as FT#. The label is automatically updated if the rows are changed.
• Name: The name of the target, as given by the user. A mnemonic name (e.g. Virgo Field1) will make the subsequent steps easier. The name must be shorter than 20 characters.
• Aladin: Aladin is an efficient software to display sky images. It has been developed by CDS and can be very useful for different tasks in PH2. However, it is optional: pointing coordinates can be entered directly in the target table. First, if you know the real astronomical name of your target, Aladin can find the coordinates for you. Just enter the name (e.g. NGC 4258) and click on the Aladin "FOV" buttons (Note: To search by name, the coordinates entry fields have to be empty). The CDS database will be contacted and a window showing an area surrounding the pointing coordinates will be displayed. If you know already the coordinates of your target and want to verify the positioning or transform the target coordinates into pointing coordinates, you can enter the coordinates and click again on the Aladin button.
  The "FOV" option displays an 15 x 15 arcmin image of the field (1 pixel = 1.7"); on this image you have a blue square of about 2' illustrating the field of view of the ESPaDOnS guider. The 1.6" entrance fiber is represented by the little blue circle within the red cross, centered on the target coordinates. This HR image can be used for accurate positioning. However, due to the display limitations and the astrometry of the plates, the pointing accuracy of Aladin will never be better than 3-4". ATTENTION: Aladin works only with coordinates for J2000.0. The coordinates sent back are automatically in J2000.0. As an example, the field around the quasar 3C273 would be represented as follow:


Stars in the field are identified from the GSC (red circles) catalogs. The coordinates indicated at the top left refer to the position of the cross, which represent the entrance fiber of the spectrograph. By clicking and holding the left button of the mouse, the blue circle can be moved across the field to position exactly the object where it should be. To be very precise, the zooming option can be used. When the object is correctly positioned, the pointing coordinates (that is, the center of the mosaic showed as the red cross) can be transferred to PH2 by simply clicking on the "Grab" button in the PH2 table, before closing the Aladin window. The coordinates will be included in the table. That's it!

• Coordinates: Coordinates of the targets can be entered manually through these entry fields, or with Aladin. The "check" and "save" options always verify that no typos resulting in illegal coordinates values (e.g. RA=26h) have been entered. No values lower than -60 degrees in DEC are allowed.
• Epoch:The Epoch of the coordinates of the target. It can be fractional (e.g. 2001.3). All epochs between 1900.0 an 2050.0 are allowed.
• Magnitude: This field is optional although we recommend that this information is given by the user. It will be very useful for the QSO Team to know what target brightness to expect during the observations.
• Select: Row selection for manipulation of the table with the "Duplicate", "Delete", etc. buttons.

Downloading/Uploading Target Files. At the bottom of the page, an option is available to download/upload a PH2 target list:

• Astrores: Astrores is a special XML format that is becoming standard in astronomy for this kind of application.

The "Download" option allows you to transform a list of target in the table of PH2 into an Astrores formatted file. For instance, if you have already a list of targets in a program that you would like to transfer to another program with a different runID, you can first go to the program with the target list, download it to an file on your local machine, edit it if necessary, and upload it in the appropriate program with the "upload" button. You can use also this button to create a template for further use: for instance, first enter a target, click "download", and you'll see the correct format for the Astrores template.

To upload a file, you can first save the example on your local machine by clicking on the "Astrores" button. All you have to do is to copy this template to your local machine within your favorite editor and then edit the ASCII table with your targets (do not change the XML code!). It is essential that you keep the appropriate format. Use the vertical lines as references for the number of spaces allowed. Most editors will keep this format automatically so it should not be a problem. Important Note: Versions 6 and 7 of Netscape have an unfortunate bug affecting the translation of the XML template downloaded and ruins the format of the file. There is a workaround: 1 - After opening the Astrores template, go to "view page source" in the top menu. This will shows the HTML code. 2 - With the mouse, copy all the code between the" XMP and /XMP lines and paste to an editor. 3 - Edit the two occurrences of lowercase "table" appearing in the code to uppercase "TABLE", and save. The file is now ready to be edited and is uploadable. You can upload the file to PH2 by giving the right path and by clicking on the "Upload" button. We strongly encourage you to verify carefully your target list after that!

Button	Function
	Add N rows to the table.
	Duplicate the selected rows N times.
	Select all the rows in the table. Clicking again on it deselect all the rows.
	Delete the selected rows. A confirmation window is displayed.
	Check the entries for errors. The errors found are displayed in a separate window and are indicated by a red frame in the table. An automatic check is done also when the form is saved or when the "proceed" button is activated.
	Display the next rows of the table.
	Display the previous rows of the table.
	Cancel all the modifications done to the current page and reload data stored in the database.
	Save all the modifications done to the current page in the database and reload current page. Regular saving of the current form is recommended!
	Save the content of the current page in the QSO database and open the next form.

7) Ephemeris

This form allows the user to define targets for which coordinates might rapidly change with time. The form is only accessible if requested in the Program Constraints section.

1. At least 3 sets of coordinates must be entered, preferably 5.
2. If the moving target moves slowly and is to be observed with sidereal rates (with or without guiding), the set of coordinates closest to the observing time will be sent to the telescope.
3. If the moving target moves quickly enough that non-sidereal rates are necessary, sets of coordinates (at least 3, up to five) will be picked, and sent to the Telescope. Correct coordinates and rates will be interpolated by the Telescope Control System.

The general idea behind the ephemeris form is very simple: define a series of coordinates for a specific time for a given target. The table below shows the entry fields for the ephemeris of the target specified:

The top of the form allows the user to first give a name to a target. For instance, in the pull-down menu on the left, you can select "New". In the central window, you can then give a name to your target. When you click on "Update", the table in the middle frame window is then created and your target receives a label "ET#" (for "ephemeris target").

Each row in the table is an ephemeris labeled "E#" and includes the UTC Date (beginning of a night in Hawaii is ~ 05:00:00 UT) and the coordinates of the target for this date (in J2000.0). As many ephemeris as wanted can be entered for a target and as many targets as wanted can be entered for a program. After defining all of the ephemeris for the target, we recommend that you save it immediately before starting defining the ephemeris for the next target (if needed). When saved, the ET will appeared in the list of targets used for defining the observation blocks (below).

Since entering a large number of ephemeris can be cumbersome the Astrores format template can be used at the bottom of the page to upload ephemeris for a given target (that is, one upload per target is necessary). To do so, apply first the procedure described above (create a new target name and click on update), since the name of the target cannot be defined from the Astrores template. Below there is a Astrores template (XML) that can copied on your local machine and then used to upload ephemeris to the table in the middle frame. (You can also create your own template on your local machine by first defining a target and click on "download". However, see important note in the fixed target section if you are using Netscape 6 and 7). It is important that the format is respected. You can then prepare the ephemeris for the target as seen in the lower part of the template and save the template under a specific name. When saved on your local machine, you can then upload it by specifying the path. Check that everything is fine and then save the ephemeris table for that target. Repeat if necessary!

<?xml version = "1.0"?>
<!DOCTYPE ASTRO SYSTEM
"http://vizier.u-strasbg.fr/xml/astrores.dtd">
<ASTRO ID="v0.8"
xmlns:ASTRO="http://vizier.u-strasbg.fr/doc/astrores.htx">

<TABLE ID="Table">

<NAME>Ephemeris</NAME>

    <title>Ephemeris for
CFHT QSO</title>
    <!-- Definition of each field
-->
    <FIELD name="DATE_UTC"  datatype="A" width="19"
format="YYYY-MM-DD hh:mm:ss"> 
        <DESCRIPTION>UTC
Date</DESCRIPTION>
    </FIELD>    
    <FIELD
name="RA_J2000"  datatype="A" width="11" unit="h"
format="RAh:RAm:RAs">
        <DESCRIPTION>Right ascension
of target</DESCRIPTION>
    </FIELD>

    <FIELD
name="DEC_J2000" datatype="A" width="11" unit="deg"
format="DEd:DEm:DEs">
        <DESCRIPTION>Declination of
target</DESCRIPTION>
    </FIELD>
    <!-- Data
table -->
<DATA><CSV headlines="4"
colsep="|">
<![CDATA[
DATE_UTC           |RA_J2000
|DEC_J2000  |
YYYY-MM-DD
hh:mm:ss|hh:mm:ss.ss|+dd:mm:ss.s|
1234567890123456789|12345678901|12345678901|
-------------------|-----------|-----------|
2003-06-04
06:30:00|09:34:00.00|+16:38:00.0|
2003-06-05
06:30:00|09:35:15.00|+16:31:50.0|
2003-06-06
06:30:00|09:36:33.00|+16:25:40.0|
]]></CSV></DATA>

</TABLE>
</ASTRO>

Since ESPaDOnS is a fiber-fed instrument, it is important to make sure that right target is put into the entrance fiber. Pointing of the telescope is limited to an accuracy of about +/- 10" on the sky so in crowded fields or when the target is faint, it might become difficult to identify the right object to put into the fiber. PH2 now hass a mandatory tool where the user can precisely identify their targets in finding charts reproducing the field of view of the guiding window seen at the telescope. This tool is based on the Aladin system and is very easy to use. The idea is that the user first identifies his/her target with a little red arrow in the Aladin field and save the chart (as a .gif file) in the QSO database. When a finding chart is available, it is automatically displayed next to the guiding window for the QSO observer at the telescope. For obvious reasons, finding charts can only be defined for fixed targets; moving fields are not possible.

The top frame allows the user to first select one of the fixed target, as defined in a previous form. Then the user can click on "FOV" which will open a Aladin window, displaying the 2' x 2' field of view of the ESPaDOnS guiders and a DSS image of the sky:

An example of such a field is displayed below. Contrary to the Aladin version available for the Fixed Targets form, the field of view marked with a blue square cannot be moved around.

The user can then select the last button at the bottom right called "point". This enables an option implemented by QSO so a little red arrow can be positioned in the field of view, next to the right target, by one click of the mouse. When this is done. the user goes back to PH2 and clicks on the "grab" button. When this is done, the table in the middle of the form is updated with the finding chart:

• Label: Identification of the finding chart, for each individual target.
• RA/Dec: Coordinates of the fixed target. The field of view is centered on these coordinates.
• Comments: Comments on the finding charts, target, etc. Anything useful!
• Status: Two values are available: Pending/Ready. "Pending" means that the chart was prepared but not saved in the database yet. Clicking the save button at the bottom of the page will do just that and the status will be changed to "ready".

Note that the finding charts are displayed in the summary of the program.

12) Instrument Configurations

This is the second mandatory step in the creation of the observing blocks. This page allows the user to define all the instrumental configurations necessary for the program. The same configuration can be used several times with different targets. The main section of the page is a table with different options under pull-down menus or editable entry fields. Some entry fields are dynamically linked, that is, a selection in one of the pull-down menu will change the options in another one.

But, first the top frame can be used to help in the preparation of these configurations by offering the following elements:

• List of Targets: This little window displays the name of the targets defined in the previous form. It is just available as a mnemonic resource so that the user does not have to navigate back and forth between pages to look at the list of targets. Nothing to click on,it's just a scrolling display!
• Stokes Parameters Primer: This window presents the three main Stokes parameters and their meaning in terms of polarization of the light.
• Exposure Time Calculator: There is an exposure time calculator available for ESPaDOnS. It is maintained by J.F. Donati, in Toulouse, and the interface is automatically opened when this link is activated. We strongly recommend that you use the calculator during the preparation of your observations. By doing so, you will be able to specify the right parameters for your observations (exposure time, S/N, seeing) in order to achieve your science goals.
• Defaults Observing Mode/Readout Mode: This presents some defaults that can be used to pre-populate the instrument configuration table, prior to creating the individual rows. This can save quite a bit of time if a lot of configurations need to be defined.

The middle frame of the configuration page consists in a table and buttons to manipulate the entry fields:

• Top Row:
• RunID: Identification of the program you are currently working on.
• Table Status: List of the current rows and the total number of configurations already defined in the current table.
• Instrument: Link to the ESPaDOnS Web page.
• Table:
• Label: The label identifies a row in the table. The instrument configurations are simply identified as I#. The label is automatically updated if the rows are changed.
• Name: The name of the instrument configuration, as given by the user. A mnemonic name (e.g. 3C273 Q, Polar Q Normal) will make the subsequent steps easier. The name must be shorter than 20 characters.
• Observing Mode: Three observing modes are offered with ESPaDOnS: Polarimetry, Spectroscopy (Star only), Spectroscopy (Star+Sky). This entry field allows the user to define exactly which mode should be used. For more details on these modes, pleaser refer to the ESPaDOnS Web page.
• Readout Mode:The current CCD can be used under three different readout modes: Fast, Normal and Slow. Each mode has its own readout time (charged), gain and readout noise. Note that the overheads charged are more than the readout time; operational overheads to start and finish an exposure are necessarily larger than just the readout time. The table below presents the necessary information.

ReadoutMode	Noise/Gain	Overhead
Fast	8.0e ; 1.8e/ADU	40s
Normal	4.5e ; 1.4e/ADU	60s
Slow	2.9e ; 1.2e/ADU	85s

• Stokes Parameter In polarimetric mode, four Stokes parameters are available for ESPaDOnS: QUVW. Only one parameter can be selected for a given instrument configuration; if two parameters must be observed consecutively on a given target, this can be arranged at the OB/OG level. In spectroscopy modes, only the I (intensity) parameter is made available.
• Exptime:This is to define the exposure time (in seconds) for each individual exposure of the instrument configuration. Minimum exposure time is 1 second and maximum is 7200 seconds. Note: Fractional exposure times are not possible with ESPaDOnS.
• Nseq:This is the number of sequences, in other words, the number of times the exposures should be done for a given instrument configuration. For polarimetry, Nseq = 1 means that 4 exposures will be taken for the Stokes parameter specified.
• I-time: The total I-time calculated for a given configuration, in seconds. The value is calculated and displayed after a save. The calculation uses an algorithm defined below. Total I-time for one configuration cannot exceed 7200 seconds.
• Select: Row selection for manipulation of the table with the "Duplicate", "Delete", etc. buttons.

Integration Time Calculation

The integration time (I-time) calculation is done for each instrument configuration (IC) according to the general formula:

I-time (IC) = Nseq x [S(Obs.mode) x [Exptime + Overheads (readout)]]

Example: In polarimetric mode, the user requires 5 sequences with the Q parameter, the normal readout mode and exposure time of 100 sec/exp. We get: IC = 5 x [4 x (100 + 60)] = 3200 seconds (20 files generated).

Button	Function
	Add N rows to the table.
	Duplicate the selected rows N times.
	Delete the selected rows. A confirmation window is displayed.
	Select all the rows in the table. Clicking again on it deselect all the rows.
	Check the entries for errors. The errors found are displayed in a separate window and are indicated by a red frame in the table. An automatic check is done also when the form is saved or when the "proceed" button is activated.
	Display the next rows of the table.
	Display the previous rows of the table.
	Cancel all the modifications done to the current page and reload data stored in the database.
	Save all the modifications done to the current page in the database and reload current page. Regular saving of the current form is recommended!
	Save the content of the current page in the QSO database and open the next form.

13) Constraints

This page presents the table designed for defining the sky constraints under which the observations should be undertaken. The top frame displays information about the targets and instrument configurations defined previously:

• List of Targets: This little window displays the name of the targets defined in the Fixed Targets form. It is just available as a mnemonic resource so that the user does not have to navigate back and forth between pages to look at the list of target. Nothing to click on, it's just a scrolling display!
• List of Instrument Configurations: This window displays the names of the instrument configurations and some of their content defined in the previous form. It is just available as a mnemonic resource so that the user does not have to navigate back and forth between pages to look at the list of configurations. Nothing to click on, it's just a scrolling display! The different times between parenthesis indicate how the calculation for the total I-time of the instrument configuration was made.
• Exposure Time Calculator: There is an exposure time calculator available for ESPaDOnS. It is maintained by J.F. Donati, in Toulouse, and the interface is automatically open when this link is activated. We strongly recommend that you use the calculator during the preparation of your observations. By doing so, you will be able to specify the right parameters for your observations (exposure time, S/N, seeing) in order to achieve your science goals.

The middle frame presents the table for the constraints:

• Top Row:
• RunID: Identification of the program you are currently working on.
• Table Status: List of the current rows and the total number of constraints already defined in the current table.
• Instrument: Link to the ESPaDOnS Web page.
• Table:
• Label: The label identifies a row in the table. The constraints are simply identified as C#. The label is automatically updated if the rows are changed.
• Name:The name of the constraint, as given by the user. A mnemonic name (e.g. Best Conditions) will make the subsequent steps easier. The name must be shorter than 20 characters.
• Seeing: Pull-down menu for indicating the seeing constraint. The seeing constraint has normally the highest priority in the selection of the program to be executed by the QSO Team. However, for ESPaDOnS, this criterion does not have the same weight because the seeing is not a major parameter affecting ESPaDOnS observations. So the seeing bands proposed are rather broad. The next table illustrates some statistics on the image quality on Mauna Kea. Note that if you select for instance the seeing to be between 1" and 1.5", it is quite possible that the observations will be performed under 1" anyway, depending on the program ranking and the pressure from other programs. Important: If your program includes very restrictive time constraints, it is strongly suggested to request modest constraint on the seeing!
• Airmass:Constraint on the airmass for the observations. The weight of this constraint is usually not very strong in the selection process of the program to be undertaken, although we always try to respect it as much as possible. Four options are available: < 1.2, < 1.5, < 2.0, any. Unless absolutely necessary, < 2.0 or "any" are the preferable options. We will aim for < 1.5 but beware that scheduling constraints might forbid the QSO Team to reach this goal for all of the observations.
• Select:Row selection for manipulation of the table with the "Duplicate", "Delete", etc. buttons.

A note on the Seeing. The constraint on the seeing is usually the strongest criterion for the selection of a program to be undertaken. Our goal is to never try observations during conditions exceeding the upper limit defined by your constraint by more than 10%, and at most 20%. The probability that your program is executed depends somewhat on this constraint, even with ESPaDOnS; the table below offers some statistics. Be realistic! In particular, for Programs with the C grade, it would be much preferable not to specify a seeing better than 1.0". It is important that you request a realistic IQ also when your targets do not reach a low airmass. For instance, asking for better than 1" when the airmass is never smaller than 2.0 is not very likely to happen... By definition, snapshots programs MUST request IQ > 1.5".

Image Quality (IQ) on Mauna Kea	Frequency (%)
IQ < 1.0"	70-80
1.0" < IQ < 1.5"	20-30
IQ > 1.5"	0-5

Button	Function
	Add N rows to the table.
	Duplicate the selected rows N times.
	Delete the selected rows. A confirmation window is displayed.
	Select all the rows in the table. Clicking again on it deselect all the rows.
	Check the entries for errors. The errors found are displayed in a separate window and are indicated by a red frame in the table. An automatic check is done also when the form is saved or when the "proceed" button is activated.
	Display the next rows of the table.
	Display the previous rows of the table.
	Cancel all the modifications done to the current page and reload data stored in the database.
	Save all the modifications done to the current page in the database and reload current page. Regular saving of the current form is recommended!
	Save the content of the current page in the QSO database and open the next form.

13) Observation Blocks

This is it! This page allows the user to link all the previously defined entities within observation blocks (OB). The main page is divided into two main frames:

HINT: The number of rows displayed at once is only a few. The "Next Page", "Previous Page" buttons can be used to navigate between the different pages. The blue links OB# represent the first row of each individual pages and can also be used for moving quickly from a page to another.

• Top Frame:
• Target Selection: The first element to enter in the creation of the OB is one target. This window lists all the targets previously defined. To select one, simply click on it with the mouse. The selection is then highlighted by a darker background. It is also possible to select several targets in the list by holding the "control" button. An OB will be created for each target selected when the "Create OB" button is pressed. The selection remains visible after the creation of the OB with the "Create OB" button.
• Configuration List: The second element to enter in the creation of the OB is the configuration list. An OB can have one or several configurations. To achieve that, you must create a list with first selecting the configurations and second, by adding them to the list on the right. You can change the order of the configurations with the up and down arrows. The configurations will be executed in the order given in this list. The total integration time for the instrument configuration is indicated; the calculation is made using the algorithm defined earlier. NOTE: With ESPaDOnS, it is NOT possible to define an block using two different observing modes. This is to avoid problem with getting the right calibrations.
• Constraint Selection: The final entity to create an OB is the constraint. As with the target, the selection is done with the mouse and remains highlighted after the creation of the OB.
• Defaults: It is possible to define the defaults of certain parameters defining the observing blocks. Photometric: Should your observations be done during photometric time only? See below for details. Tracking: Guiding is possible with sidereal tracking, but non-sidereal tracking is also offered.

• Middle Frame:
• Label: The label identifies a row in the table. The observation blocks are simply identified as OB#. The label is automatically updated if the rows are changed. By clicking on the label in the table, the selections are displayed again in the windows of the top frame.
• Target: Target label used for this observation block.
• Configuration(s): List of configurations used for this observation block. Individual configurations are separated by the "+" sign and the order of execution goes from left to right.
• Constraint: Constraint label used for this observation block.
• OB I-Time: Total integration time (I-time) requested for the execution of this observation block. Since it is much easier to schedule short observation blocks, the total I-time for one OB cannot exceed 2 hours.
• Tracking: The choices are: Sidereal with guiding, or non-sidereal with tracking only.
• Type: Type of observation. Only "object" is available. This entry is not available for users other than the QSO team.
• Photometric: Does this OB require to be done during photometric time only? The definition for this flag for ESPaDOnS differs from MegaCam. For certain ESPaDOnS programs, the science goals might require that the observations must be done under photometric sky only. This flag is disabled by default. Note that only about 50% of the time on Mauna Kea is photometric so use with discretion...
• Comment: You can enter a comment for each individual OB. These comments are visible at all time during the observations. The comment associated to the OB is included in the FITS headers of the images (keyword:CMMTOBS).
• Select: Row selection for manipulation of the table with the "Delete" button.

Button	Function
	Create an Observation Block, after selecting one target, one or several instrument configurations, and one constraint.
	Modify an observation block. After selecting one or several OBs in the table ("select" column in the table), the OBs will be modified according to the parameters defined by the top lists after clicking this button. Thus, it is possible to change the content of an OB without having to delete it and create it again. Important: You must make sure that the total I-time allocated for your program has not been exceeded after modifying the OB.
	Delete the selected rows. A confirmation window is displayed.
	Select all the rows in the table. Clicking again on it deselects all the rows.
	Check the entries for errors. The errors found are displayed in a separate window and are indicated by a red frame in the table. An automatic check is done also when the form is saved or when the "proceed" button is activated.
	Display the next rows of the table.
	Display the previous rows of the table.
	Cancel all the modifications done to the current page and reload data stored in the database.
	Save all the modifications done to the current page in the database and reload current page. Regular saving of the current form is recommended!
	Save the content of the current page in the QSO database and open the next form.

14) Observation Groups

This page presents the last step in the preparation of your observations: the creation of the observation groups (OG). The OGs will be the entities scheduled at the telescope so this step is necessary, even if you have previously defined all the observation blocks. The OG page is presented below:

• Top Frame:
• Observation Group Type: Three types of Observing Groups (OG) are possible: 1) 1OB (Single OB) means that the observation blocks previously prepared are transformed into individual OGs. If all the OBs should be transformed into OGs, this can be done automatically by selecting the "Quick Create OGs" button; it is the recommended approach for the QSO mode. 2) Monitoring OG (MOB) means that one specific OB will be observed a certain number of times within a given period. The selection of the OB is done through the list on the right and the OG monitoring parameters are entered in the window on the right. 3) OBs can be linked together to form a sequence (SOB). The list of OBs to link can be done with the entry field on the right. Beware: only OBs requesting the same constraint can be linked together. We also want to discourage the use of SOBs as much as possible: shorter 1OB OGs are easier to schedule and execute!
• OB List: Except when one desires to transform all the OBs into OGs with the "Quick Create OGs" button, the creation of an OG of any type requires a list of OBs. This can be done using this window. The order of the OB within the list can be altered with the arrows. When clicking on an OB from the list, the window on the right displays a summary of its content. There is a new feature in PH2: it is now possible to do multiple selection of the OB in the left window before clicking on the "add" button. This can diminish greatly the number of clicks necessary to create a sequence of OBs for instance. If multiple OBs are found in the list (on the right) and the "single OB" option was selected, one OG per OB in the list will be created if you click on "Create OG(s)" in the table. If "monitoring OG" is selected and multiple OB are in the list, each OG created will have the same monitoring parameters.
• Observation Groups Options: See Below

• Middle Frame:
• Label: The label identifies a row in the table. The observation groups are simply identified as OG#. The label is automatically updated if the rows are changed.
• Type: Identifies the type of groups: 1OB (single OB); MOB (monitoring OB); SOB (sequence of OBs).
• OB: Identifies the observation block(s) used to create this specific observation group. Clicking on an OB from this entry field display again the content of the block in the top frame.
• Group I-time: Total integration time in seconds for this Observation Group. If monitoring, I-time (OG) = N(iterations) x I-time (OB). Maximum I-time for a 1Ob or SOB is 7200 seconds.
• Priority: Priority (high, medium, low) of this observation group for your program. This will be used by the QSO Team during the selection process leading to the execution of the observations for your program. Selecting "lowest" does not mean that this OG will never be done; we aim for the completion of programs. It is only a way to ensure that if the completion level of your program is not 100%, that at least the most important targets have been observed.
• Comment: Any comments you might think would be useful for the QSO Team.
• Select:Row selection for manipulation of the table with the "Delete" buttons.

• Third Frame:
• I-Time Allocated: Integration time allocated by the Time Allocation Committee for your program. This time cannot be exceeded!
• I-Time Calculated: Total integration time requested for all the observing groups defined in this page. It automatically includes the charged overhead for all of the individual exposure in the OG. The I-time is automatically calculated after the creation of an OG.
• I-Time Left: I-time allocated) - (I-time calculated); it cannot be negative. If I-time left < 0, a warning window is displayed. The new OG is included in the table but cannot be saved. You must modify the OG table in order to get I-Time equal or larger than zero. If you click on "cancel" instead, the new OG is removed from the table.

Observation Groups: Options

There are three important options available for the Observation Groups, useful to precise specific observations. These options are first presented in the "Program Constraints" section and appear only in the OG form if requested.

Monitoring Parameters: Parameters for the monitoring OGs. This window appears only if you have indicated that your program requires monitoring. You can enter a period in hours, days or weeks. To enter the parameters, first select the unit and then fill up its value. The number of iterations corresponds to the numbers of times that this OG should be done at the interval of the period. The minimum number of iterations corresponds to the acceptable minimum number of observations to reach the science goals. We will reach for the total number of iterations but only OGs that have met the minimum number of iterations will be considered valid.

Relational Execution Link (REEL): For certain programs, it is important that the observations take place within a specific sequence of events. For instance, if OG1 is done and validated, only then OG2 should be done within a certain timescale. It is possible to manage this kind of sequence at a higher level on a small scale (that is, during the preparation of the queues) but on a larger scale, it is much more preferable to have these options "hard coded" in the database. To cover such possibilities, we have developed the concept of the REEL: basically, it is possible to create a causal link between observation groups. This can be done in the last window on the right, if you have selected the REEL option in the "Program Constraints" section. Essentially, a REEL means this: "After the validation of the reference OG, the linked OG should be done within a certain delay." You can then link several OGs, if needed. For instance, OG3 to OG2 to OG1, etc. The links created appear in the OG table. An example of a REEL sequence is showed below.

IMPORTANT: The REEL option should be used ONLY when appropriate. If the observations cannot be done within the window defined by the (delay +/- delay) (due to bad weather or technical problems), the completion of the chain will not be done. Also, the logic involved in defining the REELs in PH2 is complicated. It is preferable to define first all the OGs, save them, and then create the links. This can be done using the "modif OGs" button: after defining all the OGs, you can create the REEL link by selecting the OG from its label, entering the REEL parameters, click in the "select" box on the row, click on the "modif OGs" button and save. Deleting OGs which have REELs will not be permitted.

Time Constraints: For certain programs, some observations must be done during a specific time range. These entry fields, available in the OG table, allow the user to define such a constraint by specifying a period for which the observations should be undertaken. The user can enter a date and a time (HST) to specify such a window. These fields are optional and will appear only if required in the "Program Constraints" page. It must also be understood that these constraints are very severe: if for a reason or another (e.g. bad weather or conditions not meeting the sky constraints) the observations cannot be done during the period required, these observations will not be attempted again and will be taken out of the queue. Time constraints are not compatible with REELs, for example if an OG is to be done after another one is validated, that OG cannot have time constraints as well.

Button	Function
	Create one observation group (it can be of types 1OB, MOB, or SOB).
	Transform all the observation blocks defined in the previous form into observation groups. The recommended approach!
	Modifying an existing observation group. After selecting one or several OGs in the table ("select" column), the OGs will be modified according to the parameters redefined by the top lists after clicking the "modif OG(s)" button. So, it is now possible to change an OG without having to delete it first from the table! Important: You must make sure that the total I-time allocated for your program has not been exceeded after modifying the OG(s).
	Select all the rows in the table. Clicking again on it deselect all the rows.
	Delete the selected rows. A confirmation window is displayed.
	Check the entries for errors. The errors found are displayed in a separate window and are indicated by a red frame in the table. An automatic check is done also when the form is saved or when the "proceed" button is activated.
	Display the next rows of the table.
	Display the previous rows of the table.
	Cancel all the modifications done to the current page and reload data stored in the database.
	Save all the modifications done to the current page in the database and reload current page. Regular saving of the current form is recommended!
	Save the content of the current page in the QSO database and open the next form.

15) OG Scheduler

For certain ESPaDOnS programs, observations can be done at specific but multiple times during a semester. For instance, if the observations has to be done during a specific transit of a binary system, several dates and times might be possible. These dates and times can now be defined precisely with a new tool, the OG scheduler, developed specifically for this purpose. The tool produces a series of possible dates and times for which one or several OGs should be executed. The OG scheduler is optional and should be used only for those few programs which really require this tool.

A note on Time Constraints

Before explaining how to use the OG scheduler, it is important to provide a clear distinction between the different possibilities offered by PH2 on how to define time constraints with ESPaDOnS. There are 3 distinct possibilities, two of them already introduced in the previous section on the OG form.

1. Time Constraint Window: When requested in the program constraints page, it is possible to define time windows during which a OG should be done. This is the type of possible time constraint defined in the OG form. The OG will only be done within that time window.
2. Monitoring: A specific OG might be done several times during the course of a semester, for monitoring a specific target. The monitoring is defined by a number of iterations and a period. The monitoring OG can be done within a time window, if desired.
3. OG Scheduling: Several specific dates and times for a given OG can be needed, not just a window. OG scheduling refer to the possibility to define several dates and times for which an OG can be done. In other words, "an OG can be done at this date and time, or that one, or that one, etc...". Even a monitoring OG can be scheduled that way. In that case, it would mean "start this monitoring OG at one of these specific dates and times, then continue the monitoring of target according to the iterations and monitoring parameters (period)".

It is very easy to define a series of dates and times for which a OG could be done. NOTE: All dates and times specified within PH2 OG Scheduler are in HST. The top frame of the OG Scheduler looks like this:

• Top Frame:
• Select OGs: You can select one or several OGs for which the dates and times should be applied to.
• Enter Start Date:This is the first date and time possible for the OG(s) selected. The date and time are in HST.
• Define Period: This is used to created the series of dates and times for the entire semester.

After entering these parameters, by clicking the "create" button in the middle table will create the list of dates:

• Middle Frame:
• Label: Each scheduling list is labeled OS#.
• OG: OG for which the list of dates and times applies. Note that the same list can apply to several OGs and that one OG can have more than one list.
• Startgin Date and Time: First date and time acceptable, in HST.
• Period: Period, as defined in the top frame.
• Status: Pending/Active. Active is when the table has been saved.
• View: This opens a small window with the list of the first 25 dates generated by the entry fields parameters. An example is given below. The summary displays all the dates generated.

16) Summary

This page opens a complete summary of what is currently the Phase 2 status of the program. As showed below, the summary can be sent by e-mail to several destinations as a HTML attachment (to be compatible with people not using a browser for their mail system), by clicking on the "Send this page to" button. The summary can also be printed using the "Print" button of the browser used for PH2.

HINT: We strongly suggest that you keep the summary (printed or electronic) of the final version of the program submitted during the Phase 2. It will be useful to you for monitoring the progress of your program with the night reports and for any necessary communication between you and the QSO Team regarding the observations.

17) HelpDesk

The HelpDesk has been discontinued and will not be used for 2009A. For any question, comment, or suggestion, please send an email to the QSO Team: qsoteam -=at=- cfht.hawaii.edu

18) Logout

To exit PH2, you must confirm it by clicking on the "Logout" button in the window below. If you do not want to do so, select another page with the navigation buttons on the left frame.

Button	Function
	Logout from PH2 and open the first page of PH2.

D - A Few QSO Rules [A - Introduction] [B - Overview] [C - Detailed Tutorial] [E - Other issues] [TOC]

Maybe the most difficult task facing the queue observing model is found in the selection process leading to the execution of a science program. This selection can be based on simple criteria (e.g. mounted filters) but it becomes immensely complicated when other parameters like actual sky conditions, completeness level, science merit, monitoring and time constraints, filters availability, or targets visibility are taken into account.

The process, resulting in the choice of a specific program to be undertaken for the queue observations with ESPaDOnS, will be done in three steps:

1- Selection: This is the first selection of the viable observations stored in the database according to instrumental constraints, sky constraints, actual sky conditions, completeness level, and the position of the targets.

2- Ordering: This second step creates a prioritized list of observations to be sequentially executed regarding their TAC grade, rank, target positions, and user's priorities.

3- Human filtering: The final step consists in the possibility for the QSO observer to modify the queue list according to special constraint like the focus sequences, calibration plan, etc.

Without going into too many details, each of these steps include an algorithm based on a set of observing rules. The rules given here are not presented in any order of priority. Among them:

• As much as possible, observations should not be obtained in worse conditions than required.
• Observations can be obtained in conditions better than required, if no other observations actually requesting these conditions are available.
• For very bad seeing periods (>1.5"), the snapshot programs requesting bad conditions should be executed, unless other possibilities exist among the regular programs.
• The priority of the programs started is automatically increased compared to programs not started.
• Unless an upper limit is specified during the Phase 2, observations will be tentatively done with airmass smaller than 1.5.
• During ordering, the priority goes from grade A to B to C, followed by the snapshots. Inside these grades, priority is given according to the TAC rank.
• As much as possible, the observer will execute the observations belonging to a given program according to the priority index given by the investigators.
• A QSO night with ESPaDOnS should never be completed without getting all the necessary calibrations for all the programs fully or partially executed during the night.
• No programs will be recycled for completion during the next semester.
• For a given grade, priority will be given to programs with time constraints in case of conflicting scheduling.
• When started, a monitoring program receives a higher priority so that the observations to be repeated can be carried out within the specified timeframe period.
• The QSO Team will always try to obtain the required number of observations for a given monitoring program. In case of other constraints, the minimum number of observations specified during Phase 2 is the minimum acceptable.
• For target-of-opportunity programs submitted during the semester, these program will be subject to the same selection process and prioritization based on a grade and a rank as the regular programs.

E - Other Issues [A - Introduction] [B - Overview] [C - Detailed Tutorial] [D - QSO rules] [TOC]

1) Night reports

After each observing night, a report detailing what observations were performed will be available on the CFHT Web site. These reports include the observations blocks executed and the sky conditions at the time of the observations. This does not necessarily mean that your data will be immediately available. 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. If you see in the Night Reports that the QSO Team might have made a mistake (OG missing, wrong timing, no enough iterations...), please send an email to qsoteam -=at=- cfht.hawaii.edu IMMEDIATELY so we can fix the mistake (if possible).

2) Data Evaluation

As part of the data quality control assessment, all data taken will be automatically processed and calibrated at CFHT. 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. If the observations are judged satisfactory, the queue database is then updated by the Queue coordinator, and the reduced data are made available to PIs.

3) Data Distribution

Data is distributed to PIs by putting them on the Web, at a location known only to the PI of each program. Data is distributed only after a human has checked the data reduction log for warnings, error messages, inconsistencies, or anything wrong. Our goal is to make the raw and processed data available by noon, the day following a night of observation.

4) The QSO Team

The current QSO Team is formed of Nadine Manset (QSO Manager), Billy Mahoney (Database Specialist), Tom Vermeulen (System Programmer), Todd Burdullis (Senior Service Observer), and Mary Beth Laychak, Adam Draginda, Rachael Zelman, Peter Forshay (Service Observers). During a QSO run, supervision is ensured by the QSO Coordinator (one of the CFHT Resident Astronomers) who, among other things, is responsible for managing the queue database, data reduction, and maintaining the contact with the investigators, if necessary. The main coordinator for the ESPaDOnS QSO runs is be Nadine Manset. Observations will be conducted by the Service Observers and with a strong involvement by the Observing Assistants. Software support will also be provided during the observing nights. For TOO programs and decisions related to the viability of some programs, the CFHT Executive Director acts as the final authority.

---