Dynamic Scheduling Use Case

Time line Detailing a Simple Use Case

Time line Detailing a Simple Use Case

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

PI Submits Proposal - May 21st 2008

PI submits proposal into the PST.

Proposal submission closes - June 1, 2008

Proposal submission process closes.

PSC Evaluation - July 15, 2008

PSC evaluates proposals.
Proposal is graded and accepted.

Add Proposals to DSS - July 17, 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.
- All relevant data in the PST database is retrieved and used to populate the DSS database.

Notify PI of Project Acceptance - July 22, 2008

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

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

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.
- 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.
PI uses the DSS Project Interface to update the session data.
- The DSS validates, then saves, session data. The history of changes are recorded.
- 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.
- 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.
- DSS saves the calender information. All changes are recorded.

The Co-I Updates Contact Information - 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.
- The DSS saves the calender, contact, and message subscription information to the DSS database. All changes are recorded.

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

The DSS will now begin regular emails to the investigator and other interested parties if project/session data is invalid or incomplete

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.

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.

Observation Day - October 21, 2008

3:45 - The cabling file is modified by a GBT receiver engineer.
- 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.
- Messages are generated when the GBT hardware configuration has changed and it has effected the runnable status of a session.

3:55 - The M&C device health file is modified.
- The DSS M&C Configuration Monitor verifies every sessions eligibility to be scheduled 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 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 DSS schedule web page is updated with the new results.
- The GBT weather page is updated with the forecast.
- 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) - 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.
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 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 - 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 weather parameters
2. 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.
  - 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 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 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, 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 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.
- 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.
- 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 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.
- Operator calls the first observing contact on the list. No one answers the phone.
- 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.

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.
  - 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.
- The operator updates the time accounting tool with the session that starts at 10:30.

10:30 - The remote observer starts observing.

Topic DSSSoftwareUseCase . { Edit | Attach | Ref-By | Printable | Diffs | r1.13 | > | r1.12 | > | r1.11 | More }

Revision r1.13 - 30 May 2007 - 19:59 GMT - MelindaMello	Content copyright © 1999-2007 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.


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

Changes \| Index \| Search \| Go