HET Phase II Management
One of the most difficult aspects to running a complex program is
managing the Phase II data. This is a problem for both the RA and
the PI. Here are a few tips for running a successful program.
- Always double check your Phase II material before sending it in. Many
failed exposures arise from mistakes made by the PI in the
Phase II details submitted.
- If you must remove an object from your Phase II list, ask that it be
marked as deferred (status=D). Permanent deletion from the queue database runs
counter to HET practices but you can Junk an entry if you don't want to see it in the Program Status field. If wanted, a target marked as deferred can be
restored to active at PI request or via the new Phase III system.
- Keep all target names unique including any later additions to your Phase II
list. E.g. if you had a target called M67_S986, then replace it with one named
M67_S986_2 or the like. Likewise for a MOS field, upon resubmission its name
should feature some clear distinction from the previous target names.
- If you must make changes to your Phase II list after it has been submitted, try keeping them small and simple; if they must be extensive, submit a entire new
Phase II target list and ask that your old targets be marked as deferred
(status=D). The RA staff
can make editing changes to several targets per program per night, but large editing
chores, particular for lengthy or detail-rich MOS or synoptic target lists, should not be off-loaded to HET night staff.
- Always check the status of your changes with the
Program Statistics CGI.
- If you have no actual targets by the deadline (as can happen with synoptic, MOS, TOO, or other programs dependent on collaborator input), send in a placeholder deferred (status=D) dummy target. Doing so enables the RA staff to verify
your Phase II format and file your materials as needed for night operations, and
also clarifies that your targets are not unintentionally missing.
- Grouping keywords allow targets to be executionally linked, but each
target standing on its own is typically operationally cleaner. Often grouping
could be tried but is in fact unnecessary. Example One. Synoptic targets
with several priority levels. Activate (status="") only the top level. Put in comment field "activate prio () when done and set date". No explicit
grouping is necessary. Example Two. Cals that are very unusual, needing explicit elaboration, can be formulated as "targets" that are grouped with the science they
are to be adjacent to. For ordinary cals, a comment entry suffices such as "Take adjacent ThAr and FFGC" again obviating explicit grouping.
- Extra cals need only be cited if they exceed in some way the standard
cals. Then the excess (extra - standard) will be furnished. It is a pointless
and possibly confusing to cite extra cals that are a subset of the standard
- A program can have multiple targets with a single
object/setup combination. Some situations leading to
this are (1) using a suite of priorities within one
trimester, or (2) using a mono-priority suite of
targets with distinct synoptic (i.e. time sequencing)
keywords or phase blocking within one trimester.
Understand that RAs carefully prevent any unwanted
repeat observation of the same target index number
during the course of one night, but having multiple
targets (indices not necessarily sequential)
concurrently ready (unblocked) for observation can
entail a risk of unwanted intra-night repeats on
the same object/setup combination. (In a
very long night it is not guaranteed feasible to cross
check against every object/setup combination logged so far.)
The safest PI practice is to use synoptics or phase
blocking to avoid multiple (same object / same setup)
targets being concurrently ready (unblocked) to visit.
One way e.g. is by setting the status to D (deferred) for
the to-follow priorities or synoptic patterns, and adding
the comment instruction to "unblock target N when done"
i.o.w. by structuring a chain of targets
featuring only one ready (unblocked) at a time. If there
are just a few visits at each priority (e.g. 2) it is
probably safe to assume that an accidental double visit
(at each of two different priorities on the same night)
is not going to occur by mischance, and in this (few visit)
limit only, concurrently active (same object / same setup) targets
can be assumed safe from unintentional repeats.
- Please provide finder charts digitally (pdf, ps, jpg, tif, or png).
Supply one file per target with the name precisely matching the target name;
for example HD123456.pdf not HD123456_chart.pdf.
Last updated: Thu, 31 Jan 2013 22:55:47 -0600 caldwell