Pure Parallels - PhaseII Structure
Pure parallel targets:
In 1997 the Parallel Working Group (PWG) officially defined two types of pure parallel programs.
The most common type makes use of large generic regions dependant on galactic latitude
while the second type uses small generic regions placed around extended targets such as nearby
galaxies or galactic objects. A proposal can contain either or both of these strategies,
so a good example is STIS pure parallel 8091(1) which actually uses both types.
The two fixed targets numbered 4 and 5 in program 8091 have the REGION, R=10'
included just after the RA and DEC. This creates a circular region with radius of ten
arcminutes around the target. If the parallel aperture falls within this
region, a pure parallel visit may execute at that pointing. A list of the
targets to be observed per cycle is essential in order to write this so called "special object" type of pure parallel program, such as this list for cycle 9(2).
A list of targets to be observed in cycle 10 will also be available online before the cycle 10
phaseII deadline. These special object parallel programs may execute with primaries
from any cycle. Program 8091 has only two such special object targets, but one can use hundreds if they
so desire. The trick then is to reference the target numbers of these fixed targets via
a generic target. Note how generic target number 3 uses the "targets = 4-5" for the criteria entry.
This allows any visit in the parallel proposal which uses the name of this generic target, REDSHIFT2 in this case,
to be used for scheduling with possibly hundreds
of fixed targets, instead of just the two in program 8091. Just one parallel visit could reference up to 999 fixed targets for instance.
Creating 999 seperate visits in RPS2, each for its own target, would be impractical. Different generic targets can reference
different fixed targets also. For instance one list could refer to galaxies while another list refers
to planetary nebulae. Different template visits with the certain types of filters and exposure times
could be used for the galaxy list than from the nebulae list. The target list strategy is documented
in the phaseII proposal instructions section 3.12.6.
Generic target numbers 1 and 2 in program 8091 use the larger generic region type of
strategy. Any template visit using the target name HI-LATITUDE-FIELD
will craft parallel visits when the primary is greater then 15 degrees
in absolute galactic latitude. Conversely for template visits with target
LOW-GALACTIC-FIELD and primaries less than 15 degrees galactic latitude.
The PWG defined archival (default) pure parallel programs for each instrument using the large generic
region type of targets, all dependant on galactic latitude. All data from these archival programs are
non-proprietary and thus immediately retrievable from the archive. Of course, in addition to these archival
programs, the TAC will award pure parallel orbits to General Observers with promising science programs
or programs making innovative use of the instruments. The GO parallel data is also usually
non-proprietary. The PWG also recommended awarding funds for researching the already archived data
from these default pure parallel programs.
POMS
The software for scheduling pure parallels is called POMS (Parallel Observation
Matching System). It matches the actual pointings and orbit durations available for pure parallels
on weekly flight calendars to the visits contained in a pure parallel proposal. POMS then creates
pure parallel visits "on the fly" for the specific orbit(s) available for parallel scheduling.
The visits in a pure parallel program are used as "templates" by POMS to use for creating
the parallel visits which actually execute.
Visit_Priority
Each template visit has a
visit_priority value. The highest values are placed on the most scientifically
valuable visits. The typical scenario is to give the longest visit the highest
priority since POMS attempts to match these to parallel opportunities first.
In a "bubble sorting" type of routine, POMS will try to match all highest priority
visits first and proceed downwards in priority until all visits have been attempted.
So proposers really control the structure of the visits that are crafted as far
as length, filters, gratings, etc. If only a six orbit visit is to be executed,
only a six orbit template visit should be submitted. However, the typical case is
to have all lengths of visits from as many as eight orbits down to fractions of an
orbit in a program. This ensures at least some parallel science will schedule,
whereas a single six orbit case may never be scheduled.
EXPAND, MAX DUR
Since pure parallels are scheduled late in the weekly calendar building process, unlike
primary observations they can be "crafted" in real time to best fit an orbit's true duration.
Use of the exposure level EXPAND and MAX DUR requirements will allow this adjustment to the
requested exposure time to occur. An orbit's duration depends on the target's declination.
Throughout the year that duration can change depening on HST's 56 day precessional period.
An orbit's duration in RPS2 is limited to allow the longest 30% of the orbits over a given year
to schedule. That means there could be extra time available in the actual orbit in which the
visit executes. Anywhere from a few minutes to the point where a target could be continuously
viewable (CVZ). While primaries are restricted to use the RPS2 visibility on orbit, pure
parallels are not. This can be a very advantageous for programs requiring the longest
integration times possible, so make good use of these requirements. All pure parallels except
those using NICMOS can make use of EXPAND, MAX DUR and MIN DUR. The EXPAND requirement on
a primary program will simply adjust that exposure to fit the orbit in RPS2. An EXPAND
requirement on a pure parallel will adjust the exposure to fit the actual orbit in which
it will execute.
ACS pure parallels can make use of the EXPAND, MAX DUR and MIN DUR
special requirements. However the auto parallels need to be turned
off in order to not cause buffer management problems. The optional
parameter PAREXP=NONE should be used for each exposure to do this.
The avail_ok flag needs to be set to YES in order to use the PAREXP
parameter in a GO program. When using the PAREXP parameter the
number of iterations on that exposure must be equal to one, or RPS2
will generate an error message. It's also best not to use CR-SPLIT
and EXPAND at the same time since the multiple exposures may be
expanded unevenly. Set CR-SPLIT=NO and create multiple exposures
instead. Here is the example of the
ACS archival program.
Parallel Pointing Tolerance
The pure_parallel_pointing tolerance is entered near the very start of the RPS2 file
This is the maximum value in arcseconds which the primary visit can move (dither) before
the pointing can be considered for an individual template visit of the parallel proposal.
The parallel instruments will not be exposing during spacecraft motion, but the individual
exposures within a parallel visit can execute during exposures in a primary visit which are
dithered a given distance before POMS will not craft a parallel visit. Dithers can cause
problems for parallel scheduling since there may be too many conflicts too allow any
parallels science at all, such as the more common NICMOS dither patterns. However if
there are one or two dithers per orbit, POMS can usually allow parallel scheduling.
Setting this value to the maximum possible will ease scheduling constraints and make it
more likely for your pure parallels to execute. If movements between exposures are acceptable
to a certain point, then this will allow the longest, most valuable template visit to be
used instead of several shorter and less valuable template visits in its place.
Proposal Tools
RPS2 does not display the true on orbit type visibilities for pure parallels of course, but itis still used just as for primary programs to create, display and change program structure,
submit. The Proposal Category entry, part of the proposal information section at the beginning should be set to GO/PAR, than every visit in the proposal is considered a pure parallel.
PED allows all of the values mentioned so far to be entered, although for programs with
hundreds of targets your favorite text editor may be a better choice.
VTT - the visual target tuner is a big step in helping to write pure parallel programs, especially of the "special object" type.