Version 1.9 Build 1556

News	FAQ
Search	Home

Next: Comments on the design process Up: The Generic Instrument: III Design of Calibration and Previous: Examples

Subsections

Discussion

Scalar

A scalar version of the formalism is needed to handle calibration and imaging of e.g. RR alone, or RR, LL to I, V.

Weights

We need to introduce true weights and keep track of the covariance structure, at least in the visibility domain.

Persistence

This design is based upon the observation that calibration and imaging are best viewed as activities involving three separate categories of things:

1.: A source of data (the MeasurementSet in AIPS++),
2.: A method of interpretation (the SkyEquation and VisEquation ),
3.: Tools used in the interpretation (methods and data in the Jones matrices and SkyModel.)

All these things are best modelled explicitly as classes. What then does one store? And where? And how is the connection between the various elements to be remembered? We can legitimately regard these as questions for higher level design. However, it is probably worth a few words. We can assume that each of the components will be persistent (through AIPS++ tables - see next item). Thus the major thing to be remembered is the connection between the VisSet the SkyModel the VisJones the SkyJones etc. We think that since this association is one major role for the SkyEquation and VisEquation , it makes sense to make these persistent.

Higher level organization

We have concentrated on how these various classes inter-relate and we have omitted discussion of how the classes relate to other parts of AIPS++ and to the User Interface. By longstanding policy, the data in the calibration classes should reside in AIPS++ tables. Each such AIPS++ table should be made available for manipulation and plotting by the user in whatever way is deemed appropriate. Furthermore, the classes described here are sufficiently high level that the user will want to use the methods directly as envisaged in the Tasking design. One can then envisage high level algorithms being possible at, for example, the Glish script level, just as spelled out in the User requirements.

The design of overall calibration and imaging is described in a subsequent memo in this series.

Iteration order

Different algorithms may require different sort orders. In AIPS++, sort order of the data is regarded as responsibility of the Table system. Iteration order will therefore be specified by the solve method via construction of the appropriate VisIter. We also envisage formation of transient tables by a solve method to allow selection of the data, by, for example, calibration algorithms that solve for the gain every 5 minutes in a 8 hour observing run.

Different telescopes

The historically thorny question of whether a MS contains data from more than one telescope has been finessed in a particularly sweet way. As long as the data obeys the SkyEquation and VisEquation it belongs in a single MS, and it makes no sense to require that, for example, VLA and WSRT data reside in different MSes. Having said that, we should recognize that each observatory is likely to require different calibration strategies for a given telescope. This level of observatory dependence could be quite thin, and implemented via Glish scripts, for example. Another important level of observatory dependence can occur in some of the classes themselves. Redundant spacing calibration would presumably be implemented by WSRT internal to a classes similar to GJones shown above. Similarly, the VLA would be interested in implementing some of the wide-field imaging algorithms needed for low-frequency imaging with the VLA. These would be implemented in special versions of the FTCoh and IFTCoh and a SkyModel.

Composition of Jones matrices

A telescope formed by adding the voltages of the elements of an array is called a tied array. Support for tied arrays is possible in the SkyEquation and VisEquation if a Jones matrix object (most naturally the E matrix) actually just sums the relevant Jones matrices of the array elements.

Further optimization for speed

The FFT and gridding classes limit the speed available. Since these are encapsulated in the classes FFTCoh and IFFTCoh, re-implementing these is a clearly separable task. It would be worth investigating the following (perhaps disjoint) possibilities:

Implement gridding via FORTRAN code.
Allow gridding and FFT of any object that can be scaled with complex numbers ax + b. This would allow FFT of a frequency spectrum of StokesVectors.

An explicit performance goal should be set soon to test against. To be meaningful, this probably requires a scalar version.

Simulation

Simulation of data is vital but is quite straightforward. We need a tool to construct a template MeasurementSet. If a test image is then generated, the predict service of the SkyEquation and the apply service of the VisEquation can be used, togther with whatever calibration effects are desired, to form a set of predicted coherences. Another SkyEquation or VisEquation can then be constructed, with the usual calibration objects, and a reconstruction attempted. This is available in the program simulator.

Completion of the classes

We have not yet implemented significant versions of MJones ACoh or XCorr. These seem quite straightforward.

Inter-relatedness of classes

The calibration classes can be inter-related. For example, the correction for channel averaging decorrelation in the VLBA FX correlator depends upon the delay found in a global fringe fitting procedure (via a VisJones solve). There are two ways of addressing this: either implement the correction via an MJones and allow it to talk to the global fringe fitting VisJones or allow VisJones to report to VisEquation via a 4 by 4 matrix for a given baseline. It is not clear which one of these should be preferred.

Versioning and related issues

One presumably wants to be able to do various things with calibration objects e.g. copy, edit, delete, attach version numbers, etc. We regard these as higher level operations. We will discuss these in a subsequent memo.

Next: Comments on the design process Up: The Generic Instrument: III Design of Calibration and Previous: Examples Contents