Selection Rules

The selection process should proceed down the listing below, in numerical order of the "Criteria" sections. The selection criteria listed in green should have the option for the telescope operator to turn them off in the case where not enough sessions meet the selection criteria. Additionally, if a session does not have complete information in the database (the observer has not filled out the information needed to make the assessments below) that session will be ignored in the selection process. (This then leads to another tool that will be needed - something to check and see if the database has been filled out for sessions which are accepted to be run during the semester. An "urgent" check would also have to be in place in the case of fixed time sessions.)

Criteria Summary

The Selection Rules below are divided into Criteria groups. Each group contains rules that are of type Elimination or Ranking. The Elimination rules are a binary, yes/no, decision, that determine whether an session will become a candidate or not. Ranking rules are applied to each surviving candidate, and result in a prioritized list of candidates.

Criteria I-III, V & VI are Elimination Rules, while Criteria IV is Ranking Rules.

The Elimination Rules below are, by nature, discrete, while the Ranking Rules in Criteria IV are continuous: these rules use a numeric scale to assign values to each session candidate (or weighting factor) which may then be compared to other candidates. A candidate’s priority is ultimately determined by the product of all these weighting factors.

Criteria I (Is a session eligible to be run? All criteria need to be met in order for the session to be chosen.)

Does the LST range defined in the session fit into the current schedule (see Scientific Requirements Memo)?
- As a starting point, current schedule is going to be defined as the next 12 hours. The "best" choice session must necessarily be an session that can be run at the specified time, but the "best" telescope period depends on many factors: upcoming fixed and window projects, other high priority sessions that can start in the near future but can not run now, weather changes (to name a few). The process we envision endeavors to provide the operator a list of prioritized sessions and the associated metadata that helps the operator choose the TPs appropriately. For example, fixed and window Sessions that are within 12 (?) hours of the specified time are always included in the candidate Session list and will be clearly marked as fixed/window with their required start times. Furthermore we believe that providing the operator with a widget that allows them to overlay upcoming sessions that can be run in the near future but not at the input LST will provide the operator with useful information to choose the TP appropriately. The "look ahead overlay time" might be specified by the operator or defaulted. We suggest the overlay method as a default because of our concern of information overload for the operator.
Is the observer available?
Is the hardware for the project available?
- The determination of availability of the hardware is time sensitive. When the DSS is used to determine the next project to be run, hardware availability will be determined using the current cabling and dev_health files. For scheduling forecasts, a master cabling file that includes all commonly routed signals will be used and all devices will be assumed healthy.

The Current implementation for the near real time scheduler is just a flag indicating whether the hardware is available. For forecasting the plan is to use a cabling file that includes all backends and receivers with no devices inoperative.

Is the project's semester the current one? If not, is it an 'A' ranked proposal with a current or past semester?
- The option here is to allow the operator to look at all proposals from past semester(s). Projects from previous semesters with a science grade equal to or higher than the science grade specified by the operator (Bullet item #8) will be eligible to be run.
- We may eventually also want the ability to look at proposals/sessions from future semesters.
Has the total project time elapsed?
- If a project is left with less hours than any of their sessions' minimum time, the Session verifier should notify the investigator(s)and the appropriate human intervention can happen.
Has the total session time elapsed?
- If a project is left with less hours than any of their sessions' minimum time, the Session verifier should notify the investigator(s)and the appropriate human intervention can happen. Additionally, when using the override for this option, if the sessions time has elapsed, the time gets charged to the session, but not to the project. This means that any reporting tools for total telescope usage must look at total session times, and not total project times.
Has the total time for this session exceeded the maximum allowed for the given semester?
- If a project is left with less hours than any of their sessions' minimum time, the Session verifier should notify the investigator(s)and the appropriate human intervention can happen. In this case, when using the override for this option, the time is charged to the session and the project.
Does this project have an A or B science grade?
- Note - the operator should be given the choice to individually include "C" and "D" science grade projects.
If none of the observers are on site, are any of the potential remote observers approved for GBT remote observing and available?
- We note that only those users who are qualified for remote observing should be on the contact list provided to the operator.
Has any "time between" time elapsed?
- There are three possible uses for the "time between" idea:
  - Case 1: time between is the time between the last observation by an observer and the next time the observer should be contacted again to observe ANY project. this will be handled on a case-by-case basis by the operators. At most, a mention the operator's logs to note that a person wishes not to be disturbed may be needed.
  - Case 2: time between is used by the PI because there must be time in between session "segments". For example, an observer must analyze the data from his last session segment before the session is scheduled again. This is an session specific 'time between'. It is expected that sequentially ordering between different Sessions within a project will be handled by the "priority" session metadata and not in conjunction with the time between metadata. This is a standard use of the "time between" parameter.
  - Case 3, time between scheduled runs for fixed windows sessions. This, too is a standard use of the "time between" parameter.

Criteria II (Fixed time and fixed window sessions)

If more than one session falls into this category, both should be displayed with a warning that there is a severe scheduling conflict. The conflict will be resolved by human intervention.

Is there a fixed time session? (If yes, that session is run, provided Criterion V and VI hold.)
Is this the last opportunity for a fixed window session? (If yes, that session is run.)

Criteria III (Weather and session time)

All of the below should be met for any non-fixed time or fixed window session to be run.

Is the time of day correct (work hours, nighttime, any time, solar avoidance)?
Is the minimum time for the session less than or equal to the available Telescope period (e.g. it doesn't run into any fixed time sessions)?
Is the weather at least as good as the desired weather, using the methods described in the Scientific Requirements Memo.
1. Assuming a canonical frequency and declination calculate the transit atmospheric observing efficiency ( $\eta_{atm}$ ) using Equation (1) of DSPN2 (i.e., set the hour angle, H, equal to zero). Is $\eta_{atm} \ge \eta_{min}$ ? (The default value is $\eta_{min} = 0.5$ ; although we need to let the observer modify this default if justified.)
2. Assuming a canonical frequency calculate the maximum usable wind speed ( $V_{max}$ ) using Equation (24a) of DSPN2. Is the current wind speed less than $V_{max}$ ? (The default value of $V_{max}$ is determined by Equation (24a) but we need to let the observer modify this default if justified.)

Criteria IV (Ranking the eligible sessions)

All sessions which meet the first three selection criteria should be displayed for the operator's consideration after the ranking process. If we find that too many sessions are showing up in the priority list for selection, we can always limit the display to typically only show the top 10 or so, but with the option for the support staff to see all sessions which meet criteria I-III (in the same manner that JCMT allow this).

Rank the remaining sessions using a weighting scheme defined by the rank, R, whereby a higher number implies a better score. Here, we will be using a multiplicative ranking scheme, with

$R=\Pi_k,l=1,… \; K^l$

where the weights for the different factors have been determined empirically (through testing and later through experience)

The different factors are listed below. A more complete description is given in Project Note 4.

Stringency factor for session (see Scientific Requirements Memo). It will be a number greater than or equal to 1. Since the stringency is the most important factor for ranking maybe use k1=1.0. The stringency is determined from three factors:
1. Stringency for winds based on usable performance.
2. Stringency for atmosphere based on zenith atmospheric efficiency greater than 0.5.
3. Stringency for thermal gradients affecting the surface during the day for frequencies over 40 GHz.
Observing efficiency, defined as the ratio of the integration time needed to reach a given signal-to-noise ratio (SNR) under the best circumstances to the time needed under the actual circumstances. A difficult observation should be scheduled only when conditions are good enough that the observing efficiency is reasonably high (e.g., > 0.5). Observing efficiency depends on three factors:
1. Atmospheric efficiency (due to weather)
2. Surface efficiency (due to surface deformations)
3. Tracking efficiency (due to winds)
Queue pressure, a measure of how difficult it is to get on the telescope as a function of parameters not directly related to scientific merit. The most important example for the GBT is high proposal pressure for observations close to the Galactic Center. Dynamic scheduling uses pressure in a feedback mechanism to ensure that the delay in executing an approved project is minimally biased by such extraneous factors.
Observer on site. This factor is designed to encourage observers to come to the GBT for observations without unduly punishing those who are unable to come. Its weighting is such that an observer on site should have his/her sessions ranked higher than a remote observer with similar weather requirements.
Semester for this project. The purpose of this factor is to ensure that projects are finished in a timely fashion and do not end up “hanging around” waiting to be completed.
Project’s science grade. This is the grade given to the project by the proposal selection committee. A higher grade would naturally result in a higher numerical factor.
Percent completion. Like the semester factor, this is designed to ensure a timely completion of projects. It is a continuous factor and is proportional to the percentage of its allotted time which a project has completed. The purpose of this factor is to insure that, all other factors being roughly equal, a project which is 90% complete is scheduled before one that has not yet started.
Windowed session. The purpose of this factor is to prevent windowed sessions from always running on the last day of their window.
Thesis project. All other factors being relatively equal, we would prefer to give telescope time to a project which is part of a thesis or dissertation over another project. This factor has a low weight in the overall scheme.
Lower atmospheric observing efficiency. All else being relatively equal, we would prefer to select the session with a more limited time frame, in this case chosen by the sessions low declination.

Criteria V (Can this session really be run?)

Once the priority listing is made, these criteria must be considered. The answer to the questions will be provided by the support staff (most likely the telescope operator). If the answer is "no", then the next priority session, as listed by "Criteria IV", will be run

Is the observer really available (can we find him/her)?

Criteria VI (Made during observations)

The observer and/or support staff (telescope operator and observing support) will make the decision on this. If either answer is "yes" then a new session is chosen either from the priority list (if little time has elapsed) or by restarting the selection process again.

Is the RFI environment to bad to support this observation?
Has the weather turned, making the data taken useless?
Did the equipment break?

Science Grades - The Working Hypothesis

The policy on science grades is still to be decided. In the meanwhile, we have adopted the policy below. Once the final policy is decided, this strawman policy will be discarded and the true policy will be used within these documents and in the DSS.

Proposals will be ranked A, B, C and D
'A' grades will be given to a few, very-highly rated proposals. These are the ones we really, really want to discharge as soon as conditions allow. Their grade status mean that at the start of the semester, when no projects have been started, they get a natural selection-likelihood boost - an SLB - and then they should keep that on the basis of being a "started" proposal. This would typically never fill more than 25% of the expected weather in a given classification.
'B' grades will be given to the vast majority of proposals. The PSC should select enough of these so that the weather queues are almost, but not quite complete. These are the "normal" proposals which we hope to complete in a semester. This would fill almost the remainder of the expected weather in a classification (e.g. filling an additional 50%)
'C' grades are for filler proposals. The PSC selects a reasonable number of these to overflow all of the queues. These will never be selected as long as there is anything better to do, but they prevent the telescope sitting idle due to an unusually long spell of good (or bad) weather.
'D' grades are rejected. If we contemplate having to run these, we beat the bushes, or have local support staff make up some more commissioning work, or whatever.

Note that we will also have to identify Legacy proposals, but once a trimester starts, these may not be any different from other proposals.

The above criteria result in fixed time/window projects being observed provided it gets an "A" or "B" science grade. If the Proposal Scheduling Committee selects a fixed window project, by definition they think it is important enough to over-ride other projects which could make better use of the prevailing weather conditions. A trivial wrinkle is that there might be some C-grade fixed window projects. These would be "don't do them if there is anything better to do, but if you are going to do them, it only makes sense to do them at a fixed date/time". Low priority telescope maintenance might often fall in to this category - we'll only grease the bearings if there is absolutely nothing else to do, but if we are going to grease the bearings, we want to do it week-day mornings.

Temporarily interrupted Telescope Periods

Periodically a TP may need to be stopped due to, e.g. high winds. In this case the following policy will be adopted:

The current observer is allowed to choose whether they wish to finish out their current session segment, despite the temporarily interrupted TP (this could be a wind stow, or e.g. an equipment failure).
If it is a high frequency project and it gets too windy for the requested wind grade, the observer may decide to continue with their TP in spite of the wind (e.g. they are convinced the wind is going to drop soon). In this case, since they choose to keep "observing" in bad weather, the time is charged to their project. Note in general we should be discouraging this sort of behavior since it means the observer is using marginal (for them) observing conditions which might be excellent for a lower-frequency observer.
It is a high-frequency project and it gets too windy, the observer may decide to abandon his TP. In this case we just start a new TP, having updated the "current weather conditions" metadata.
It is a low-frequency project, and the wind reaches the stow limit, we just have to stop observing and stow the telescope. The time is not charged to any project, but is billed to lost time due to weather. When it looks like the wind is going to be sustained low enough to resume observing, the observer may continue and complete his TP. If a considerable length of time has passed, the previous observer may decide to abandon, at which point we just start a new TP, with updated current metadata.

Concerns

VLBA dynamic scheduling: We are working with the VLBA scheduling team to come up with a policy for VLBA+GBT dynamic scheduling.
We need to know the final policy on science grades
We need to know the limitations imposed for large (legacy) proposals. Will the limit be no more than a certain percentage of LST? RA? Weather?
Scheduled receiver changes will not be included in the current forecasting which may become a problem when we attempt to provide probabilities for sessions to be run.

Flowchart of rules

Logical Flow Chart

Topic SelectionRules . { Edit | Attach | Ref-By | Printable | Diffs | r1.42 | > | r1.41 | > | r1.40 | More }

Revision r1.42 - 23 May 2007 - 20:36 GMT - KarenONeil Parents: WebHome	Content copyright © 1999-2007 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.


NRAO Home > Green Bank \| Wiki Topic: GB > Dynamic > SelectionRules

Changes \| Index \| Search \| Go