PMAP <reflong> <reflat> <refsystem>
/MAPSIZE_PMA <lon> <reslon> <lat> <reslat> <scan direction>
/TIME_PMA <Ton> <Toff>
/ON_OFFS <n on's per off> <f: on first>
PMAP sets up a rectangular raster with one scanning axis (<scan direction>) and one stepped axis perpendicular to the scanning direction. The /MAPSIZE_PMA adverb defines the sizes and steps and the scanning direction which is determined by the keywords ``LAM'', ``BET'', ``AZM'' or ``ELV'' after the first four /MAPSIZE_PMA parameters. Usually, one uses either ``LAM'' or ``BET'' which are equivalent to the two axes of the currently selected coordinate system (e.g. for equatorial LAM R.A., BET Dec., for galactic LAM l, BET b). Descriptive coordinate systems with a position angle (e.g. SBAS 1 D)) can also be used and LAM / BET correspond to the new axes.
Figure 1 shows a sample PMAP command and the resulting map size and point distribution. It has been centered on (-30'',5'') relative to the source origin using the SET OFFSET command. The scanning occurs along the lambda axis. It is more efficient to scan along the longer edge of the rectangle unless the total time per row or column exceeds the limits set by the stability of the atmosphere (on the order of 10 to 100 seconds depending on weather conditions). The spacing along the scanning axis (the ``dump distance'') should be a fraction of the beam (here 5'') to avoid smearing. Recent calculations by [Beuther 1999] show that half beam spacing leads to about 4% widening while quarter beam spacing results in a beam that is only 1% wider than for raster mapping.
The spacing perpendicular to the scanning axis should be on the order of or smaller than half the beam width to ensure full sampling (here 10''). This map would consist of 12 subscans (6 ``Off's'' and 6 ``On'' scan lines). To first explore a large region, one can use a one beam spacing perpendicular to the scanning axis, rather than using a large dump distance which would cause unrecoverable beam smearing.
The ``On'' time (Ton) is the time per spacing along the scanning axis, also called the ``dump time''. Currently, the SMT OTF dump time must be 2 seconds or longer because of limitations in the VAX / Camac computer and control system. If you use all 6 backends simultaneously, you should increase the dump time to 3 seconds so that the VMS calibration software (CHEF Online Display) can keep up with the data reduction. It will then take about the same time to calibrate the data that it takes to observe it. For the future UNIX / PC / VME system faster dumping (about every 100 milliseconds) is planned to speed up the individual OTF maps in order to minimize atmospheric effects and pointing and possible tracking errors. We are also working on a Unix version of CHEF to speed up the data calibration.
The total ``On'' time per scanning row or column is <Total on time> = <Ton> * <lon> / <reslon>for scanning in LAM and <Total on time> = <Ton> * <lat> / <reslat>for scanning in BET. The time per dump <Ton> should be chosen such that the total time per subscan is on the order of 10 to 100 seconds depending on atmospheric conditions.
The ideal ``Off'' time would be the total time spent per independent ``On'' (i.e. all dumps within one beamsize) times the square root of the number of independent ``On's'' between two ``Off's''. For example, if you want to scan 150 arc-seconds at 345 GHz (24'' beam) with 8''dump distance and 2 seconds dump time, you will integrate for seconds per beam and you will have Nyquist-sampled positions. The necessary ``Off'' time is thus 6 seconds = 21.6 seconds.
The software does not yet know about beam sizes and therefore currently calculates the ``Off'' time as <Total on time per subscan> sqrt(<n on's per off>) which is too long. For the time being, you should specify the ``Off'' time manually using the above formula.
The maximum time for one map (including subscan overheads) should be on the order of 10 to 20 minutes. Then, a new calibration is necessary to compensate for variations in the atmosphere and the receivers and for changes in elevation. One should observe several OTF maps of the same region if the lines are too weak to be detected in one scan. It is also recommended to alternate scanning directions for subsequent OTF maps in order to randomize possible tracking errors (although our tests so far indicate that tracking errors are usually only of the order of a few 0.1'').