Welcome to iraf.net Tuesday, April 30 2024 @ 07:23 PM GMT

Buglog #143

  • Monday, February 25 1991 @ 05:03 PM GMT
  • Contributed by:
  • Views: 1,125
MODULE: images.imsurfit
SYSTEM: V2.9
NUMBER:	143
MODULE:	images.imsurfit
SYSTEM:	V2.9
DATE:	Mon Feb 25 10:03:39 MST 1991
FROM:	davis

BUG:	There is a bug in the bad pixel rejection code in the IMSURFIT task
	which occurs when the parameter upper > 0.0 and lower = 0.0, or
	if lower > 0.0 and upper = 0.0. In the former case all points with
	negative residuals were rejected instead of none, and in the latter
	case all points with positive residuals were rejected instead of
	none. IMSURFIT was computing the rejection limits by multiplying
	the computed standard deviation by upper and lower respectively
	without checking for the zero case.

STATUS:	The big is fixed in IRAF 2.10. There is no workaround, except to
	set upper or lower to very large values if you do not want to
	reject pixels.

NUMBER:	463
MODULE:	splot
SYSTEM:	V2.11-V2.11.3a
DATE:	Tue Feb 15 15:59:39 MST 2000
FROM:	valdes

BUG:	The 'h' key method for measuring equivalent widths will produce
	an arithmetic exception (such as divide by zero) when the pixel
	coordinate becomes large (say > 4000).  The exact error and limit
	value depends on the host system.  The workaround is to extract the
	desired piece of the spectrum into a shorter piece.  If you know
	the pixel coordinates you could use IMCOPY with an image section.
	If you know the wavelength region then use SCOPY.

	    on> imcopy longspec[5210:5310] temp
		or
	    on> scopy longspec temp w1=6140 w2=6143 rebin-

	    on> splot temp
	    

	Alternatively one can use one of the other methods for measuring
	equivalent widths such as 'e', 'k', or 'd'.

STATUS:	The algorithm is revised in the next release.

Buglog #143 | 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