Typical use

The processing of mosaics for NOEMA is essentially similar to that of single fields. There are only two small changes

Creation of uv table

For NOEMA data, a mosaic UV table should be created using the /MOSAIC option of command TABLE in CLIC. For ALMA data, this is implicitely handled by the FITS to UVT conversion. In case UV data files come by separate pointings, UV_MOSAIC can consolidate them into a single UV table.

Imaging

is done through UV_MAP as for a single field. However, the process is different. The command takes into account the various fields, the primary beams, and select an optimum projection center (phase center). The later may need to be specified by the user using the MAP_CENTER string, or as argument to UV_MAP, of, for the SAULT method, by command MOSAIC.

Deconvolution

is also similar, but not all algorithms are available: MX, SDI and MRC do not work for mosaics. The change of behavior of the CLEAN algorithms is visualized through the change of prompt from IMAGER> to MOSAIC>.

Compared to single-dish, a few additional variables are used to control mosaic creation and deconvolution. These are handled through a number of MOSAIC_... variables

MOSAIC_BEAM

The truncation level of primary beams when doing the individual field combination, in fraction of peak, so in range[0,1].

MOSAIC_FIELD

The map size around individual pointings in the SAULT method, in numbers of FWHP. A typical value of 4 is often appropriate. Very high dynamic range mosaics may require somewhat larger values. Limited S/N mosaics can accomodate smaller values, though probably not less than 2.

MOSAIC_GUARD

The guard band size beyond the mosaic region, in numbers of FWHP. The default value of 2.5 is in general appropriate. However, mosaics with confusing sources near the edge may require a larger fraction of a primary beam

MOSAIC_SEARCH

The minimum fraction of a primary beam below which no Clean component is searched for. A default value of 0.2 is often appropriate.

MOSAIC_TRUNCATE

The minimum fraction of a primary beam cumulated response below which no image restoration is performed. Below this threshold, the Clean image is blanked. A default value of 0.2 means the noise is 5 times larger at the edge than at center...

The first 3 variables above apply to the map making process ( UV_MAP and UV_RESTORE) while the last 2 apply to the deconvolution ( CLEAN). In addition, there are 2 information variables: the logical MOSAIC_ACTIVE indicates if Mosaicing is active, and the character string MOSAIC_MODE indicates the Mosaic method (NONE, GUETH or SAULT).

Finally, note that the mosaic deconvolution produces sky brightness images ( SKY variable) while single-field deconvolution produces images attenuated by the primary beam. IMAGER makes no specific assumption about the uv coverage of individual fields. However, it uses a single Clean beam in the deconvolution, so Mosaics where fields have widely different uv coverage may not conserve flux properly. Mosaicing deconvolution will work better if all fields are equivalent in uv coverage and noise level.

A mosaicing session would thus just be like a single-field imaging:

       1 read uv gag_demo:demo-mosaic
      (2) mosaic [args ...]
       3 uv_map
       4 hogbom /flux 0 10
       5 fit /jvm
       6 uv_restore
       7 show sky
       8 write * demo

Comments:

Step 1

Read the UV table

optional Step 2

Turn to the SAULT method

Step 3

Image the mosaic

Step 4

Deconvolve

Step 5-6

Optimize residuals (see Sec.7.5)

Step 7

Look at the result. The result is in SKY.

Step 8

Save the result SKY, and the intermediate files ( BEAM, DIRTY, PRIMARY).

However, mosaics can be huge and require more memory than available (see Section 14). To overcome this issue, IMAGER provides the script @ image-mosaic⁷ that splits the UV_MAP step into slices that fit into memory. The user can then read the resulting images and deconvolve them, eventually by blocks of channels if needed (in particular when a uv_restore step is desired) using a similar logic.