2.4 How to Prepare a Mosaic File

2.4.1 General Mosaic Strategy

Mosaic observations use a standard schedule file and an additional file, called the mosaic file, which lists the positions of the mosaic field centres. Up to 2048 fields can be specified in a single file. This mosaic file must consist of one line per pointing centre in the mosaic pattern. Lines beginning with the # character are ignored and can be used for comments.

The general mosaic file format is:

# Comments .... ignored by the software
#

The items in each line are: d(RA) is the offset Right Ascension of the pointing centre in “degrees of polar rotation” from the reference position. For example, d(RA)~=~+15.00 will move +1 hr in RA at all declinations. d(DEC) is the offset declination of the pointing centre in degrees from the reference position. eg d(DEC)~=~+1.000 will move the pointing centre one degree north. INT is the integral number of integration cycles to spend on each pointing centre. The ‘$’ is a prefix to the field name, and indicates that scans will follow in the order as they are listed in the mosaic file. The name of the field, $FIELD_n, must be different for each pointing centre and should be \leq 9 characters (naturally, $ can not be used as a first character of the field name). Note: The UVSPLIT task in MIRIAD needs the field names to be different by ‘_n’, where n is an integer. This file should be named mosnam.mos, where mosnam should be a short name that describes the mosaic.

To include a mosaic in a schedule file, insert a scan and set:

• Source to the name of the mosaic file, excluding the .mos extension, ie. mosnam
• ScanType to Mosaic
• the RA and Dec to the reference position for the mosaic, ie. the position that all the mosaic field centres are offset from
• ScanLength to the minimum time to be spent doing the mosaic, and must be greater than three integration cycles

All other scan settings have their usual effect, including the Pointing mode, and the observing frequencies. The mosaic file must be saved in the /atca/mosaic directory on XBONES so that CAOBS can locate it during the observations. The mosaic file name should be completely in lowercase letters, even if the corresponding source name in the schedule has uppercase letters, as CAOBS will report that the mosaic file could not be found unless it has an all-lowercase file name.

The mosaic scan will be observed repeatedly until the time specified by ScanLength has elapsed, after which the mosaic scan will continue until the last specified field centre is next observed. In this way, the mosaic sequence will always be executed an integral number of times, regardless of ScanLength.

The following example shows a mosaic file specifying a four pointing centre pattern on a 0.25^\circ grid. Note that the RA offsets are coordinate increments not sky distances.

The scan in the corresponding schedule file might have the parameters:

With these settings, and with the default integration time of 10 seconds, the four pointing centres will be observed every 80 seconds, and the pattern will be repeated 23 times during the scan.

2.4.2 On-the-fly Mosaicing Strategy

On-the-fly (OTF) mosaicing has a couple of important differences to general mosaicing, which will be described here. Most importantly, although the mosaic pattern should be broadly the same – the hexagonal pattern is still the optimal sampling – the order of observation should be such that the telescope scans in a straight line for as long a distance as possible.

During an OTF mosaic, the phase center follows the mosaic points as specified, and the pointing center moves continuously across the pointings. In effect the primary beam of the antennas becomes elongated (to 1.5 beams) in the scanning direction.

To satisfy proper sampling of the sky, the antennas should not move by more than half a beam per integration cycle, so the spacing of pointings in the mosaic file should be the same as before. The way this is implemented in CAOBS assumes you are scanning in rows or columns, the direction of scanning is inferred from the next point. At the last point of a row or column the previous direction is maintained to complete the scan. One extra point, marked with the name TURN, needs to be specified at the start of the next row/column, to allow for the antennas to change direction and scan at the correct speed again. As an example, here is a 3x3 grid around 1934-638:

 0.0000   0.00    2  $@1934-on C
-0.1812  -0.16    1  $TURN-10 
-0.1812  -0.08    1  $1934-11 
-0.1812   0.00    1  $1934-12 
-0.1812   0.08    1  $1934-13 
 0.0000   0.16    1  $TURN-24
 0.0000   0.08    1  $1934-23 
 0.0000   0.00    1  $1934-22 
 0.0000  -0.08    1  $1934-21 
 0.1812  -0.16    1  $TURN-30 
 0.1812  -0.08    1  $1934-31 
 0.1812   0.00    1  $1934-32 
 0.1812   0.08    1  $1934-33

Note that you can specify a non-scanning position in an OTFMOS file by starting the field name with a "@", like the 2 cycle calibration on 1934-on above. Also note the fields marked with TURN - these are the extra points required at the start of each row/column to give the antennas time to get to the correct position and scanning speed. They should be discarded when processing the data. To use the OTF mosaic mode, specify a scantype of OTFMos in the web scheduler and put a mosaic file like the one above in /atca/mosaic/ on XBONES.

The primary advantage of OTF mosaicing over regular mosaicing is its speed in covering a large area of sky, making it possible to get good uv coverage of a large field in a single observing run. It will not usually provide any better sensitivity than a carefully crafted regular mosaic.

Although OTF mosaicing is most useful at low frequencies where the slew time between mosaicing points are a more significant fraction of the total integration time, this mode could also be used for mm observations by using bin mode and moving the antennas by e.g., 16 beams in a single integration with 32 time bins. The MIRIAD program ATLOD will need some work to properly record the phase center and pointing center in this case.