• • The operator chooses to view the predicted scheduler/probability results of the probability generator for this telescope period. The top 5 ranked sessions vie ranking values that are very close, so the operator chooses the session that closely matches the predicted schedule.

• • The operator chooses to view the predicted scheduler/probability results of the probability generator for this telescope period. The top 5 ranked sessions have ranking values that are very close, so the operator chooses the session that closely matches the predicted schedule.

Proposal aubmission closes - June 1, 2008

Proposal submission closes - June 1, 2008

• • The project page is displayed. Project data will not be modifiable by the user and only some session fields will be displayed as modifiable. (If fields need o be changed that are unmodifiable by the investigator, he/she wll contact the telescope scheduler to request the change.) Note - In this case it is assumed the PST will populate the majority of the fields needed for the DSS (proposal 1 in the DSSSoftwareSuite). If this is not the case, it is likely there will be few fields which are not modifiable by the investigator.

• • The project page is displayed. Project data will not be modifiable by the user and only some session fields will be displayed as modifiable. (If fields need o be changed that are unmodifiable by the investigator, he/she will contact the telescope scheduler to request the change.) Note - In this case it is assumed the PST will populate the majority of the fields needed for the DSS (proposal 1 in the DSSSoftwareSuite). If this is not the case, it is likely there will be few fields which are not modifiable by the investigator.

• • The DSS M&C Configuration Monitor is run on the session to determine if changes have effected the schedulability of the session. The sessions hardware availability is updated if appropriate.

• • The DSS M&C Configuration Monitor is run on the session to determine if changes have affected whether the session is eligible for scheduling. The sessions hardware availability is updated if appropriate.

Regulur notification of invalid project/session data - September 17, 2008

Regular notification of invalid project/session data - September 17, 2008

We need something here indicating the observer has recevied email(s) notifying that the project will be run soon

The session becomes a high probability candidate to and is expected to be scheduled within the next week - October 13, 2008

• The DSS probability generator lists Joan's session as a likely candidate to be run in the next week and sends the message to the emailer.
  • The DSS emailer notifies the PI and interested parties that this session is likely to be run within the next week,

The session becomes a high probability candidate and is expected to be scheduled within the next 48 hours - October 19, 2008

• The DSS probability generator lists Joan's session as a likely candidate to be run in the next 48 hours and sends the message to the emailer.
  • The DSS emailer notifies the PI and interested parties that this session is likely to be run within the next next 48 hours.

The session becomes a high probability candidate and is expected to be scheduled within the next 24 hours - October 20, 2008

• The DSS probability generator lists Joan's session as a likely candidate to be run in the next 24 hours and sends the message to the emailer.
  • The DSS emailer notifies the PI and interested parties that this session is likely to be run within the next next 24 hours.

• • The DSS M&C Configuration Monitor (asynchronous daemon continuously running) determines every sessions' schedulability and updates the DSS database with the results for each session.

• • The DSS M&C Configuration Monitor (asynchronous daemon continuously running) determines every if each session is eligible for scheduling and updates the DSS database with the results for each session.

• • The DSS M&C Configuration Monitor verifies all sessions schedulability and updates DSS database with the results for each sessions.

• • The DSS M&C Configuration Monitor verifies every sessions eligibility to be scheduled and updates DSS database with the results for each sessions.

PI Submits Proposal - May 1st 2008

PI Submits Proposal - May 21st 2008

PSC Evaluation - June 1, 2008

Proposal aubmission closes - June 1, 2008

PSC Evaluation - July 15, 2008

• Proposal is accepted.

• Proposal is graded and accepted.

Add Proposals to DSS - July 20, 2008 (Prior to the beginning of the semester after a semesters proposal deadline has passed)

Add Proposals to DSS - July 17, 2008

• The GBT Scheduler modifies project metadata using the DSS project interface. The required project metadata fields are science grade, total project allocated hours, project allocated hours for each science grade (if more than one science grade applies) and maximum semester hours. The Telescope Scheduler will modify those fields that have changed due to the refereeing process. For example, the proposal requested 100 total telescope time, abut the PSC only allocated 80 hours to the project.

• The GBT Scheduler modifies project metadata using the DSS project interface. The project metadata fields which may be filled in are science grade, total project allocated hours, project allocated hours for each science grade (if more than one science grade applies) and maximum semester hours. The Telescope Scheduler will modify those fields that have changed due to the refereeing process. For example, the proposal requested 100 total telescope time, abut the PSC only allocated 80 hours to the project. In all cases the science grade will need to be entered.

• • The project page is displayed. Project data will not be modifiable by the user and only some session fields will be displayed as modifiable.

• • The project page is displayed. Project data will not be modifiable by the user and only some session fields will be displayed as modifiable. (If fields need o be changed that are unmodifiable by the investigator, he/she wll contact the telescope scheduler to request the change.) Note - In this case it is assumed the PST will populate the majority of the fields needed for the DSS (proposal 1 in the DSSSoftwareSuite). If this is not the case, it is likely there will be few fields which are not modifiable by the investigator.

Regulur notification of invalid project/session data - September 17, 2008

We need something here indicating the observer has recevied email(s) notifying that the project will be run soon

Simple Use Case

Timeline Detailing a Simple Use Case

The following is a simple use case intended to demonstrate how various components of the Dynamic Scheduling Software Suite interacts.

The following is a simple use case intended to demonstrate how various components of the Dynamic Scheduling Software Suite interact.

May 1st 2008

• PI submits proposal into the PST.

June 1, 2008

PI Submits Proposal - May 1st 2008

• Proposal submission process closes. PSC evaluates proposals. Proposal is accepted.

• PI submits proposal into the PST.

PSC Evaluation - June 1, 2008

• Proposal submission process closes.
• PSC evaluates proposals.
• Proposal is accepted.

July 20, 2008 (Prior to the beginning of the semester after a semesters proposal deadline has passed)

Add Proposals to DSS - July 20, 2008 (Prior to the beginning of the semester after a semesters proposal deadline has passed)

• The Telescope Scheduler runs the Proposal Handling tool to update the Dynamic Scheduling database with data from the PST Proposal database.

• The Telescope Scheduler runs the Proposal Handling Tool to update the Dynamic Scheduling database with data from the PST Proposal database.

Notify PI of Project Acceptance - July 22, 2008

• The GBT Scheduler modifies project metadata using the DSS project interface. The required project metadata fields are science grade, total project allocated hours, project allocated hours for each science grade (if more than one science grade applies) and maximum semester hours. The Telescope Scheduler will modify those fields that have changed due to the refereeing process. For example, the proposal requested 100 total telescope time, abut the PSC only allocated 80 hours to the project.
  • An e-mail to the PI is generated by the DSS indicating that the project has been accepted. Included in the e-mail is a link to the project selection page and the project name and password.

July 22, 2008

• The GBT Scheduler modifies project data using the DSS project interface. The required project data fields are science grade, total project allocated hours, project allocated hours for each science grade (if more than one science grade applies) and maximum semester hours. The telescope Scheduler will modfy those fields that have changed due to the refereeing process. For example, the proposal requested 100 total telescope time, abut the PSC pnly allocated 80 hours to the project.
  • A message to the PI is generated by the DSS indicating that the project has been accepted. Included in the email is a link to the project selection page and the project name and password.

PI Updates Project Metadata & Contact Information - September 12, 2008

September 12, 2008

• PI logs into the project page by inputing the project name and password.
  • The DSS verifies the user and if user is validated, redirects the user to the project page.

• PI logs into the project page by providing the project name and password.
  • The DSS authenticates the user and if user is authenticated, redirects the user to the project page.

• • DSS emailer receives message from the Project page interface that the session data has changed.

• The PI updates his dynamic contact data through the DSS calender interface available from the project page.

• • DSS e-mailer receives message from the project page interface that the session data has changed.
• The PI updates his dynamic contact information through the DSS calender interface available from the project page.

September 14, 2008

The Co-I Updates Contact Information - September 14, 2008

• • The DSS saves the calender, contact and message subscriber information to the DSS database. All changes are recorded.

• • The DSS saves the calender, contact, and message subscription information to the DSS database. All changes are recorded.

Qualifying a Remote Observer - September 28, 2008

• GBT Support Staff using the contact management interface modifies the remote observing qualifications of Joan to "qualified."
  • The DSS updates the projects associated with Joan to indicate that there is a qualified remote observer associated with this project. All changes are recorded.

September 28, 2008

Observation Day - October 21, 2008

• GBT Support Staff using the contact management interface modifies the remote observing qualifications of Joan to "qualified"
  • The DSS updates the projects associated with Joan to indicate that there is a remote qualified observer associated with this project. All changes are recorded.

October 21, 2008

• 3:45 The cabling file is modified by a GBT receiver engineer
  • The DSS M&C monitoring system (asynchronous Daemons continuously running) determines every sessions schedulability and updates the DSS database with the results for each session.

• 3:45 - The cabling file is modified by a GBT receiver engineer.
  • The DSS M&C Configuration Monitor (asynchronous daemon continuously running) determines every sessions' schedulability and updates the DSS database with the results for each session.

• 3:55 The M&C device health file is modified.
  • The DSS M&C monitoring system verifies all sessions runability and updates DSS database with the results for each sessions.
  • Messages are generated when GBT hardware failures and fixes have affected the runnable status of a session.

• 3:55 - The M&C device health file is modified.
  • The DSS M&C Configuration Monitor verifies all sessions schedulability and updates DSS database with the results for each sessions.
  • Messages are generated when GBT hardware failures and fixes have affected the scheduling status of a session.

• 6:00 (daily) The DSS probability generator cron job is run. The predicted weather forecast is used to create probabilities/schedule (TBD) for the next 24, 48 hours and 1 week periods.

• 6:00 (daily) - The Session Probability Forecast is run. The predicted weather is used to create probabilities/schedule (TBD) for the next 24, 48 hours and 1 week periods.

• • The emailer receives any significant changes between this prediction and previous predictions for the same time period.
    • Significant changes will be sent to the project investigators and other interested parties.

• • The e-mailer receives any significant changes between this prediction and previous predictions for the same time period.
    • Significant changes will be sent to the project investigators and other subscribed parties.

• 6:10 (daily) Session Verifier automatically runs and constructs a message for each session that is incomplete. A session is considered incomplete and not able to be scheduled when:

1. There is not enough information for the DSS schedule algorithms to schedule the session. For each incomplete seession a message is sent to emailer and will be included in emails to the PI and all interested parties of the project.

• 6:10 (daily) - The Session Verifier automatically runs and constructs a message for each session that is incomplete. A session is considered incomplete and not able to be scheduled when:
  1. There is not enough information for the DSS schedule algorithms to schedule the session. For each incomplete session, a message is sent to e-mailer and will be included in emails to the PI and all subscribed parties of the project.

• 6:15 (daily or continuously TBD) For each project that has unsent messages associated with it, the emailer constructs one email containing all messages generated by the DSS components and emails the information to the PI. In addition, an email is sent to each subscriber containing the messages that the observer has subscribed to. It is expected that a periodicity associated with each message type will be required. One option to alleviate spamming the user with many emails is to allow the user to specify message periodicity during the subscription process. The user may also choose to receive a digest or each message individually.

• 6:15 (daily or continuously TBD) - For each project that has unsent messages associated with it, the e-mailer constructs one e-mail containing all messages generated by the DSS components and sends the information to the PI. In addition, an e-mail is sent to each subscriber containing the messages to which the observer has subscribed. It is expected that a periodicity associated with each message type will be required. One option to alleviate spamming the user with many e-mails is to allow the user to specify message periodicity during the subscription process. The user could also be given the option to choose to receive a digest or each message individually.

• 10:00 GBT Operator runs the scheduling program with the time of interest as 10:30. Other inputs into the scheduling program are defaulted:

• 10:00 - The GBT Operator runs the scheduling program with the time of interest as 10:30. Other inputs into the scheduling program are defaulted:

1. default for all options results in science grade A and B, current semester (includes A projects from previous semesters), projects and allocations with remaining time, semester allocated time remaining, and time of day are used in selection process.

1. 1. default for all options, results in science grade A and B, current semester (includes A projects from previous semesters), projects and sessions with remaining time, semester allocated time remaining, and time of day are used in selection process.

• • • All sessions that can run at the chosen time are displayed and ranked. Critical information such as LST constraints, min and max run times for each session are graphically presented to the operator. Critical factors in determining telescope periods such as day/night transition times are displayed. Other auxiliary session data augments the graphical display.

• • • • All sessions that can run at the chosen time are displayed and ranked. Critical information such as LST constraints, minimum and maximum run times for each session are graphically presented to the operator. Critical factors in determining telescope periods such as day/night transition times are displayed. Other auxiliary session data augments the graphical display.

• The operator chooses to view the predicted scheduler/probability results of the probability generator for this telescope period. The top 5 ranked sessions vae ranking values that are very close, so the operator chooses the session that closely matches the predicted schedule.

• • The operator chooses to view the predicted scheduler/probability results of the probability generator for this telescope period. The top 5 ranked sessions vie ranking values that are very close, so the operator chooses the session that closely matches the predicted schedule.

• • The DSS displays a list of observers associated with the project and their contact numbers for Oct 21, 2008. Contact numbers are listed in the priority order designated by the PI and do not include observers who are not on site and who are not remote qualified.

• • • The DSS displays a list of observers associated with the project and their contact numbers for October 21, 2008. Contact numbers are listed in the priority order designated by the PI and do not include observers who are not on site and who are not qualified for remote observing.

• 10:25 the operator asks the current observer if his observation was successful. The observer answers yes. * The operator updates the telescope period (if required) into the DSS time accounting tool and presses the save button.

• 10:25 - The operator asks the current observer if his observation was successful. The observer answers yes.
  • The operator updates the telescope period (if required) into the DSS time accounting tool and saves the information.

• 10:30 the remote observer starts observing.

• 10:30 - The remote observer starts observing.

The following is a simple use case intended to demonstrate how various components of the Dynamic Scheduling software suite interact when an observer uses the DSS.

The following is a simple use case intended to demonstrate how various components of the Dynamic Scheduling Software Suite interacts.

May 1st 2008

PI submits proposal into the PST.

June 1, 2008

Proposal submission process closes. PSC evaluates proposals. Proposal is accepted.

May 1st 2008

• PI submits proposal into the PST.

June 1, 2008

• Proposal submission process closes. PSC evaluates proposals. Proposal is accepted.

July 20, 2008 (Prior to the beginning of the semester after a semesters proposal deadline has passed)

July 20, 2008 (Prior to the beginning of the semester after a semesters proposal deadline has passed)

July 22, 2008

The GBT Scheduler modifies project data using the DSS project interface. The required project data fields are science grade, total project allocated hours project allocated hours for each science grade (if more than one science grade applies) and maximum semester hours. The telescope Scheduler will modfy those fields that have changed due to the refereeing process. For example, the proposal requested 100 total telescope time, abut the PSC pnly allocated 80 hours to the project. A message to the PI is generated by the DSS indicating that the project has been accepted. Included in the email is a link to the project selection page and the project name and password.

September 12, 2008

PI logs into the project page by inputing the project name and password.

July 22, 2008

• The GBT Scheduler modifies project data using the DSS project interface. The required project data fields are science grade, total project allocated hours, project allocated hours for each science grade (if more than one science grade applies) and maximum semester hours. The telescope Scheduler will modfy those fields that have changed due to the refereeing process. For example, the proposal requested 100 total telescope time, abut the PSC pnly allocated 80 hours to the project.
  • A message to the PI is generated by the DSS indicating that the project has been accepted. Included in the email is a link to the project selection page and the project name and password.

September 12, 2008

• PI logs into the project page by inputing the project name and password.

PI uses the DSS Project Interface to update the session data.

• PI uses the DSS Project Interface to update the session data.

The PI updates his dynamic contact data through the DSS calender interface available from the project page.

• The PI updates his dynamic contact data through the DSS calender interface available from the project page.

September 14, 2008

The PI gives the project password to his co-PI, Joan. She visits the project page and updates her dynamic contact and availability information through the DSS calender interface. She also subscribes to the the probability, hardware availability, and session modification messages. Do we want the ability to sign up for individual bits of information, or should it just be ""give me the emails or don't give me the emails?

September 14, 2008

• The PI gives the project password to his co-PI, Joan. She visits the project page and updates her dynamic contact and availability information through the DSS calender interface. She also subscribes to the the probability, hardware availability, and session modification messages.

September 28, 2008

GBT Support Staff using the contact management interface modifies the remote observing qualifications of Joan to "qualified"

September 28, 2008

• GBT Support Staff using the contact management interface modifies the remote observing qualifications of Joan to "qualified"

October 21, 2008

3:45 The cabling file is modified by a GBT receiver engineer

October 21, 2008

• 3:45 The cabling file is modified by a GBT receiver engineer

3:55 The M&C device health file is modified.

• 3:55 The M&C device health file is modified.

6:00 (daily) The DSS probability generator cron job is run. The predicted weather forecast is used to create probabilities/schedule for the next 24, 48 hours and 1 week periods. The DSS schedule web page is updated with the new results. The GBT weather page is updated with the forecast. The emailer receives any big changes in the schedule, to be sent out to the project investigators + other interested parties. Also, note that the 6am cron job is probably for some upcoming period, like 10am-10am or some other TBD period.

• 6:00 (daily) The DSS probability generator cron job is run. The predicted weather forecast is used to create probabilities/schedule (TBD) for the next 24, 48 hours and 1 week periods.
  • The DSS schedule web page is updated with the new results.
  • The GBT weather page is updated with the forecast.
  • The emailer receives any significant changes between this prediction and previous predictions for the same time period.
    • Significant changes will be sent to the project investigators and other interested parties.

6:10 (daily) Session Verifier automatically runs and constructs a message for each session that is incomplete. A session is considered incomplete and not able to be scheduled when:

• 6:10 (daily) Session Verifier automatically runs and constructs a message for each session that is incomplete. A session is considered incomplete and not able to be scheduled when:

6:15 (daily or continuously TBD) For each project that has unsent messages associated with it, the emailer constructs one email containing all messages generated by the DSS components and emails the information to the PI. In addition, an email is sent to each subscriber containing the messages that the observer has subscribed to. It is expected that a periodicity associated with each message type will be required. One option to alleviate spamming the user with many emails is to allow the user to specify message periodicity during the subscription process. The user may also choose to receive a digest or each message individually.

• 6:15 (daily or continuously TBD) For each project that has unsent messages associated with it, the emailer constructs one email containing all messages generated by the DSS components and emails the information to the PI. In addition, an email is sent to each subscriber containing the messages that the observer has subscribed to. It is expected that a periodicity associated with each message type will be required. One option to alleviate spamming the user with many emails is to allow the user to specify message periodicity during the subscription process. The user may also choose to receive a digest or each message individually.

10:00 GBT Operator runs the scheduling program with the time of interest as 10:30. Other inputs into the scheduling program are defaulted:

• default weather parameters
• default for all options - science grade A and B, current semester (includes A projects from previous semesters), projects and allocations with remaining time, semester allocated time remaining, time of day is used in selection process
  • The DSS uses weather forecasts to determine the predicted weather at 10:00 OR current weather is used. (TBD what is the default)

• 10:00 GBT Operator runs the scheduling program with the time of interest as 10:30. Other inputs into the scheduling program are defaulted:

1. default weather parameters
2. default for all options results in science grade A and B, current semester (includes A projects from previous semesters), projects and allocations with remaining time, semester allocated time remaining, and time of day are used in selection process.
   • The DSS uses weather forecasts to determine the predicted weather at 10:00 OR current weather, or average current weather is used. (TBD what is the default)

• • • The operator probably also needs to be aware of what the scheduler thought was going to be run at this time, according to the 6:00 am cron job, so that he/she can match that when its sensible

• The operator chooses to view the predicted scheduler/probability results of the probability generator for this telescope period. The top 5 ranked sessions vae ranking values that are very close, so the operator chooses the session that closely matches the predicted schedule.

Operator chooses a session and telescope period. Operator selects the session and selects the view contact information in the scheduling program interface.

• Operator chooses a session and telescope period. Operator selects the session and selects the view contact information in the scheduling program interface.

Operator calls the first observing contact on the list. No one answers the phone.

• Operator calls the first observing contact on the list. No one answers the phone.

• The emailer receives any significant changes to the 24 hours scheduler as a result of the updated weather and current scheduling choice

10:25 the operator asks the current observer if his observation was successful. The observer answers yes. The operator updates the telescope period (if required) into the DSS time accounting tool and presses the save button. The operator also adds any notes to the log at this point which the observer feels are necessary. These are in addition to any notes which the observer him/herself have entered during observing. The DSS updates the project page with the log and observer notes.

• The DSS accounting tool updates the projects total used time, the sessions used time, and the last scheduled date and time. If the session was a window session, the DSS creates the next window start and stop dates. The telescope scheduling history is updated with the project, session and telescope period that has just finished, as well as the weather over that observing period.

• 10:25 the operator asks the current observer if his observation was successful. The observer answers yes. * The operator updates the telescope period (if required) into the DSS time accounting tool and presses the save button. * The DSS accounting tool updates the projects total used time, the sessions used time, and the last scheduled date and time. * If the session was a window session, the DSS creates the next window start and stop dates. * The telescope scheduling history is updated with the project name, session identification, telescope period, and the weather conditions for the telescope period. * The operator adds his notes to the log. These are in addition to any notes which the observer him/herself have entered during observing. * The DSS updates the project page with the log and observer notes.

10:30 the remote observer starts observing.

• 10:30 the remote observer starts observing.

Issues not dealt with in above example but which we need tools for:

• RFI recording tool, which also has to send emails when appropriate to the RFI group and the various projects affected. Also something which flags sessions as not useful due to RFI and which can then be unflagged.
• Lost time needs to be emailed not just to project people, but to other interested parties (e.g. Ron, other relevant/interested staff members)
• Logs need to be readily searchable/filterable
• All Carl's reports generating tools
• Also reports generating tool for Ron - lost time, etc. (we've never talked to him about this, but he does make a weekly report)

Simple Use Case - From the Observer's Point of View

Simple Use Case

The GBT Scheduler modifies project data using the DSS project interface. The required project data fields are science grade, total project allocated hours (if changed from PST submission), project allocated hours for each science grade (if more than one science grade applies) and maximum semester hours (if different from total project hours). A message to the PI is generated by the DSS indicating that the project has been accepted. Included in the email is a link to the project selection page and the project name and password.

The GBT Scheduler modifies project data using the DSS project interface. The required project data fields are science grade, total project allocated hours project allocated hours for each science grade (if more than one science grade applies) and maximum semester hours. The telescope Scheduler will modfy those fields that have changed due to the refereeing process. For example, the proposal requested 100 total telescope time, abut the PSC pnly allocated 80 hours to the project. A message to the PI is generated by the DSS indicating that the project has been accepted. Included in the email is a link to the project selection page and the project name and password.

1. There is not enough information for the DSS schedule algorithms to schedule the session. Message sent to emailer

1. There is not enough information for the DSS schedule algorithms to schedule the session. For each incomplete seession a message is sent to emailer and will be included in emails to the PI and all interested parties of the project.

10:25 the operator asks the current observer if his observation was successful. The observer answers yes. The operator updates the telescope period (if required) into the DSS time accounting tool and presses the save button. The operator also adds any notes to the log at this point which the observer feels are necessary. These are in addition to any notes which the observer him/herself have entered during observing. The DSS loggin tool (or whatever you want to call it) would then update both the log on the ongoing project's page as well as the global system log.

10:25 the operator asks the current observer if his observation was successful. The observer answers yes. The operator updates the telescope period (if required) into the DSS time accounting tool and presses the save button. The operator also adds any notes to the log at this point which the observer feels are necessary. These are in addition to any notes which the observer him/herself have entered during observing. The DSS updates the project page with the log and observer notes.

--+!! Dynamic Scheduling Use Case

Dynamic Scheduling Use Case

AMY REMOVE OVERVIEW WHEN YOU ARE FINISHED

All this matches well with the AstronomyRequirements page (formerly known as the Astronomer's view page)

Overview

PST/Scheduler -> Project name, Thesis, maxiumum hours project can be scheduled for in any given semester, Science Grades and allocated time for each science grade.

PI -> receives email that project has been approved, the project name and password with a link to DSS website. The PI may deseminate the password to COPIs/observers of their project.

• User -> User goes to website and inputs their project name. Password is verified. Project page demo/screenshot Karens email of project page layout .
• User adds? and modifies sessions through the project page. If they are to add sessions through the project page may we remove the"session verification" daemon from the list of software products, since this can be done throught the web app?

Email notification to the Pi and any subscribers to that information:

• Changes to any project or session data
• Incomplete sessions data
• Significant changes to the probabilty of the allocation being scheduled
• Changes to the hardware availabilty required by the session
• Notification of time accounting issues
• RFI issues makes sense
• note that we also need a means to link the project friend to the project email list

Email Notifier - each part of the DSS may generate 1 or more emails to the same person. For example allocations that are incomplete. A change in project or allocation data. A significant change to the probablility or schedule of an allocation. We don't want to overburden the user with emails. Each subsystem of the DSS will be responsilble the content of the message. It is the E-mail notification subsystems responsibility to collate each message within one email. We envision this process to also include individual date and time stamps of each message which will be used to winoow the messages. For example, if a session is missing data and the user was notified yesterday about the problem, we may not want to send this message again today.

Session verification: All data required by the DSS for scheduling purposes should be filled in by the PIs. If any data is missing, the session is not runnable and the user will be notified.

Simple Use Case - From the Observer's Point of View

M&C Configuration monitor: Sessions should only be eligible to be run when the hardware is available. Currently there is never a telescope period when all receivers are available. Hardware may fail that make sessions ineligible to be scheduled. We expect to have more than 200 sessions per semester, (This number does not include sessions from previous semesters from "A" projects, nor the current GBT backlog.) The current GBT hardware configuration is determined by a cabling file and a device health file. Whenever either of these files is modified The M&C Configuration Monitor will evaulate each sessions ability to run and update the database appropriately. This information in the database is used by the scheduling algorithm to select candidate sessions. It is a go/nogo.

The following is a simple use case intended to demonstrate how various components of the Dynamic Scheduling software suite interact when an observer uses the DSS.

Scheduling:

• Current - See flow chart? DSS is responsible for selecting allocations that are elible to be run and ranking them according to the ranking scheme discussed earlier.
• The operator will make the final decision on the session to be scheduled and the telescope period. It is crucial that the ranked results of the current scheduler program be presented to the operator in a graphical form that the operator will use to make intelligent decisions.
• All upcoming fixed and window sessions must be presented to the operator at least 12 hours in advance of their start time.
• All sessions that can run at the chosen LST should be displayed ranked with auxially information such as LST constraints, min and max run times, day/night transistions. Other session data as needed like observer on site, obs efficiency.
• The operator may choose to overlay these sessions with a "future" look. For example, overlay the sessions that can run now, with sessions that can run in 2 hours with different weather inputs. The future look will assist the operator in determining the appropriate telescope period.

Future - TBD:

• possible solutions:
  • a 24 schedule based on the weather forecast.
  • issues: predicted weather changes have a very good chance of actually happening, but probably will not occur exactly when it is predicted to occur.
  • give advanced notice to users of their probablility of being scheduled in the next 24/48/week period.
  • uses predicted weather to determine ranking of sessions for the next 24 hours. The sessions that are expected to be scheduled are notified that their probabilty is very good if the predicted weather occurs.
  • since weather rankings are continuous it is difficult to access the relative rankings of projects. For instance if wind is 1 mph less than predicted, this may cause a different session than predicted to run. We have pushed off from making discrete weather queues but maybe for probabilites we should revisit?

A simple use case

May 1st 2008

May 1st 2008

June 1, 2008 Proposal submission process closes.

June 1, 2008

Proposal submission process closes. PSC evaluates proposals. Proposal is accepted.

PSC evaulates proposals. Proposal is accepted.

July 20, 2008 (Prior to the begining of the semester after a semesters proposal deadline has passed)

July 20, 2008 (Prior to the beginning of the semester after a semesters proposal deadline has passed)

• All relevent data in the PST database is retrieved and used to populate the DSS database.

July 22, 2008

• All relevant data in the PST database is retrieved and used to populate the DSS database.

July 22, 2008

September 12, 2008

September 12, 2008

• The DSS M&C Configuration Monitor is run on the session to determine if changes have effected the runnability of the session. The sessions hardware availability is updated if appropriate.

• The DSS M&C Configuration Monitor is run on the session to determine if changes have effected the schedulability of the session. The sessions hardware availability is updated if appropriate.

The PI updates his dynamic contact data through the DSS calander interface available from the project page.

• DSS saves the calander information. All changes are recorded.

September 14, 2008

The PI gives the project password to his co-PI, Joan. She visits the project page and updates her dynamic contact and availability information through the DSS calander interface. She also subscribes to the the probability, hardware availability, and session modification messages. Do we want the ability to sign up for individual bits of information, or should it just be ""give me the emails or don't give me the emails?

• The DSS saves the calander, contact and message subscriber information to the DSS database. All changes are recorded.

September 28, 2008

The PI updates his dynamic contact data through the DSS calender interface available from the project page.

• DSS saves the calender information. All changes are recorded.

September 14, 2008

The PI gives the project password to his co-PI, Joan. She visits the project page and updates her dynamic contact and availability information through the DSS calender interface. She also subscribes to the the probability, hardware availability, and session modification messages. Do we want the ability to sign up for individual bits of information, or should it just be ""give me the emails or don't give me the emails?
• The DSS saves the calender, contact and message subscriber information to the DSS database. All changes are recorded.

September 28, 2008

Oct 21, 2008

October 21, 2008

• The DSS M&C monitoring system (asynchronous Daemons continuously running) determines every sessions runability and updates the DSS database with the results for each session.

• The DSS M&C monitoring system (asynchronous Daemons continuously running) determines every sessions schedulability and updates the DSS database with the results for each session.

3:55 dev health file modified.

3:55 The M&C device health file is modified.

10:00 GBT Operator runs the scheduling program with the time of interest as 10:30 Other Inputs into the scheduling program are defaulted:

10:00 GBT Operator runs the scheduling program with the time of interest as 10:30. Other inputs into the scheduling program are defaulted:

• default for all options - science grade A and B, current semester (includes A projects from previous semesters), projects and allocations with remaining time, semester allocated time remaininga, time of day is used in selection process

• default for all options - science grade A and B, current semester (includes A projects from previous semesters), projects and allocations with remaining time, semester allocated time remaining, time of day is used in selection process

• • • In addition to sessions that are eligilbe to be run at 10:30, all upcoming fixed and window sessions within 12 hours of 10:30 are presented to the operator. They are clearly identified as upcoming Fixed and Window sessions.
    • All sessions that can run at the chosen time are displayed and ranked. Critical information such as LST constraints, min and max run times for each session are graphically presented to the operator. Critical factors in determining telescope periods such as day/night transistion times are displayed. Other auxiliary session data augments the graphical display.

• • • In addition to sessions that are eligible to be run at 10:30, all upcoming fixed and window sessions within 12 hours of 10:30 are presented to the operator. They are clearly identified as upcoming Fixed and Window sessions.
    • All sessions that can run at the chosen time are displayed and ranked. Critical information such as LST constraints, min and max run times for each session are graphically presented to the operator. Critical factors in determining telescope periods such as day/night transition times are displayed. Other auxiliary session data augments the graphical display.

• • • The oeprator probably also needs to be aware of what the scheduler thought was going to be run at this time, according to the 6:00 am cron job, so that he/she can match that when its sensible

• • • The operator probably also needs to be aware of what the scheduler thought was going to be run at this time, according to the 6:00 am cron job, so that he/she can match that when its sensible

Operator chooses a session and telescope period. Operator selects the session and selects the view contact information in the scheduling program interface.

Operator chooses a session and telescope period. Operator selects the session and selects the view contact information in the scheduling program interface.

10:25 the operator asks the current observer if his observation was successful. The observer answers yes. The operator updates thetelescope period (if required) into the DSS time accounting tool and presses the save button. The operatr also adds any notes to the log at this point which the observer feels are necessary. These are in addition to any notes which the observer him/herself have entered durin observing. The DSS loggin tool (or whatever you want to call it) would then updae both the log on the ongoing project's page as well as the global system log.

10:25 the operator asks the current observer if his observation was successful. The observer answers yes. The operator updates the telescope period (if required) into the DSS time accounting tool and presses the save button. The operator also adds any notes to the log at this point which the observer feels are necessary. These are in addition to any notes which the observer him/herself have entered during observing. The DSS loggin tool (or whatever you want to call it) would then update both the log on the ongoing project's page as well as the global system log.

• RFI recording tool, which also has to send emails when appropriate to the rfi group and the various projects affected. Also something which flags sessions as not useful due to rfi and which can then be unflaggedd

• RFI recording tool, which also has to send emails when appropriate to the RFI group and the various projects affected. Also something which flags sessions as not useful due to RFI and which can then be unflagged.

• Logs need to be readily serachable/filterable

• Logs need to be readily searchable/filterable

-- MelindaMello - 22 May 2007

%COLOR RED%

All this matches well with the AstronomyRequirements page (formerly known as the Astronomer's view page)

PST/Scheduler -> Project name, Thesis, maziumum hours project can be scheduled for in any given semester, Science Grades and allocated time for each science grade.

PST/Scheduler -> Project name, Thesis, maxiumum hours project can be scheduled for in any given semester, Science Grades and allocated time for each science grade.

User -> User goes to website and inputs their project name. Password is verified. Project page demo/screenshot Karens email of project page layout . User adds? and modifies sessions through the project page. If they are to add sessions through the project page may we remove the"session verification" daemon from the list of software products, since this can be done throught the web app?

• User -> User goes to website and inputs their project name. Password is verified. Project page demo/screenshot Karens email of project page layout .
• User adds? and modifies sessions through the project page. If they are to add sessions through the project page may we remove the"session verification" daemon from the list of software products, since this can be done throught the web app?

Changes to any project or session data Incomplete sessions data Significant changes to the probabilty of the allocation being scheduled Changes to the hardware availabilty required by the session Notification of time accounting issues RFI issues?

• Changes to any project or session data
• Incomplete sessions data
• Significant changes to the probabilty of the allocation being scheduled
• Changes to the hardware availabilty required by the session
• Notification of time accounting issues
• RFI issues makes sense
• note that we also need a means to link the project friend to the project email list

We don't want to overburden the user with emails. Each subsystem of the DSS will be responsilble the content of the message. It is the E-mail notification subsystems responsibility to collate each message within one email. We envision this process to also include individual date and time stamps of each message which will be used to winoow the messages. For example, if a session is missing data and the user was notified yesterday about the problem, we may not want to send this message again today.

We don't want to overburden the user with emails. Each subsystem of the DSS will be responsilble the content of the message. It is the E-mail notification subsystems responsibility to collate each message within one email. We envision this process to also include individual date and time stamps of each message which will be used to winoow the messages. For example, if a session is missing data and the user was notified yesterday about the problem, we may not want to send this message again today.

Current - See flow chart? DSS is responsible for selecting allocations that are elible to be run and ranking them according to the ranking scheme discussed earlier. The operator will make the final decision on the session to be scheduled and the telescope period. It is crucial that the ranked results of the current scheduler program be presented to the operator in a graphical form that the operator will use to make intelligent decisions. All upcoming fixed and window sessions must be presented to the operator at least 12 hours in advance of their start time. All sessions that can run at the chosen LST should be displayed ranked with auxially information such as LST constraints, min and max run times, day/night transistions. Other session data as needed like observer on site, obs efficiency. The operator may choose to overlay these sessions with a "future" look. For example, overlay the sessions that can run now, with sessions that can run in 2 hours with different weather inputs. The future look will assist the operator in determining the appropriate telescope period.

• Current - See flow chart? DSS is responsible for selecting allocations that are elible to be run and ranking them according to the ranking scheme discussed earlier.
• The operator will make the final decision on the session to be scheduled and the telescope period. It is crucial that the ranked results of the current scheduler program be presented to the operator in a graphical form that the operator will use to make intelligent decisions.
• All upcoming fixed and window sessions must be presented to the operator at least 12 hours in advance of their start time.
• All sessions that can run at the chosen LST should be displayed ranked with auxially information such as LST constraints, min and max run times, day/night transistions. Other session data as needed like observer on site, obs efficiency.
• The operator may choose to overlay these sessions with a "future" look. For example, overlay the sessions that can run now, with sessions that can run in 2 hours with different weather inputs. The future look will assist the operator in determining the appropriate telescope period.

possible solutions: a 24 schedule based on the weather forecast. issues: predicted weather changes have a very good chance of actually happening, but probably will not occur exactly when it is predicted to occur. give advanced notice to users of their probablility of being scheduled in the next 24/48/week period. uses predicted weather to determine ranking of sessions for the next 24 hours. The sessions that are expected to be scheduled are notified that their probabilty is very good if the predicted weather occurs. since weather rankings are continuous it is difficult to access the relative rankings of projects. For instance if wind is 1 mph less than predicted, this may cause a different session than predicted to run. We have pushed off from making discrete weather queues but maybe for probabilites we should revisit?

• possible solutions:
  • a 24 schedule based on the weather forecast.
  • issues: predicted weather changes have a very good chance of actually happening, but probably will not occur exactly when it is predicted to occur.
  • give advanced notice to users of their probablility of being scheduled in the next 24/48/week period.
  • uses predicted weather to determine ranking of sessions for the next 24 hours. The sessions that are expected to be scheduled are notified that their probabilty is very good if the predicted weather occurs.
  • since weather rankings are continuous it is difficult to access the relative rankings of projects. For instance if wind is 1 mph less than predicted, this may cause a different session than predicted to run. We have pushed off from making discrete weather queues but maybe for probabilites we should revisit?

• The Telescope Scheduler runs the Proposal Handling tool to update the Dynamic Scheduling database with data from the SSS Proposal database.
• All relevent data in the PSS database is retrieved and used to populate the DSS database.

• The Telescope Scheduler runs the Proposal Handling tool to update the Dynamic Scheduling database with data from the PST Proposal database.
• All relevent data in the PST database is retrieved and used to populate the DSS database.

The GBT Scheduler modifies project data using the DSS project interface. The required project data fields are science grade, total project allocated hours, project allocated hours for each science grade (if more than one science greade applies) and maximum semester hours. A message to the PI is generated by the DSS indicating that the project has been accepted. Included in the email is a link to the project selection page and the project name and password.

The GBT Scheduler modifies project data using the DSS project interface. The required project data fields are science grade, total project allocated hours (if changed from PST submission), project allocated hours for each science grade (if more than one science grade applies) and maximum semester hours (if different from total project hours). A message to the PI is generated by the DSS indicating that the project has been accepted. Included in the email is a link to the project selection page and the project name and password.

• The DSS validates, then saves session data. The history of changes are recorded.

• The DSS validates, then saves, session data. The history of changes are recorded.

The PI gives the project password to his co-pi, Joan. She visits the project page and updates her dynamic contact and availability information through the DSS calander interface. She also subscribes to the the probability, hardware availability, and session modification messages. * The DSS saves the calander, contact and message subscribe information to the DSS database. All changes are recorded.

The PI gives the project password to his co-PI, Joan. She visits the project page and updates her dynamic contact and availability information through the DSS calander interface. She also subscribes to the the probability, hardware availability, and session modification messages. Do we want the ability to sign up for individual bits of information, or should it just be ""give me the emails or don't give me the emails?

• The DSS saves the calander, contact and message subscriber information to the DSS database. All changes are recorded.

6:00 (daily) The DSS probability generator cron job is run. The predicted weather forecast is used to create probabilities/schedule for the next 24, 48 hours and 1 week periods. The DSS schedule web page is updated with the new results. The GBT weather page is updated with the forecast.

6:00 (daily) The DSS probability generator cron job is run. The predicted weather forecast is used to create probabilities/schedule for the next 24, 48 hours and 1 week periods. The DSS schedule web page is updated with the new results. The GBT weather page is updated with the forecast. The emailer receives any big changes in the schedule, to be sent out to the project investigators + other interested parties. Also, note that the 6am cron job is probably for some upcoming period, like 10am-10am or some other TBD period.

1. There is not enough information for the DSS schedule algorithms to schedule the session. 2. There is no observer on site and there are no remote qualified observers associated with the project.

6:15 (daily or continuously TBD) For each project that has unsent messages associated with it, the emailer constructs one email containing all messages generated by the DSS components and emails the information to the PI. In addition, an email is sent to each subscriber containing the messages that the observer has subscribed to. It is expected that a periodicity associated with each message type will be required. One option to alleviate spamming the user with many emails is to allow the user to specify message periodicity during the subscription process. The user may also shoose to receive a digest or each message individually.

1. There is not enough information for the DSS schedule algorithms to schedule the session. Message sent to emailer
2. There is no observer on site and there are no remote qualified observers associated with the project.

6:15 (daily or continuously TBD) For each project that has unsent messages associated with it, the emailer constructs one email containing all messages generated by the DSS components and emails the information to the PI. In addition, an email is sent to each subscriber containing the messages that the observer has subscribed to. It is expected that a periodicity associated with each message type will be required. One option to alleviate spamming the user with many emails is to allow the user to specify message periodicity during the subscription process. The user may also choose to receive a digest or each message individually.

• • • The oeprator probably also needs to be aware of what the scheduler thought was going to be run at this time, according to the 6:00 am cron job, so that he/she can match that when its sensible

Operator calls the next observing contact for the project and notifies the observer that the telescope will be available to run session "X" in 25 minutes and that the telescope period will be 4 hours.

• Operator calls the next observing contact for the project and notifies the observer that the telescope will be available to run session "X" in 25 minutes and that the telescope period will be 4 hours.
• The emailer receives any significant changes to the 24 hours scheduler as a result of the updated weather and current scheduling choice

At 10:25 the operator asks the current observer if his observation was successful. The observer answers yes. The operator updates thetelescope period (if required) into the DSS time accounting tool and presses the dave button.

• The DSS accounting tool updates the projects total used time, the sessions used time, and the last scheduled date and time. If the session was a window session, the DSS creates the next window start and stop dates. The telescope scheduling history is updated with the project, session and telescope period that has just finished.

10:25 the operator asks the current observer if his observation was successful. The observer answers yes. The operator updates thetelescope period (if required) into the DSS time accounting tool and presses the save button. The operatr also adds any notes to the log at this point which the observer feels are necessary. These are in addition to any notes which the observer him/herself have entered durin observing. The DSS loggin tool (or whatever you want to call it) would then updae both the log on the ongoing project's page as well as the global system log.

• The DSS accounting tool updates the projects total used time, the sessions used time, and the last scheduled date and time. If the session was a window session, the DSS creates the next window start and stop dates. The telescope scheduling history is updated with the project, session and telescope period that has just finished, as well as the weather over that observing period.

AT 10:30 the remote observer starts observing.

10:30 the remote observer starts observing.

Issues not dealt with in above example but which we need tools for :

• RFI recording tool, which also has to send emails when appropriate to the rfi group and the various projects affected. Also something which flags sessions as not useful due to rfi and which can then be unflaggedd
• Lost time needs to be emailed not just to project people, but to other interested parties (e.g. Ron, other relevant/interested staff members)
• Logs need to be readily serachable/filterable
• All Carl's reports generating tools
• Also reports generating tool for Ron - lost time, etc. (we've never talked to him about this, but he does make a weekly report)

%COLOR RED% AMY REMOVE OVERVIEW WHEN YOU ARE FINISHED

Email Notifier - each part of the DSS may generate 1 or more emails to the same person. For example allocations that are incomplete. A change in project or allocation data. A significant change to the probablility or schedule of an allocation.

USE CASE:

A simple use case

Proposal handling and initial project and session data USER inputs proposal to the PST on May 1st 2007

May 1st 2008 PI submits proposal into the PST.

June 1, 2008 Proposal submission process closes.

Proposal submission process closes on June 1, 2007.

July 20, 2007 (Prior to the begining of the semester after a semesters proposal deadline has passed)

July 20, 2008 (Prior to the begining of the semester after a semesters proposal deadline has passed)

July 22, 2007 The GBT Scheduler modifies project data using the DSS project interface. The required project data fields are science grade, total project allocated hours, project allocated hours for each science grade (if more than one science greade appliesa) and maximum semester hours. A message to the PI is generated by the DSS indicating that the project has been accepted. Included in the email is a link to the project selection page and the project name and password.

July 22, 2008

The GBT Scheduler modifies project data using the DSS project interface. The required project data fields are science grade, total project allocated hours, project allocated hours for each science grade (if more than one science greade applies) and maximum semester hours. A message to the PI is generated by the DSS indicating that the project has been accepted. Included in the email is a link to the project selection page and the project name and password.

September 12, 2008

September 12, 2007

PI logs into the project page by inputing the project name and password.

• The DSS verifies the user and if user is validated, redirects the user to the project page.
• The project page is displayed. Project data will not be modifiable by the user and only some session fields will be displayed as modifiable.

• The DSS M&C Configuration Monitor is run on session to determine if changes have effected the runnability of the session. The sessions hardware availability is updated if appropriate. * DSS emailer receives message from Project interface that the session data has changed and schedules the email to the subscribers. The PI is always subscribed to all messages and will receive an email containing all messages from the DSS.

• The DSS M&C Configuration Monitor is run on the session to determine if changes have effected the runnability of the session. The sessions hardware availability is updated if appropriate. * DSS emailer receives message from the Project page interface that the session data has changed.

• DSS saves the calander information.

• DSS saves the calander information. All changes are recorded.

July 23, 2007 Another Observer Joan, who is associated with project who the PI has given the project password to updates her dynamic contact and availability information through the DSS calander interface. They also use select the messages they want to receive via email via from the project page. * The DSS saves the calander, contact and message subscribe information to the DSS database.

September 14, 2008

July 28, 2007 GBT Support Staff modifiies the remote observing qualifications of Joan to "qualified"

• The DSS updates the projects associated with Joan to indicate that there is a remote qualified observer associated with this project.

The PI gives the project password to his co-pi, Joan. She visits the project page and updates her dynamic contact and availability information through the DSS calander interface. She also subscribes to the the probability, hardware availability, and session modification messages. * The DSS saves the calander, contact and message subscribe information to the DSS database. All changes are recorded.

September 28, 2008

Oct 21st, 2007

GBT Support Staff using the contact management interface modifies the remote observing qualifications of Joan to "qualified"

• The DSS updates the projects associated with Joan to indicate that there is a remote qualified observer associated with this project. All changes are recorded.

6:00 (daily) The DSS probability generator cron job is run. The predicted weather forcast is used to create probabilities/schedule for the next 24, 48 hours and 1 week periods. The DSS schedule web page is updated with the new results. The GBT weather page is updated with the forecast.

6:10 Session Verifier automatically runs and constructs message for each session that is incomplete. A session is considered incomplete and not able to be scheduled when: 1. There is not enough information for the DSS schedule algorithms to schedule the session. 2. There is no observer on site and there are no remote qualified observers associated with the project.

6:15 (daily) For each project that has unsent messages associated with it, the emailer constructs one email containing all messages generated by the DSS components and emails the PI. In addition, an email is sent to each subscriber containing the messages that the observer has subscribed to. It is expected that a periodicity associated with each message type will be required. One option is to allow the user to speicify message periodicity during the subscription process.

Oct 21, 2008

3:45 The cabling file is modified by a GBT receiver engineer

• The DSS M&C monitoring system (asynchronous Daemons continuously running) determines every sessions runability and updates the DSS database with the results for each session.
  • Messages are generated when the GBT hardware configuration has changed and it has effected the runnable status of a session.

3:55 dev health file modified. * The DSS M&C monitoring system verifies all sessions runability and updates DSS database with the results for each sessions. * Messages are generated when GBT hardware failures and fixes have affected the runnable status of a session.

Asynchronous Daemons- cabling file modified -> DSS M&C monitoring system verifies all sessions runability and updates DSS sessions with results. Messages are created when a sessions runability is changed dev health file modified -> DSS M&C monitoring system verifies all sessions runability and updates DSS sessions with results. Messages are created when a sessions runability is changed

6:00 (daily) The DSS probability generator cron job is run. The predicted weather forecast is used to create probabilities/schedule for the next 24, 48 hours and 1 week periods. The DSS schedule web page is updated with the new results. The GBT weather page is updated with the forecast.

6:10 (daily) Session Verifier automatically runs and constructs a message for each session that is incomplete. A session is considered incomplete and not able to be scheduled when: 1. There is not enough information for the DSS schedule algorithms to schedule the session. 2. There is no observer on site and there are no remote qualified observers associated with the project.

10:00 GBT Operator runs the scheduling program with time of 10:30 Inputs: default weather parameters default for all options - science grade A and B, current semester (includes A projects from previous semesters), projects and allocations with remaining time, semester allocated time remaininga, time of day is used in selection DSS -> uses Weather forecasts to determine predicted weather at 10:00 OR current weather is used. TBD what is the default DSS - applies Selection Rules. Selected ranked sessions are presented to operator in graphical form.

6:15 (daily or continuously TBD) For each project that has unsent messages associated with it, the emailer constructs one email containing all messages generated by the DSS components and emails the information to the PI. In addition, an email is sent to each subscriber containing the messages that the observer has subscribed to. It is expected that a periodicity associated with each message type will be required. One option to alleviate spamming the user with many emails is to allow the user to specify message periodicity during the subscription process. The user may also shoose to receive a digest or each message individually.

All upcoming fixed and window sessions must be presented to the operator at least 12 hours in advance of their start time. All sessions that can run at the chosen LST should be displayed and ranked with auxiliary information such as LST constraints, min and max run times, day/night transistion time. Other session data as needed like observer on site, obs efficiency. The operator may choose to overlay these sessions with a "future" look. For example, overlay the sessions that can run now, with sessions that can run in 2 hours with different weather inputs. The future look overlay will assist the operator in determining the appropriate telescope so that future telescope periods may be run that include sessions higher stringency, efficiency and ranking.

Operator -> chooses a session based on ranking, current and near future fixed and window constraints. -> Operator uses contact tool to acquire observing contact phone number. -> Operator calls observer contact #1 for that session. No answer -> Operator calls next observer contact for the project and notifies observer that the telescope will be available to run session "X" in 25 minutes. The telescope period will be for 4 hours.

AT 10:25 the operator asks current observer if the observation was successful. The observer answers yes. The operator inputs the past telescope period (4 hours) and saves it. -> the DSS updates the projects total used time and the sessions used time, and last scheduled date and time. The telescope scheduling history is updated with the project, session and telescope period that is finished. the operator inputs the nest session that will start at 10:30 into the time accounting tool.

10:00 GBT Operator runs the scheduling program with the time of interest as 10:30 Other Inputs into the scheduling program are defaulted:

• default weather parameters
• default for all options - science grade A and B, current semester (includes A projects from previous semesters), projects and allocations with remaining time, semester allocated time remaininga, time of day is used in selection process * The DSS uses weather forecasts to determine the predicted weather at 10:00 OR current weather is used. (TBD what is the default) * The DSS applies Selection and Ranking rules. Selected sessions are presented to operator in graphical form and are clearly ranked. * In addition to sessions that are eligilbe to be run at 10:30, all upcoming fixed and window sessions within 12 hours of 10:30 are presented to the operator. They are clearly identified as upcoming Fixed and Window sessions. * All sessions that can run at the chosen time are displayed and ranked. Critical information such as LST constraints, min and max run times for each session are graphically presented to the operator. Critical factors in determining telescope periods such as day/night transistion times are displayed. Other auxiliary session data augments the graphical display. * The operator chooses to overlay these sessions with a "future" look ahead of 2 hours. The sessions that can be run at 10:30 are overlayed with sessions that can run in at 12:30 hours. The operator expects the weather to dramatically improve in the next 2 hours so when configuring the look ahead overlay, the operator overrides the default weather inputs and specifies each of them. The future look overlay assists the operator in determining the appropriate telescope period and session.

Operator chooses a session and telescope period. Operator selects the session and selects the view contact information in the scheduling program interface.

• The DSS displays a list of observers associated with the project and their contact numbers for Oct 21, 2008. Contact numbers are listed in the priority order designated by the PI and do not include observers who are not on site and who are not remote qualified.

At 10:25 the operator asks the current observer if his observation was successful. The observer answers yes. The operator updates thetelescope period (if required) into the DSS time accounting tool and presses the dave button.

• The DSS accounting tool updates the projects total used time, the sessions used time, and the last scheduled date and time. If the session was a window session, the DSS creates the next window start and stop dates. The telescope scheduling history is updated with the project, session and telescope period that has just finished.
• The operator updates the time accounting tool with the session that starts at 10:30.

Asyncronous Process: M&C Configuration Monitor whenever cabling or device health status changes it will evaluate each sessions ability to run and update the database appropriately. session is changed then Email Notifier - each part of the DSS may generate 1 or more emails to the same person. For example allocations that are incomplete. A change in project or allocation data. A significant change to the probablility or schedule of an allocation.

Core Software Functionality

Proposal Submission Tool

Project Management

ProjectsPage

• Telescope Scheduler - logs, project view, edit all
• Investigators - logs, project view, add and modify allocations, add contact info
• Operator -logs, project view, add contact info
• Support - logs, project view, add contact info
• Friends - logs, project view, add contact info
• Operations - activities and resources data

Session Management

Session Information

• create and modify sessions

Session Verification

Contact Management

Observer Information

Calendars

Scheduling

• "the guts"

Session Scheduling

Session Scheduling Forecast

• automatic (?) look ahead process that generates probabilities or schedules. It uses the Session Scheduling code.

Weather Information

Current Weather

Predicted Weather

RFI

Past Telescope Schedule(s)

Configuration Checker Daemon

• Looks for additions and changes to cabling files and generates pickled cabling files
• Verifies configurations and Modifies DSS database "configuration valid" field accordingly.

E-mail Daemon

• email to RFI group when unexpected RFI occurs
• email results of refereeing process to Investigators
• email Investigators when Allocations can not be scheduled
• email Telescope Scheduler when a telescope period was deemed unsuccessful
• emails to Investigators when probability of receiving telescope time has significantly changed

VLB Schedule Interface

Support Software Functionality

Interface to the Proposal Submission Tool Database

• The database contains Proposal data.
• It is assumed that the interface will be provided by the group responsible for the PST.
• This group is also responsible for the NRAO User Database which has query servlet interfaces that provide user info in XML format. Something similar to the PST database would be desirable if we don't get full access to the database itself.

Proposal Database Update Process

• Updates the Dynamic Scheduling database with data from the SSS Proposal database
• Probably run by the Telescope Scheduler after a semesters proposal deadline has passed.

Proposal Selection Committee and/or Telescope Scheduler Interface (tabled until we understand requirements better)

• Tool to update the results from the refereeing and Proposal Selection Committee process (e.g. science grade, allocation hours, weather grades etc.)

Replacement program(s) for Current Telescope Scheduler Support Tools

• This could include things like report generators. MikeMcCarty will be meeting with Carl to discuss the requirements within the next few weeks. Information on Carl's Support Tools can be found at SchedulingSoftware.

USER -> PST

USER inputs proposal to the PST on May 1st 2007