The GBT observer interface (GO) should contain applications which aid the user in a productive and efficient manner. There should be sensible error checking. Below we list the essential ingredients for GO.
GO should have an interactive GUI with both monitor and control panels. The GUIs should behave similar to those developed in most standard software packages. A layered approach should be employed where the most important parameters are displayed on main panels. There should be three main panels: a control panel, a monitor panel, and a status panel.
The main control panel should include information from various devices which plan to be utilized in the observing. For example, the front-end receiver, the back-end configuration, any relevant frequency information, the observing and switching modes to be utilized, etc. There should also be information about the source, its coordinates, velocity information for spectroscopy, pulse period for pulsars, etc. Generic information about the observing program should be listed (e.g., the observer and project ID). Information about the procedure, which defines the observation, should be listed along with the relevant procedure parameters.
Additional details should be provided from underlying panels with the philosophy that most of the relevant information is on the main panel. Thus, there needs to be a balance. Too much information on the main panel make it difficult to absorb, while too little requires the observer to bring up additional panels.
The main monitor panel should focus on the antenna. This should be done graphically where telescope position and its scheduled movement for the current scan is indicated. Also, the user should be able to display the positions of sources from a catalog which can be specified from an ASCII file. Important information from other devices should also be displayed on the main monitor panel. There should be information about the weather, the tipper for high frequency observations, the total power levels, and any relevant frequency information.
Underlying GUIs should contain information which the observer would not regularly wish to monitor. It should display graphically the available frequency band in RF units from the front-end to the back-end. This might only be viewed once during the initial setup. Also display the power levels from the front-end to the back-end at critical places.
The main status panel should reflect the current status of the system. This panel need not be very sophisticated. A ``christmas-tree-light'' approach is desirable. The main purpose of the status panel would be to let the user know that all devices are working properly. Additional information should exit in underlying panels. However, it is the job of the observatory staff to fix any problems with the system and thus the tools to perform repairs need not be located within GO.
GO should also be able to run in batch mode by executing an observing file (GO table). These should be simple ASCII files which can be manipulated with any standard text editor. Software to check the sanity of these files should be available. At a minimum the syntax of the GO table should be verified. Because of the complexity of the GBT there are hundreds of parameters which are required to configure the system. A limited number of well documented GO parameters (keywords) should be defined that are tailored for the astronomer which can be used to configure the system. These keywords need to be mapped onto the lower-level monitor & control (Ygor) parameters which are device specific. However, GO should be able to set each of the Ygor parameters as well with the intention that this would not be normal operation.
Software which aids the observer in planning their observing schedule should be developed. It should be possible to import an ASCII file containing a source list. In principle this could be the same format as that used for the GO table. The software should allow the user to plan the observing schedule and at least generate scheduling reports. That is, information about when each observation begins and ends, where the source is located on the sky, slew times, etc. An interactive mode would also be useful. It should be possible to generate a GO table.
A calibrator lists should be available to the user within GO. There should at least be a continuum, spectral line, and pulsar list of calibrators.