Velocity Considerations

For a typical galactic object, the velocity is assumed to be given with respect to the local standard of rest (`lsr'), and to be defined according to the radio astronomy standard. In such cases, these are the system defaults and neither you nor the operator will give this a second thought, so if you really want something else, it is worth knowing what we can offer you, and understanding the distinctions.

Velocity reference frame
That is, the frame of reference with respect to which your velocities are to be defined. The JCMT control system understands the following keywords:

• LSR --- with respect to the Local Standard of Rest (and as noted above, the default, and assumed unless you say otherwise)
• HELIOCENTRIC --- for velocities defined with respect to a frame in which the Sun is at rest; some optical velocities are reduced to this reference frame, particularly those for galaxies
• BARYCENTRIC --- with respect to the solar system centre of mass; this is not used at all at the JCMT
• GEOCENTRIC --- with respect to the centre of the Earth (often used for planets and comets)
• TOPOCENTRIC --- measured in a frame in which the telescope is at rest (also used sometimes for planets and comets, and for observations of the Earth's atmosphere): i.e. egocentric.

The velocity definition
This is how the velocity is defined from the resultant wavelength or frequency shifts (most astronomical velocity data is just the doppler shift represented as a velocity --- and that can be done in several ways). In what follows the velocity of the source (in the reference frame of your choice) is given by v, and the remainder of the symbols are pretty self-explanatory. There are three different definitions that JCMT's control software can handle:

• RADIO --- This is the default for JCMT observations. In this, the frequency, nu, for a velocity (with respect to the given frame of reference) is given by
  nu = nu_rest(1 - v/c)
  as is traditional in radio astronomy. Here, nu_rest is the rest frequency, and c the velocity of light. This corresponds to
  v/c = (nu_rest - nu)/nu_rest.

• OPTICAL --- The `optical' definition is more easily related to redshift z and wavelength lambda. Thus the resultant
  lambda = lambda_rest(1 + z). This then corresponds to
  v/c = z = (lambda - lambda_rest)/lambda_rest.

• RELATIVISTIC --- Relativistic definition. Defined by
  nu = sqrt((1 - v/c)/(1 + v/c)).
  Alternatively, this can be rewritten as
  v = c[(1-(nu/nu_rest)²)/(1+(nu/nu_rest)²)].
  This is the relativistic doppler shift if you assume that the shift is due only to a velocity along the line of sight in the special relativistic sense. It is not true for partly transversal velocities, cosmological redshifts or other reasons for redshifts such as gravitation. It has been argued that this definition of velocity scale (as computed from redshift data) was invented to further confuse the issue --- one more possible definition. There is no guarantee that it will give a more correct velocity than the other scales.

Note that for large velocities is it important to make sure that you are using the right velocity definition. The difference can easily cause your line to fall partly or wholly outside the spectrometer window. For instance the difference between the radio and optical definition for a velocity of 10000km/s is 250MHz. This is half the typical spectrometer bandwidth.

If one is observing highly redshifted objects (as is the fashion these days) it is important to know the redshift accurately. Using the redshift definition given above a small uncertainty Delta-z in the redshift translates into a uncertainty Delta-nu in the redshifted frequency via the relation
Delta-z = -(z+1)²Delta-nu/nu_rest.
So, for example, if you are using a 760-MHz spectrometer window, you need to know the frequency to better than, say, 200MHz, which for a redshifted frequency of 350GHz and a redshift of 2.0, means that the maximum tolerable redshift error is +0.0017. In general the redshift needs to be known accurately to at least three decimal places.

Telling the control system what you want
Both the velocity reference frame and the velocity definition need to be specified prior to, or at least at the same time as, setting the frequency, sideband and velocity themselves. In the days of ICL, both variables were `hidden parameters', which need to be communicated to OBSCONTROL using the special vset ICL command (See p25 of MTUN134).

Thus to set the velocity reference frame (hidden parameter vel_ref) to heliocentric the operator issues the ICL command

vset vel_ref heliocentric

or, more conveniently, specifies the appropriate reference frame during the frontend setup command, in response to the appropriate prompt in the frontend command.

Likewise, the operator would use the ICL command

vset vel_defn optical

to set the velocity definition (vel_defn) to the optical one. The frontend command does not prompt for this parameter, so it needs to be set prior to the fe ] command.

But NB: The ICL command terminology will be replaced before Aug 2006 and the above commands will become redundant;
Watch This Space.