Getting Started Documentation Glish Learn More Programming Contact Us
Version 1.9 Build 1367
News FAQ
Search Home

NOTE 219 - AIPS++ Mosaicing development plan

Tim Cornwell

Draft 1997 April 30

A postscript version of this note is available (100kB).

Contents

Purpose

This document describes a phased plan to realize the Mosaicing specifications as described by Holdaway et al. (AIP++ Specification memo 120) (hereafter HSCR). The concentration here is on the grouping of work to be done. For any necessary clarification of the definition of the work, see HSCR.

Current status

sky currently (April 1998) provides simple mosaicing capabilities. Specifically, the program can correct for VLA and WSRT primary beams in either a linear mosaic or via a clean-based algorithm. In the clean-based algorithm, the minor cycles are performed using an average PSF, and major cycles using the fully correct PSF (including any time-variation). Both these capabilities result from an initiative to demonstrate that the synthesis framework is capable of supporting mosaicing data reduction.

A significant design decision in sky is that all deconvolution is performed inside sky. This is contrary to the model used in Miriad mosaicing, whereby the dirty image, PSFs and primary beams are written out and processed separately in another program. The rationale for the choice not to do this in sky is that the ancillary information (arising from the MeasurementSet) that must be carried along may be quite complicated (internally the VisibilityIterator class is used to encapsulate this information).

Other points relevant to HSCR:

Phase I: Improve sky

To build on the current capabilities of sky, we need to do the following:

A suitable concluding milestone for this phase would be to able to make mosaics from a very large spectral-line mosaic dataset from WSRT. Another milestone would be to correct known assymetries in the primary beam model e.g. the VLA primary beam squint when observing circular polarization on the Sun.

Phase II: Develop Single Dish OTF imaging in sky

Single Dish On-The-Fly data reduction can be accomplished using the SkyEquation formalism but to acheive satisfactory performance when imaging only OTF data, some changes may be required. In particular, a different version of SkyEquation::gradientsChiSquared is probably necessary since a Fourier transform is not required. In the case of mixed single dish and interferometric data, the current gridded transform machine should be adequate.

An important dependency is that MeasurementSet V2 is needed in order to hold OTF data in a reasonably compact form.

A concluding milestone would be to construct an OTF image from 12m spectral data.

Phase III: Simulation capability

Once the changes above have been made, we can move on to develop a simulation capability using the tools refined in the previous work. Specifically, the SkyEquation can be used to provide transforms of models, and the refined PBSkyJones can be used to implement various primary beams in the mosaicing.

I suggest that the simulator be a separate object, with an interface similar in spirit to that of sky i.e. tending towards atomic, low-level operations rather than high-level operations.

VisJones classes for simulating additive noise and gain errors now exist and are used in the current simulator. Some work is needed on an interface for defining observing patterns (such as mosaicing sequences).

Part of the simulation tools should be devoted towards examining the three measures of accuracy of reconstruction described by Cornwell, Holdaway and Uson (1992):

Dynamic range
: Peak on-source brightness divided by rms off-source rumble.
Fidelity
: Median of on-source brightness divided by error in reconstruction.
Visibility SNR curve
: Radial average of visibility divided by rms error in reconstruction.

A concluding milestone would be to simulate a simple mosaiced observation from one of the consortium telescopes, and make an image using sky, and evaluate the imaging performance. As a check on performance, the simulation should be done for separate time-variable pointing errors per antenna.

Phase IV: Mosaicing tools

There is a need for a number of basic tools for aiding mosaicing.

Phase V: Advanced mosaicing tools

Development of advanced mosaicing tools will require the simulation capabilities and tools developed in phases III and IV.

Scheduling

The phasing is not strict. Phase I and II can proceed concurrently. Phases II, IV can be interchanged. Phase V obviously must come last.

I'd estimate phases I-IV are several FTE-months of effort each. Phase V is probably substantially longer, maybe 6 months. Hence the entire effort is probably 18-24 FTE-months. Phase II should be done by someone familiar with OTF data, phase III requires a moderate but not sophisticated understanding of interferometry, and the other phases require someone with a deep understanding.


next up previous
Please send questions or comments about AIPS++ to aips2-request@nrao.edu.
Copyright © 1995-2000 Associated Universities Inc., Washington, D.C.

Return to AIPS++ Home Page
2006-03-28