iraf.net

NUMBER:	203
MODULE:	sarith, scombine, splot
SYSTEM:	V2.10-V2.10.2
DATE:	Wed Feb 10 10:55:11 MST 1993
FROM:	valdes

BUG:	In certain circumstance (listed below) when the dispersion coordinates
	are inverted to get pixel coordinates the wrong pixel coordinates
	are obtained.  In practice this is important only when resampling
	spectra such as in arithmetic or combining between two spectra
	as might occur with SARITH, SCOMBINE, or the function mode in
	SPLOT.  It also can cause a problem with the SPLOT equivalent width
	options (giving a floating divide by zero).  This problem does NOT
	apply to DISPCOR!  The conditions under which this problem occurs
	are when all the following apply:

	    1.  Multispec coordinate system images with more than one
		spectrum.
	    2.  The spectra have different coordinate systems; i.e.
		are not all at a common coordinate system.
	    3.  The spectrum aperture numbers differ from the line
		numbers; for example line 1 is aperture 3 and line 3
		is aperture 1.  Note that if an image section is
		used this will change the line number so even if
		the apertures are the same as the line numbers in
		the original image this will not be true with an
		image section.

	In many applications DISPCOR is used to linearize all spectra
	to a common dispersion system.  This problem does not apply
	to such data.  It is likely to affect echelle spectra and users
	who use nonlinear dispersion coordinates.  The workarounds are
	to assign aperture numbers sequentially increasing with pixel
	coordinate when extracting, renumber the apertures with the
	renumber option in SCOPY, dispersion correct to a common system
	with DISPCOR, separate the spectra into ONEDSPEC images before
	doing the arithmetic/combining, or avoid arithmetic/combining
	operations.

	What is happening is that the coordinate transformations
	between pixel and world coordinates are (x,l) <-> (w, a)
	where x is the pixel image coordinates along the dispersion,
	l is the line number, w is the wavelength, and a is the aperture
	number.  Note that the image line maps to an aperture and vice-versa.
	The bug is that instead of using the aperture number the inverse
	transformation being used is (w,l) -> (x,?).  So unless the
	line number happens to be the same as the aperture number or
	the dispersion functions are the same for all apertures the
	dispersion function from the wrong spectrum is used for the
	inversion.

STATUS:	This will be fixed in V2.10.3.