Welcome to iraf.net Tuesday, April 23 2024 @ 06:20 PM GMT

Buglog #323

  • Monday, January 22 1996 @ 10:06 PM GMT
  • Contributed by:
  • Views: 965
MODULE: scopy, sarith
SYSTEM: V2.10 - V2.10.4
NUMBER:	323
MODULE:	scopy, sarith
SYSTEM:	V2.10 - V2.10.4
DATE:	Mon Jan 22 15:06:10 MST 1996
FROM:	valdes

BUG:	When using SCOPY or SARITH with a wavelength range specified
	in the reverse sense of the data and without rebinning a
	segmentation error occurs.  By reverse sense this means if the
	spectra have decreasing wavelength with increasing pixel then the
	limits are specified with the starting pixel less than the ending
	pixel (or vice-versa). The task resamples any and all associated
	spectra such as the sky and sigma spectra.  However, in this
	particular case it was applied without checking whether such
	spectra exist which cause the memory access error.  The workaround
	is to specify the limits in the same sense as the dispersion if the
	direction really doesn't matter or to flip the spectrum with an
	image section.  An example of the last case for a 1D spectrum would
	be:

		cl> scopy spec1[-*] spec2 w1=3600 w2=5600 rebin=no

	where spec1 has decreasing wavelength with increasing pixel.


STATUS:	Fixed in the next release.

NUMBER:	360
MODULE:	splot
SYSTEM:	-V2.10p2
DATE:	Thu Feb  6 15:53:00 MST 1997
FROM:	valdes

BUG:	Equivalent widths and line fluxes measured with the 'e' and 'h' keys
	will have the wrong sign if the wavelength increment per pixel in
	the spectrum image is negative; i.e. the dispersion units decrease
	with increasing pixel number.  This is because these quantities are
	computed in pixels and then converted to wavelength units by
	multiplying by the wavelength increment per pixel rather than the
	absolute value.  Note that SPLOT always plots with dispersion units
	increasing to the right whether or not the actual order of pixels
	in the image has increasing or decreasing wavelength with
	increasing pixel number.  The only error is one of sign and the
	workaround is to take account of this sign error when reporting
	equivalent widths.  The convention is that absorption lines have
	positive equivalent widths.

STATUS:	Fixed for the next release.

Buglog #323 | 0 comments | Create New Account

The following comments are owned by whomever posted them. This site is not responsible for what they say.



Privacy Policy
Terms of Use

User Functions

Login