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.

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 25° 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.

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.

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

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.

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:

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.

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
http://telescope.livjm.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.