Analysis of Velocity Corrections in CALFUSE 1.8.7 Alex Fullerton Last Modified: June 28, 2001

This document describes tests of the implementation of the geocentric and heliocentric velocity corrections in the calfuse data reduction pipeline. These tests show that the motion of the satellite around the earth is removed correctly from the reduced spectra, but that the correction for the motion of the earth around the sun has been implemented in the wrong sense in versions of calfuse up to and including 1.8.7. A simple algorithm to correct this error in processed data is described, and corrections to subsequent versions of calfuse are recommended. Similar tests of the LSR corrections indicate that they must be implemented as negative corrections to the heliocentric reference frame.

Table of Contents

1. Introduction
2. Orbital Doppler Correction
3. Heliocentric Velocity Correction
4. Corrections to the Local Standard of Rest
5. Discussion and Recommendations

1. Introduction

For convenience, the velocities required to implement transformations to two other reference frames are also included in the PDU header:

1. V_LSRSTD converts wavelengths or velocities in the heliocentric frame to the Local Standard of Rest (LSR).
2. V_LSRDYN converts wavelengths or velocities in the heliocentric frame to the dynamical LSR.

These corrections are computed within calfuse by the Starlink library of subroutines for positional astronomy (SLALIB); see here for more information. The convention used by these procedures is that a velocity is positive when the the earth is moving away from a source or reference point. Evidently this convention is not adopted universally: e.g., detailed comparison with results generated by the IRAF routine rvcorrect yields numbers with the same magnitude but opposite signs.

However, irrespective of the convention adopted, it appears that the heliocentric correction is being applied incorrectly by calfuse v1.8.7 and its predecessors.

The most direct indication of this problem was detected by Charles Danforth (JHU). He noticed systematic offsets in the positions of interstellar lines in SMC sightlines between observations obtained in May-July, 2000 and September - October, 2000. The effect is illustrated in Figure 1, which includes a subset of FUSE observations of SMC targets in an image format. The central panels show the region around the strong interstellar C II 1037 resonance line, which were extracted from LiF1 (i.e., the guide channel) spectra. The horizontal strips in the image provide a greyscale representation of a particular observation; the overall mean spectrum is plotted below the image. The distribution of the observations in time is given in the left-hand panel, which shows Mission Elapsed Time (MET) in years, starting from December 1, 1999. The values of V_HELIO as recorded in the FITS headers of the various files are indicated in a similar panel on the right-hand side of the figure. Along with the expected variation in line position from one sightline to the next, there is a systematic shift of all features to the right (i.e., a redshift) that occurs between July 3 and September 29.

There are several possible sources of this shift:

1. A different wavelength calibration file might have been used for the later data.
   All observations were reduced uniformly with wave1a009.fit (i.e., version 9 of the wavelength calibration).

2. There might have been a systematic change in the positioning of targets.
   Figure 2 shows a subset of FUSE observations of sightlines in the LMC obtained over a comparable interval in the same image format. If there were a change in operational procedures, the shift would also be apparent in these data. However, no comparable shifts are evident.

3. The SMC shift might be astrophysical.
   This is unlikely, since the Galactic component of the C II line also exhibits the shift.

Figure 1	Figure 2	Figure 3

where lambda[new] is the correct heliocentric wavelength vector, lambda[old] is the wavelength vector currently available, V_HELIO is the value currently recorded in the PDU header, and c is the velocity of light in km/s. Figure 3 confirms that when the SMC data are plotted with the corrected wavelength scale, the systematic wavelength shift disappears. Since the LMC is near the ecliptic pole, the earth never has a substantial velocity component toward it, and consequently errors in the application of the heliocentric velocity are not expected to result in large seasonal velocity variations.

The remainder of this report documents explicit tests to determine whether the orbital and heliocentric velocity corrections are being applied correctly by calfuse .

2. Orbital Doppler Correction

2.1 Fundamentals

Figure 4		Figure 5

In the frame of reference traveling with the satellite, the source appears to be moving toward the satellite from time 1 until time 3, and away from it thereafter (times 3-5). This reflex motion blueshifts the photons on the detector during the first part of a typical orbital visibility period (times 1-3) and redshifts them during the second part (times 3-5). Thus, to remove orbital motion from FUSE data, the spectra must be redshifted by the component of the satellite's velocity whenever it is moving toward the source (i.e., times 1-3), and blueshifted whenever it is moving away from the source (i.e., times 3-5). As illustrated schematically in Figure 5 , application of these corrections puts the spectra in the geocentric reference frame.

2.2 A Test of the Orbital Doppler Correction

1. A suitable TTAG file was selected. This was the publically-accessible exposure A0030206014 (PI: Hutchings) of a target (RXJ 0019+22) that is conveniently placed at RA(2000) = 0:19:50 and DEC(2000) = 21:56:54; i.e., at a low declination near the vernal equinox. All 4 channels were present in this exposure, which was 3467 seconds long. The earth was moving directly towards RXJ 0019+22 on 2000-07-05; tangentially across its line of sight on 2000-10-05; and directly away from it on 2000-01-05.

2. The files for each of the 4 detector segments associated with this exposure were copied into 4 test files named W0010101001, W0010101002, W0010101003, and W0010101004.

3. To separate the correction of the satellite's motion around the earth from the heliocentric correction, the observation date was reset in each of these files to 2000-10-05 (MJD 51822). This was accomplished by updating the DATEOBS , EXPSTART, and EXPEND keywords in the FITS header of the PDU.

4. The values of EXPSTART were further modified so that the four exposures would start 25 minutes after each other. Consequently, the four test exposures cover an entire orbit, with considerable overlap since the actual exposure time (3467 s) is more than twice as long as the offsets (25 minutes = 1500 s).

5. Since the arbitrary adjustment of the starting times of the exposures produces a mismatch with the actual orbital phases, the SAA_SCR and LIMB_SCR flags were both set to OFF in the calfuse parameter files.

6. The W0010101*ttagfraw.fit files were processed through the first two steps of calfuse v1.8.7, i.e., cf_ttag_init and cf_ttag_screen. In order to have access to the instantaneous projected velocity of the satellite along the direction to the target, cf_orbit was run on the *_scrn.fit files.

7. The shifts in the dx column of the *_ scrn.fit files were compared with the component of the satellite's orbital velocity projected along the line of sight. The sense of the velocity shift was of prime concern. The ORBITAL_VELOCITY vector computed by cf_orbit is positive when the the satellite is moving toward the source. This convention is confirmed explicitly in Figure 6 , which shows both the mission planning timeline for exposure A0030206014 and the orbital velocity computed by cf_orbit. The timeline shows that the exposure began as the satellite emerged from earth occultation. It was moving toward the source, which corresponds to a positive orbital velocity.

2.3 Results

The spectral shifts, dx computed by calfuse are in the correct sense in all cases. When the satellite is approaching the target (i.e., v(s/c) is positive), the correction is a redshift ; i.e., to larger pixel number for channels with positive dispersion (dlambda/dx), and to smaller pixel number for channels with negative dispersion. Conversely, when the satellite is receding from the target (i.e., v(s/c) is negative), the correction is a blueshift , as required. Spot checks indicate that the magnitudes of the spectral shifts are also correct.

2.4 Conclusions

3. Heliocentric Velocity Correction

3.1 Fundamentals

Figure 7		Figure 8

3.2 A Test of the Heliocentric Velocity Correction

1. The files for each of the 4 detector segments associated with exposure A0030206014 were copied into two test files named W0010102001*.fit and W0010102002*.fit.

2. The observation dates were reset in these test exposures as follows:

   	Files	New Date	Remarks
   	W0010102001*ttagfraw.fit	2000-07-05 (MJD 2451730)	maximum velocity of earth toward target
   	W0010102002*ttagfraw.fit	2000-01-05 (MJD 2451548)	maximum velocity of earth away from target

   These changes were implemented by updating the DATEOBS, EXPSTART, and EXPEND keywords in the FITS headers of the PDUs.

3. Since the arbitrary adjustment of the dates associated with the test exposures produces a mismatch with the actual orbital phases, the SAA_SCR and LIMB_SCR flags were both set to OFF in the calfuse parameter files.

4. The W0010102*ttagfraw.fit files were processed through the first two steps of calfuse v1.8.7 , i.e., cf_ttag_init and cf_ttag_screen . In order to have access to the instantaneous projected velocity of the satellite along the direction to the target, cf_orbit was run on the *_scrn.fit files.

5. The spectral shifts in the dx column of the *_ scrn.fit files were compared with expectations. The shifts represent the combined removal of the satellite's motion around the earth (which is implemented correctly; see above) and the heliocentric correction, which provides a zero-point offset over the short duration of these test exposures. The sense of the heliocentric velocity shift is of prime importance.

3.3 Results

Figure 9		Figure 10

The circumstances illustrated in Fig. 9 correspond to the time of maximum earth velocity in the direction of the target. In accordance with the SLALIB convention, V_HELIO is negative in this situation. Irrespective of the sign convention, the heliocentric correction must be applied as a redshift in this case; i.e., as a positive spectral shift for channels like LiF1 with d(lambda)/dx > 0. However, Fig. 9 shows that the shifts have been implemented as a blueshift.

The situation is reversed for Fig. 10 . Since it corresponds to the time of maximum earth velocity away from the target, the heliocentric correction should be implemented as a blueshift. However, it has been implemented as a redshift.

The intermediate case, when the earth's motion is tangential to the line of sight to RX J0019+22 is illustrated in the figures comprising Table 1. In all cases, the magnitude of the V_HELIO and the resultant spectral shifts computed by cf_ttag_screen is correct. However, for the chosen sign convention, the sense of the shifts has not been implemented correctly.

3.4 Conclusions

4. Corrections to the Local Standard of Rest

The values of V_LSRSTD and V_LSRDYN are consistent with the sign convention used by SLALIB, but are opposite to those used, e.g., by the IRAF routine rvcorrect. Consequently, the LSR corrections computed by calfuse v1.8.7 (and earlier versions) must be applied as a negative correction:

since (as emphasized in the previous two sections) motion of a frame (here: the heliocentric frame) toward the reference point of another frame (in this case, the LSR) is compensated by a redshift.

5. Discussion and Recommendations

This error is due to the incorrect application of the shifts for the adopted sign convention. For the case where the earth's velocity is considered positive when it is moving away from a reference position (i.e., the SLALIB convention), the heliocentric correction should be implemented in a negative sense, i.e.,

With the alternate convention (i.e., that adopted by IRAF), the heliocentric correction is implemented in a positive sense:

which necessarily implies that the underlying sign convention is for the earth's velocity to be considered positive when it is moving toward the target. Indeed, this is the convention used to correct for the motion of the satellite about the earth. Although the heliocentric (and other) corrections are computed consistently and correctly by the SLALIB subroutines, they are being applied within calfuse as positive corrections, which is incorrect in the context of the SLALIB sign convention.

The recommended approach to correcting this error in subsequent versions of calfuse is to swap the sign convention for V_HELIO. This can be accomplished simply by removing the minus sign in the last line of the subroutine helio_vel.c. This subroutine is called by cf_velang.c, which is used by both cf_ttag_screen and cf_hist_screen to populate the V_HELIO keyword for TTAG and HIST data, respectively. Consequently, even though HIST data has not been examined explicitly during these tests, it is certain that the erroneous implementation extends to them.

Since cf_ttag_screen computes the magnitude of the pixel shifts correctly, only the sign convention for V_HELIO needs to be changed. However, for clarity, it is also recommended that documentation (including a COMMENT line in the header) emphasize that V_GEO and V_HELIO have already been applied to the data. Since the application of V_LSRSTD or V_LSRDYN is left to the user, it is strongly recommended that the sense of the correction be indicated explicitly in accompanying documentation, along with an example of the proper application of the LSR corrections. Insofar as the "positive correction" convention is more prevalent (if for no other reason than it is implemented in IRAF), the sign convention currently being used by calfuse should be changed.

In the meantime, data processed by any version of calfuse up to and including v. 1.8.7 can be easily corrected for the error in the application of V_HELIO:

where lambda[new] is the correct heliocentric wavelength scale; lambda[old] is the wavelength vector currently available in *fcal.fit files; V_HELIO is the value of the heliocentric velocity currently recorded in the header of the PDU; and c is the velocity of light in km/s. An implementation of this correction in IDL is available here .

Finally, the correction of this error might have ramifications for various other anomalies beyond the seasonal changes in wavelength scale illustrated in Fig. 1 . These include:

• the differential offsets reported between the velocities derived from widely separated lines of the same species;
• the difficulties encountered establishing a consistent zero point for the wavelength scale; and perhaps even
• the apparent differences in the wavelength scale derived from airglow lines.

Last Updated: June 28, 2001