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 RangeAlgorithm 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)/(3*minfreq)))
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
else 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 0.6*(requested_visits-visits_done)/requested_visits) 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 4*(actual_current_share-agreed_HET_share)/agreed_HET_share 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.

Illustrative examples:

  • 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

Observing Status


Weather Closure Policy

Observing Priority List

Priority List Algorithm

Night Reports

Operations Schedule