Queued Service Observations WIRCam

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, that is sequences of "observation blocks" 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 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).

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 also being conducted under the QSO mode. Starting with the semester 2005B, all observations for WIRCam, the new wide-field near-IR imager, will all be done through the QSO system as well.

The actual tutorial describes a version of PH2 developed specifically for observations with WIRCam. 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 WIRCam.  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 CFH12K, MegaPrime and the one developed for WIRCam. 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 entire 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 main steps lead to the creation of these observation blocks with WIRCam:

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, micro-dithering option, exposure time) planned to be used for observing the targets of the program (see below). Patterns for nodding or defined by the user can be defined in previous forms and selected in this table as well. 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, 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:



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, other overheads (e.g. offsets in the nodding mode) 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! For WIRCam, additional patterns for nodding can be defined and exclusion of guide stars can also be performed (guiding for WIRCam is done on the arrays). There are also 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 data format and observing modes with WIRCam

Data Cubes

Operation of WIRCam under QSO is similar to MegaCam in several ways. However, there are also some significant differences regarding observing modes and data format. The main difference between MegaCam and WIRCam for the observation strategy is this: Each exposure N within a given dithering pattern (DP) will be a cube made of shorter sub-exposures or micro-dithered exposures. This is because the sky emission in the infrared becomes a strong limitation. For instance, it is typical that to get one exposure of 300 seconds in total on one pointing, the strategy will be to take 10 shorter exposures of 30 seconds each.

In the case of WIRCam, two options are offered for exposures within a DP: Sub-exposures: In this mode, each exposure of the DP is split into a cube of shorter sub-exposures. Each sub-exposure has an individual exposure time. Due to technical limitation on file size, the maximum number of sub-exposure is 28. Thus, s = 1,2,3,4,.....28.  Micro-dithering: In this mode, each exposure of the DP is split again into a set of shorter micro-exposures m forming a micro-dithering pattern (a square box of size of 0.5 pixel across). Each micro-exposure has an individual exposure time and m < 28. A full cycle for a micro-dithering pattern includes 4 different micro-exposures offset by 0.5 pixel. Thus m = 4, 8, 12, 16 … 28. NOTE: Since micro-dithering will only work well with good (bright) guide stars, it is NOT offered for narrow-band filters.

Thus the actual observation scenario for an OB, which essentially resides in defining the appropriate parameters in the instrument configuration form, in that case is roughly illustrated by those two examples:

Example 1: Dithering pattern on the sky of 5 exposures, with each exposure being a cube of 4 micro-dithered exposures; Example 2: Dithering pattern on the sky of 4 exposures, with each exposure being a cube of 6 sub-exposures (no micro-dithering).



Nodding

An important option for WIRCam is the possibility to define nodding (target-sky-target-...) patterns. PH2 offers a sophisticated form in order to be able to define those patterns for objects covering a large portion of the mosaic (see detailed tutorial). The same exposure strategy illustrated above applies to the nodding patterns.

7) 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 several consecutive nights, the quality of the calibrations is also 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 WIRCam, 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 WIRCam filter set, YJHKs, 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 calibration plan for WIRCam should reach a level of 3-5% or better (see point 4 if this is not enough for your program).

3- If your program includes the WIRCam narrowband filters (H2,CH4(on,off), LowOH (1&2), Kcont; Br-gamma), 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 one of the WIRCam array.  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 WIRCam 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.

Non-photometric Conditions

Of course, clouds are part of astronomy (!) so we will have to observe under non-photometric from time to time. For MegaCam, we take short exposures of fields requesting photometry, but done with cloudy conditions, during photometric time. However, for WIRCam, this is not necessary. Bootstrapping of photometric calibration of fields done during non-photometric conditions can be done directly using the 2MASS catalog which cover the entire sky.

8) PH2: WIRCam and Recent Changes

The actual version, specifically developed for WIRCam observations, include some very significant differences with the previous versions available for CFH12K/MegaCam. The basic functionality remains the same (that is, assembling the blocks and transforming them into observation groups) but PH2 now offers different options for pointing, nodding and dithering patterns, exclusion of guide stars, micro-dithering option, data distribution, etc. Refer to the detailed tutorial below for more information.

If you are already familiar with PH2 for WIRCam, the most significant differences implemented for WIRCam are the following:

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 WIRCam 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

Special form used to define nodding (target-sky-target...) patterns for WIRCam. Not mandatory and only accessible from the navigation menu, if user specifies so in the Prg Constraints page.

Special tool used to indicate regions to avoid using for guiding purposes for WIRCam. Not mandatory and only accessible from the navigation menu, if user specifies so in the Prg Constraints page.

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

 

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. We use these comments all the time. The more we know, the better!





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 WIRCam 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. Note: If you plan to use the "WIRCam Dithering Pattern" (WDP; that is put the object successively on each array of the mosaic), the pointing coordinates should be set in order to have the object at the "1" position (see 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. 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. 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) Nodding Patterns

Infra-red astronomy differs from visible observations mostly because the sky background is a strong contributor and is much more variable. The near-IR sky on Mauna Kea can change by up to 10-20% in a few minutes.  This is why exposure times and observing strategy must be able to frequently sample the sky.  If the object is not very extended, the sky can be derived in regions of the mosaic without scientific signal for each dithering pattern position.  However, when the object is extended (e.g. > 40% of the field of view of the mosaic),  another technique must be used to sample the sky: nodding. The idea is simple: during the observations on the target, the telescope is slewed to a position away from the object in order to frequently established the sky background.  For WIRCam, this is possible by applying regular offsets to the telescope.

PH2 offers a special (optional) form to define nodding patterns. The idea behind the form is this: define a precise sequence of observations (i.e. target-sky-target...) in order to be able to adequately sample the sky on a position close to the object and defined by offsets with respect to this target. The form in PH2 will appear quite complex at first but is in fact simple to use and allows the user to quickly define complex sequences. At the touch of a few buttons, the form allow the user to:

There are two important things to take into account before defining the patterns:
  1. The exposure strategy between the target and the sky will be the same. In other words, for each exposure within the DP, the time spent on the target and the sky will be spent the same way. For example, if for each DP position on the target, you apply a micro-dithering of 4 exposures of 10 seconds each, the same thing will be done on the sky region. Of course, the number of DP exposures on the sky is determined by the number of nodding offsets requested. 
  2. There is an overhead of 60 seconds charged for every offset to or from the sky position.  We hope to reduce this overhead with some future improvements. The overhead is automatically accounted form in the Instrument Configuration form.
    3.

The top frame is where the  user can fully define the nodding pattern for a given target:

 

  • Basic Target DP: The first step is to define what basic Dithering Pattern must be applied to the target. For more information, the Instrument Configuration section below  includes the complete list of patterns available. A pattern will be applied to the target, whatever the frequency of sky sampling is, so that the target will not be be found exactly at the same place all the time on the mosaic.
  • Scale:  The scale applies to the dithering pattern selected. See Instrument Configuration for more details.
  • Sequence Start: The nodding sequence can either start on the target or on the sky region. 
  • Sky Frequency: This determines at what frequency the sky should be sampled relative to the target observations. For example, for each target DP exposure, the sky region can also be observed by slewing the telescope. There is no magical recipe for this sampling, however, since it all depends of your filter, exposure strategy and desired photometric precision.
  • DP on Sky Exposure: The dithering pattern selected for the target can also be applied to the sky region, if desired. The default is set to "yes" since it's by far the best option to get a good sampling of the sky and remove the bad pixel regions.
  • Reference Sky Offsets: The nodding patterns are defined by offsets relative to the original target position. The entry fields allow the user to precisely define the position of the sky region with respect to the target. The maximum offsets allowed is 5 degrees from the target. The sign represent the motion of the telescope of the sky: + is East, + is North.  The second set of entry field "view sky") can be used to either visualize or fine tune the sky region position. It opens the Aladin tool as below:
    •


The yellow frame display the WIRCam mosaic at the location of the sky region as defined by the offsets with respect to the target. By selecting the frame with the mouse, it's possible to move it and fine-tuned the location. When this is done, the "grab" button in the top frame form of the nodding form can be used to update this new position for the sky. That's all there is to it!

  • Existing Nodding Pattern: This is used to display the parameters used for any existing nodding patterns saved by the user.
  • Creating Nodding Pattern: This is used to give a name to the pattern created and some mnemonic description.
    •

When the "create" button is selected, the table of offsets is displayed in the middle frame. All of the entry fields remained editable and additional offsets can even be added. The type of observation (target or sky) is described as well as the type of offset (e.g. target -> sky). When the user is satisfied, clicking on "save" will save the pattern and make it available in the Instrument Configuration form for further creation of the observation blocks.

NOTE: There is no simple way to directly edit an existing nodding pattern yet. The way to do it is like this: 1) View the existing pattern; 2) Change the name of the pattern in the create window; 3) Edit the pattern as needed; 4) Save.

Example
Nodding observation of an extended target is required from a user following this strategy:  Five exposures on the target with a sky region located -1.5 degrees away in RA sampled every target exposure. For each exposure, micro-dithering is requested (1 loop of 4 micro-exposures; see instrument configurations).  The nodding starts on the target and the DP is also applied on the sky.  After selecting the appropriate entry fields in the form and saving the offsets, the observing sequence resulting in this strategy is illustrated in the figure below:

In this example, the sequence of offsets will be T1-S1-T2-S2-T3-S3-T4-S4-T5-S5, which each DP position
producing a data cube of 4 exposures generated by the optional micro-dithering mode (instrument configuration).


10) Guide Star Exclusion Zones

Guiding for WIRCam is done on the arrays themselves. Acquisition software selects the stars according to their magnitude and location, and small guiding windows (size ~5" x 5") are then automatically positioned on those stars for guiding. Since those windows are read at a high rate, stars selected for guiding cannot be used for scientific purpose.  For most scientific programs, this will not be an issue. However, for programs looking at bright stars, guiding might result in the lost of science if one of the interesting targets is choose for guiding.


To avoid this problem, we have developed a simple tool in PH2 with which the user can define small 30" x 30" exclusion zones for guide star selection. This information is passed to the acquisition software during the observations and algorithm for guiding selection automatically rejects stars located in those exclusion boxes. The form needed for that in Ph2 is optional and is only available when requested in the program constraints page.  

Important Note 1: Use the exclusion zone tool only if you need it, that is, if there is a danger to lose one of your scientific targets to guiding.  Guiding priorities are established according to the magnitude of the object. If your objects of scientific interest are bright stars (e.g. mag < 11), it might be preferable to use the exclusion zone tool to make sure that you will not lose interesting targets. Programs looking for extragalactic sources are not required to do although we have seen problematic cases when the center of a galaxy was very bright and peaked, enough to be confused with a star...

Important Note 2: Exclusion zones are directly linked to the target positions defined in the fixed target form. Before you define zones, make sure that the coordinates of the target are definitive. If not, a change in the target will result in invalidating the zones and you will have to start again!

Important Note 3: Exclusion zones are only possible for fixed targets. Targets defined by ephemeris positions cannot be used for defining zones of exclusion.



The top frame allow the user to first select the target for which the zones of exclusion of guide stars should be defined. The principle of the tool is very simple: when a target is selected, Aladin can be open either with the "low resolution" (LR) or " high resolution" (HR) mode. When this is done, the target is displayed along with the 2MASS and GSC catalog:


Aladin displays the field of the fixed target selected by the user. Here, for instance the object NGC 6946 is displayed in the
low-resolution mode (1.5d x 1.5d) with the WIRCam mosaic field of view.


Here, the same target is displayed in the high-resolution mode. Unfortunately, this only shows a field of 15' x 15', smaller than
the total field of view of WIRCam. The "gsez" button can be used to define 30" x 30" guide star exclusion zones across the field.

Guide Star Exclusion Zones: Selection and Editing

To enter exclusion zones, the user can select the "gsez" button and click on stars that he/see would like to remove from potential candidates for guide stars. A box of 30 " x 30" will be displayed in Aladin; it is not possible to change the size of this box but everything inside will not be considered for guiding. Clicking again on the star will remove the box.  If previous stars were already defined and saved in the table (see below), when you open Aladin, clicking on the "gsez" button will display all the stars in the list. DO NOT CLOSE ALADIN BEFORE SAVING THE ZONES (see below)!!

When the user is satisfied with the selection of zones, the grab button in the PH2 form should be selected.

Exclusion Zones Table

When the user is satisfied with the selection of zones, the grab button in the PH2 form should be selected. This action will result in a similar table as below:


This table displays all the zones defined by the user, including the coordinates and status. Three different status are possible: Pending, means that the zone has been defined but not saved; Ready means that the zone has been saved and will be taken into account during the observations; Invalid means that the zone was previously saved but that the coordinates of the target have changed and that the zone is no longer valid for the observations.

Editing a list of zones already saved is easy. Reselect the target in the top frame, open Aladin and click on the "gsez" button. If you want to remove one of the box, click on it (the box will disappear) and grab the boxes again in the PH2 form and save.

11) 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 and 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:

 

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

 


Basic Dithering Patterns
The WIRCam mosaic has only one series of gaps between the detectors which have all the same size (45").  The pre-defined basic dithering patterns offered for WIRCam (DP#) at this time cover those gaps and the bad pixel regions on the mosaic. The DP offsets are detailed in the following tables. The "DP" patterns can be used with two scale factor. Scale 1 covers the bad pixels regions and mosaic gaps. Scale 1.5 will cover all of those plus give a better sampling of the sky.  



WIRCam Dithering Patterns

The pre-defined WIRCam dithering patterns (WDPs) are special patterns which put an object on the center of the four arrays.  The number following WDP indicate the number of loops; A limit of 5 loops, that is 20 cubes, is possible.  Offsets are automatically applied each time the object comes back to a specific array to help removing bad pixels and sky background.  The figure below illustrates the 20 cube that a WDP5 would do, for example. Note of course, that each cube can have several sub- or micro-exposures.  IMPORTANT NOTE: If you plan to use WDPs, make sure that the pre-defined pointing offsets in the fixed targets table is set to position 1 (in order word, the object should be found at the bottom right corner of chip 60).