Priority List Algorithm
Version 20 Oct 2006
The priority list is constructed by modifying the TAC allocation assigned
to a target by the PI by a series of modifiers, that try to improve net
efficiency by recognizing time-dependent differences in urgency.
Remember that a lower
priority number equals greater importance.
| Modifier ||Effective Range||Algorithm || Reason
|Priority 0 modifier || -1 || if priority 0: -1
|| This forces priority 0 targets to be more important by 1 modified priority
than lower priority targets
|Priority 4 modifier || +1 || if priority 4: +1
|| This forces priority 4 targets to be less important than non-optimized
or easily observable priority < 4 targets
|Object availability || 0 to 2.4
|| if LRS_g2 or LRS_g3 or LRS_e2:
log10((num_possible_visits_left_in_tri- remaining_requested_visits * minfreq ))
| This gives more weight to targets soon to disappear
in the west or before some synoptic end date, e.g. <20041012
|Max sky brightness || 0 to 7.5
|| limit sky constraint to between 18 and 20.5
moon phase to sky brightness = (1.0-phase)*2.5+18.0
if sky constraint - sky brightness > 0
(sky constraint-sky brightness)*3.0
| This de-emphasizes targets with loose sky brightness constraints when the
sky is darkest but still gives them some chance
|Completeness || 0 to 0.6
|| This gives some extra emphasis to targets that have been started but not completed
|Filling factor || 0 to 1.0
|| This uses the HETweb filling factor code to get the filling factors, then uses:
| Higher priority accrues to objects near their
optimal filling factor times, except for targets boxed in by
times of prohibitive sky brightness
|Partner share || -1.5 to 0.5
|| This allows us to emphasize partners with smaller HET access
|Past due modifier || -1.0 to 0
|| if not past due:
| This favors synoptic targets approaching or exceeding the
maximum due date, but the priority boost for being overdue is capped at -1.0
These modifiers are added together and the targets are then sorted by their
modified priorities. Targets are chosen from lowest priority number
(viz. greatest importance) and placed
in the priority list. If subsequent targets have start or end times that
overlap the previous targets, the code tries to slide the lower priority
target in time (up to 14 % of the track length) to see if it can be fit into
the queue. If not then it moves on to a higher priority number
(viz. lesser importance) target to find one that will fit in.
- A P2 dark time target vs. a P1 bright time target during dark time
with similar numbers of visits left in the period: the bright
time target is docked by the sky brightness modifier enough so that
the P2 target takes precedence.
- A P1 bright time target vs. a P2 bright time target during dark time
with similar numbers of visits left in the trimester: all modifiers
cancel out and the P1 target wins by its original 1 priority unit.
- A P1 dark time target with 100 visits left vs. a P2 dark time target
with 10 dark visits left: the modifier for number of tracks
left favors the P2 target by 1 priority unit.
- A P2 Munich target vs. a P1 UT target with otherwise similar parameters:
P1 Munich gets emphasized by an institutional modifier of -1.28
priority units, to compensate for the large partner share ratio;
the Munich target goes first.
- A P3 target with synoptic frequency of RAND2-5 vs. a P2 target. If all
other parameters are equal, the P3 target could beat the P2 target
by virtue of becoming long overdue past the RAND-coded window.
Note that no modifier giving absolute primacy to dark time targets is currently mandated by the HET user committee.
Last updated: Tue, 08 Jun 2010 10:20:11 -0500 shetrone