Home > Proposal Instructions > Phase 2 > phase2UI_inst

Phase2 UI: Instructions

Contents


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.

Phase 2 Concepts Diagram (click for bigger)
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 & near2mag
    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.

Target Coordinates


  • EXTRASOLAR: Specify RA & Dec in J2000. If inputting many targets, a list can be entered in one go using the Multiple Target Entry Tool popup in the Phase2UI.
  • EPHEMERIS (planets, moons, asteroids, spacecraft etc):
    • For moving targets you may provide tabulated positions covering your observation window. The RCS will interpolate between the tabulated values to obtain a position and non-sidereal tracking rate for the instant of observation. See the Ephemeris Tables page for table format details.
    • When you add the target to an observation sequence it will initially be set to sidereal tracking mode by default. If you wish to use non-sidereal tracking:
      • enter observation sequence as before; it will (currently) use sidereal tracking.
      • when sequence is entered, click on 'Edit Observation Sequence' which will open the sequence editor window and display the observing sequence you just entered
      • highlight the line where it says you slew to the ephemeris target
      • click 'edit' in the 'sequence editing' box in left of the window; options should appear at the top of the window
      • at top right in these options is a button saying 'sidereal tracking'; click on that to turn it to 'Non-sidereal tracking' and press 'Replace' at the bottom of that panel
      • press continue at bottom left of the window and your observing sequence should now be using non-sidereal tracking.
      • press continue again to return to the phase 2 UI.
  • CATALOGUE: A small number of solar system objects may be addressed by name.

Adding a list of multiple targets to a programme/proposal


A list of multiple targets may also be uploaded to a programme, so that these can then be selected for observation within any of the proposals within that programme.

With the proposal itself highlighted in the main Phase2 window, click on Targets in programme: XJL15A03 (assuming a programme ID of XJL15A03, of course) and from the subsequent window select Add Multiple Extra-Solar Targets. The 'Multiple Target Entry' window will walk you through uploading your list of targets, and includes a note on formatting. The text file of targets should include only the target name, RA and Dec - one target per line - with no spaces in the target name and a colon separating hrs:mins:secs and deg:arcm:arcs.

Instrument Configurations


Instrument configurations are defined within the programme and shared by all proposals in that programme. The dialogue screen to define or edit configurations is accessible from either the proposal or programme definition screens.

You must provide an Instrument Config Name which is a simple text string you will use to identify the configuration within an observation sequence. It must be unique within the programme and should be sufficiently descriptive for your own convenience.

The available filters, gratings and CCD binning factors are provided in drop down lists and the legal values change dynamically as you select different instruments.

Observation Sequences


An observation sequence specifies the exact series of steps the telescope and instrument will go through to collect your data. For common tasks, wizards are provided to help build the sequence for you:

    Multicolour Photometry Wizard


    Create an observation sequence of a single sky target using a combination of one or more of the imaging cameras. Some defaults are set automatically and the most common configurable options are presented in a single simplified dialogue screen. See the IO:O-specific phase2UI guide for further details.

    Polarimetry Wizard


    Create an observation sequence of a single sky target using the RINGO3 polarimeter. Some defaults are set automatically and the most common configurable options are presented in a single simplified dialogue screen. Though this is very similar to the generic imaging and photometry wizard, this instrument has some specific requirement regarding telescope configuration, which are outlined in the RINGO3-specific phase2UI guide .

    FRODOspec (Dual beam Spectrograph) Wizard


    Create an observation sequence of a single sky target using either or both arms of FRODOSpec simultaneously. Some defaults are set automatically and the most common configurable options (e.g., calibration arcs) are presented in a single simplified dialogue screen. See the FRODOSpec-specific phase2UI guide for details.

    SPRAT (Imaging Spectrograph) Wizard


    Similar to the FRODOspec Wizard, this allows users to create an observation sequence of a single sky target using SPRAT. See the SPRAT-specific phase2UI guide for details.

Sequence Builder


For more complex tasks you must use the Sequence Builder to build a custom sequence (ideally editing a basic sequence generated by a wizard). The most common reasons for using the Sequence Builder are:

  • Combining imaging and spectroscopy or polarimetry of the same target into a single group. Combining direct imaging from multiple cameras can be achieved with the wizard.
  • Combining multiple targets into a single group. Remember that in the great majority of cases your best approach is to include a single target object per group. 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.

The Sequence Builder gives complete access to all schedulable functions of the telescope. It is entirely possible to create groups that would be unobservable on the telescope and certainly very easy to create groups which use the instruments in non-optimal ways. For this reason although sequences can be constructed from scratch using this tool, for the majority of observations you are better to use the wizards. For more complicated sequences it is usually easier to create a template sequence first using the wizard, submit it and then edit the details using the sequence builder.

See Sequence Builder for full details and the Sequence Builder Tutorial for a quickstart guide to creating an observation sequence.

The following pages for each instrument describe observation sequences for different instruments in detail, and provide the background you will require in order to decide whether you want to override the wizard generated configurations:

Cassegrain Rotator and Sky Position Angles


The phase2UI slew command incorporates both the target RA,dec and the cassegrain rotator angle which determines the image orientation on the sky. The cassegrain axis however does not provide a full 360 degree rotation and can only be commanded to positions in the range -86 < cass < +86. Therefore at any moment, only about half of the full range of sky PAs are available and assuming your observation is more than a few seconds long, the useful range is further restricted by the need to track the cass axis through the observation. You want to start your observation at a position where the axis will not reach its limit during the observation sequence. In some rare cases (e.g., tracking a dec +30 source for several hours as it crosses the sky, passing close to the zenith) there may not be any valid sky angle and the observation would need to be split into two parts, observed at different orientations.

Normal procedure is to leave choice of field rotation angle to the robotic scheduler by selecting "Automatic" or "Cardinal" for the rotator in either the wizard or the sequence editor. In this mode the field rotation angle will be chosen so as to give the cardinal orientation (i.e., sky position angle 0, 90, 180 or 270) which provides the longest possible unimpeded track of the target. The sky angle may therefore change depending on the time of the night when the observation commenced, but since the orientation will always be one of the four cardinal positions, the region of sky covered is always the same.

For those cases where definite selection of the sky angle is important, a software tool is available within the phase2UI which graphically represents the range of sky PAs available throughout the night for any given target. This tool should be used by any observer requesting a specific sky angle or creating a sequence more than a couple of hours long.

There is a separate web page providing detailed description of the rotator calculator tool and providing usage guidance.

Scheduling Priorities & Urgent Groups


The scheduler takes account of the proposal ranking set by the TAG in selecting which group to observe and all other things being equal, will select a group from a more highly ranked proposal. A group from a lower ranked proposal may still be selected however if it is substantially better placed on the sky or better matches the prevailing conditions. See https://telescope.ljmu.ac.uk/TelInst/Robotic/index.php#sched for more details.

Within a particular proposal there is no priority ranking and all your groups within that proposal are ranked equally against each other. In special cases however a proposal may be granted permission to use Urgent Groups. This option does not appear unless it has been granted and you should contact the Support Astronomer if you think you need it. Setting the "urgent flag" for a group just slightly raises the priority of the group but does not raise it to the level of non-urgent group in a higher ranked proposal. The urgent flag has no effect on FIXED groups. It is primarily intended to help the scheduler choose between your own multiple groups, not to get your observations scheduled sooner, in preference to some other observer's.

Resubmitting Observed Groups


FLEXIBLE and PHASED groups are only observed once, and after that will be flagged in the database as Group Done. A new button will then appear on the group definition screen offering the option to Resubmit the group to be observed again. This option never appears for FIXED, MONITOR or INTERVAL groups.

If the Resubmit button is pressed, what happens next depends on the timing constraint:

  • FLEXIBLE: The timing constraints are automatically reset to allow the group to be observed again. The group activation date will be reset to now. If the expiry date is still in the future it will be left unchanged. If the group has already expired then the expiry date will be set to a future time so as to make the group available for the same duration as it previously was.
  • PHASED: The timing constraints are automatically reset to allow the group to be observed again. The original start time, period and phase will be used to reset the group start time to the first available epoch after the successful observation. If the end date is still in the future it will be left unchanged. If the group has already expired then the end date will be set to an appropriate future time so as to make the group available for the same duration as it previously was.

The proposal expiry date takes precedence over group timing constraints, so no group would be available after the proposal has expired even if the group end date has been set later than that.

Starting the UI


The User Interface directly accesses the live scheduler database online so requires an active internet connection and is launched from within your web browser using the link on this page.

The principal system requirements are a live internet connection and Java 5, which may be obtained from www.java.com. The UI has been tested on a wide range of common OS (Linux, OS X, windows) and browser (Firefox, Safari, Internet Explorer, Chrome) combinations. Your username and password will be provided by the Support Astronomer.

Checking and Configuration Validation


Most fields are tested for legal values at the point of data entry and you will be alerted immediately of any invalid values. Some configurations and the interplay between particular options cannot however be tested until the group and sequence are complete. The interface therefore offers Validate buttons which you may click at any time. Validate Group checks the currently selected group and its observation sequence. Validate Proposal runs the same checks on all groups and sequences within the proposal in addition to a few proposal level checks.

A validation can return FAILURE which means the observation is invalid and will not be allowed to run on the telescope or WARNING which means the observation can technically be performed as defined but is probably not doing what you really wanted. An example FAILURE is a group without a timing constraint set. An example of a WARNING is a sequence which does not contain a target slew command. In this case the observation would be performed wherever the telescope happened to be pointing. You should run the proposal validation tool at the end of any editing session.

Accessing the data


This new Phase2UI is used only for scheduling of observations. The data archive remains unchanged from past semesters and may be found here. There has been no change to the data archive passwords; they remain associated with the proposal ID rather than the user, and therefore are completely independent of your Phase2UI password.