For a typical galactic object, the velocity is assumed to be given with respect to the kinematical local standard of rest (`LSR’), and to be defined according to the radio astronomy standard. In such cases, these are the system defaults, 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 JCMTOT understands the following velocity reference frames:
- LSR — with respect to the kinematical Local Standard of Rest (and as noted above, the default)
- 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; this is not used at all at the JCMT
- TOPOCENTRIC — measured in a frame in which the telescope is at rest; at the JCMT this is used for planets and comets, and for observations of the Earth’s atmosphere
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 the JCMTOT 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 ν = νrest(1 – v/c)as is traditional in radio astronomy. Here, νrest is the rest frequency, and c the velocity of light.
This corresponds tov/c = (νrest – ν)/νrest. - OPTICAL — The `optical’ definition is more easily related to
redshift z and wavelength λ. Thus the resultant λ = λrest(1 + z).
This then corresponds tov/c = z = (λ – λrest)/λrest. - RELATIVISTIC — Relativistic definition. Defined by ν = sqrt((1 – v/c)/(1 + v/c)).Alternatively, this can be rewritten asv = c[(1-(ν/νrest)2)/(1+(ν/νrest)2)].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 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 δν in the redshifted frequency via the relation
δz = -(z+1)2δν/νrest.
So, for example, if you are using a 1000-MHz spectrometer window, you need to know the frequency to better than, say, 250MHz, which for a redshifted frequency of 350GHz and a redshift of 2.0, means that the maximum tolerable redshift error is +0.0021. In general the redshift needs to be known accurately to at least three decimal places.
How to convert data between velocity frames
to convert processed data from the JCMT Science Archive, which is in Barycentric frequency, into radio line-of-sight velocity () in LSRK. You can use the following Starlink commands to do this, assuming you have started with a file named ‘archive_file.fits’. These would be copied into a terminal, after setting up the Starlink software within that terminal. The lines starting with a # symbol are comments.
# Load the convert package to enable conversion from FITS to NDF convert # Convert your archive file into Starlink Data Format (NDF) fits2ndf archive_file.fits archive_file.sdf # Load the KAPPA package (contains many useful routines) kappa # Set the 3rd axis of the coordinate system to be in units of radio velocity wcsattrib ndf=archive_file.sdf mode=set name=system\(3\) newval=vrad # Set the standard of rest to be the LSRK wcsattrib ndf=archive_file.sdf mode=set name=StdofRest newval=LSRK # OPTIONAL: if fits output is required, convert the file back to fits ndf2fits archive_file.sdf archive_file_radiovelocity.fits
Sometimes it is also needed to add together spectral data from moving targets (eg comets) onto a ‘source’ (‘cometocentric’) velocity scale: this can be done by doing:
makecube <rawdatafile00099> system=GAPPT alignsys=TRUE out=out99.sdf wcsattrib out99.sdf set alignoffset 1 wcsattrib out99.sdf set skyrefis origin wcsattrib out99.sdf set sourceVRF topocentric wcsattrib out99.sdf set stdofrest source wcsattrib out99.sdf set alignstdofrest source wcsattrib out99.sdf set SourceVel <velocity> wcmosaic out*.dat . . .