Queued Service Observations for MegaPrime

Phase 2 Proposal Submission Tutorial
 

Updated 11/29/2007


 
Table of Contents

A- Introduction

B - Overview of the Phase 2 Tool (PH2) C - PH2: A detailed Tutorial D - A Few QSO Rules

E  - Other Issues

A - Introduction

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 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 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).

Since January 2001, queue observations have been 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. All of the observations with MegaPrime are also being conducted in the QSO mode. The actual tutorial describes a version of PH2 developed specifically for observations with MegaPrime. 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 2008A extends over a period of several weeks. The two important dates to remember are given in the table below:

 

Event
Date
Phase 2 Starts for Semester 2008A  December 5, 2007 14:00 (HST) (24:00 UTC)
End of Phase 2 for Semester 2008A  January 22, 2008 14:00 (HST) (24:00 UTC)

 

Please take these points into consideration:

3) Document Outline

This document presents the complete information for the second submission Phase of the QSO proposals accepted for MegaPrime.  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.  Users already familiar with PH2 might want to consult the section entitled "PH2: Recent changes" to learn about the most recent modifications done to PH2. 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)

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 sometime 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:

3) The PH2 Interface

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.
 


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 an unique label so each target, configuration or constraint is an "individual" 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 steps lead to the creation of these observation blocks:

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. filter, dithering pattern, 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. image quality, sky background) 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, due to the large overhead in changing a filter in MegaPrime, we recommend avoiding too many filter changes within an OB. 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:

 

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 other options available for the observation groups (e.g. time constraints, relational execution link); 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. There is also a sophisticated HelpDesk available for e-mail exchanges between the QSO team and the investigators, if needed.

6) A Word on the Calibrations

One of the main advantages of the queue mode is the possibility to share calibrations between programs.  More so, since the queue runs are spread over about 10-20 consecutive nights, the quality of the calibrations can also be greatly improved compared to the ones obtained during a short run in a classical mode.  To achieve this, a calibration plan has be defined and carried out regularly by the service observers.  This plan includes the necessary "detrend" frames for removal of the instrument signatures (bias, darks, flat-fields, fringing) and the astronomical calibrations (standard stars, astrometric fields).

For the current semester, you can consider the following situations:

1- No programs under any circumstances are allowed to request "detrend" calibrations during Phase 1 or Phase 2.  These calibrations are exclusively handled by the QSO and Elixir Teams. It is, in fact, not possible to define detrend calibrations through PH2 for the general users...

2- If your program includes the standard MegaPrime filter set, u*g'r'i'z', the astronomical calibrations will be automatically done during the QSO runs and distributed to you.  You do not have to include these calibrations during the Phase 2, that is, the integration time allocated should not be used for these calibrations. The accuracy of the photometry through the Elixir calibration plan for MegaPrime should reach a level of 2% or better (see point 4 if this is not enough for your program).

3- If your program includes the CFH12K narrow-band filters (Ha, HaOFF, CN, and TiO filters), the astronomical calibrations will not be done automatically by the QSO Team.  You must include these specific calibrations during the Phase 2.  Photometric calibration for these filters consist generally in observing a spectrophotometric standard star across the mosaic.  To simplify, the entire mosaic will be relatively calibrated by the Elixir team so we rather  recommend that you observe a spectrophotometric star on only two of the MegaPrime chips.  The predefined offsets included in PH2 (below) allow you to define these positions very rapidly. The frequency of these observations depends, of course, of the relative photometry accuracy aimed for in your program.  For this kind of procedure, we recommend to link the photometric observations with the science observations using the "sequence of OBs" (SOB) option.

4- If your program includes any MegaPrime filters with a broad bandpass and that you prefer to obtain your own astronomical calibrations, these calibrations can be added as normal observation groups during the Phase 2. Of course, the integration time will be automatically charged to the program for this kind of observations.

7) PH2: MegaCam and Recent Changes

The most important changes to PH2 are:

C - PH2: A detailed Tutorial

1) Accessing PH2

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


Access to PH2 is done through this small window:

2) Navigating within PH2

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 user dithering patterns. Not mandatory and only accessible from the navigation menu
Page containing the table used to define all of the instrument configuration (e.g. filters, exposure time, dithering pattern) 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.
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 your convenience, the runID 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.

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:

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:

 

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. The more we know, the better!


Several options are possible for indicating the moment you would like to receive your data. Four options are available here:

1 - Quick Access: For certain programs, it is important to evaluate the data soon after being gathered at the telescope. However, if you ABSOLUTELY need access to the data during the QSO run, indicate so. We cannot promise that the observations will be immediately available due to the large volume of data produced by MegaPrime.  However, we will try our best. Please note that this will be achieved ONLY for programs requesting a quick access to the data and for which this procedure is entirely JUSTIFIED. Please indicate also if raw data are acceptable.

2 - After Each QSO Run: If your program is long and that you prefer to receive data regularly through the semester, you can choose to receive the data after each QSO run. Due to the data volume produced with MegaPrime, this will be done on a best effort only by the QSO/Elixir/DADS Teams. Please justify this request also in the entry field. The QSO Team will also review this request and decide if it makes sense or not to prepare the network files after the run (for instance, in the case where only a few files were acquired). .You can expect a delay of 7-10 days before we start the distribution after a run; this delay is necessary for Elixir to produce the best calibration data possible.

3 - 100% Completion: If you would like to receive your data only when your program is completed, indicate so. If your program does not reach a completion level of 100% at any time during the semester, you will only receive the data at the end of the semester, unless the QSO Team judges that no additional observations will be performed for the rest of the semester due to other constraints (i.e. target distribution on the sky).

4 - End of semester: If this option is selected, all data accumulated during the semester for your program will only be sent all together after the end of the semester. This is the default option.




 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.

A word on Target Coordinates.  Coordinates for the targets can be entered from different ways in PH2. However, at the telescope, pointing coordinates, that is the combination of the target coordinates and the pointing offsets will be used. Basically, Pointing Coordinates = Target Coordinates + Pointing Offsets.  So, placing the object on the right location on the CCD mosaic can be done from two ways: By using the real coordinates of the target and set up the pointing offsets to the appropriate values or, by modifying the target coordinates, so that they become the pointing coordinates, and set the pointing offsets to zero. Both ways can be easily achieved in PH2, as described below.


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

 

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.

the following is a template of the Astrores file that you can copy to your local machine to use the download/upload features: 
<?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>Fixed Targets</NAME>
    <TITLE>Fixed Targets for CFHT QSO</TITLE>
    <!-- Definition of each field -->
    <FIELD name="NAME" datatype="A" width="20">
        <DESCRIPTION>Name of target</DESCRIPTION>
    </FIELD>
    <FIELD name="RA"    datatype="A" width="11" unit="h"   format="RAh:RAm:RAs">
        <DESCRIPTION>Right ascension of target</DESCRIPTION>
    </FIELD>
    <FIELD name="DEC"   datatype="A" width="11" unit="deg" format="DEd:DEm:DEs">
        <DESCRIPTION>Declination of target</DESCRIPTION>
    </FIELD>
    <FIELD name="EPOCH" datatype="F" width="6">
        <DESCRIPTION>Epoch of coordinates</DESCRIPTION>
    </FIELD>
    <FIELD name="POINT" datatype="A" width="5">
        <DESCRIPTION>Pointing name</DESCRIPTION>
    </FIELD>
        <!-- Data table -->
<DATA><CSV headlines="4" colsep="|">
<![CDATA[
NAME                |RA         |DEC        |EPOCH |POINT|
                    |hh:mm:ss.ss|+dd:mm:ss.s|      |     |
12345678901234567890|12345678901|12345678901|123456|12345|
--------------------|-----------|-----------|------|-----|
M33                 |01:33:51.02|+30:39:36.7|2000.0|1    |
NGC4258             |12:18:57.54|+47:18:14.3|2000.0|1    |
NGC3359             |10:46:36.30|+63:13:29.0|2000.0|1    |
NGC2903             |09:32:11.67|+21:37:21.6|2000.0|1    |
]]></CSV></DATA>
  </TABLE>
</ASTRO>

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. We hope to add even more options in the future for moving targets. Before explaining how to use the form, here are two important caveats: 1 - For the moment, no extrapolation of any sort is conducted on the ephemeris entered; that is, coordinates used during the observations will be the ones matching the closest ephemeris entered for that date and time. 2 - Differential tracking (e.g. rates) is NOT possible right now; telescope tracking will be sidereal, with or without guiding (as can be indicated later in the OB form).

The general idea behind the ephemeris form is very simple: define a series of coordinates for a specific time for a given target. The top of the form, illustrated below, 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. "Pointing" refer to options for pointing offsets explained in the above "fixed targets" section. 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").

The table below shows the entry fields for the ephemeris of the target specified:

 

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>

8) User Dithering Patterns

This form allows the user to define his/her own dithering patterns. It is NOT a mandatory form and is only accessible from the navigation menu (i.e. "Proceed" from the "Fixed Targets" form will go to the "Instrument Configurations" form, not this one. Defining his own dithering patterns can be useful for some programs. Our experience, however, shows that data reduction can become much more difficult or can even be severely compromised with nonstandard patterns. Use only this form if only necessary for your program and if you have previous, extensive experience with data reduction of wide-field camera observations. For any doubt, do not hesitate to contact the QSO/Elixir Teams.

The idea behind this form is simple: the user can define a list of absolute offsets and saved this list as a dithering pattern under a customized name. This name can then be found under the pull-down menu for the available dithering patterns in the next PH2 form ("Instrument Configurations").

The top frame allows the user to visualize the offsets of a dithering pattern, create a new pattern, or delete a user pattern.

The middle frame displays the table used to define the dithering pattern:

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.

 

9) 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.

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

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

It is important to know that the MegaCam mosaic has three different series of gaps between the detectors:

Dithering patterns offered for MegaPrime at this time are detailed in the following tables. The "DP" patterns can be used with two scale factor. Scale 1 covers the bad pixels but none of the mosaic gaps. Scale 1.5 will cover the vertical and horizontal gaps (but not the connector gap). The large dithering pattern (LDP) is special: some offsets are large (2') and the general geometry is elliptical. IMPORTANT: As the field distortion is not negligible, big dithering patterns like the LDP will not allow a simple shift and add, especially on the edge of the field. The tables below give all the offsets defining the dithering patterns.

10) 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:

The middle frame presents the table for the constraints:

A word on the Image Quality.  The constraint on the band image quality is the strongest criterion for the selection of a program to be undertaken.  The QSO Team will try to respect the constraint on the image quality at all time for your observations. Our goal is to never exceed the upper limit defined by your constraint by more than 10%, and at most 20%. Evidently, the image quality varies through a band to another.  The reference band for the QSO project will be the r-band, that is that during the observations, the image quality will always be translated to this band.  So, for instance, if you specify an IQ between 0.65" and 0.80" for an observation with the u filter, you should expect an resulting image quality of about 1", as shown in the table below. Statistics performed on data obtained with CFH12K show the following trend (note: data with MegaPrime will show if these offsets in IQ will remain valid):
 
 
Parameter

Value observed with respect to IQ specified in PH2

Image Quality in u band FWHM   ~ + 0.2-0.3" larger than r band 
Image Quality in g band FWHM   ~ + 0.1-0.2" larger than r band
Image Quality in r band (Reference)
Image Quality in i band FWHM similar to r band
Image Quality in z band FWHM similar to r band (or slightly better)

 
Image Quality (IQ) R Band
Frequency (%)
 IQ < 0.55"
5
0.55" < IQ  0.65"
25
0.65" < IQ  0.80"
30
0.80" < IQ  1.0"
25
1.0" < IQ 1.2"
15
IQ > 1.2"
5

 

From these tables, a few facts can be stated:

A word on the Sky Brightness.  At present, only three general qualitative sky brightness can be indicated. During the observations, the sky background will be constantly measured by Elixir and converted to these qualitative values.  In gray time (i.e. Moon Illumination 0-50%), and bright time (i.e. Moon Illumination > 50%), the QSO Team will always try to observe at at least 45 degrees away from the Moon.  However, it might not always be possible to do that due to scheduling constraints.  We strongly suggest to include some comments in the "Program Constraints" page on this issue, for instance, if you think that we could get a bit more Moon without compromising the quality of science of your project.
 
 
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.

 

11) 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.

12) 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:


 

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 li