NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > ObservingTools

Changes | Index | Contents | Search | Statistics | Go

GBT Scheduling Block Based Observing - Spring 2005

Quick Links: Source Catalogs, ScanTypes, ObservingDirectives

• 1. Introduction
• 2. Interactive Observing Process
  • 2.1 Before Your Observing Session - Create Scheduling Blocks
    • 2.1.1 Choose the Optimal Size for your Scheduling Block
    • 2.1.2 Specifying Sources
    • 2.1.3 Configuration
    • 2.1.4 Available Scans
    • 2.1.5 Other Directives
    • 2.1.6 User-Defined Scans
    • 2.1.7 Selecting a Good Name for your Scheduling Block
    • 2.1.8 Storing your Scheduling Block in the Observation Management Database
  • 2.2 During Your Observing Session - Execute and Monitor Scheduling Blocks
    • 2.2.1 Security
    • 2.2.2 Project ID and Session ID
    • 2.2.3 Observing Process
  • 2.3 After Your Observing Session
• 3. Non-Interactive Observing Process
• 4. Known Issues
• 5. Core Team

1. Introduction

The GBT Observing Tools (OT) are a suite of applications used to build Scheduling Blocks and execute your observations on the telescope, whether you are an interactive observer or your observations are being run for you in a dynamically scheduled manner. The main user applications are:

• Astronomer's Integrated Desktop (Astrid) - A container that launches most of the applications you will need for you. CLEO windows for advanced access to the control system must be launched separately; the CLEO container is recommended.

• GBT Observation Preparation System (Scheduling Block Builder) - Prototype available; requirements review to be done Fall 2005; refinement and release possible by end 2005. This GUI application will allow you to set globals, click buttons (like on GO), and type values into fields to automatically create your Scheduling Block and submit it to the GBT Observation Management Database. We expect that this will be used by visiting observers, and staff astronomers in GB who want to build their Scheduling Blocks as quickly and easily as possible.

• Observation Management System (Code Named "Turtle") - Available now for all observers. This application allows you to load, edit and validate Scheduling Blocks, submit them to the telescope for execution immediately or dynamically, and monitor the progress of execution. We expect that most staff astronomers in GB, and expert level visiting observers, will use this application to execute their Scheduling Blocks during an interactive observing session.

These applications all use the Observing API to create, validate, and execute Scheduling Blocks on the GBT. All of the applications depend on the Observation Management Database, which stores and tracks all Scheduling Blocks (and monitored output when the SBs are executed) associated with a GBT project.

How Does the Observing API Relate to Scheduling Blocks and the Observation Management system ("Turtle")? 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. The Observation Management helps you organize your Scheduling Blocks for a project, select and submit them to the telescope, and review what occurred during execution.

2. Interactive Observing Process

Although the GBT Observing Tools can be used for both interactive and dynamically scheduled observations, nearly all of the staff members who will be using and evaluating the application in the fall of 2004 will be using it in interactive mode.

2.1 Before Your Observing Session - Create Scheduling Blocks

Scheduling Blocks can be created using the Observation Management System, which contains a simple text editor reminiscent of Notepad, or your favorite text editor (e.g. emacs). Once the SB is created, you will need to use the "Observation Management" tab in Astrid to upload it into the database. It is best to do this step prior to your telescope time. Additionally, make sure your project ID is valid and entered into the Observation Management Database. Nicole, Amy, or the operators can check on this for you, and/or make the appropriate entries into the database.

2.1.1 Choose the Optimal Size for your Scheduling Block

When preparing your science program, you should construct several Scheduling Blocks. A Scheduling Block should ideally contain from 5 to 30 minutes worth of observations. A good example is the following Scheduling Block, which sets up a source list, configures for the observation, slews to the source, balances, does a peak and then follows up with a focus:

# this is the set-up for MYPROJECTID #first, set Locations of some flux calibrators Catalog(fluxcal) myCalibrator = "3C123" calOffset = Offset("J2000", -0.58, 0.0, cosv = True) galOffset = Offset("J2000", -1.45, 0.0, cosv = True) # set things up for a peak for a sanity check Comment("Configuring for peaking up with L-band") Configure(""" receiver = 'Rcvr1_2' obstype = 'Continuum' backend = 'DCR' nwin = 1 restfreq = 1400.0 deltafreq = 0 bandwidth = 200 swmode = 'tp' swtype = 'none' swper = 0.2 swfreq = 0.0, 0.0 tint = 0.2 vlow = 0 vhigh = 0 vframe = 'topo' vdef = 'Optical' noisecal = 'lo' pol = 'Linear' notchfilter = 'Out' """) Slew(myCalibrator) Balance() #run a peak, with length=120', rate=260'/min, firing the cals at 0.2s phases hoff = Offset("Encoder", "02:00:00", 0.0) voff = Offset("Encoder", 0.0, "02:00:00") Peak(myCalibrator, hoff, voff, 30)

The following should NEVER be done within a single Scheduling Block, as it will make the block too long:

• Multiple configurations (peak/focus and science observations should optimally be done in separate blocks)
• Changing receivers
• Multiple maps

2.1.2 Specifying Sources

The Source Catalog system in Astrid provides a convenient way for the user to specify a list of sources to be observed, as well as a way to refer to standard catalogs of objects. At a minimum for each source there must be a name and a location (ra/dec or Glat/Glon, etc). Other parameters may be given, such as radial velocity. There are several "standard" catalogs available. Each catalog is an ASCII file located in the directory: /home/astro-util/astridcats/

There are four formats of catalogs:

• SPHERICAL - A fixed position in one of our standard coordinate systems, e.g., RA/DEC, AZ/EL, GLON/GLAT, etc.
• EPHEMERIS - A table of positions for moving sources (comets, asteroids, satellites, etc.)
• NNTLE - NASA/NORAD two-line element sets for earth satellites.
• ORBIT - Orbital elements for solar system objects.

See the source catalog specification for further instructions on creating and using source catalogs within your Scheduling Block.

2.1.3 Configuration

There are three ways to set up the system: a) use a predefined Configuration Case with or without edits, b) define your configuration metakeywords directly within your observing script, or c) include a configuration script that you have prepared previously.

Details and examples to guide you through the process can be found here.

2.1.4 Available Scans

There are 16 available ScanTypes which can be used in a Scheduling Block, including Peak, Track, Tip, and OnOff. You can also write your own user-defined scan if you need advanced functionality.

2.1.5 Other Directives

In addition to the 16 available ScanTypes, there are 11 other ObservingDirectives that are used within observing scripts and Scheduling Blocks. For example, the Configure directive described in 2.1.3 enables the user to specify a telescope setup in three different ways. Break is used to pause the execution of a Scheduling Block so that certain conditions can be verified by the astronomer, such as, "did my balance produce the results I expected?"

2.1.6 User-Defined Scans

If you need to move the antenna in a pattern that is not supported by one of the 16 available ScanTypes, you can write your own. These must be written in standard Python. Writing a user-defined scan is a little more difficult than other uses of the Observing API, but expert observers now have the capability to create their own new scans as needed, without having to request software division effort. The astronomer is now in control.

Learn how to write your own user-defined scan or view the QuickPeak example to get started. Additional functionality is available beyond what is shown in QuickPeak - you may use any of the objects or methods found in the examples at ObservingAPIBuildingBlocks.

2.1.7 Selecting a Good Name for your Scheduling Block

Choosing a descriptive name for your Scheduling Block, such as BCPM_Lband or subrXsElComa, which will remind you of the science you are trying to accomplish by running that particular block. Names such as test or turtle.p are not descriptive, and you may have to open several Scheduling Blocks to determine which one you want to run. The name you choose can be up to 96 characters long, and can contain whitespaces, so you may have a Scheduling Block name that consists of a few words (such as K-band frequency-switched spectroscopy).

You do not need to add a suffix to your Scheduling Block name (.turtle or .py) since the Scheduling Block executor that runs your scripts knows that they are written using the Observing API and Python.

2.1.8 Storing your Scheduling Block in the Observation Management Database

Prior to your telescope time, you should store all of your Scheduling Blocks in the Observation Management Database. All Scheduling Blocks must pass a syntactic validation process before they are stored to this database, so storing your blocks to the database ahead of your on-telescope time will help you avoid losing time due to syntax problems in what you have written.

For further information on uploading Scheduling Blocks to the observation database, please review the Observation Management usage page.

2.2 During Your Observing Session - Execute and Monitor Scheduling Blocks

2.2.1 Security

Ask the operator to put you in the gateway for all devices, and also to add monctrl@wind to the gateway with permission to operate the Antenna and the AntennaManager.

At the present time, there is no additional security on the Turtle Observation Management System. As a result, please only use the Run tab if you are the scheduled interactive observer. Future plans include limiting the availability of the Run tab to only the scheduled interactive observer, to support users who wish to use the application offline to create and store Scheduling Blocks to the database.

2.2.2 Project ID and Session ID

Your project ID is the unique code assigned to your project when your proposal is accepted. This project ID does not change throughout the life of your project. If you observe interactively, however, you may wish to distinguish various data directories that comprise your project. This is the purpose of the "Session" field you will see on the Run tab. The session number is filled in by the Observation Management system once a project is selected in the Run tab. This number is auto-suggested, but may be overridden. Your data will be written to a data directory (in /home/gbtdata) which is comprised of your project ID and session number, e.g. AGBT04C_045_01 where AGBT04C_045 is the project ID and 01 is the session number.

2.2.3 Observing Process

The observing process is described in the Observation Management usage page. The basic idea is that all Scheduling Blocks that are saved under your project ID in the database are available to be executed on the telescope. The Job Queue is a list of all available Scheduling Blocks. The Run Queue is the list from which the Scheduling Block Executor takes Scheduling Blocks to run on the telescope. The History list details each Scheduling Block that has been run during the current session.

A description detailing the progress of your Scheduling Block can be found near the bottom of the Astrid screen in the observation log.

2.3 After Your Observing Session

After you finish observing, you can export your observing log (all the text that was displayed on the observation log) by clicking on the "Export Log" button located just above the observation log. You will be prompted for a filename and the directory to store this file.

You should also ask the operator to take you out of the gateway at this time.

3. Non-Interactive Observing Process

Turtle, and the Observing API, have been designed to support non-interactive observing. That is, you should be able to create Scheduling Blocks and submit them to the telescope to be run whenever there is available time. This process is not currently supported on the GBT, but is planned - after all, this is the key to automated dynamic scheduling. To automate the execution of Scheduling Blocks, however, constraints for the weather, or the times your sources will be up, must be part of the Scheduling Block metadata. Enhancements are required to the Observation Management Database and the Observing API to make it possible to store this information in your blocks and to submit the blocks to a queue that will be managed by the operators. We anticipate that some work will be done on this in 2005.

4. Known Issues

• See also Troubleshooting.
• It is REQUIRED that you slew to your source before your first attempt to perform a focus. If you try to focus without first being on source, the telescope will try to focus at the last location stored in the antenna, which is probably not on your source. You will end up with LFCs that are extremely unreasonable and you will have little or no apparent signal in your data.
• If the operator restarts turtle.d to refresh the Observation Management ("turtle") application, you must resubmit your configuration even if the telescope is already configured. This is necessary so your observation will produce GO FITS files, which are needed for many kinds of data reduction.
• Project IDs must be entered into the database by a developer prior to the observing run. Eventually, all approved Project IDs will be accessible.
• Commissioners may find it awkward to execute short tasks as Scheduling Blocks, since the inclination is to create large Scheduling Blocks and then want to highlight one or two lines and run just those lines. This situation is remedied very easily by storing and running smaller Scheduling Blocks.
• All data collected by procedures that have a time-dependent component (i.e. OffOnSameHA) will be invalid. We are working on getting the mechanics down pat first and will focus on time dependencies second.
• Cannot specify offsets in terms of beam widths.
• No flexibility in specifying position units.
• There are also many enhancement requests that have been made during initial test periods. Feel free to add to the list.

5. Core Team