Version 1.9 Build 1556

News	FAQ
Search	Home

Next: MeasurementModel Up: The Dwingeloo `UVCI' Design AIPS++ Implementation Note 181 Previous: Image-Plane Representations

Subsections

MeasurementSet Correction (Calibration) and Corruption

A Corrector is an abstract base class for objects which create a new MeasurementSet from an existing one, correcting (or corrupting⁷) the data in the process. This correction will typically be applied ``on-demand'', but a physical copy may be made instead if desired. In the case where correction is being applied on-demand, the Corrector needs to inject the necessary machinery into the MeasurementSet to do this⁸.

The Corrector will normally modify values in existing columns. However it could also add or delete new columns, or add and delete rows⁹. Columns which are unaffected by a particular correction are generally just forwarded to the underlying Table, however this policy is up to the particular Corrector.

Corrections may be nested arbitrarily. That is, a correction may be applied to a MeasurementSet which is itself a corrected MeasurementSet and so on. As shown in the next section though, typically a ``multi''-corrector object will be used instead.

We believe that with our Corrector classes, we have achieved our fundamental goal of being able to create and insert new calibrations without having to perturb the rest of the system.

Visibility Correctors

**Figure 2:** Correctors and MeasurementSet.
$\begin{figure} \epsfverbosetrue \epsfxsize=6.0in \epsfbox{uvci-1.ps}\end{figure}$

The great generality of the Corrector base class also implies that it cannot provide much support. The on-demand calibration must thus be implemented by the programmer directly using the Table classes. While this is not particularly difficult, it can be simplified even further by limiting the possible corrections which can be applied.

Thus we introduce a new abstract base class, the VisibilityCorrector. To create a new type of Visibility Correction, the programmer merely needs to define two abstract member functions:

applyVis(Visibility \&data): This member function corrects (corrupts) the Visibility object "data". Typically it uses the state in the Visibility object (e.g., time) to look-up some correction parameters, then it modifies the Visibility in some Corrector-dependent fashion.
Vector<Bool> correctedFields(): Returns a Vector<Bool>, with positions which correspond to the columns that are actually corrected set to True. While a member such as this isn't strictly necessary, it is used to optimize access to columns which aren't actually corrected.

We have implemented two concrete classes derived from VisibilityCorrector.

ReceptorGains: The current version of this corrector supposes that all feeds and receptors on an antenna share a single complex gain, which varies with time. A simple linear interpolation is performed.
VisibilityCorrectorSequence: For efficiency, and simplicity, this multi-corrector class was created. It contains a series of (any type of) VisibilityCorrectors within itself, and its applyVis() function merely passes the incoming Visibility object through all the applyVis() members of its contained correctors. Its correctedFields() member of course OR's all its contained correctors results together.

Solvers

A Corrector is a class which applies some correction to a MeasurementSet. A ``solver'' is a generic name for an entity (class, function, or program) that creates a particular Corrector, i.e., sets its state.

These ``solvers'' are not a software class. They cannot be meaningfully polymorphic (you cannot solve for a calibration without knowing what it is).

It may still prove useful to create a polymophic interface to Solvers for which the detailed parameters can be set up in advance, e.g., to allow them to be used in general selfcal loops.

Corrector Persistence

We have chosen a simple scheme for Corrector persistence. Every Corrector has a member function to save its state into a Table keyword. Similarly there is a function to restore a Corrector from a Table keyword.

Thus the Corrector only knows how to save and restore itself. The policy of where this should be done is left to another entity. At present, the only such policy is the default MeasurementSet corrector described above.

Whence the Telescope Model?

The reader may be wondering about the difference between the Corrector class described here, and the ``TelescopeModel'' class which had previously fulfilled many of the same functions. In brief:

1.: The Correctors do not have a polymorphics solve method, for reasons described previously.
2.: The Correctors are not an alternative store for information available in the MeasurementSet.

Thus the present Corrector object corresponds to the ``apply'' part of the previously envisaged TelescopeModel.

It seems to us that a TelescopeModel class might still be useful for simulating a telescope, however we have not pursued this.

Next: MeasurementModel Up: The Dwingeloo `UVCI' Design AIPS++ Implementation Note 181 Previous: Image-Plane Representations Contents