 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1556 |
|
The design of the Image is unchanged from [Gle94]. It consists of a data hyper-rectangle with associated coordinate information, and methods for iterating through it.
Besides an Image it is often required to have a, possibly non-gridded, estimate or model of a sky brightness distribution, for example in the predict method of the MeasurementModel (described later). In particular, we want to be able to sample the brightness in both the Image and Fourier planes, and for the latter we want to admit the possibility of a DFT, which in some circumstances allows for higher precision than gridding the model and performing an FFT.
The class that provides this modeling capability is known as the SkyModel. It was formerly known as the SourceModel. We decided to change its name to indicate that we are not (yet) solving the problem of projecting an astrophysical simulation onto the celestial sphere. Thus our SkyModel is a function of Sky position, frequency, time, and polarization.
Such estimates have traditionally come from a variety of different sources:
Of course one might also want to apply variations to a basic SkyModel -- spectral index effects, faraday rotation, and time-dependent positions (to simulate non-isoplanatic effects).
We break these classes down in two levels, one level for pure computation, and another which handles ``book-keeping'' or policy. Such decompositions are often fruitful.
In particular, we have base class functions which model multi-dimensional mathematical functions, with and without Fourier transforms. These classes are used by the SkyModel classes, which add coordinates, polarization, and a default grid.
The major function-like base classes classes4 are:
Functional<Domain,Range>
Array<Domain>,
placing the results into an Array<Range>5.
FunctionND<Domain,Range>
Functional<Vector<Domain>, Range>. It adds members to evaluate
itself on a grid, to smooth itself onto a grid, and also to get and
set internal parameters (defaults to no modifyable parameters).
Real and Complex specializations of this class are provided. The Real specialization has a member function to (Direct) Fourier transform itself, yielding a complex function. Besides this DFT member, a FFT global function is available which will FFT a FunctionND onto a grid.
While we anticipate that a great many classes derived from the above may eventually be required, the ones immediately required are:
DeltaFunctions
GridFunction
Other classes we anticipate needing in the relatively short term include classes to augment the dimensionality of a Functional (assume it's constant, apply a bandpass/spectral index, move it), as well as classes related to parameterized mathematical functions (Gaussians and the like). Functional expressions would of course be extremely expressive and convenient.
The SkyModel class is an abstract base class which returns real valued FunctionND objects to represent sky brightness as a function of position, frequency, and time for a given polarization. It also has a Fourier method which returns a complex valued FunctionND.
This Fourier method might use a DFT (if available, and the user has chosen accuracy over speed), otherwise it performs an FFT and returns complex valued GridFunction. Partly for this reason, and partly because gridding a SkyModel to an Image is expected to be a common operation, a default grid is defined for the SkyModel. The SkyModel is only assured of being defined within the confines of the grid. (SkyModels containing very widely separated components will need to have a DFT method implemented).
Since many SkyModels will be constant in time, and possibly frequency, methods are provided for inquiring along which axes a SkyModel is constant.
Presently, the only concrete SkyModel is a very simple one which varies only on the sky, and is instantiated with an abstract base class which returns a FunctionND as a function of polarization (for example, through a matrix multiplication).
While the SkyModel was created for the express purpose of predicting visibilities, we were struck that this class, or one very much like it, might be suitable for use as a generalized image. For example, it appears that a SkyModel which is in turn made up of SkyModels is capable of storing a mosaiced ``image.''
If this view ultimately prevails, a class very much like this one (tentatively named ``SkyView'') would also be a base class for all Image-like classes. In the design process for the SkyModel we played with the idea of a SkyView that has associated information describing its limitations in terms of the multiplicative and convolution `filters' that have been applied in all dimensions. Such a SkyView would be able to handle overlapping 'subViews' and present a combined View.
Presently we are just using an Image to hold the synthesized beams we produce. In the future we will need to allow for beams which are functions of position, time, ....
It seems to one of us (BEG) that a reasonable solution to this problem is to produce a PSF base class whose major method produces an Image6 as a function of position, time, .... That is, it is very much like a SkyModel, only instead of producing a single number at one ``point,'' it produces an entire response function.
Presently we apply no image-plane corrections (e.g., primary beam correction, off-axis polarization, pointing errors, non-isoplanaticity, etc.) These corrections will need to be implemented at some stage, and we need to keep them in mind as the design proceeds as they are often `scheme-breakers'.
There are a number of approaches which are possible:
The last solution is pleasingly symmetric, however at this time we have no other reason to choose one solution over another. For the most advanced corrections we may be forced into a Corrector-like approach. Some effects (like time variable pointing errors) cannot really be corrected for, but models can be corrupted with them, allowing an iterative solution scheme.
