Phase2 UI: Instructions

Contents

• Basic Concepts
  
  • Programmes and Proposals
  • PIs and Co-Is
  • Groups
  • Constraints
    • Timing Constraints (required)
    • Observing Constraints (recommended)
  • Target Coordinates
  • Instrument Configurations
  • Observation Sequences
    • Multicolour Photometry Wizard
    • Polarimetry Wizard
    • Dual Beam Spectrograph Wizard
    • Sequence Builder
    • Cassegrain rotator and sky position angles
  • Scheduling Priorities & Urgent Groups
  • Resubmitting Observed Groups
• Starting the UI
• Checking and Configuration Validation
• Accessing the Data

Basic Concepts

The structure of the present Phase 2 database is more modular than the previous version. This diagram shows how the different modules are related to each other. A full description of each module follows below.

Click for bigger [76KB]

Programmes and Proposals

A PROPOSAL is created each time an application form is submitted to one of the TAGs. Each proposal has associated with it a single PI user and the single TAG to which the application was made. A proposal might, at the TAG's discretion, span multiple semesters without changing its proposal number.

A PROGRAMME allows multiple proposals to be associated as parts of an ongoing or larger study. This might occur when users re-apply in future semesters for more time, where multiple PIs collaborate by submitting separate parts of a programme and might even span allocations made by different TAGs to the same project.

Time allocation and accounting are always performed at the proposal level, but programmes are useful to both the TAGs and observers in several ways:

• Target objects and instrument configs only need to be defined once in the programme and are then shared between the individual proposals without the user having to type them into each. Similarly if time is later allocated in a future semester, the proposal ID would change, but it would not be necessary to re-enter targets in that new proposal because it is part of a single programme.
• Typically the proprietary data period is defined by the completion of the programme rather than expiry of individual proposals.

PIs and Co-Is

Proposals are first created in the database with only Principle Investigator (PI) named as specified on the time allocation application. The PI may contact us and request that Co-Investigators (Co-Is) be added and granted full access to the phase 2 data base for a particular proposal. We also have the concept of Associated Investigators (AIs) who would have read-only access but this has not been implemented in the current software. Please let us know if you think it is an important addition. Pre-observation planning and post-observation data access are controlled by independent password systems. (See also Accessing the data.)

Groups

A Group is the smallest consecutive set of observations that can be scheduled. If any observations in a group fail, the whole group will be rescheduled for observation. A group can carry out one or more observations of one or more targets. In the great majority of cases, your best approach is to include a single target object per group, potentially with several actual exposures using different filters and integration times. A multiple-target group should only be used if it is essential the observations are made consecutively (e.g., target and calibrator) as this will usually reduce the probability of the group being schedulable.

Groups must have a single Timing Constraint (and optionally several Observing Constraints) defined for them - see below.

Constraints

The constraints placed on a group are used by the robotic system to decide if a group may be performed. A group may be observed whenever conditions match or exceed the requested quality criterion. The fewer constraints you define, the more likely your group will be done, but under less controlled observing conditions.

Timing Constraints (required)

Note: Time windows, as discussed below, are used to specify the interval within which a group should begin its observing run. The total execution time is unaffected by any time window specification. For example, a group with a four-hour execution time and a two-hour window could start its run near the end of the window and still run for four hours.

• FLEXIBLE
  To be performed once, at any time between the start and expiry dates. After a group has been observed it may be manually resubmitted to be observed again.
• FIXED
  • Observed at the time specified. If for any reason (e.g. weather) the group is not performed within that time window, you will need to reschedule it for another time.
  • FIXED groups by their nature disrupt other group types, and so only certain proposals are authorised to submit them. You must ask permission to use FIXED groups when submitting your proposal.
  • The start time of the fixed group must be specified along with a user-configurable tolerance (the "slack"). The slack defines the total width of a time window, centered around the specified start time at which the group may be executed. For example, a 10 minute slack will allow execution to begin any time between 5 minutes before and 5 minutes after the specified start time.
  • A feature of FIXED groups for rising targets is that they will usually not run if the slack includes some time when the target is still below the LT's 21° horizon limit. For example, consider a target that rises past the LT's horizon at 22:40, and the FIXED group's start time is set to 22:45, with a slack of 20 mins. This means the observation could begin between 22:35 and 22:55. The target is still below the horizon at 22:35, and as FIXED groups tend to execute as soon as the window opens, the RCS would consider the target unobservable.
    
    This effect can be avoided by altering the start time and/or the slack to ensure the time the window opens is well clear of the target's rise time. To continue the example above, the start time could be reset to 22:55 while keeping the same 20 min slack, so the window opens at 22:45. Alternatively the start time could be set to 22:50 and the slack narrowed to 10 mins, so the window again opens at 22:45. It's best not to make the slack too small however; we recommend no smaller than 10 mins.
    
    In practice then it's best to think first of the start and end times of the time window, and then calculate what start time and slack are necessary to engineer that window in the Phase2UI. For example a window starting at 22:45 and ending at 23:15 means entering a slack of 30 mins and a start time of 23:00.
  • Only seeing and photometricity constraints are used by the scheduler. All other constraints will be ignored, since circumstances such as solar or lunar position, airmass etc are all calculable by you in advance. Therefore, when you define a fixed time, we consider that time to have overriding force. Consider carefully before putting any constraints on a fixed group. For example, if there were a brief period of poor seeing around the time your group was scheduled, would you really want the group to be abandoned? At the fixed scheduled time, there is no way to know if the conditions might improve during your observation and it would have been OK.
  • When scheduling a fixed group, you should check first that another user has not already booked your desired slot by looking in the Phase2UI toolbar menu under View > Future Fixed Groups.
• MONITOR: Scheduled at periodic intervals between start and end dates. The time between start and expiry dates is divided up into observation windows and the RCS will attempt to execute the group once in each window. There is no preference for when within that window the observation will be obtained and success or failure to obtain a particular epoch does not affect when the next epoch starts. Three parameters are defined: a start, a period and a window. The window defines the total length of time centred around the quantity (start_time + N * period) where N=0,1,2,3 etc. For example, consider a group where the following time constraints are defined:
  starttime = midnight UT tonight
  period = 48 hours
  window = 1hour
  This group can be observed at any time between 23:30 and 00:30 UT on alternate nights (except for the first and possibly last night, see below). If one of the scheduled nights were cloudy, the group would still not be attempted in the following night - it would wait for the next scheduled window. The very first and last window periods are affected by the start date and end dates delimiting the lifetime of the group - the first observation window is halved in size (because the start date of the group is half way through it). Hence, in this example the group can be observed between 00:00 and 00:30 UT on the first night, after that it can be observed at any time between 23:30 and 00:30 UT on alternate nights. If the end date of the group occurs during a window, that final window will also be truncated accordingly. To get the best populated light curves, we recommend setting the window to be about 80% of the period. This means that the group can be observed at almost any time, but only once per window. There is no guarantee that the groups will be equal times apart and it is possible for a group to be observed at the very end of one window and then be re-observed at the start of the next window. However, over the long term, observations will tend to average out to be separated by the period with some possibly advantageous dither on the exact timings.
• INTERVAL:
  • The group will be observed as often as possible but never with an interval between epochs of less than the defined time. For example if a group is observed at midnight UT and it has a minimum interval of 25 hours, the earliest it can be done again is 01:00UT the following night. If it were then actually observed at 04:00UT the next time it could then be observed would be 05:00UT on the following night etc.
  • NB: If switching an existing group from non-Interval to Interval mode, make sure to set the "maximum number of repeats" greater than the number of observations already made by that group. The scheduler (currently) does not discriminate between timing constraints when it comes to counting previous observations.
• PHASED: Defined exactly like a MONITOR group, but the observation will only be obtained once. Used where you want a single observation of a periodic phenomenon at a specified phase but you do not care on which epoch it is obtained. After a group has been observed it may be resubmitted to be observed again.

Observing Constraints (recommended)

The following observing constraints are available:

• Airmass: All of the targets in the group must have airmass smaller than the specified value over the entire estimated execution length of the group. We recommend a value of 2.0 for this parameter unless you have a requirement to observe at lower altitude.
• Hour Angle: All of the targets in the group must have an hour angle within the range specified evaluated at the start time of the group.
• Photometricity (transparency): If "photometric" is selected then the night must have been flagged as potentially photometric at the start of the night. This is not a guarantee of photometric conditions but will avoid obtaining data on nights with any obvious cloud or severe dust. A group with a photometric observing constraint will only be executed in photometric conditions. Similarly, a group with a non-photometric constraint will only be observed in non-photometric conditions. Do not enter a Photometricity constraint if your data can be acquired in photometric or non-photometric conditions.
• Seeing: The predicted R band (FWHM) seeing at your target's zenith distance as derived from recent photometric standards must be equal to or better than the specified value. Seeing changes rather unpredictably so the scheduler is set to attempt an observation when the predicted seeing gives at least an 80% probability of achieving the requested seeing at the start of the group execution. No prediction is made for changes over the duration of the entire group execution. Scheduling is always performed on an assumption of r'-band so you might expect for example, u-band images to show FWHM larger than the criterion set in the observing constraint.
• Sky Brightness
  This combines both twilight and moonlight in a single constraint and is expressed in terms of how much brighter the r'-band sky is than under best possible dark sky conditions. The constraint is applied for the entire expected execution time of the group, so a group may not be started if it is expected to run into morning twilight or Moon rise. As with Seeing, the constraint is based on the r'-band irrespective of what filters or instrument you use. The following table gives some guidelines fr converting traditional phenomenological criteria to the numerical one. A more full description of how the sky brightness models were derived and are applied is available on the Sky Brightness page.

  Twilight	Moon	Phase 2 class
  Civil	Any	10mag
  Nautical	Any	6mag
  Astronomical	Bright	4mag
  Astronomical	None	2mag
  Night	Gibbous & near	2mag
  Night	Gibbous & far	1.5mag
  Night	Crescent	0.75mag
  Night	None	dark

  As with all Observing Constraints, if you do not set any value in the phase2ui that means the parameter is completely unconstrained. I.e., you are happy to observe from the moment the Sun is below the horizon; perfectly legal, but not likely what you want.