Predicted Weather Requirements

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

%META:FILEATTACHMENT{name="DSSPredictedWeatherRequirements_v11.pdf" attr="h" comment="DSS Predicted Weather Requirements" date="1192030135" path="DSSPredictedWeatherRequirements_v11.pdf" size="17344" user="KarenONeil" version="1.1"}%

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

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

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

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

Allocation & project data:

Project & session data:

• Needs to have a page where co-investigators can choose to receive emails or not regarding project/allocation status changes
• The project/allocation 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 allocations are missing information and therefore cannot be scheduled

• 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

• Observers should be readily able to see the probability of their projects/allocations being run at a given time

• Observers should be readily able to see the probability of their projects/sessions being run at a given time

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

• The means for flagging and unflagging RFI for allocations needs to be straightforward

• The means for flagging and unflagging RFI for sessions needs to be straightforward

• It should be easy to search the combined observing logs in a variety of ways, e.g. by project/allocation (this is likely the information to be displayed on the project's website), by date, by type of information (failure, weather, pointing, etc)

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

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

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.

• Log entries pertinant to a given project shoudl be displayed on the project page
• In all cases the log diplays 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)

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

• The log should recrod who made hwat entry
• Past entries in the log should be editable, but in all cases a history of edits must be kept (and accesible)

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

• The DSS ust 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

• 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

Astronomer's View

General Requirements

Below is an attempt to capture the type of input/output that an astronomer might wish to see with the DSS, as well as the means for getting it. At this point this is a very preliminary description (more a stream of consciousness) intended merely to point us in the correct direction rather than be a definitive list of what is needed.

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

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

• It would be good is all the necessary information were contain in some easy to navigate web pages

• All the necessary information should be contained in some easy to navigate web pages

• Need easy means for displaying the project and allocation data and also for associating that data to scheduling blocks. While SBs are not going to be viewed by the DSS, the observing needs to be able to associate allocations and SBs, even if it is only superficially, through comments in the allocation data tables. Maybe this can even be linked to an online SB editor and submitter PRM - this seems reasonable if it is just for book keeping purposes. Should the links be both ways? (attributes of SBs link them to an allocation(s) as well). Does this also imply a change in Astrid (show me scheduling blocks for Project A and Allocation X) ?

MJM: I thought that specific maintenance activities would not necessarily go throught the DSS (although it would be nice), but rather a general maintenance activity would be input ( i.e. telescope at birdbath for 4 hours with a window from 2-6-07 to 2-9-07).

• The telescope schedule is a public document, so info on the telescope scheduling should be publicly available

• The historical telescope schedule is a public document, so info on the telescope scheduling should be publicly available

• 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

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

Logging

• There needs to be a unified logging system for the telescope
• Log entries pertinant to a given project shoudl be displayed on the project page
• In all cases the log diplays 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 recrod who made hwat entry
• Past entries in the log should be editable, but in all cases a history of edits must be kept (and accesible)
• There should be a time stamp associated with every entry in the log

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

%META:TOPICMOVED{by="KarenONeil" date="1179998531" from="Dynamic.AstronomyView" to="Dynamic.AstronomyRequirements"}%

PRM - this seems reasonable if it is just for book keeping purposes. Should the links be both ways? (attributes of SBs link them to an allocation(s) as well). Does this also imply a change in Astrid (show me scheduling blocks for Project A and Allocation X) ?

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

• 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 allocation 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. PRM - this implies the unification of several new (some weather info, observer's logs) and pre-existing (Astrid, message mux, operator's logs) elements.

MJM: I thought that specific maintenance activities would not necessarily go throught the DSS (although it would be nice), but rather a general maintenance activity would be input ( i.e. telescope at birdbath for 4 hours with a window from 2-6-07 to 2-9-07).

%META:TOPICINFO{author="KarenONeil" date="1164646198" format="1.0" version="1.1"}% %META:TOPICPARENT{name="SoftwareSuite"}%

Astronomer's View

Below is an attempt to capture the type of input/output that an astronomer might wish to see with the DSS, as well as the means for getting it. At this point this is a very preliminary description (more a stream of consciousness) intended merely to point us in the correct direction rather than be a definitive list of what is needed.

• Overall feel
• Allocation & project data:
• Contact information
• Telescope scheduling information
• Observing

Overall feel

• It would be good is all the necessary information were contain 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

Allocation & project data:

• Initial input just needs to be easy and non-repetitive (e.g. through an improved PST)
• Need easy means for displaying the project and allocation data and also for associating that data to scheduling blocks. While SBs are not going to be viewed by the DSS, the observing needs to be able to associate allocations and SBs, even if it is only superficially, through comments in the allocation data tables. Maybe this can even be linked to an online SB editor and submitter
• Needs to have a page where co-investigators can choose to receive emails or not regarding project/allocation status changes
• The project/allocation 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 allocations 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 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/allocations 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

Observing

• 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 allocation 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.
• 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)
• 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)
• The means for flagging and unflagging RFI for allocations needs to be straightforward
• 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/allocation (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.

-- KarenONeil - 27 Nov 2006