Correction for Velocity Information

In the case of a Doppler tracked observation, the sky frequency slowly changes with time due to the motion of the observatory with respect to the rest frame chosen. Various velocity components need to be taken into account for a particular rest frame. For example, in the Local Standard of Rest (LSR) frame, three components are included in the Doppler tracking:

Components            Correct for                        Speed

Diurnal               Observatory motion due to          < ~0.5 km/s 
                      the Earth's rotation      

Annual                Earth's motion around the          < ~30 km/s
                      Sun

Solar motion          Solar motion w.r.t. the LSR          ~20 km/s

In order to reduce the observed velocity with respect to the rest frame, one needs the information of the sky frequency and the Doppler velocity projected in the direction of the source in addition to the rest frequency. At the SMA, two observing modes have been supported: 1) non-planet mode and 2) planet mode. For the non-planet observing mode, the SMA supports on-line Doppler tracking for spectral line observations, i.e. the observatory continuously changes the observing frequency to account for the effect of the observatory motion with respect to the rest frame. However, a sky frequency with a fixed value at the central channel of a given spectral chunk is stored in the archived SMA data. The sky frequency in the SMA data has been corrected for a part of the tracked Doppler velocity (the diurnal term and a part of annual term). Therefore, the sky frequencies given in the SMA data appear not to follow the convention of Miriad . For the BIMA array, on-line Doppler tracking was supported and the Doppler tracked frequency was stored in the data header, slowly varying with time (Miriad Users Guide for BIMA, version 1.0 March 1991, printed: August 3, 2004; and inline note in uvindex.for by Mel Wright). For the ATCA, the observatory does not Doppler track. The channel-smearing problem due to the Earth motion is handled in Miriad by converting the frequency channels to velocity channel (Miriad Users Guide for ATCA by Bob Sault and Neil Killeen, 19 Mar 2004). Regardless of whether the observatories Doppler track or not, a particular velocity component will remain in the same velocity channel using the linetype in Miriad :

line=velocity,nchan,start,width,step

The usage of the Miriad linetype requires that the sky frequency and the Doppler velocity provided in the data are self-consistent.

In order to use the Miriad software for the reduction of SMA spectral line data, SMA users might consider to recompute velocity information depending on the following three cases. The corrections are particularly important to the observations of narrow spectral lines.

1. Deriving Velocity Information with smalod

In the case that the Doppler tracked source is the only interested target source (e.g. SgrB2_N) in one's program (e.g. 050801_04:49:59) and the sky frequency stored in the archived SMA data has been corrected for a part of the Doppler velocity, one may use smalod in the defualt options to derive the proper residual Doppler velocity ( ${\rm\Delta V_{D}}$) for the target source (SgrB2_N):

$${\rm\Delta V_{D} = V_D-V_{SMA},}$$

where ${\rm V_D}$ is the tracked Doppler velocity and ${\rm V_{SMA}}$ is the effective part of the tracked Doppler velocity that has been taken out in the on-line calculation of the sky frequency which is stored in the SMA data. We note that in Miriad the Doppler velocity ${\rm V_D}$ (veldop) is the sum of the radial velocity of the observatory (in the direction of the source, with respect to the rest frame) and the nominal system radial velocity of the source (vsource). Miriad task smalod decodes the radial velocity of the observatory from the information in the SMA archival data header files. The value of vsource is given by users from input Keywords. As long as the value of the uv variable vsource is consistent with veldop in the Miriad data header, the Miriad linetype and tasks will correctly handle the conversion between radial velocity and sky frequency.

Here is the usage of smalod for this case:

  Task:   smalod
  in       = /data/SMAdata/050801_04:49:59/  % name of input file
  out      = smatest                         % prefix of the output file
  rxif     = 0                               % rx id
  vsource  =                                 % the nominal velocity of target 
                                               source w.r.t. the rest frame 
                                               which was applied in the 
                                               online Doppler tracking.
                                               Here we used default value
                                               to set vsource to zero.
  refant   = 6                               % reference antenna
  sideband = 0                               % lower side band
  nscans   = 2,                              % skip the first two integrations

The derived value of the residual Doppler velocity ${\rm\Delta V_{D}}$ corresponding to the stored sky frequency (sfreq in Miriad ) is saved in the Miriad variable veldop in the header of the output Miriad uv data ( ${\it smatest\_rx0.lsb}$ for this case).

To inspect the derived residual Doppler velocity ${\rm\Delta V_{D}}$, one can use smavarplt to plot the variable veldop as function of ut time:

smavarplt vis=smatest_rx0.lsb device=/xs xaxis=time yaxis=veldop nxy=1,1

One should see a constant value across the observing period for all the sources. Keeping in mind, this value is correct only for the Doppler tracked target source (SgrB2_N).

Figure: The value of the Doppler velocity ( ${\rm \Delta V_{D}}$) derived from the SMA archival data header corresponding to the stored sky frequency as function of UT time is plotted. This value ( ${\rm \Delta V_{D}}$) is correct only for the Doppler tracked target source (SgrB2_N).

2. Recomputing Velocity Information with uvredo

Besides the Doppler tracked target source (e.g. SgrB2_N), other sources (e.g. SgrB2_M and sgrastar) might be interested in the observing program. One might need to recompute the velocity information in order to avoid errors in reducing the radial velocities of the sources and to get rid of channel-smearing effect in the synthesized spectral line images due to the errors in velocity.

A patch for handling SMA data has been added into uvredo. The SMA patch calculates the proper residual Doppler velocity ( ${\rm\Delta V_{D}}$) for each of the data records corresponding to the "sky frequency" in the data. Here is the usage of uvredo for using the SMA patch:

  Task:   uvredo
  vis      = smatest_rx0.lsb       % input data
  out      = smatest_rx0.lsbrd     % output data
  options  = smaveldop             % using the SMA patch to
                                     recompute the velocity
                                     information
  dopsour  = SgrB2_N               % the name of the Doppler
                                     tracked source
  doptime  =                       % default using smavel
                                     to calculate the part
                                     of Doppler velocity
                                     that has been corrected
                                     to the sky frequency
  velocity = lsr                   % rest frame

The results on the velocity information recomputed using the SMA patch in uvredo can be reviewed with a plot or a log file using smavarplt:

smavarplt vis=smatest_rx0.lsbrd device=/xs log=log xaxis=time yaxis=veldop nxy=1,1

Fig. 2.4 shows the proper residual Doppler velocities for the sources corresponding to the sky frequency in the data. The numerical values at each of the records plotted can be reviewed from the log file (log). We note that the radial velocity of a planet with respect to the rest frame might significantly change during the course of a long observing track. For the use of non-planet observing mode, planets are used as calibrators with a short observing time on source and the effect due to the motions of planets is ignored.

Figure: The proper residual Doppler velocities ( ${\rm \Delta V_{D}}$) recomputed with the SMA patch in uvredo are plotted for all the sources.

After having the proper residual Doppler velocities corresponding to the sky frequency in the data header, we can safely use the Miriad tasks to reduce the SMA spectral line data.

3. Case without On-line Correction to The Sky Frequency

In the case that Doppler tracking is performed but no on-line corrections are made to the sky frequency, the frequency stored in the data header is the true sky frequency. The frequency in the SMA data is considered to follow the Miriad convention. Then, one needs to simply recalculate the Doppler velocities while loading the SMA data to Miriad using smalod.

smalod in=/data/SMAdata/050101_03:59:50 out=smatest \
  rxif=1 vsource=-30 refant=6 options=lsr sideband=1 nscans=2,

With options=lsr, the Doppler velocities can be calculated for each of the sources and are stored in the Miriad variable veldop. Alternatively, one can recalculate the Doppler velocity with options=velocity in uvredo:

uvredo vis=smatest_rx1.usb out=smatest_rx1.usbrd
       options=velocity velocity=lsr

4. Reset The Value for The Radial Velocity (vsource)

We note that uvredo recomputes only the radial velocity of the observatory in the direction of the source, with respect to the rest frame and resets vsource to be zero, i.e. the nominal radial velocity of the source is automatically taken out from both veldop and vsource.

In the case of using smalod, the Doppler velocity veldop decoded from the MIR data header includes only the radial velocity of the observatory in the direction of the source, with respect to the rest frame. Users might want to add the systemic radial velocity of the source back. Then one must give the value of the radial velocity of the source to vsource in the input Keyword of smalod.

Alternatively, with puthd, users can put a value for vsource

puthd in=psource_rx1.usb/vsource value=-11 type=real

The radial velocity of -11 km/s is put to vsource in the header of the data. Users must beware of using puthd to reset vsource unless ones know what is the consequence caused by the change of vsource.

We recommend that users run uvredo to avoid the complication in getting the correct velocity information.