Implementation

The typical processing of PdBI mosaics has four main steps

Creation of $uv$ tables

The convention inside MAPPING is that the visibilities associated to one field of the mosaic are grouped in one $uv$ file whose name is made of a generic part plus the field number. For instance, a mosaic of 7 fields would imply the presence in the same working directory of 7 $uv$ table, e.g. demo-1.uvt, demo-2.uvt, demo-3.uvt, ... demo-7.uvt. This is the user responsibility to enforce this at the time of creation of the $uv$ table in CLIC.

Imaging of individual fields

Each field ($uv$ table) must then be individually imaged using the standard UV_MAP command. This is in this step that the fields are put in the larger framework of the mosaic, i.e. they are placed in an image large enough to contain the whole mosaic. This implies that

1. The user must feed the size of the final mosaic through the map_size sic variable because the UV_MAP command has no information about the mosaic as it works on one field after the other.
2. The projection (i.e. phase) center will have to be shifted in this step with the use of the UV_SHIFT, MAP_RA and MAP_DEC variables. Indeed, the observing setup of a mosaic at PdBI implies that each field has its own projection center (the sky tracking direction of the field). The new value of the phase center will be stored in the A0 and D0 values of the header while the RA and DEC values will keep the tracking direction of the observation. Indeed, the latter information is needed to correct for the primary beam attenuation and to form the mosaic. The new phase center can be arbitrarily chosen but it is recommended to choose it around the middle of the mosaic.

At the end of this step, the dirty beams and images must be stored in files (e.g. demo-1.beam, demo-2.beam, ... demo-7.beam and demo-1.lmv, demo-2.lmv, ... demo-7.lmv) in the same directory.

Creation of the mosaic

The MAKE_MOSAIC task linearly combines the dirty images using the least square formula 5.3 into a single dirty image named demo.lmv and it creates a weight image ($1/\sigma^2$) stored in the demo.weight file. In fact, to simplify the deconvolution bookkeeping, the demo.lmv contains only the numerator of formula 5.3. As the denominator is equal to the weight image, formula 5.3 can easily be retrieved by dividing the dirty image by the weight image. *** Is this fully true? JP *** The MAKE_MOSAIC task also gathers the different dirty beam as different planes of the demo.beam file. Finally, it creates a data cube of primary beams (demo.lobe). The four files created at this step are needed during the deconvolution. Two input parameters of the MAKE_MOSAIC task are important for mosaicing: the primary beam width (FWHM), and the truncation threshold of the primary beam. It is recommended to use a relatively high value for this threshold, typically 0.2, to avoid contaminating adjacent field in case of pointing errors.

Deconvolution of the mosaic

The HOGBOM, CLARK and SDI variants of the CLEAN algorithm has been adapted to treat mosaics. The same commands are used to deconvolve a single field or a mosaic. The change of behavior of the CLEAN algorithms is visualize through the change of prompt from MAPPING> to MOSAIC. The toggle from single field to mosaic is done by the MOSAIC command. Note that the use of the READ PRIMARY command also automatically switch on the mosaic mode. All standard control variables for a single-field deconvolution control the same aspect of a mosaic deconvolution. Two additional variables are used for mosaic deconvolution

SEARCH_W

*** ? JP ***

RESTORE_W

*** ? JP ***

Finally, note that the mosaic deconvolution produces sky brightness images while single-field deconvolution produces images attenuated by the primary beam.

An additional subtlety of the current MAPPING implementation of mosaicing is that MAPPING assumes that the individual fields of the mosaic have similar noise level. This is why combining two mosaics observed at different moments is not straightforward.