PH2 tutorial for WIRCam

SUMMARY OF BASICS

• There can only be one session per user at a time.
• There is a time out of 2 hours. Beware: No "save" is performed if your session has automatically timed out. Save your work regularly!
• Until the deadline, you can access PH2 as many time as you want.
• There is no submit button. Anything "saved" is in the PH2 database.
• If you have used Poopsy, the login information for PH2 is the same as for Poopsy.
• Non-sidereal tracking (not guiding!) is offered, but this is only good for less than about 2-3 minutes.
• For imagers, if possible, refrain from using User Dithering patterns and use the DP provided.
• ICs and OBs (Instrument Configurations and Observing Groups) can be used more than once, so there is no need to duplicate identical ICs or OBs.
• The QSO Team encourages PIs to add comments to their OGs, to include specific additional constraints or repeat information found elsewhere in PH2: hour angle constraint, different Image Quality requirement, tolerable extinction, timing constraint, etc.
• PIs should also fill in the PH2 comments box with as many details possible on what is expected from the QSO Team: acceptable extinction, priorities, to finish observations in one filter first or finish a target in various filters first, etc.
• The entity executed at the telescope is the Observing Group (OG). An OG is made of one or more Observing Blocks (OBs). An OB is made of one (and only one) target, one (or many) instrumental configurations, and one (and only one) set of constraints. OBs and OGs cannot exceed 2 hours.
• For WIRCam, PIs do not need to define photometric calibrations using standard stars. We regularly observe 3 standards every night on the top left array (the array to array zero-point offset is well characterized). The strategy is 2 broad-band and 1 narrow-band observations on even nights, and the opposite on odd nights. So over the course of one run, we obtain as many observations in both broad and narrow band filters. For narrow-band filters, we observe the 3 CALSPEC standards: G191B2B, GD71 and GD153. For broad-band, we use about 10 "Faint Standards" (FS) standards. If PIs want more standards observed then they must define them in their own phase-2.

TABLE OF CONTENT:

• Accessing PH2 Login and password
• Navigating within PH2
• Program Selection
• Program Details Title, Abstract, PI information, grade and rank, I-time
• Program Constraints IQ limits, Monitoring, Tome Constraints, REEL, Moving Targets, CCD Failure, Comments, Data Distribution
• Fixed Targets Name and Coordinates, Pointing Offsets, Aladin, Astrores format to upload lists of targets
• Ephemeris
• User Dithering Patterns
• Nodding
• Exclusion zones
• Instrument Configuration
• Constraints
• Observation Blocks
• Observation Groups
• Summary
• Logout

ACCESSING PH2

The User ID and Password are the same ones that were used for Poopsy during the Phase 1, or were provided to you by e-mail by the QSO Team. If you used PH2 before, they are the same. If you do not remember them, please contact the QSO Team.

Back to Table of Content

NAVIGATING WITHIN PH2

The navigation buttons and their corresponding pages are described below.

Button	Corresponding Page
	First page of PH2 (Login). User ID 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. Please use the box provided to add as many instructions as possible (priorities, acceptable extinction, if IQ can be pushed, exact requirement for photometric conditions, Moon distance or illumination constraints, etc.) Includes a section for the distribution of the data.
	Page containing the table used to define all of the fixed 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. Only use if absolutely necessary, otherwise use provided DPs. 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.
	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.

Back to Table of Content

PROGRAM SELECTION

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. You must 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.

Back to Table of Content

PROGRAM DETAILS

• 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: The name of the Principal Investigator for each program cannot be changed. The contact information (Institute, phone and fax numbers including the area code, email) must be up to date and accurate. Email is the main contact method.

• Program Information:
• RunID: Identification number for your QSO program. This number is assigned 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 (H), NTU (T), Large Programs (P), Brazil (B), 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.
• 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).
• TAC Rank: Rank of your proposal within your program grade, assigned by the TAC.
• 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 of the WIRCam mosaic 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.

Back to Table of Content

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:

• IQ Limit: The image quality (IQ) constraint is one of the important parameters for QSO. In the constraints form later on, you will be ask to define a range (in K band) of IQ for your observations. During the validation process, the QSO Team uses the upper limit defined by this range to judge if the images meets the requirements or not. A margin of about 15% higher than this upper limit is still considered acceptable for allocating a "grade 1" for the quality of the data. Example 1: A range of 0.55-0.65" in K band is selected; images in K band with IQ ~ 0.72" will be considered as valid. Example 2: A range of 0.65 - 0. 80" is specified in K band, but the Y filter is used instead (which has usually an offset of about + 0.1" with respect to r band). So, images with IQ ~ 0.8 x (0.8 x.15) + 0.1 = 1.0" will be acceptable. If this is not acceptable, the user should specify this here and describe in the comments box what the upper limit for the observations should be.
• 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. It is not possible to have monitoring for sequences of observation blocks (SOB), only individual blocks.
• Time Constraints: If some of your observations have to be performed within certain dates, 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 option in PH2 allows the user to create specific links between observation groups. In short, we can resume the REEL concept as: " if OGx is observed, 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 if 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.
• Zones of Exclusion: Guiding for WIRCam is done on the arrays themselves; the guide stars are selected by an automated process at the telescope. Stars brighter than about 14-15th magnitude can be selected. Stars used for the guiding cannot be analyzed for scientific purpose. If your program is aimed at specific stellar objects, you might want to indicate to avoid selecting them for guiding.  To do so, a special form has been implemented in PH2 and will become available if you select "yes" to the question.
• Nodding Observations: Due to the rapid variations of the sky background in near-IR astronomy, it is often necessary to insert "sky" observations between the target exposures, if the target cover an extensive fraction of the field-of-view of the camera. This is called "nodding". A special form has been implemented in PH2 to be able to define "nodding patterns".  This is the most complicated mode of observations in PH2 by far but the form is relatively straightforward to use. If you need nodding, indicate so here and the form will become accessible from the navigation menu.

• Program Comments: It is extremely important that the investigators transmit any comments that they judge useful for the execution of their observations. This space is reserved for general comments which will be available at all time during the preparation of the queues and while performing the observations. Comments can include, but are not limited to: acceptable level of extinction, minimum number of fields to take under photometric conditions, how much IQ can be pushed, priorities, Moon distance or illumination, tolerance on execution of an observation which has a time constraint, etc. For example: "Observations to be done in photometric conditions only"; "Thin cirrus less than 0.2mag extinction 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!

• Data Distribution: CFHT now only offers network distribution of the processed data, which will be placed in a special FTP site at CFHT for downloading over the network.

Four delivery schedules are available:

1. Quick Access: If data need to be looked at as soon as obtained at the telescope, request the Quick Access option. This option is offered on a best effort basis, as our manpower constraints do not always allow us to quickly fulfill such a request. This request must be justified in the box provided. Please indicate if raw and/or processed data are requested.
2. After Each QSO Run:If you program is long and 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 WIRCam, this will be done on a best effort basis. Please justify this request in the box provided. .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 prefer 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: This is the default option. All data will be provided once, at the end of the semester.

• Data Distribution Recipient: By default, the PI will receive the information necessary to retrieve the data over the network. An alternate person may be designated by selecting "Alternate" in the drop-down menu and filling the appropriate boxes. All contact information must be up to date.

Back to Table of Content

FIXED TARGETS

This is the first step toward the creation of the observation blocks, and where the user defines the fixed targets of the program and their precise pointing coordinates. The target table includes the target name, coordinates, and a pointing offset. A few buttons allow the addition, duplication, selection or deletion of entries. The maximum number of rows displayed at once is five. The "Next Page" and "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 that identifies which program is being edited, list of displayed rows, total number of targets already defined, link to the instrument's page.
• Target identification (Label/Name): each row has a unique label (FT) which is automatically updated if the rows are changed. The name is entered in the box; a clear and simple name (e.g. Virgo Field1) will make the subsequent steps easier. The name must be shorter than 20 characters.
• Coordinates: Coordinates can be entered manually through these entry fields, or with Aladin. The "check" and "save" options always verify that no typos or illegal values were entered. No value lower than -60 degrees in DEC is allowed. The Epoch of the coordinates can be fractional (e.g. 2001.3), but must be between 1900.0 and 2050.0.

  At the telescope, pointing coordinates, that is the combination of the target coordinates and the pointing offsets will be used. 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. 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).

  Pointing Offsets: are offsets applied from the target coordinates. The 5 positions are predefined offsets, illustrated below. These offsets are useful if you want to put the target at a specific location on the mosaic. By selecting the "New" button, you can edit the offset fields and define new positions. When the page is saved, these offsets are refereed under the name U_nnn (U for "user") and this option becomes available for all the targets in the table. After the save, it is not possible to redefine the values for a given customized offset. Just create a new one... When the target coordinates are rather entered with Aladin, the pointing offsets are set to zero. NOTE: As shown, the default offset "1" does NOT correspond to the physical center of the mosaic (center of the cross) but is rather shifted by about 1 arcminute from it to ensure that the object falls on a chip.

  
• Aladin is used to display sky images. Using Aladin is optional, since pointing coordinates can be entered directly in the target table with the combination of target coordinates and pointing offsets. To use Aladin, and if you know the real astronomical name of your target, enter the name (e.g. NGC 4258) and click one one of the "Aladin" buttons. 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 one of the Aladin buttons.

  The "LR" and "HR" buttons are used to display a field with either a "Low Resolution" (field of view of 1.5 x 1.5 degrees; 1 pixel = 6.8"), or a "High Resolution" (15 x 15 arcmin image; 1 pixel = 1.7"). The HR image can be used for accurate positioning, but due to the display limitations and the astrometry of the plates, the pointing accuracy of Aladin will never be better than 3-4". Aladin works only with coordinates for J2000.0. The coordinates sent back are automatically in J2000.0. Please also note that the slight rotation of the superimposed WIRCam grid does not mean that we can rotate the mosaic!

  As an example, the low resolution field surrounding M27 in the Aladin window will look like:

  

  An image of the target is displayed, stars in the fields are identified from the GSC with red circles, and a grid showing the WIRCam mosaic (including the gaps) is superimposed (see below for correct identification and orientation of the arrays). The coordinates indicated at the top left refer to the position of the center of the mosaic, indicated by the red cross, at the bottom corner of array 60. By clicking and holding the left button of the mouse, the mosaic 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 and the pointing offsets set to zero; the target coordinates have now been transformed into pointing coordinates.

  As shown in Aladin, the WIRCam mosaic has two different series of gaps between the detectors:

  • Vertical gaps: about 45 arcseconds. A dithering pattern with several exposures separated by offsets ~90" will get rid of these gaps (see instrument configurations).
  • Horizontal gaps: about 45 arcseconds. A dithering pattern with several exposures separated by offsets ~90" will get rid of these gaps (see instrument configurations).

  Very bright stars will saturate the chips so if it is an issue for your fields, you can use the GSC stars displayed in Aladin (magnitude is given by clicking on the red circles) and the moving grid to carefully define the target pointing.

• Downloading/Uploading Target Files. At the bottom of the page, an option is available to download/upload a PH2 target list: 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.

  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 crucial 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: 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!

• Here is a summary of the various buttons available:

  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.

Back to Table of Content

EPHEMERIS

This form is used to define targets for which coordinates 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 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>

Back to Table of Content

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.

• Left Window: the pull-down menu has the name of the existing dithering patterns, including the predefined "standard" patterns (see next form). The selection automatically displays the offsets in the table in the middle frame. The box belows has a short description of the pattern
• Middle Window: Name and description of the dithering pattern to be defined by the user. Clicking on "Create" open the table in the middle frame.
• Left Window: to delete the current dithering pattern displayed in the table. A confirmation window will appear.

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

• The label identifies a row in the table which corresponds to an ABSOLUTE offset.
• The values of the RA/DEC offsets for each pointing within the dithering pattern are ABSOLUTE, that is, DEFINED WITH RESPECT TO THE POSITION (0,0), NOT THE PREVIOUS POSITION. Positive offsets correspond to East and North. In the example above, the dithering pattern "UDP3", has four pointings: a reference (O1) corresponding the pointing coordinates of the target since offsets are at 00:00; and three additional pointings all with respect to the position O1. Note that the largest offset possible for WIRCam is 10 arcminutes; this is to avoid problem with guide star selection.

Here is table with the list of the available buttons:

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.

Back to Table of Content

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:

• Define a sequence of observations between the target and the sky region, with very flexible sampling frequency of the sky (T-S-T-S ; T-T-S-T-T; S-T-T-T-S, etc).
• Apply different dithering patterns (DP) or different scale to the target and the sky observations.
• Precisely define the sky region for a given target with a visual tool, Aladin.

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. The overhead is automatically accounted form in the Instrument Configuration form.

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.

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

Back to Table of Content

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.

Back to Table of Content

INSTRUMENT CONFIGURATION

This is the second mandatory step in the creation of the observing blocks, used 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.

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 page to look at the list of targets. Nothing to click on, it's just a scrolling display!
• Predefined Dithering Patterns: This window presents some of the different dithering patterns ("DP") offered in one of the pull-down menu in the configuration table. The "single" pattern represents the option for one exposure. The blue circle represents the radius of the pattern and the red dots show the relative positions of the individual exposures within the pattern. Two parameters describe the geometry of the other patterns: the number of exposures (indicated by the digits following the "DP"), and the scale factor within which the offsets are applied. The patterns have been designed so that the coordinates of the objects will never be the same twice during the sequence.

  As described elsewhere, each exposure within a DP for WIRCam is a cube of N sub- or micro-exposures. Experience has showed that at least a minimum of 5 exposures is necessary to get rid of the gaps between the chips. Additional pre-defined ditherings, WDP, successively putting the object in the center of each array are also available. More information on the different options for the dithering patterns is found below.

• Exposure Time Calculator: There is an exposure time calculator available for WIRCam. The Digital Imaging Exposure Time (DIET) 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, seeing, sky brightness) in order to achieve your science goals.

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

• Top Row: The RunID identifies which program you are currently working on. A list of the current rows and the total number of configurations already defined in the current table is provided. The link goes to the instrument's webpage.
• Table: The label identifies a row in the table and is automatically updated if the rows are changed. The instrument configurations are simply identified as I#. The name of the instrument configuration is given by the user; a simple and clear name (e.g. Filter J, short) will make the subsequent steps easier. The name must be shorter than 20 characters. The drop-down menus show the list of filters currently available for WIRCam; the number of filters offered for one semester is limited for a given semester (8). Information on the filters can be found on the WIRCam Web page. The name of the Pattern can be: Single (one exposure), DP# ("dither pattern with # number of exposures"), WDP# ("WIRCam dithering pattern" with # number of loops) and, NP (a nodding pattern previously defined in the special form designed for this purpose). Multiple exposures with no dithering are possible by selecting the appropriate pattern and requesting a scale of 0. These values are possible: N/A, 0, 1 and 1.5. Default is 1. The N/A is only judged valid for the single exposure, WDPs and nodding patterns.

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

Micro-dithering: The pixel scale in WIRCam is 0.3"/pixel so the best image quality which is adequately sampled is ~0.7". To make good use of better seeing, WIRCam uses micro-dithering: 4 individual exposures, shifted by 0.15" on a square grid, provide Nyquist sampling of the recombined image for all conditions (several groups (up to 7) of 4 micro-dithered exposures can be done sequentially on one dithering pattern position (a cube)). In some cases this may require additional detectors readouts, and therefore introduce overheads. Note that micro-dithering is not expected to yield much improvement when the natural seeing is ~ > 0.8". For the YJHKs filter set, the user has the choice of using micro-dithering or not in this column. Since micro-dithering requires good (bright) guide stars, it is not offered for narrow-band filters. The next column options is defined by this selection. The micro-dithering mode requires guiding as it uses the guiding stars to control the offset produced by the ISU. This requirement is checked in the observing block PH2 form.

Number of sub- or micro-exposures: Number of sub-exposures or micro-exposures (N) per exposure of the DP (that is, the number of exposures within the cube). To keep the size of the files manageable, N < 12.  Of course, for micro-dithering exposures, N = 4,8,12.

Exposure Time: Exposure times for the individual sub- or micro-exposures taken within the dithering pattern. As of 2008B, the lower limit is 2.5 seconds. For WIRCam, the upper limit depends on the filter selected to avoid saturation by the sky background. The current maximum exposure times for each filter are given in the following table:

Filter	Maximum Exptime
Y	150 seconds
J	60 seconds
H	15 seconds
Ks	25 seconds
LowOH-1, Low OH-2	3000 seconds
Ch4-On, CH4-Off	50 seconds
H2(1-0)	200 seconds
Kcont	200 seconds
Br-gamma	200 seconds

Integration Time Calculation

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

I-time (IC) = I-time (target) + I-time (Sky) + Overheads (target + sky)
where
I-time (target) = [Number of DP exposures x number of sub- (micro) exposures x Exptime] on target
I-time Sky) = [Number of DP exposures x number of sub- (micro) exposures x Exptime] on sky region
Overheads (target + sky) = readout 10sec overhead (target + sky) per sub- or micro-exposure + 60 sec x Number of Offsets for nodding

Of course, if no nodding is used, no I-time or overheads are charged for the sky exposures and offsets. At the moment, readout overhead = 10 seconds. The actual readout of the camera is shorter but there is all kind of other overheads related to the operations of WIRCam to achieve an exposure that must be taken into account. In short, each sub- or micro-exposure has an total overhead of 10 seconds.

The following table shows the available buttons:

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.

Back to Table of Content

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 (T: I-time on target ; S: I-time spent on sky for nodding; O: Overheads charged for nodding).
• Exposure Time Calculator: There is an exposure time calculator available for WIRCam. The Digital Imaging Exposure Time (DIET) 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, seeing, sky brightness) in order to achieve your science goals.

The middle frame presents the table for the constraints:

• Top Row: The RunID identifies which program you are currently working on. Then comes a lit of the current rows and the total number of constraints already defined in the current table. The link goes to the instrument's webpage
• Table:
• The label identifies a row in the table abd is automatically updated if the rows are changed. The constraints are simply identified as C#. The name of the constraint is given by the user. Using a simple and clear name name (e.g. Best IQ, dark) will make the subsequent steps easier. The name must be shorter than 20 characters.
• Pull-down menu indicate the image quality constraint in the K band (see below) The image quality constraint has normally the highest priority in the selection of the program to be executed by the QSO Team. The option available are ranges of acceptable image quality: IQ < 0.55", 0.55" < IQ <0.65", 0.65" < IQ < 0.80", 0.80" < IQ < 1.0", 1.0" < IQ < 1.2", IQ > 1.2". The table below indicates the equivalent image quality (+/- 25%) for the other broad-band filters. The next table illustrates some statistics on the image quality on Mauna Kea.
• The Max IQ (monitoring) option only appears for programs requesting monitoring constraints. You can indicate here the maximum image quality acceptable for your program. This upper limit will be used to meet the time constraints associated with the program (for instance, if the seeing is worse than the regular constraint requested when an observation has to be repeated). The N/A option means that the IQ band as specified will have to be respected - in short, the IQ band has priority over the time constraint. If the IQ is not met during the time constraint, the observation will not be done. If the time constraint has the absolute priority and that the field should be observed whatever the seeing conditions, indicate an upper limit of > 1.2".
• The Sky Background constraint is given as a qualitative sky brightness. Two options are offered for WIRCam: Median and High. In near-IR, the Moon does not have much of an influence but the sky emission can vary greatly during a night. On Mauna Kea, the first hour or so of the night can be considered "high" and after the airglow settles down a bit, the sky is usually darker (median"). Variations of 10-20% within a few minutes are common, however, so the actual range define by those two background values are quite large. Unless it's very critical that the sky emission is at the lowest possible for your observations, we recommend that you use "high" for the constraint.
• The weight of the airmass constraint is not very strong in the selection process of the program to be undertaken. 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.

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 15%, and at most 20%. Evidently, the image quality varies through a band to another.

The reference band for the QSO with WIRCam will be the K-band, that is that during the observations, the image quality will always be translated to this band. So, for instance, if you specify a limit of IQ of 0.80" for an observation with the Y filter, you could expect that an resulting image with about 1.0" would still be validated by the QSO Team. As explained above, the QSO Team will validate images within about 15% of the upper limit of the IQ specified in K band . If this is not acceptable, or if the limit acceptable is below the upper limit of the range, this should be described in the program constraints page.

These tables show the following:

• Variations of the seeing are fast. This again argues for short observation blocks or groups. These quick variations might introduce images in a sequence for which the image quality is outside the IQ band specified. If the difference is about 10-20%, these images will be considered valid. However, if the IQ variation is too important, these images might be taken again.
• The probability that your program is executed depends strongly on the image quality required. Be realistic! In particular, for Programs with the C grade, it would be much preferable not to specify an IQ better than 0.8".
• It is important that you request a realistic IQ also when your targets do not reach a low airmass. For instance, asking for 0.6" when the airmass is never smaller than 1.5 is not very likely to happen....
• By definition, snapshots programs MUST request IQ > 1.2".

Here is a table of all available buttons:

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.

Back to Table of Content

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:

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 enlighten 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 the sum of the I-time spent on the target (T), the sky (S) and the overheads (O) charged in case of nodding.
• 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 enlighten after the creation of the OB.
• Defaults:. It is possible to define the defaults of certain parameters defining the observing blocks. Accurate Pointing Option: Pointing accuracy of the telescope is about 10-15". If this option is selected, an automated correction will be done to the pointing using an astronmetric solution automatically computed during the observations. Final pointing will be accurate to about 1". The default is enabled. Photometric: See below. Tracking:You can specify if the observation will need guiding or non-guiding. Note that if you select non-guiding for an OB requesting micro-dithering, the tracking will be set to guiding.
• 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. The calculation is done as follows: I-Time(OB) = N(exposures) x [ Exp.Time/Exposure + Readout/Exposure], where readout/exposure = 40 seconds. Since it is much easier to schedule short observation blocks, the total I-time for one OB cannot exceed 2 hours.
• Tracking: Two options are offered here: 1) Sidereal, guiding. This is the typical exposure and the default selection. 2) Sidereal, non-guiding. In case of short exposures (e.g. < 10 seconds), it is entirely preferable to select this option because finding a guide star is time consuming and that the image quality is not degraded for images with very short exposure times.
• Type: Type of observation. Only "object" is available.
• Photometry: Does this OB require to be done during photometric time only? The definition for this flag for WIRCam differs from MegaCam. Observations for MegaCam done under non-photometric conditions are calibrated later on with short exposures if this flat is enabled. For WIRCam, photometric calibration is provided on each exposure by Elixir using the 2MASS catalog. So, in principle, photometry will be accurate to a few percents and extinction to clouds can be estimated for each image. However, for certain programs, in particular programs requesting very high photometric accuracy or programs with nodding might require to be done under photometric sky only. This flag is disabled by default.
• Accurate P? Indicates if accurate pointing was selected or not. See above.
• 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.



Here is a table with all the available buttons:

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

Back to Table of Content

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 OG, 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 desire 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). The total I-time includes all the readout time for each individual exposures.
• 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 readout time for the CCD for all of the individual exposure in the OG and an overhead of 2 minutes for each accurate pointing required, if necessary. 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.

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

2. 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 executed, 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 execution 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.

   
3. 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. 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 tempted 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.

Here is a table of the available buttons:

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.

Back to Table of Content

---

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.

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.

Back to Table of Content

---

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.