• flowchart_v2.pdf: Flow Chart

• Logical Flow Chart

%META:FILEATTACHMENT{name="flowchart_v3.pdf" attr="h" comment="Flow Chart" date="1179952465" path="flowchart_v3.pdf" size="39815" user="KarenONeil" version="1.1"}%

Flowchart of rules

• flowchart_v2.pdf: Flow Chart

%META:FILEATTACHMENT{name="flowchart.pdf" attr="" comment="Flow Chart" date="1174335434" path="flowchart.pdf" size="25225" user="DanaBalser" version="1.1"}%

%META:FILEATTACHMENT{name="flowchart.pdf" attr="h" comment="Flow Chart" date="1174335434" path="flowchart.pdf" size="25225" user="DanaBalser" version="1.1"}% %META:FILEATTACHMENT{name="flowchart_v2.pdf" attr="h" comment="Flow Chart" date="1179915434" path="flowchart_v2.pdf" size="29678" user="KarenONeil" version="1.1"}%

Criteria IV (Choosing from a list of eligible sessions)

Criteria IV (Ranking the eligible sessions)

Rank the remaining sessions using a weighting scheme defined by the rank, R, whereby a higher number implies a better score. Experience at JMCT indicates that an additive scheme works best. So,

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

Here are the different weights:

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

• (a) 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.
• (b) Observer on site. [e.g., k2=0.3 with b=1 on site; b=0 off site]
• (c) Semester for this project. [e.g., k3=0.25 with c=1 previous semester; c=0 this semester]
• (d) Project’s science grade. [e.g., k4=0.20 with d=1 grade A; d=0 grade B]
• (e) Percent completion. [e.g., k5=0.15 with e=1 for > 75%; e=0.5 for 25-75%; e=0 for < 25%]
• (f) Fixed window project. [e.g., k6=0.10 with f=1 for fixed window; f=0 for normal]
• (g) Thesis project. [e.g., k7=0.05 with g=1 for thesis; g=0 for normal]
• (h) Lower atmospheric observing efficiency. Choose the source at lower declination. [e.g., k_8=0.25 with .]

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

Notice that most of these weights are political decisions.

1. 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.
2. 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)
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. Windowed session. The purpose of this factor is to prevent windowed sessions from always running on the last day of their window.
9. 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.
10. 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.

• For Penn Array, an important component of "is the hardware available" is "will the cryostat be cold for the duration of the run". The Penn Array manager will make available a "remaining hold time" estimate which assumes something about the elevation of the cryostat. For ~6 hours prior to the PAR run we will need to impose a limit on the elevation (>~30 deg) of the telescope, and possibly cycle the PAR helium fridges. Details of this TBD but for now the things to be aware of is that projected elevation tracks and elevation history matter. Currently the Penn array is not a user backend. Hopefully this issue will be resolved before it becomes one.
• VLBA dynamic scheduling: we need to know the final policy for GBT participation in VLBA dynamic scheduling

• VLBA dynamic scheduling: We are working with the VLBA scheduling team to come up with a policy for VLBA+GBT dynamic scheduling.

Selection Rules - Complete, pending testing of the rules

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 allocations meet the selection criteria. Additionally, if an allocation does not have complete information in the database (the observer has not filled out the information needed to make the assessments below) that allocation 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 allocations 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 allocations.)

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.)

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 wether an allocation will become a canidate or not. Ranking rules are applied to each surviving canidate, and result in a prioritized list of canidates.

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 are Ranking Rules.

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 continous: these rules use a numeric scale to assign values to each allocation canidate (or weighting factor) which may then be compared to other canidates. A candidates priority is ulimately determined by the product of all these weighting factors.

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 an allocation eligible to be run? All criteria need to be met in order for the allocation to be chosen.)

• Does the LST range defined in the allocation 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 allocation must necessarily be an allocation 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 allocations that can start in the near future but can not run now, weather changes (to name a few). The process we envision endeavers to provide the operator a list of prioritized allocations and the associated metadata that helps the operator choose the TPs appropriately. For example, fixed and window Allocations that are within 12 (?) hours of the specified time are always included in the candidate Allocation list and will be clearly marked as fixed/window with their required start times. Futhermore we believe that providing the operator with a widget that allows them to overlay upcoming allocations 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.

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.

• • The determination of availability of the hardware is time sensitive. When the DSS is used to determine the next project to be run, hardware availabilty 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 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.

• • We may eventually also want the ability to look at proposals/allocations from future semesters.

• • We may eventually also want the ability to look at proposals/sessions from future semesters.

• • If a project is left with less hours than any of their allocations minimum time, the Allocation verifier should notify the investigator(s)and the appropriate human intervention can happen.
• Has the total allocation time elapsed?
  • If a project is left with less hours than any of their allocations minimum time, the Allocation verifier should notify the investigator(s)and the appropriate human intervention can happen. Additionally, when using the override for this option, if the allocations time has elapsed, the time gets charged to the allocation, but not to the project. This means that any reporting tools for total telescope usage must look at total allocation times, and not total project times.
• Has the total time for this allocation exceeded the maximum allowed for the given semester?
  • If a project is left with less hours than any of their allocations minimum time, the Allocation 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 allocation and the project.

• • 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.

• • • 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 meansin 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 allocation "sessions". For example, an observer must analyze the data from his last session before the allocation is scheduled again. This is an allocation specific 'time between'. It is expected that sequentially ordering between different Allocations within a project will be handled by the "priority" allocation 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 allocations. t=This, too is a standard use of the "time between" parameter.

Criteria II (Fixed time and fixed window allocations)

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

• • • 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)

• 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.)

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

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

• Is the minimum time for the allocation less than or equal to the available session time (e.g. it doesn't run into any fixed time sessions)?

• 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)?

Criteria IV (Choosing from a list of eligible allocations)

Criteria IV (Choosing from a list of eligible sessions)

Rank the remaining allocations using a weighting scheme defined by the rank, R, whereby a higher number implies a better score. Experience at JMCT indicates that an additive scheme works best. So,

Rank the remaining sessions using a weighting scheme defined by the rank, R, whereby a higher number implies a better score. Experience at JMCT indicates that an additive scheme works best. So,

• (a) Stringency factor for allocation (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:

• (a) 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. 1. Stringency for atmosphere based on zenith atmopsheric efficiency greater than 0.5.

1. 1. Stringency for atmosphere based on zenith atmospheric efficiency greater than 0.5.

Criteria V (Can this allocation really be run?)

Criteria V (Can this session really be run?)

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 allocation is chosen either from the priority list (if little time has elapsed) or by restarting the selection process again.

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.

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 select 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 make 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.

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 interupted Telescope Periods

Temporarily interrupted Telescope Periods

• The current observer is allowed to choose whether they wish to finish out their current session, despite the temporarily interrupted TP (this could be a wind stow, or e.g. an equipment failure).

• 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).

• Scheduled receiver changes will not be included in the current forcasting which may become a problem when we attempt to provide probabilities for allocations to be run.

-- KarenONeil - 19 May 2006

• 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.

• • The option here is to allow the operator to look at all proposals from past semester(s).

• • 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.

• Is the project's semester the current one? If not, is it an 'A' ranked proposal?

• Is the project's semester the current one? If not, is it an 'A' ranked proposal with a current or past semester?

• • The current implemenation includes allocations from ALL semesters if it is an "A" ranked proposal and all other tests pass. This inlcudes "A" projects from future semesters as well. We need to determine if this is a good idea.

• • We may eventually also want the ability to look at proposals/allocations from future semesters.

Requirements questions: What does "current schedule" mean?

• • The current implemetation is a single LST input used to select allocations that can run at that LST. Factors inlcuded in this rule include the minimum LST, maximum LST and minDuration of the Allocation. The implementation can be easily changed to accomodate a range of LSTs or a "Telescope Period", however we forsee problems with adopting that process. If the operator/user inputs a telescope period, this would result in arbitrary elimination of Allocations. Some Allocations may require a longer TP then the operators first choice and would be "blindly" eliminated. The "best" choice must necessarily be an allocation 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 allocations that can start in the near future but can not run now, weather changes (to name a few). The process we envision endeavers to provide the operator a list of prioritized allocations and the associated metadata that helps the operator choose the TPs appropriately. For example, fixed and window Allocations that are within 12 (?) hours of the specified time are always included in the candidate Allocation list and will be clearly marked as fixed/window with their required start times. Futhermore we believe that providing the operator with a widget that allows them to overlay upcoming allocations 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.

• • As a starting point, current schedule is going to be defined as the next 12 hours. The "best" choice allocation must necessarily be an allocation 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 allocations that can start in the near future but can not run now, weather changes (to name a few). The process we envision endeavers to provide the operator a list of prioritized allocations and the associated metadata that helps the operator choose the TPs appropriately. For example, fixed and window Allocations that are within 12 (?) hours of the specified time are always included in the candidate Allocation list and will be clearly marked as fixed/window with their required start times. Futhermore we believe that providing the operator with a widget that allows them to overlay upcoming allocations 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 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 availabilty 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.
  • For Penn Array, an important component of "is the hardware available" is "will the cryostat be cold for the duration of the run". The Penn Array manager will make available a "remaining hold time" estimate which assumes something about the elevation of the cryostat. For ~6 hours prior to the PAR run we will need to impose a limit on the elevation (>~30 deg) of the telescope, and possibly cycle the PAR helium fridges. Details of this TBD but for now the things to be aware of is that projected elevation tracks and elevation history matter, and elevation constraints will need to be imposed.

The Current implementation for the near real time scheduler is just a flag indicating whether the hardware is available. For forcasting the plan is to use a cabling file that includes all backends and receivers with no devices inoperative. Scheduled receiver changes will not be included in forcasting which may become a problem.

• 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 availabilty 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 implemenation includes allocations from ALL semesters if it is an "A" ranked proposal and all other tests pass. This inlcudes "A" projects from future semesters as well. Rational:
    • This was the easist implemetation that met the requirement.
    • JCMT blurs thier semester boundaries at the beginning and end of each semester in order to have a large pool of candidate schedule blocks at the end of each semester and to finish projects.
  • The overide option needs clarification: is it an exclusionary override? If the override is true, should the DSS only include projects from the semester or should it include projects from other semesters regardless of their science grade?

• • The option here is to allow the operator to look at all proposals from past semester(s).
  • The current implemenation includes allocations from ALL semesters if it is an "A" ranked proposal and all other tests pass. This inlcudes "A" projects from future semesters as well. We need to determine if this is a good idea.

We have a concern about projects being left with less hours than any of their allocations minimum time. These projects will never be completed. Solution Ideas: Should the DSS need to notify the operator when a project is close to finishing so that the operator can schedule appropriate TPs so this doesn't occur? Should the Allocation Verifyer notify someone when this occurs and the appropriate human intervention can happen? (add a few hours to the project allocated time?)

• • If a project is left with less hours than any of their allocations minimum time, the Allocation verifier should notify the investigator(s)and the appropriate human intervention can happen.

We have a concern about sllocations being left with a less hours than any of their minimum time. Solution Ideas: Should the DSS need to notify the operator when an allocation is close to using its maiximum semester hours and allotted hours so that the operator can schedule appropriate TPs so this doesn't occur? Should the Allocation Verifyer notify someone when this occurs and the appropriate human intervention can happen? (add a few hours to the allocated times?) When using the override, if the allocations time has elapsed, should the project be charged at all since the user technically does not want to run this allocation for these hours?

• • If a project is left with less hours than any of their allocations minimum time, the Allocation verifier should notify the investigator(s)and the appropriate human intervention can happen. Additionally, when using the override for this option, if the allocations time has elapsed, the time gets charged to the allocation, but not to the project. This means that any reporting tools for total telescope usage must look at total allocation times, and not total project times.

See concern above

• 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 observering?

• Time between is not listed in any of the selection rules. There are 3 distinct uses for time between; a "personal" time between for an observer and an astronimical time between.
  • 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 could be handled via the calander, but requires the user updating the calander after many(?) of his observing runs. This seems like it would be a burden on an observer. It seems like we should consider "time between" metadata linked to a observer.
  • Case 2: time between is used by the PI because there must be time in between allocation "sessions". For example, an observer must analyze the data from his last session before the allocation is scheduled again. This is an allocation specific 'time between'. It is expected that sequentially ordering between different Allocations within a project will be handled by the "priority" allocation metadata and not in conjunction with the time between metadata.
  • Case 3, time between scheduled runs for fixed windows allocations.

• • If a project is left with less hours than any of their allocations minimum time, the Allocation 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 allocation 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 meansin 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 allocation "sessions". For example, an observer must analyze the data from his last session before the allocation is scheduled again. This is an allocation specific 'time between'. It is expected that sequentially ordering between different Allocations within a project will be handled by the "priority" allocation 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 allocations. t=This, too is a standard use of the "time between" parameter.

Policy issues to be decided

Concerns

• For Penn Array, an important component of "is the hardware available" is "will the cryostat be cold for the duration of the run". The Penn Array manager will make available a "remaining hold time" estimate which assumes something about the elevation of the cryostat. For ~6 hours prior to the PAR run we will need to impose a limit on the elevation (>~30 deg) of the telescope, and possibly cycle the PAR helium fridges. Details of this TBD but for now the things to be aware of is that projected elevation tracks and elevation history matter. Currently the Penn array is not a user backend. Hopefully this issue will be resolved before it becomes one.
• VLBA dynamic scheduling: we need to know the final policy for GBT participation in VLBA dynamic scheduling

• Scheduled receiver changes will not be included in the current forcasting which may become a problem when we attempt to provide probabilities for allocations to be run.

• • The current implemetation is for a single LST input that is used to select allocations that can run at that LST. Factors inlcuded in the rule include the minimum Lst, maximum LST and minDuration of the Allocation. The implementation can be easily changed to accomodate a range of LSTs or a "Telescope Period", however we forsee problems with adopting that process. If the operator/user inputs a telescope period, this would result in arbitrary elimination of Allocations. Some Allocations may require a longer TP then the operators first choice and would be "blindly" eliminated. The "best" choice must necessarily be an allocation 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 Allocations that can start in the near future but can not run now, weather changes (to name a few). Our process endeavers to provide the operator a list of prioritized Allocations and the associated metadata that helps the operator choose the TPs appropriately. For example, fixed and window Allocations that are within 12 (?) hours of the specified time are always included in the candidate Allocation list and will be clearly marked as fixed/window with their required start times. Futhermore we believe that providing the operator with a widget that allows them to overlay upcoming Allocations that can be run in the near future (specified by the operator or defaulted), but not currently will provide the operator with helpful information to choose the TP appropriately. We could easily provide these allocations without the use of a "overlay widget" but believe that the list of allocations will be quite long and will cause information overload.

• • The current implemetation is a single LST input used to select allocations that can run at that LST. Factors inlcuded in this rule include the minimum LST, maximum LST and minDuration of the Allocation. The implementation can be easily changed to accomodate a range of LSTs or a "Telescope Period", however we forsee problems with adopting that process. If the operator/user inputs a telescope period, this would result in arbitrary elimination of Allocations. Some Allocations may require a longer TP then the operators first choice and would be "blindly" eliminated. The "best" choice must necessarily be an allocation 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 allocations that can start in the near future but can not run now, weather changes (to name a few). The process we envision endeavers to provide the operator a list of prioritized allocations and the associated metadata that helps the operator choose the TPs appropriately. For example, fixed and window Allocations that are within 12 (?) hours of the specified time are always included in the candidate Allocation list and will be clearly marked as fixed/window with their required start times. Futhermore we believe that providing the operator with a widget that allows them to overlay upcoming allocations 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.

Dan, Mark, Amy and Melinda believe the Penn Array section of this requirement should be lifted for the following reasons:

Dana, Mark, Amy and Melinda believe the Penn Array section of this requirement should be lifted for the following reasons:

The Current implementation for the near real time scheduler is just a flag indicating whther the hardware is available. For forcasting the plan is to use a cabling file that includes all backends and receivers with no devices inoperative. Scheduled receiver changes will not be included in forcasting which may become a problem.

The Current implementation for the near real time scheduler is just a flag indicating whether the hardware is available. For forcasting the plan is to use a cabling file that includes all backends and receivers with no devices inoperative. Scheduled receiver changes will not be included in forcasting which may become a problem.

• • The current implemenation includes allocations from ALL semesters if it is an "A" ranked proposal and all other rule tests pass. This inlcudes "A" projects from future semesters as well. Rational: this was the easist implemetation that met the requirement. JCMT blurs thier semester boundaries at the beginning and end of each semester in order to have a large pool of candidate schedule blocks and to finish projects.
  • The overide of this rule needs clarification. Is it an exclusionary override? If the override is true, should the DSS only include projects from the semester or should it include projects from other semesters regardless of their science grade?

• • The current implemenation includes allocations from ALL semesters if it is an "A" ranked proposal and all other tests pass. This inlcudes "A" projects from future semesters as well. Rational:
    • This was the easist implemetation that met the requirement.
    • JCMT blurs thier semester boundaries at the beginning and end of each semester in order to have a large pool of candidate schedule blocks at the end of each semester and to finish projects.
  • The overide option needs clarification: is it an exclusionary override? If the override is true, should the DSS only include projects from the semester or should it include projects from other semesters regardless of their science grade?

We have a concern about projects being left with a less hours than any of their allocations minimum time. Doe the DSS need to notify the operator when a project is close to finishing so that the operator can schedule appropriate TPs so this doesn't occur? Should the Allocation Verifyer notify someone when this occurs and the appropriate human intervention can happen? (add a few hours to the project allocated time?)

We have a concern about projects being left with less hours than any of their allocations minimum time. These projects will never be completed. Solution Ideas: Should the DSS need to notify the operator when a project is close to finishing so that the operator can schedule appropriate TPs so this doesn't occur? Should the Allocation Verifyer notify someone when this occurs and the appropriate human intervention can happen? (add a few hours to the project allocated time?)

%RED We have a concern about sllocations being left with a less hours than any of their minimum time. Doe the DSS need to notify the operator when an allocation is close to using its maiximum semester hours and allotted hours so that the operator can schedule appropriate TPs so this doesn't occur? Should the Allocation Verifyer notify someone when this occurs and the appropriate human intervention can happen? (add a few hours to the allocated times?)

We have a concern about sllocations being left with a less hours than any of their minimum time. Solution Ideas: Should the DSS need to notify the operator when an allocation is close to using its maiximum semester hours and allotted hours so that the operator can schedule appropriate TPs so this doesn't occur? Should the Allocation Verifyer notify someone when this occurs and the appropriate human intervention can happen? (add a few hours to the allocated times?)

%RED See concern above

See concern above

This should read if none of the observers are on site, are there any remote observers approved for GBT remote observering and are available. We note that only those users who arequalified for remote observing should be on the contact list provided to the operator

• Time between is not listed in any of the selection rules. There are 2 distinct uses for time between; a "personal" time between for an observer and an astronimical time between. In case 1 time between is the time between an observer being contacted again to observe ANY project. This could be handled via the calander, but requires the user updating the calander after many? of his observing runs. This seems like it would be a burden on an observer. The second use case for time between is when an PI wants some time between his observing runs to analyze his last set of data. This is a Allocation/Project wide time between.

This should read: "If none of the observers are on site, are there any remote observers approved for GBT remote observering and are available". We note that only those users who are qualified for remote observing should be on the contact list provided to the operator

• Time between is not listed in any of the selection rules. There are 3 distinct uses for time between; a "personal" time between for an observer and an astronimical time between.
  • 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 could be handled via the calander, but requires the user updating the calander after many(?) of his observing runs. This seems like it would be a burden on an observer. It seems like we should consider "time between" metadata linked to a observer.
  • Case 2: time between is used by the PI because there must be time in between allocation "sessions". For example, an observer must analyze the data from his last session before the allocation is scheduled again. This is an allocation specific 'time between'. It is expected that sequentially ordering between different Allocations within a project will be handled by the "priority" allocation metadata and not in conjunction with the time between metadata.
  • Case 3, time between scheduled runs for fixed windows allocations.

The Elimination Rules below are, by nature, discrete, while the Ranking Rules in Criteria IV are continous: these rules use a numeric scale to assign values to each allocation canidate (or weighting factor) which may then be compared to other canidates. A canidates priority is ulimately determined by the product of all these weighting factors.

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

Requirements questions: What does "current schedule" mean?

• • The current implemetation is for a single LST input that is used to select allocations that can run at that LST. Factors inlcuded in the rule include the minimum Lst, maximum LST and minDuration of the Allocation. The implementation can be easily changed to accomodate a range of LSTs or a "Telescope Period", however we forsee problems with adopting that process. If the operator/user inputs a telescope period, this would result in arbitrary elimination of Allocations. Some Allocations may require a longer TP then the operators first choice and would be "blindly" eliminated. The "best" choice must necessarily be an allocation 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 Allocations that can start in the near future but can not run now, weather changes (to name a few). Our process endeavers to provide the operator a list of prioritized Allocations and the associated metadata that helps the operator choose the TPs appropriately. For example, fixed and window Allocations that are within 12 (?) hours of the specified time are always included in the candidate Allocation list and will be clearly marked as fixed/window with their required start times. Futhermore we believe that providing the operator with a widget that allows them to overlay upcoming Allocations that can be run in the near future (specified by the operator or defaulted), but not currently will provide the operator with helpful information to choose the TP appropriately. We could easily provide these allocations without the use of a "overlay widget" but believe that the list of allocations will be quite long and will cause information overload.

Dan, Mark, Amy and Melinda believe the Penn Array section of this requirement should be lifted for the following reasons:

• • Imposing an elevation limit for 6 hours before a penn array observation implies that Penn Array obaservations are always scheduled as a fixed time. If not fixed then the DSS does not know ahead of time when it will be scheduled to run.
  • "Imposing" limits is inconsistent with the basic concept that the observer remains in control of thier telescope period.
  • The galactic center is at 24 degrees and we suspect the elevation limit will have huge effects on number of allocations that will be run
  • We currently have no mechanism for monitoring the elevation track history.
  • Since the penn array is another "future" backend and will not be a "user" backend in the near future, this requirement is premature.

The Current implementation for the near real time scheduler is just a flag indicating whther the hardware is available. For forcasting the plan is to use a cabling file that includes all backends and receivers with no devices inoperative. Scheduled receiver changes will not be included in forcasting which may become a problem.

• • The current implemenation includes allocations from ALL semesters if it is an "A" ranked proposal and all other rule tests pass. This inlcudes "A" projects from future semesters as well. Rational: this was the easist implemetation that met the requirement. JCMT blurs thier semester boundaries at the beginning and end of each semester in order to have a large pool of candidate schedule blocks and to finish projects.
  • The overide of this rule needs clarification. Is it an exclusionary override? If the override is true, should the DSS only include projects from the semester or should it include projects from other semesters regardless of their science grade?

We have a concern about projects being left with a less hours than any of their allocations minimum time. Doe the DSS need to notify the operator when a project is close to finishing so that the operator can schedule appropriate TPs so this doesn't occur? Should the Allocation Verifyer notify someone when this occurs and the appropriate human intervention can happen? (add a few hours to the project allocated time?)

%RED We have a concern about sllocations being left with a less hours than any of their minimum time. Doe the DSS need to notify the operator when an allocation is close to using its maiximum semester hours and allotted hours so that the operator can schedule appropriate TPs so this doesn't occur? Should the Allocation Verifyer notify someone when this occurs and the appropriate human intervention can happen? (add a few hours to the allocated times?) When using the override, if the allocations time has elapsed, should the project be charged at all since the user technically does not want to run this allocation for these hours?

%RED See concern above

This should read if none of the observers are on site, are there any remote observers approved for GBT remote observering and are available. We note that only those users who arequalified for remote observing should be on the contact list provided to the operator

• Time between is not listed in any of the selection rules. There are 2 distinct uses for time between; a "personal" time between for an observer and an astronimical time between. In case 1 time between is the time between an observer being contacted again to observe ANY project. This could be handled via the calander, but requires the user updating the calander after many? of his observing runs. This seems like it would be a burden on an observer. The second use case for time between is when an PI wants some time between his observing runs to analyze his last set of data. This is a Allocation/Project wide time between.

1. 1. Assuming a canonical frequency and declination calculate the transit atmospheric observing efficiency () using Equation (1) of DSPN2. Is ? (We need to produce a lookup table with the "best" zenith opacity and atmospheric system temperatures as a function of frequency.)
   2. Assuming a canonical frequency calculate the maximum usable windspeed () using Equation (24a) of DSPN2. Is the current windspeed less than ?

1. 1. Assuming a canonical frequency and declination calculate the transit atmospheric observing efficiency () using Equation (1) of DSPN2 (i.e., set the hour angle, H, equal to zero). Is ? (The default value is ; although we need to let the observer modify this default if justified.)
   2. Assuming a canonical frequency calculate the maximum usable windspeed () using Equation (24a) of DSPN2. Is the current windspeed less than ? (The default value of is determined by Equation (24a) but we need to let the observer modify this default if justified.)

Rank the remaining allocations using a weighting scheme defined by the rank, R, whereby a higher number implies a better score.

Rank the remaining allocations using a weighting scheme defined by the rank, R, whereby a higher number implies a better score. Experience at JMCT indicates that an additive scheme works best. So,

R = a*b*c*d*e*f*g*h

• (a) Stringency factor for allocation (see Scientific Requirements Memo). We need to produce a lookup table with the stringency determined as a function of frequency based on 1 year of weather data. It will be a number greater than or equal to 1. The stringency is determined from three factors:

• (a) Stringency factor for allocation (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:

• (b) Observer on site. [e.g., 1.2 on site; 1.0 off site]
• (c) Semester for this project. [e.g., 1.05 previous semester; 1.0 this semester]
• (d) Project’s science grade. [e.g., 1.1 grade A; 1.0 grade B]
• (e) Percent completion. [e.g., 1.1 for > 75%; 1.05 for 25-75%; 1.0 for < 25%]
• (f) Fixed window project. [e.g., 1.05 for fixed window; 1.0 for normal]
• (g) Thesis project. [e.g., 1.02 for thesis; 1.0 for normal]
• (h) Transit atmopsheric observing efficiency. [e.g., ]

• (b) Observer on site. [e.g., k2=0.3 with b=1 on site; b=0 off site]
• (c) Semester for this project. [e.g., k3=0.25 with c=1 previous semester; c=0 this semester]
• (d) Project’s science grade. [e.g., k4=0.20 with d=1 grade A; d=0 grade B]
• (e) Percent completion. [e.g., k5=0.15 with e=1 for > 75%; e=0.5 for 25-75%; e=0 for < 25%]
• (f) Fixed window project. [e.g., k6=0.10 with f=1 for fixed window; f=0 for normal]
• (g) Thesis project. [e.g., k7=0.05 with g=1 for thesis; g=0 for normal]
• (h) Lower atmospheric observing efficiency. Choose the source at lower declination. [e.g., k_8=0.25 with .]

Would an additive rule be better? For example, R = k1*a + k2*b + ...

• Is the time of day correct for the entire session (work hours, nighttime, any time, solar avoidance)

• Is the time of day correct (work hours, nighttime, any time, solar avoidance)?

1. 1. For canonical frequencies greater than 40 GHz is the local time between 3 hours after sunset and 2 hours after sunrise?

R = a*b*c*d*e*f*g

R = a*b*c*d*e*f*g*h

• (b) Observer on site. [1.2 on site; 1.0 off site]
• (c) Semester for this project. [1.05 previous semester; 1.0 this semester]
• (d) Project’s science grade. [1.1 grade A; 1.0 grade B]
• (e) Percent completion. [1.1 for > 75%; 1.05 for 25-75%; 1.0 for < 25%]
• (f) Fixed window project. [1.05 for fixed window; 1.0 for normal]
• (g) Thesis project. [1.02 for thesis; 1.0 for normal]

• (b) Observer on site. [e.g., 1.2 on site; 1.0 off site]
• (c) Semester for this project. [e.g., 1.05 previous semester; 1.0 this semester]
• (d) Project’s science grade. [e.g., 1.1 grade A; 1.0 grade B]
• (e) Percent completion. [e.g., 1.1 for > 75%; 1.05 for 25-75%; 1.0 for < 25%]
• (f) Fixed window project. [e.g., 1.05 for fixed window; 1.0 for normal]
• (g) Thesis project. [e.g., 1.02 for thesis; 1.0 for normal]
• (h) Transit atmopsheric observing efficiency. [e.g., ]

Would an additive rule be better? For example, R = k1*a + k2*b + ...

%META:FILEATTACHMENT{name="flowchart.pdf" attr="" comment="Flow Chart" date="1174335434" path="flowchart.pdf" size="25225" user="DanaBalser" version="1.1"}%

• Is the time of day correct for the entire session (specified LST range, work hours, nighttime, any time, solar avoidance)

• Is the time of day correct for the entire session (work hours, nighttime, any time, solar avoidance)

1. 1. Assuming a canonical frequency and declination calculate the atmospheric observing efficiency () using Equation (1) of DSPN2. Is ? (We need to produce a lookup table with the "best" zenith opacity and atmospheric system temperatures as a function of frequency.)

1. 1. Assuming a canonical frequency and declination calculate the transit atmospheric observing efficiency () using Equation (1) of DSPN2. Is ? (We need to produce a lookup table with the "best" zenith opacity and atmospheric system temperatures as a function of frequency.)

• Is the Hour Angle limit (as described in the Scientific Requirements Memo) for at least one of the Allocation's sources or local time correct?

• Does the LST range defined in the allocation fit into the current schedule (see Scientific Requirements Memo)?

1. 1. Assuming a canonical frequency and declination calculate the atmospheric observing efficiency () using Equation (1) of DSPN2. Is the
   2. Assuming a canonical frequency calcualte the maximum windspeed for usable tracking ( using Equation (24a) of DSPN2). Is the current windspeed less than ?

1. 1. Assuming a canonical frequency and declination calculate the atmospheric observing efficiency () using Equation (1) of DSPN2. Is ? (We need to produce a lookup table with the "best" zenith opacity and atmospheric system temperatures as a function of frequency.)
   2. Assuming a canonical frequency calculate the maximum usable windspeed () using Equation (24a) of DSPN2. Is the current windspeed less than ?
   3. For canonical frequencies greater than 40 GHz is the local time between 3 hours after sunset and 2 hours after sunrise?

TBD - The weighting factor for each rule below must be determined by a higher power.

Rank the remaining allocations using a weighting scheme defined by the rank, R, whereby a higher number implies a better score.

• Stringency factor (see Scientific Requirements Memo) for allocation.
• Observer on site.
• Semester for this project.
• Project’s science grade.
• Percent completion? (higher completion projects have a higher priority)
• Fixed window project.
• Thesis project.

R = a*b*c*d*e*f*g

Here are the different weights:

• (a) Stringency factor for allocation (see Scientific Requirements Memo). We need to produce a lookup table with the stringency determined as a function of frequency based on 1 year of weather data. It will be a number greater than or equal to 1. The stringency is determined from three factors:
  1. Stringency for winds based on usable performance.
  2. Stringency for atmosphere based on zenith atmopsheric efficiency greater than 0.5.
  3. Stringency for thermal gradients affecting the surface during the day for frequencies over 40 GHz.
• (b) Observer on site. [1.2 on site; 1.0 off site]
• (c) Semester for this project. [1.05 previous semester; 1.0 this semester]
• (d) Project’s science grade. [1.1 grade A; 1.0 grade B]
• (e) Percent completion. [1.1 for > 75%; 1.05 for 25-75%; 1.0 for < 25%]
• (f) Fixed window project. [1.05 for fixed window; 1.0 for normal]
• (g) Thesis project. [1.02 for thesis; 1.0 for normal]

Notice that most of these weights are political decisions.

• Is the time of day correct for the entire session (work hours, nighttime, any time, solar avoidance)
• Is the weather at least as good as the desired weather, using the methods described in the Scientific Requirements Memo.

• Is the time of day correct for the entire session (specified LST range, work hours, nighttime, any time, solar avoidance)

• 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 atmospheric observing efficiency () using Equation (1) of DSPN2. Is the
  2. Assuming a canonical frequency calcualte the maximum windspeed for usable tracking ( using Equation (24a) of DSPN2). Is the current windspeed less than ?

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 wether an allocation will become a canidate or not. Ranking rules are applied to each surviving canidate, and result in a prioritized list of canidates.

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

The Elimination Rules below are, by nature, discrete, while the Ranking Rules in Criteria IV are continous: these rules use a numeric scale to assign values to each allocation canidate (or weighting factor) which may then be compared to other canidates. A canidates priority is ulimately determined by the product of all these weighting factors.

• Is the LST range (derived from the RA range and elevation requirements) or local time correct?

• Is the Hour Angle limit (as described in the Scientific Requirements Memo) for at least one of the Allocation's sources or local time correct?

• Is the weather at least as good as the desired weather queue?

• Is the weather at least as good as the desired weather, using the methods described in the Scientific Requirements Memo.

The list below is listed in terms of priority, and should be the priority ranking given by the DSS scheduler program. All allocations 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 allocations 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 allocations which meet criteria I-III (in the same manner that JCMT allow this).

• Does the weather match the desired weather classification? (Are we in the same weather bin?) Assume the weather falls into the 25%-50% ‘Tsys’ and ‘Good’ wind category (marked by ) then the qualifying allocations are marked by .

*Weather Classifications (See WeatherQueue) *
Wind/’Tsys’	0%-25%	25%-50%	50%-75%	75%-100%
Excellent
Good
Poor

• Does the weather almost match the desired weather classification? (Is the weather within one step of the current weather classification?) Still assume the weather falls into the 25%-50% ‘Tsys’ and ‘Good’ wind category (marked by ) then the qualifying allocations are marked by .

*Weather Classifications (See WeatherQueue) *
Wind/’Tsys’	0%-25%	25%-50%	50%-75%	75%-100%
Excellent
Good
Poor

• Is the observer on site?
• What is the semester for this project?
• What is the project’s science grade?
• What is the percent completion?
  • This is broken into bins of 0%-25%, 25%-75%, 75%-100%
  • The higher completion projects have a higher priority.
• Is this a fixed window project?
• Is this a thesis project?

All allocations 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 allocations 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 allocations which meet criteria I-III (in the same manner that JCMT allow this).

TBD - The weighting factor for each rule below must be determined by a higher power.

• Stringency factor (see Scientific Requirements Memo) for allocation.
• Observer on site.
• Semester for this project.
• Project’s science grade.
• Percent completion? (higher completion projects have a higher priority)
• Fixed window project.
• Thesis project.

Selection Rules

Selection Rules - Complete, pending testing of the rules

• Is the project's semester the current one? If not, is it an 'A' ranked proposal?

• If none of the observers are on site, are any of the potential remote observers approved for GBT remote observering?

• Is the hardware for the project 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 availabilty 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.

• Is the equipment really available?

• If it is a high frequency project and it gets too windy, the observer may decide to keep observing (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. If/when the winds die down again, they can restart. 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. 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. When it looks like the wind is going to be sustained low enough to resume observing, the observer may continue with the same session. Or, 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.

• 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.

• Is the observer on site? RMP shouldn't this be: is the observer available (onsite or remotely)?

• Is the observer available?

• Does the weather match the desired weather classification? (Are we in the same weather bin?) if not, then is the weather within one step of the current weather classification?

• Does the weather match the desired weather classification? (Are we in the same weather bin?) Assume the weather falls into the 25%-50% ‘Tsys’ and ‘Good’ wind category (marked by ) then the qualifying allocations are marked by .

• • Now, assume the weather falls into the 25%-50% ‘Tsys’ and ‘Good’ wind category (marked by ). If there are no eligible allocations which match that exact weather classification, the DSS would look in the squares marked by the .

• Does the weather almost match the desired weather classification? (Is the weather within one step of the current weather classification?) Still assume the weather falls into the 25%-50% ‘Tsys’ and ‘Good’ wind category (marked by ) then the qualifying allocations are marked by .

• Is the observer on site?

• Is the observer on site? RMP shouldn't this be: is the observer available (onsite or remotely)?

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 allocations meet the selection criteria. Additionally, if an allocation does not have complete information in the database (the observer has not filled out the information needed to make the assesments below) that allocation 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 allocations 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 allocations.)

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 allocations meet the selection criteria. Additionally, if an allocation does not have complete information in the database (the observer has not filled out the information needed to make the assessments below) that allocation 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 allocations 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 allocations.)

• Is the observer on site?

• Has the total proposal time elapsed?

• Has the total project time elapsed?

• 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.