Holography Software Development for the MMA

B.E. Glendenning

1999-Apr-15

  1. Introduction

This document has been prepared for the MMA Holography PDR to take place in Tucson on 1999-Apr-19. It should be read in conjunction with the holography software requirements as described in the MMA Project Book and distributed for the meeting, and the draft note "Holography Support in AIPS++ DRAFT V1.0" by A. Kemball. This note considers only that software required to implement "single dish" holography. Discussions of interferometric holography are deferred to a later time.

In brief, there are three major software subsystems required to implement holography for the MMA.

    1. The real-time systems required to scan the beacon (or satellite) appropriately, and to collect and format the data from the holography backend.
    2. The analysis software to take the raw data, calibrate, grid, and transform it, resulting in a surface residual image.
    3. Software to take the residual image and produce instructions for adjusting the surface.

The above must work in a nearly-automatic pipeline system, and must be amenable to modification by operations and other staff as the holography techniques required for the MMA antennae are further refined.

If possible, it would clearly be of value to test the hardware and software systems together in advance of delivery of the prototype antenna, for example on the NRAO 12m telescope.

  1. Real-Time Systems
  2. The detailed implementation strategy for the real-time systems is not yet decided for example, which software to write, which to adopt. This section contains some general considerations for the real-time software as required for holography. Some preliminary use cases are shown in a later section.

    In general, the requirements for single dish holography are similar to those required for on the fly mapping. The antenna rapidly scans (0.5deg/s) the beacon in azimuth and elevation. If a satellite is used, the grid will have to follow the satellite motions. Note that for a terrestrial beacon the refraction calculations required for observations of extra-atmospheric objects will need to be turned off.

    At 90GHz the scan length will be about 5 degrees, and the row separation about 1 arcmin. This implies that the entire raster will require about an hour of observing time. During the raster frequent reobservations at the boresight position are required for calibration purposes. The MMA antenna specifications imply that each boresight sample will only cost a few seconds of move time, so they can be taken very frequently if desired. Similarly, occasional pointing calibrations will also be required.

    During the raster and boresight observations data from the holography backend need to be taken. Samples from the holography backend will be required at a TBD rate, not faster than every 10ms. The real-time system shall be responsible for time-tagging the data.

    The data samples will consist of complex (or possibly amplitude, phase) values. It is presently undecided whether or not the samples will be single complex values, or spectra. If the latter the spectra will consist of no more than one hundred points.

    Assuming 2x4 (8) byte complex samples (less should suffice), the worst case data-rate from the holography backend will be 640kb/s (100 point spectra, 10ms sampling). The "best" case rate is 0.64kb/s (1 point, 100ms). The former is uncomfortably close to the achievable upper limit of CAN a fast commercial fieldbus under consideration for the M&C bus (Brooks, private communication). Thus at the higher data-rates an additional communications path may be required, at the lower data-rates the M&C system would suffice.

    In either event, as the data is collected coordinate information will have to be associated with the samples. This will be done by interpolating the encoder readings (effectively sampled at 40Hz according to the antenna RFP) to the sample time and applying the pointing model resulting in sky azimuth and elevation.

    The data must be written into a data format suitable for data processing and analysis. There is no standard for recording holographic data in FITS; however the GBT project will (has?) define a FITS format which might be suitable for MMA single dish holography. Another possibility would be to directly write the AIPS++ MeasurementSet format. This latter would have the advantage of removing a stage in the reduction pipeline, reducing the latency of the processing. On the other hand, FITS is more suitable for archiving. On balance if the GBT FITS format is suitable it should probably be adopted.

    Interactive displays should be provided for the benefit of operators and other interested staff for example a picture showing the fraction of the raster which has been observed and the estimated time to completion.

  3. Data Analysis
  4. The AIPS++ project has assumed responsibility for holography data analysis. Interferometric holography within AIPS++ has already been implemented for the WSRT as part of their new Telescope Management System (TMS). Single dish holography will be implemented within AIPS++ by AIPS++ and GBT staff in 1999.

    A principal difference between MMA single dish holography and other holography requirements of AIPS++ is the use of a terrestrial beacon in the near field of the antenna. The AIPS++ staff is familiar with the literature in this area and appreciates that it is required for the MMA.

    It is important that it be straightforward to make changes to the analysis software in a to allow for unanticipated calibrations and to perform ad-hoc operations on the data. Much of this analysis will be written as Glish scripts which has powerful scripting and data processing features.

    Similarly it is important that various tools for plotting and viewing the data in all stages of its reduction be available. The general AIPS++ toolkit should suffice in this regard.

    The fundamental outputs of the analysis stage are an image of surface residuals, and the important values determined during the analysis such as the pointing offset.

  5. Surface Adjustment
  6. The output of the data analysis stage is an image of surface residuals in an antenna coordinate system. This needs to be turned into "instructions" for adjustment of the surface of the dish. The following discussion outlines a procedure similar to that used at BIMA (Lugten, private communication).

    A model is fit for each panel on the dish. For example, at BIMA they fit a combination of a vertical offset, a tilt, and a twist. Pixels are given a weight to accommodate pixels that fall on more than one panel. This fit can then be turned directly into screw adjustments for the panel, and a report of all these adjustments represents the instructions necessary to adjust the surface.

    Clearly it will be important to determine what model should be fit for the panel errors. It must be straightforward to change this model. For example, we might start with a vertical offset only, and add more terms as the surface comes closer to its final configuration.

    Besides a textual list of adjustments, it is desirable to produce a visual map showing the panels, surface contours, and the required turns for each screw.

  7. Pipeline Implementation
  8. A nearly automatic pipeline for implementing holography observing, data analysis, and surface adjustment instructions shall be implemented by MMA staff. Given the central role of AIPS++ in this pipeline, the pipeline will almost certainly be implemented in Glish.

    Note that such pipelines have previously been implemented in interactive observing systems, perhaps most notably for the Parkes Multibeam survey, as described in: http://www.stsci.edu/stsci/meetings/adassVII/barnesd1.html

  9. Use Cases

Use cases are a method of describing and enumerating software requirements. The following use cases are preliminary, with known flaws - nevertheless comments are solicited.

Use Case: Perform Holography Observation

--------------------------------------------------

CHARACTERISTIC INFORMATION

Description: Move the antenna in a raster scan pattern centered on the source without stopping. Simultaneously collect time-stamped and position-stamped amplitude and phase data. At the end of a scan row be able to stop the observing and perform system calibrations. Be able to start an observation beginning at any scan row.

Actor(s): Operator

-----------------------

PARAMETERS

  1. Source Position: This position is tracked (if necessary) to remain at the scan center at all times.
  2. Scan Direction: The coordinate in which the map rows will be acquired. It can be either azimuth, elevation, right ascension, declination, lII, or bII.
  3. Map Row Size: The map dimension of the coordinate given by Scan Direction. This excludes the antenna movement required to reach the Scan Velocity.
  4. Map Column Size: The map dimension orthogonal to the coordinate given by Scan Direction.
  5. Number of Rows: Number of passes to be made across the map in the Scan Direction. This must be an odd number typically between 29 and 513, inclusive. An odd number places the center row on the source position.
  6. Data Integration Time: This sets the time between each data point, and is expected to be 10ms or longer.
  7. Scan Starting Row: The row number at which to begin the observation. Rows are numbered beginning with zero.
  8. Scan Velocity: The rate at which the antenna is to be moving during data collection (arc-second per second).
  9. Rows per Calibration: The number of observation rows between periods spent acquiring calibration data.
  10. Calibration Integration Time: The time spent acquiring boresight calibration data per boresight calibration observation.
  11. Rows per Pointing: The number of observation rows between periods spent acquiring pointing data.
  12. Pointing Integration Time: TBD depending on the pointing calibration method.

Use Case: Collect Holography Data

--------------------------------------------------

CHARACTERISTIC INFORMATION

Description: Collect amplitude and phase data to include a time and position stamp. Once setup, the collection can be started and stopped at arbitrary times.

Actor(s): Operator

-----------------------

PARAMETERS

  1. Integration time
  2. # of integrations

----------------------------------------

MAIN SUCCESS SCENARIO

  1. Setup a clock routine to interrupt at 10 to 100 millisecond rate.
  2. Wait for a clock interrupt.
  3. Signal system time tag, phase, and amplitude are available.
  4. Downcount integrations done.
  5. If more integrations to be done repeat

----------------------

EXTENSIONS

  1. The integration has been cancelled.
  2. Exit the integration loop.

----------------------------------

OPEN ISSUES (optional)

  1. Poll or interrupt
  2. Is dump rate a parameter? What is the hardware interface?
  3. Do we really care if the integration is interrupted?
  4. Where do we want to check for quit an integration?
  5. Where is blanking handled? At the data source or at a higher level?