NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Dynamic > SoftwareSuiteOriginal

Changes | Index | Search | Go

Software Suite for Dynamic Scheduling

• Tool for building SBs
• Query Tool
• Observing Log
• Time Accounting Tool
• Web feedback page
• Metadata information tool
• Data Reduction
• Quick Look Data Display
• Running SBs Tool
• User/Staff feedback tools

Note that many of these tools may be combined into one. However at the moment they are listed as separate for development purposes

Here are AmysJCMTNotes, which contains what the JCMT is doing.

Tool for building SBs

This has been discussed (and requested) for some length at GB. It is definitely a tool which we want, and would greatly ease the burden of the support staff in getting project prepared for observations. Additionally, a tool such as this would likely result in much simpler and more standard SBs. As a result, it would be highly beneficial (but not completely necessary) to build this tool before the start of Stage II of the dynamic scheduling system. In the absence of this tool (and also as a preparation for it), we need to build a very good database of template SBs for observers. If we decide not to have a tool to build SBs (or, really, observing scripts), we might redirect our efforts into building a tool which accesses the templates and helps the observer write their personalized observing script. The JCMT observing tool has such a tool.

Query Tool

This tool is the lynchpin of the dynamic scheduling system, and must be built (or at least a prototype must be built) before the Stage I tests begin. This is the tool which will use our predefined algorithms and metadata to choose which projects/SBs should be run at a given time. This tool also, though, must be able to be run two weeks in advance (and less) to choose which SBs are the most likely upcoming candidates. It needs also to either be able to send information to observers if their proposal is likely to be run, or interface to another program which does that. Similarly, the output from the query tool should be placed on a publicly observable web page.

Note - The JCMT combines the query tool with the MSB submission functionality, which is sort of like (from our point of view) replacing the SB list on the left-hand side of the Run tab with a query button, query result list, and keep the submit button.

Some note on the Query Tool can be found at SchedulingAlgorithms

Observing Log

This is should be considered as part of the "unified messaging" project which has been on the queue for the GBT for the past year. While it is not vital for the dynamic scheduling system, it will make the resultant data much more useful both for the investigators and also for anyone wishing to use our data archive. This tool should be built before Stage II observing begins.

This is one item that needs a lot of discussion. To date, our logs have been write-only entities generated by the system. For the JCMT, their observing log software seems to be a mechanism which allows the observer to add their own notes to an observation. Furthermore, they use the log when doing time accounting. E.g. the observer uses the observing log in order to explain dead time between MSBs. We definitely need to ensure that we are capturing observer intent especially from an archiving point of view. This is not a dynamic scheduling concern per se, but still important in the scheme of things. Of course, we should realize (in general) that many of these dynamic scheduling tools have larger impacts to the GBT than just dynamic scheduling.

Regardless, the operator and observer logs and comments should be logged in a manner to allow for easy viewing and understanding by any observer whose project may be affected by the comments. Alos, the operator log needs to be expanded to allow easy logging of rfi, with an rfi feedback tool being added in such that when time is lost, or a project ended, due to rfi, the operator is requested to fill in enough information (gethered with the help of the observer) to enable the rfi group to track down the rfi.

Time Accounting Tool

This tool will be extremely important for the telescope scheduler and the investigators to keep track of the time left on a project, as well as the time left for a session and the dates needed for fixed time and fixed window projects. In will likely need to incorporate the information in the operators logs, and ideally should be fairly sophisticated, doing all time calculations itself and needing only human intervention for confirmation. In its first incarnation, though, it could be a very simple fill-out form which someone (telescope operator? Pete? Carl?) fills out by hand each day. Some version of the tool must be in place by Stage II observing, and it would be good if a prototype were in place by the Stage I tests.

Note that this tool also needs to retain the ability to let us change percent completion and time usage numbers for both projects and SBs after the fact - ala what Pete Chestnut does manually now and in the infant incarnations above.

Web feedback page

This tool will be vital to keep track of the thoughts of the observers, telescope operators, and project friends. In would be good to be in place by the Stage II observing, but could be put off until Stage III.

Metadata information tool

This tool will provide some of the vital information which the query tool will use to determine the order of SBs, and which the telescope operators will use to contact observers. That is, it will not contain all the project metadata, but only that metadata which may change rapidly, such as observer contact information, observer availability, notes from the observer regarding the SBs, etc. A prototype of the tool must be in place by the Stage I tests, and version 1 must be in place before the Stage II observations.

Data Reduction

GBTIDL currently does a good job of proving rapid data reduction for many of the observations on the GBT. However, we should be considering if GBTIDL is adequate for the needs of 90% of our users, or if it should be expanded/altered to meet those needs. Any upgrade to GBTIDL would be considered separate from this project.

Quick Look Data Display

GFM currently does a good job on this end, and will remain the tool planned for quick look displays with dynamic scheduling. Any upgrades to GFM will be considered separate from this project. We should, though, begin considering a tool to allow for quick looks of pulsar data, which could be done within GFM or elsewhere.

Running SBs Tool

At the moment we use Astrid, which is sufficient. However we need to re-think a means to make it easy for the telescope operators/observers to go between the information given by the query tool and choosing the SB to run. This interface should be in place by Stage II.

Note - The JCMT combines the query tool with the MSB submission functionality, which is sort of like (from our point of view) replacing the SB list on the left-hand side of the Run tab with a query button, query result list, and keep the submit button.

User/Staff feedback tools

The JCMT has automated emails notifying users and support staff when MSBs are complete. Also, I imagine that we'll need some sort of "where is my SB in the scheme of things" software entity for users to figure out what exactly is going on with their project at any given time. We need to think long and hard about providing easy to use tools so that the user can keep track of what is going on. A prototype of this tool should be in place for Stage I.

This will probably involve making a unified messaging system. It also needs a ready means for the observer/operator to record RFI information, and automatically send that information to the rfigrp. The mechanism to report RFI will contain a list of questions (supplied by the RFI group) and the options to: A) Postpone and Coordinate (if signal is on the coordinatable list) B) Postpone and try to Identify with the hopes of mitigation C) Don't postpone, but still notify the RFI group (when the RFI doesn't severely compromise the study, for instance)

-- KarenONeil - 01 Jun 2006