130.text

From: Dave Shone
Subject: YegSets, Telescope models and Calibration
Date: Tue, 7 Apr 92 09:01:49 EDT

The Relationships between YegSets and Telescope Models
======================================================

The part of the Green Bank scheme of "high-level" objects which is least
clear is the nature of the associations between IntYegSets and IntTelescope
Models (I shall confine myself to the interferometric case).  Perhaps
we can clarify this by considering the ways in which we wish to use these
in calibration and self-calibration.

It is often convenient to think of calibration as a process where a
single IntTelescopeModel is updated (typically as part of a
self-calibration, inversion/deconvolution iterative loop, or where
many target source observations are to be calibrated using a single
set of corrections).  In this case, it may be natural to have a single
IntTelescopeModel associated with a particular IntYegSet, so that the
IntYegSet is always consistent with the TelescopeModel; thus the
YegSet would be virtual, and a change in the state of the
IntTelescopeModel would be reflected in the IntYegSet.  Such an
IntYegSet would be created using the "Apply" (or "Correct") method of
IntTelescopeModel, given an existing IntYegSet (and parameters for the
Apply method, such as interpolation parameters).

The YegSets themselves can be regarded as "views" or "filtered views"
of some underlying data:

                                  _________________________________
                                  |IntYegSet ys1C = tm1.Apply(ys1)|
                                                 | |
                                                 | |
               _______________          _________| |_____
               |IntYegSet ys1|         |IntTelModel  tm1|
                   | |                  ---------| |-----      
                   | |                           | |
              _____| |___________________________| |______
              |  Underlying Data (FITS blob/YegSet (?))  |
              --------------------------------------------


The following piece of pseudo-C++ illustrates the use of the ideas above:


	IntYegSet ys0;			// Calibrator YegSet;
	IntYegSet ys0M;			// Model YegSet for calibrator;

        IntYegSet ys1;			// Target YegSet
	   :
	   :
	IntTelescopeModel tm;		// Telescope Model;

	IntImagingModel iim;		// Imaging Model;
	   :
	   :
// Initial calibration and imaging; assume some model of calibrator exists or 
// has been determined:

	tm1.Solve(ys0, ys0M);		// Determine gains etc.;

	IntYegSet ys1C = tm.Apply(ys1); // Create new "corrected" YegSet;
					// corrections are actually applied 
					// "on the fly" when ys1A is used;

	Image map1 = iim.Invert(ys1C);	// Make a map;
	   :
	   :				// Probably do some deconvolution;
	   :
// Self Calibration:

	IntYegSet ys1M = iim.Predict(map1, ys1); // Predict model yegs;

	tm.Solve(ys1, ys1M);		// Determine revised gains etc.;

// Now we can remake the map with ys1A; the revised gains will be
// applied "on the fly":

	Image map1A = iim.Invert(ys1C);
	   :
	   :

Notes:

1) It is possible that many YegSets would be associated with a particular
   TelescopeModel, in which cases changes would be reflected in all of
   the YegSets.

2) There must be an association between the corrected YegSet ys1C,
   the Telescope Model tm1, and the original YegSet ys1.  The latter are 
   required to exist while ys1C exists, although if we regard all of these 
   objects as handles to something else, we can use a reference counting 
   mechanism to ensure we don't destroy anything we need to keep.

   The user of these objects must be aware that ys1C is associated with
   tm1, in order to know which Telescope Model must be modified to change
   the calibration of that YegSet.  This association is made when ys1C
   is created using tm1.Apply().  However, the user need not be aware of
   the association between ys1C and ys1.  In fact, this association could
   be regarded as arising because the objects are simply different "filtered 
   views" of the same underlying data.


In addition to the calibration strategy outlined above, it may be desirable
to calculate and apply a sequence of Telescope Models, thus preserving
the intermediate results.  The following pseudo-C++ illustrates this:

	IntTelescopeModel tm1, tm2, tm3;
	IntYegSet ys1;
	IntImagingModel iim;
		:
		:
	IntYegSet ys2 = tm1.Apply(ys1);	// Apply a succession of
	IntYegSet ys3 = tm2.Apply(ys2);	// Telescope Models;
	IntYegSet ys4 = tm3.Apply(ys3);

	Image mapA = iim.Invert(ys3);	// Make a map;
		:
		:
	tm2.Solve(...);			// Redo one of the calibration steps;

	Image mapB = iim.Invert(ys3);   // Make new map.  The new intermediate
                                        // calibration will be applied
                                        // automatically;


Summary
=======

1)  YegSets may be associated with a Telescope Model, in which case the
    Telescope model is considered to be applied, probably "on the fly".
    Such YegSets are created by using the Apply method of Telescope Model.

2)  If a YegSet has no Telescope model, then raw values are presented
    to the user of the YegSet.

3)  Multiple YegSets may be associated with the same Telescope Model,
    in which case a change to the Telescope Model is reflected in all
    the YegSets.

Unresolved issues:

1)  Should we distinguish between virtual and real YegSets, in order to
    produce a "new copy" of the data? e.g.,:

	ys2 = tm.Apply(ys1, VIRTUAL); // Make a virtual YegSet;
        ys3 = tm.Apply(ys1, REAL);    // Make a new, calibrated copy;

    In practice, the VIRTUAL/REAL option would be passed in with other
    parameters for Apply.

2) Should the Telescope Model have a "default state" so that a user
   may access uncalibrated data without using the original?