NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Data > ObservingAPIBeta

Changes | Index | Contents | Search | Statistics | Jump to Topic

Observing API Beta Release

The next BetaRelease is planned during Cycle 7 of 2004 (on 10/29/2004).

1. Introduction

The Observing API is used to build observing scripts, which are the key component of a Scheduling Block. The Observing API consists of two components:

• ObservingAPIBuildingBlocks
  • these are primitive commands that control antenna motion
• Standard ScanTypes
  • these have been created for you using the ObservingAPIBuildingBlocks
  • these can be called directly from the observing script
  • these will also be callable from within your Scheduling Block

Should an observer or a commissioner wish to create an entirely new pattern of antenna motion which is not covered by one of the standard ScanTypes, he or she should use the ObservingAPIBuildingBlocks. These are a collection of a handful of primitive functions for antenna control. Unlike writing new scan types in glish, you do not have to worry about "bookkeeping" such as ensuring that devices or the Scan Coordinator are in a healthy state before moving the antenna. This is all done for you.

2. Capabilities

1. Can configure with a canned script, a canned script plus individualized edits, or an external configuration script. Configuration and setup data is now stored as HISTORY keywords in the GO FITS file.
2. No import statements or g. or a formal g.setup() required to execute a setup
3. Can use one of 16 ScanTypes (formerly called procedures)
4. Can add your own debugging comments to the observing script
5. Can add annotations to the observing script which are recorded as keyword/value pairs in the primary HDU of the GO FITS file
6. Works with dynamic corrections
7. New User-defined Scans can be written by using the Turtle Building Blocks directly
8. Produces an editable "history" file that shows what happened during your observation

3. How Does the Observing API Relate to Scheduling Blocks?

The Observing API is used to build an Observing Script, which is one component of a Scheduling Block. Scheduling Blocks also contain project metadata, observing constraints, and source information, which allows them to be archived and managed as comprehensive descriptions of the observer's intent. For the beta release, you will only be working with observing scripts. Once the functionality in the observing scripts is validated, we will have confidence that Scheduling Blocks will execute correctly on the telescope and produce viable and reasonable data.

4. Project Background

The goal of the Observing API project is to build on the lessons learned from GO to produce the next generation observing utility. However specifically, the goal of the Beta Release is twofold. First, the Beta Release will generate much needed feedback from on-staff astronomers. Second, the exercise of implementing observing procedures will expose the strengths and weaknesses of a new observing specification language. An initial step in creating the Observing API has been to partition the user interface per se from underlying specification language. GO was built directly on the Ygor API via the Glish client interface which is oriented to the telescope hardware. The system can better reflect astronomical use if the specification language is oriented to observing concepts such as procedures, beamwidths, offsets, or beams. This approach will allow the enhancement of the system with user-defined procedures, increase robustness, introduce command-line interaction, facilitate general maintenance, improve reliability, and support integration into telescope scheduling.

The core of the Observing API is a small set of building blocks implemented as Python objects which allow the definition of all possible observing procedures for the GBT. The metaphor for moving the antenna's beam on the sky is LOGO a classic program which allowed the user to move a turtle around the computer screen. Initially, our handle for the Observing API is Turtle. Turtle focuses the observer's attention on the science being done on the GBT rather than the actual procedural elements that are required to collect his/her data. The observer's needs are specified by constructs that describe "what" is to be done rather than "how." Therefore scans in Turtle are less a series of step-by-step instructions of what is to be done, but more of a description of the desired result. For concrete examples, please refer to the Observing API Beta Usage instructions.

5. Known Issues

• Cannot specify offsets in terms of beam widths.
• No flexibility in specifying position units.
• Plus those items listed in ObservingAPIBetaRequests

6. Additional Work Required

In C1 2005:

1. Source catalogs
2. Simplication of arguments to ScanTypes
3. Global Keywords as specified in NewGoProcedureParameters
4. Simplifications in syntax for use within Scheduling Blocks (e.g. eliminating the need for the Configure(""" line).

Beyond C1 2005:

• Implementation of recording antenna position at a specified time
• User-defined coordinate modes
• Tracking solar system objects and using ephemeris tables

Long Term (2005+):

• Ability to insert runtime conditionals into the observation (e.g. integrate until the signal to noise reaches a certain value; not according to calculated values but measured goodness of the data)
• Adding an unconstrained __Track as per BrianMason and RichardPrestage's needs

7. Out of Scope

• All work on the Observing API is being geared towards ease of use at the Scheduling Block level, and not at the Program level. (A Program is a collection of Scheduling Blocks which are arranged logically to accomplish the goals of a Science Program.)
• Pipeline processing will be triggered at the Program level for the subset of GBT StandardObservingModes that demand this. As a result there will be no keyword or trigger provided at the Scheduling Block level, which implies that this is not considered within the Observing API.
• Although constraints on the observation (e.g. required opacity, valid LSTs) are an important considerations for when to execute an SB automatically, we assume that for at least the next 1-2 years, SBs will be primarily be selected by the observing astronomer, who will evaluate observing conditions subjectively. To support automated dynamic scheduling, a new entity will be added to the Scheduling Block definition which may require additional work on the Observing API.

8. References

Frank's Main Documents:

• Command Line Proposal, Frank et al - May 2003. Contains details for configuration and balancing commands.
• Specifications for a command line observing language: NewGoProcedureParameters - Nov 2003, Revised Spring 2004. Contains details for observational parameters.

• Draft specification for source catalogs: SourceCatalogSpecs
• Up to Date References (in use for development): GOFitsFileParameters, SchedulingBlock, ObservingAPIBuildingBlocks
• Early Project Information: GbtObservingScope, ProcedureParameters, ProcedurePseudocode and ProcedureTrack
• Early Design Notes: ObservingProcTestCases
• Technical Design: ObsPrepGUI

Core Team