NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Dynamic > SoftwareSuite > AstronomyRequirements

Changes | Index | Search | Go

General Requirements

This page is intended to be the overall requirements for the project. It does not include detailed requirements for each component of the DSS, but is instead intended to be the overarching requirements for the project.

• Overarching Requirements
• More details
  • Overall feel
  • Project & session data:
  • Contact information
  • Telescope scheduling information
  • Observing
  • Logging
  • Reporting tools
  • Predicted Weather Requirements

Overarching Requirements

1. Project scheduling data must be prepared in advance. A limited subset of the project scheduling data can be modified in real time as observations proceed.
2. The observer will be able to observe interactively - following the progress of an observation's execution in real-time, subjectively evaluating the data, and making changes to subsequent Observing Blocks in response.
3. The observer retains control of his/her scheduled telescope time, meaning that he/she can observe interactively or non-interactively (queuing a list of OBs to be run), and if interactively, can choose to continue to observe at high frequency in less than ideal weather for some time if he/she wishes.
4. Observers must be able to get feedback about the execution state of their science program (in terms of percentage complete), how their observations fit into the schedule, and the execution state of individual Sessions within their projects
5. The scheduling strategies and processes should not negatively impact data quality. That is, data quality shall be at least comparable to what might be expected from a classically scheduled approach.
6. Process for scheduling and observation execution should not place an undue burden on support staff, for example, requiring them to be present to actively configure or perform detailed data quality assessments. The project investigators are always responsible for the data quality of the project.
7. Process for scheduling should readily accommodate GBT maintenance and repair activities.

More details

Overall feel

• All the necessary information should be contained in some easy to navigate web pages
• Pages would be broken down by project, with each project having a list of who can look at the pages and whom can edit the pages.
• Changing anything on the pages should be easy for an authorized individual

Project & session data:

• Initial input just needs to be easy and non-repetitive (e.g. through an improved PST)
• Needs to have a page where co-investigators can choose to receive emails or not regarding project/session status changes
• The project/session data which can be changed needs to be easily changeable probably through these web pages, although its possible that in certain cases (e.g. that of the GBT telescope scheduler) direct access to the project database would be desirable
• There needs to be a means for investigators to be notified if their sessions are missing information and therefore cannot be scheduled
• There needs to be an easy means, similar to the current resource calendar, for GBT staff to request maintenance and other activities;
• There needs to be an easy means for a day's requested maintenance activities to be displayed and searched for conflicts (much in the way the resource calendar is used now)

Contact information

• Needs to be very easy to change the contact information for observers
• Should include calendar or other easy to read display which shows which observers should/should not be contacted on certain days/times and how to contact them, along with an order for whom should be contacted first if more than one observer will be available
• Also needs information on whom the project "friend" is
• This is also the place where information on when someone affiliated with the project will be on site should be listed, although the link for placing yourself on site could simply point to our current reservations system

Telescope scheduling information

• The historical telescope schedule is a public document, so info on the telescope scheduling should be publicly available
• All events with predetermined dates/windows should be displayed in some easy fashion
• Observers should be readily able to see the probability of their projects/sessions being run at a given time
• Past telescope schedules (what the telescope actually did) should be stored and that information should be easily accessible both as a traditional telescope schedule and as a means for obtaining telescope statistics for a given period
• Weather information, past, present, and future, should also be displayed, or accessible from, here
• GBT staff need to be easily able to determine when given maintenance and commissioning activities are going to occur
• Telescope operators need to be able to easily obtain which sessions/project to run next. This decision involves not only knowing what sessions would are available to run in the upcoming telescope period, but any additional future facts needed for their decision, such as upcoming fixed and windowed projects, any highly ranked projects in the near future

Observing

• The observing interface needs to be simple and it needs to be easy for observers to change their scheduling blocks, the ordering of the scheduling blocks, etc. (Astrid is most likely sufficient for this)
• The telescope operator and support staff need likewise to be able to readily run the observations
• Any legitimately interested party should be able to readily see what the observer is doing (e.g. with GBTstatus and Astrid in "monitor only" mode)
• The means for flagging and unflagging RFI for sessions needs to be straightforward

Logging

• There needs to be one log which can be viewed by observers and support staff alike to know what happened for a given project. this needs to include information on the project and session being run, the SBs run, the results of the commands run, errors from the scheduling blocks, the message mux, information from the operators' and observers' logs, and and available weather information, feedback from pointing runs, etc. Note that this implies the unification of several new (some weather info, observer's logs) and pre-existing (Astrid, message mux, operator's logs) elements.
• There needs to be a unified logging system for the telescope
• There needs to be an easy means for telescope operators to explain problems and telescope down time (e.g. due to weather, instrument failure, RFI, or inability to contact an observer)
• Log entries pertinent to a given project should be displayed on the project page
• In all cases the log displays should be both filterable (e.g. show me only failures) and searchable (e.g. find all instances of spectrometer between June 10, 2005 and June 19 2005)
• Logging information will need to be entered by the telescope operator, observer, and GB staff members
• The log should record who made what entry
• Past entries in the log should be editable, but in all cases a history of edits must be kept (and accessible)
• There should be a time stamp associated with every entry in the log
• When a failure occurs there needs to be an easy means for that information to be automatically sent to interested parties. E.g. if time is lost due to RFI, the RFI group would likely like to know that, while if time is lost to a hardware failure then certain members of the hardware groups must be informed
• When a project looses time that fact should be sent to the telescope scheduler and perhaps a few other folks (e.g. the head of science operations and the on-duty support scientist)
• It should be easy to search the combined observing logs in a variety of ways, e.g. by project/session (this is likely the information to be displayed on the project's website), by date, by type of information (failure, weather, pointing, etc)
• At the end of a TP the operator must be asked if the TP was successful. The operator should be able to mark the entire TP as successful or not, as well as any partial time lost. when time is lost, the reason for why it is lost should be requested. If its partial time lost, the operator ought to be able to simple link to a previous "time lost" comment in his/her logs.

Reporting tools

• The DSS must provide the ability to generate all reports currently made on the GBT by the telescope scheduler (Carl Bignell). A list of these reports is captured on the SchedulingSoftware page.
• The DSS must also allow for the ability to display e.g. all lost time for the telescope over a given period. This should come as a direct result of the filtering and searching features of the logging tool

Predicted Weather Requirements

• The requirements for the predicted weather data, database, and database interface are laid out in the DSS Predicted Weather Requirements memo

-- KarenONeil - 27 Nov 2006