diff options
Diffstat (limited to 'local/bugs.log')
| -rw-r--r-- | local/bugs.log | 8527 |
1 files changed, 8527 insertions, 0 deletions
diff --git a/local/bugs.log b/local/bugs.log new file mode 100644 index 00000000..8b9c0c4a --- /dev/null +++ b/local/bugs.log @@ -0,0 +1,8527 @@ +# BUGS.V29 -- Known bugs in the frozen IRAF Version 2.9 (and previous +# versions). Started 15JUN90. +# +# Record Format: +# +# NUMBER: record number, decimal, sequential. +# MODULE: package.task or library.procedure or 'unknown' or ... +# SYSTEM: versions of iraf in which bug was present +# DATE: date bug logged, unix format date string +# FROM: user login name +# BUG: description of the bug +# STATUS: 'fixed in V2.X', 'unresolved', etc. +# +# New records are added to the tail of the bugfile. Left justify field labels, +# indent text to the first tab stop, one blank line between bug entries. +# ---------------------------------------------------------------------------- + +NUMBER: 120 +MODULE: apphot.daofind +SYSTEM: V2.8 +DATE: Fri Mar 30 08:02:12 MST 1990 +FROM: davis + +BUG: In rare circumstances daofind may abort with a "pixel file truncation + error" when trying to read back the convolved images it has just + written. This only occurs on certain sized images and is due to + the interaction of the read, write and boundary extension in image + i/o. For example daofind works fine on a 640 by 1024 image but fails on + one that is 641 by 1025 pixels. + +STATUS: The problem is fixed in 2.9. The solution was to add an imflush + statement to flush the image i/o buffers after the write was + complete and before initiating the read. There is no workaround. + Contact the IRAF group for a fix. + +NUMBER: 121 +MODULE: utilities.curfit +SYSTEM: V2.9 +DATE: Mon May 21 15:12:40 MST 1990 +FROM: sjacoby + +BUG: The errors in the coefficients reported by CURFIT are incorrect when + points have been rejected from the sample by the iterative rejection + algorithm. User deleted points are handled properly, but points + automatically rejected by sigma criteria are being incorrectly + included in the coefficient error calculation. + +STATUS: The bug is fixed in V2.10. There is no workaround, unless the user + can identify and delete by hand those points the algorithm would reject. + +NUMBER: 122 +MODULE: cl +SYSTEM: V2.9 DECstation/IRAF +DATE: Wed May 23 20:58:47 MST 1990 +FROM: tody + +BUG: If IRAFARCH is not defined in the user environment, an attempt + to run the CL in DECstation/IRAF will fail with the message + "... /bin.f68881/cl.e not found". This is caused by a malformed + if-else (missing else) on line 41 of hlib$cl.csh. + +STATUS: A simple workaround is to define "setenv IRAFARCH mips" in the + user environment before starting the CL. This bug is so easy to + fix however, that a permanent fix is probably the best approach. + Merely edit the file iraf/unix/hlib/cl.csh and change the "if" on + line 41 to "else if". + +NUMBER: 123 +MODULE: imtranspose +SYSTEM: V2.9 +DATE: Wed Jun 6 08:37:42 MST 1990 +FROM: davis + +BUG: Imtranspose fails with an "unknown pixel type error" on image of + type ushort. + +STATUS: The bug has been fixed in 2.10. There is no workaround except to + change the pixel type of the image to int or long. + +NUMBER: 124 +MODULE: proto.imedit +SYSTEM: V2.9, V2.8 +DATE: Wed Jun 6 09:22:54 MST 1990 +FROM: valdes + +BUG: The fixpix format input interpolates across the longer dimension + rather than the shorter dimension. If the region is a complete + column/line then no correction is made. + +STATUS: Now fixed. For square or nearly square regions the interpolation + across the longer dimension is probably adequate. Other workarounds + are to use FIXPIX itself or convert the fixpix format file to regular + cursor input to imedit (which then also allows use of any of the other + options). + +NUMBER: 125 +MODULE: apextract.apscatter +SYSTEM: V2.9 +DATE: Mon Jun 11 17:35:22 MST 1990 +FROM: valdes + +BUG: When specifying a "line" to be plotted a check is made against the + wrong image axis; i.e. if a line is specified then it forced to + be in the range 1 to the number of image columns and vice-versa + for the other axis. + +STATUS: This has been fixed. There is no workaround but the task will + still function correctly even though it is not possible to examine + some image lines or columns. The effect becomes obvious only in + significantly nonsquare images. + +NUMBER: 126 +MODULE: apphot package +SYSTEM: V2.9 +DATE: Wed Jun 27 16:47:34 MST 1990 +FROM: davis + +BUG: Due to fractional pixel effects the sky fitting routines in apphot + can fail to preallocate enough space to hold the sky pixels, resulting + in a memory corruption error or a segmentation violation on exit + from a task. This condition occurs rarely most often when the sky + fitting annulus is very narrow. All the apphot tasks which do + sky fitting are affected. + +STATUS: The bug is fixed in 2.10. There is no workaround although increasing + the width of the sky fitting annulus slightly may bypass the + problem. Contact the IRAF group for a fix. + +NUMBER: 127 +MODULE: artdata.mkobjects +SYSTEM: V2.9 +DATE: Mon Jul 2 11:41:14 MST 1990 +FROM: valdes + +BUG: Objects which fall partially off the lower edges of the image + (objects with centers near the (1,1) image origin) are shifted + by 1 pixel to larger coordinates. + +STATUS: This bug is caused by incorrect rounding of negative numbers. The + bug has been fixed. The workarounds are to either compensate + for the error in the analysis or offset the coordinates to + larger values (say by using the offset parameters) and make a + larger image which can then be trimmed with IMCOPY. The tricky + thing is knowing when the objects go off the edge since the + full object size depends on seeing and the specified dynamic range. + +NUMBER: 128 +MODULE: IMFORT +SYSTEM: V2.9 +DATE: Tue Jul 10 10:33:02 MST 1990 +FROM: tody + +BUG: In IRAF V2.9, IMFORT has a bug which prevents access to images not + in the current working directory. If one tries to access an image + using a pathname an error message such as "image not found (.imh)" + is seen. + +STATUS: The workaround is to CD (SET DEF) to the directory before accessing + the image. A patch (patch #2) is available in the IRAF network + archive which can be installed to fix the bug. Installation + instructions are given in the README files for each supported + architecture (SOS4, VMS5, etc.). + +NUMBER: 129 +MODULE: onedspec.splot, onedspec.calibrate +SYSTEM: V2.9 +DATE: Tue Jul 10 17:07:46 MST 1990 +FROM: valdes + +BUG: In SPLOT the first pixel is ignored. In CALIBRATE the wavelength + scale for extinction correction will be in error by one pixels. + +STATUS: These two bugs are related because the header parameter NP1, + which is the offset to the first valid pixel, should be zero in + most cases but a bug fix in Nov. 1989 put in a minimum value of 1. + The symptom in SPLOT is to lose the first pixel but the + wavelength scale is correctly compensated. In CALIBRATE the + wavelength scale is not compensated though the error should be + extremely small since the calibrations are interpolations from + a smooth curve. There is no easy work around for SPLOT. If + the one pixel wavelength error in CALIBRATE is a concern one + could reset the wavelength zero point parameter W0 or CRVAL1 to + be greater by WPC or CDELT1; i.e. make the starting wavelength + parameter refer to pixel 2. Note that this will make the + wavelengths wrong for SPLOT and other ONEDSPEC tasks. This bug + is corrected in V2.10. + +NUMBER: 130 +MODULE: artdata.mkobjects +SYSTEM: V2.9 +DATE: Thu Jul 19 15:14:14 MST 1990 +FROM: valdes + +BUG: The radius parameter for the "gaussian" model PSF is being used as + a full width instead of a radius as intended and described in the + documentation. The effect is to give narrower stars than expected. + +STATUS: The workaround is to give a FWHM for the gaussian model instead of + a radius at half maximum. + +NUMBER: 131 +MODULE: artdata.mkobjects +SYSTEM: V2.9 +DATE: Mon Jul 23 10:53:43 MST 1990 +FROM: valdes + +BUG: The moffat function size scaling (as set by the radius parameter) + is incorrect. + +STATUS: The shape of the function is based on the correct beta but the size + is scaled for a function with beta of: + + beta1 = 2 * beta - 2 + + Another way to look at it is that the flux level corresonding to + the specified radius is different than the half intensity. The + actual flux level is: + + F(radius) = 0.5 ** (beta / beta1) + + Finally, the radius which must be specified, rfudge, to get a + desired radius at half intensity, rhalf, is: + + rfudge = rhalf * sqrt ((2**(1/beta1)-1) / (2**(1/beta)-1)) + + Note that there is no error for beta=2, the size is too large + for beta>2, and the size is too small for beta<2. + + The workaround is to adjust the specified radius for a desired + radius at half intensity using the above formula. + +NUMBER: 132 +MODULE: utilities.curfit +SYSTEM: V2.9 +DATE: Mon Jul 30 17:37:48 MST 1990 +FROM: davis + +BUG: Curfit was crashing with a segmentation violation when it tried to + fit the second file of data or second image in a list of images. + The pointer to the icfit data structure was being freed after + the first file of data was fit and not reallocated before the + next fit resulting in a reference to an undefined pointer. + +STATUS: The bug has been fixed in 2.10. There is no workaround except + to use a script to loop over a large number of input data files. + +NUMBER: 133 +MODULE: math$gsurfit/dgsder +SYSTEM: V2.9 +DATE: Wed Aug 1 16:27:43 MST 1990 +FROM: davis + +BUG: Due to a typographical error in the file math$gsurfit/gsder.gx, + dgsder (the routine which computes the derivative of a double + precision surface) was inadvertantly calling salloc with a pointer + address instead of an array size. If the assigned pointer value + is very large this can cause an "out of memory error" in any task + which calls dgsder. + + Currently the only task affected by this bug is TRANSFORM + in the LONGSLIT package. + +STATUS: The bug is fixed in 2.10. There is no workaround. Contact NOAO for + a fix. + +NUMBER: 134 +MODULE: XC (SPP compiler) +SYSTEM: Sun/IRAF V2.9 (Sun systems only) +DATE: Wed Aug 8 10:04:34 MST 1990 +FROM: tody + +BUG: Sun/IRAF V2.9 will not work with the SunOS 1.3 or 1.3.1 Fortran + compiler (which Sun came out with after IRAF was released). The + new Sun compiler locates important executables such as f77, cc, + etc., in a nonstandard place, one of the Fortran libraries has + been done away with, the command line arguments have changed, + etc. (in short Sun has completely revamped their compiler). + +STATUS: A new version of XC is available from IRAF site support which + will work with the new compiler. Note that although this allows + the compiler to be used, and it appears to be possible to compile + and link programs, the IRAF V2.9 libraries were compiled with the + old Sun Fortran compiler and we cannot be certain that these + libraries are fully compatible with the new compiler and its + libraries. Also, the default host compiler flags supplied with + Sun/IRAF MKPKG are not necessarily what is best for the new + compiler. Most likely these are not serious problems, but + Sun/IRAF will not fully support the new compiler until we have had + time to recompile the full system for a future release. + +NUMBER: 135 +MODULE: noao.artdata.mkobjects +SYSTEM: V2.9 +DATE: Thu Aug 9 09:24:41 MST 1990 +FROM: valdes + +BUG: The general cumulative profile file input for both the PSF and a + an object type does not work. The error is can't open image + even though the file is not an image. + +STATUS: This bug is due to the inability of the image access checking routine + to distinguish images from regular files. Because of the order + of the logic the task always checks to see if the specified file + is an image template first, decides it is an image, and then + fails with the error can't open image. There is no work around. + Those requiring this capability wil have to contact site support + for help. + +NUMBER: 136 +MODULE: wfits/rfits +SYSTEM: V2.9 +DATE: Mon Aug 27 07:37:57 MST 1990 +FROM: davis + +BUG: Wfits sometimes crashed with a segmentation violation when + files were written with a non-standard block size (block_factor > 10). + The error was in the code which 0-filled the unused portion of the + last output block, and occurred if the unused portion of that + block was greater than 2880 bytes. + + Rfits sometimes reported read errors when it tried to read tapes + with a non-standard block size (blocks not a multiple of 2880 + bytes). Rfits was not always counting the number of characters read + from the tape correctly when the read attempted to cross tape record + boundaries. Tapes with small block sizes like 512 and 1024 were + the most affected. + +STATUS: Both bugs have been fixed in version 2.10 and the 2.9.1 patch. + +NUMBER: 137 +MODULE: IMDKERN +SYSTEM: V2.9 +DATE: Thu Sep 6 11:59:44 MST 1990 +FROM: tody + +BUG: There is a bug in the V2.9 version of the IMDKERN graphics kernel + (used to draw color graphics overlays on the image display) which + can cause the kernel to die on a segmentation violation when run + as a connected subkernel. + +STATUS: The workaround is to spool the graphics metacode for the plot in + a file and then plot this file using the IMDKERN task in PLOT. + The bug is fixed in the V2.9.1 patch, available from the IRAF + network archive. + +NUMBER: 138 +MODULE: images.convolve +SYSTEM: V2.9 +DATE: Wed Nov 28 13:38:17 MST 1990 +FROM: davis + +BUG: CONVOLVE was terminating with the error "Kernel rows are different + lengths" if the user supplied a 1D kernel without the terminating + delimiter character ';'. For example the valid kernel "1.0 2.0 1.0;" + would work but the equally valid "1.0 2.0 1.0" would not. 2D kernels + did not have this problem. + +STATUS: The bug is fixed in IRAF 2.10. The workaround is to always append + the delimiter character to the kernel. + +NUMBER: 139 +MODULE: noao.artdata.mkobjects +SYSTEM: V2.9-V2.9.1 +DATE: Tue Dec 4 12:00:32 MST 1990 +FROM: valdes + +BUG: Memory associated with the stellar, galaxy, and cosmic ray templates + is not freed in the tasks MKOBJECTS and MKNOISE. Repeated executions + (without flushing the process) eventually overflows the swap + space or causes out of memory errors. + +STATUS: The bug is caused by a simple typo and has been fixed. Large amounts + of memory are tied up only with a large number of repeated calls. + Normally all objects are created in one step rather than repeated + calls to add individual objects and so there is generally no + difficulty. The work around when using these tasks in a loop + is to add a "flprcache" call to flush the process after each + call or set of calls. + +NUMBER: 140 +MODULE: dataio.rfits +SYSTEM: V2.9 +DATE: Thu Dec 6 11:38:42 MST 1990 +FROM: davis + +BUG: A command of the form "rfits mta 1-8 "" oldirafname+" will generate + the message "ERROR: T_RFITS: Error reading output file name" because + the code was not dealing properly with an empty output file list. + +STATUS: Rfits has been modified in 2.10 so that a temporary output file + name is created if oldirafname is true or a clear error message + is generated if oldirafname is false, and the user has set the + output file name to "". The workaround is to avoid setting + the output file name to "". + +NUMBER: 141 +MODULE: identify +SYSTEM: V2.9 +DATE: Wed Dec 19 16:47:06 MST 1990 +FROM: valdes + +BUG: The automatic line identification algorithm fails to find some + lines in certain circumstances. + + The source of the problem is when multiple lines in the line + list end up being centered in the same place in the data. For + example if two lines in the list are 4888.1234 and 4889.1234, + the second one is intrinsically weak, and the data is low + resolution (say 3A per pixel) then as far as the data is + concerned there is just one line. This line will be marked + twice with the same position but different wavelengths. The + complication is that valid weaker lines will be removed based + on the maxfeatures criteria (for example only the 50 highest + peak values are kept of which say 10 are multiple assignments + to the same peaks in the data). Then after the lines are + found the minsep criteria is applied to winnow out the multiple + assignments to the same pixel leaving 40 lines found and 10 of + the weaker valid lines not found. This is a complex behavior + dependent on data resolution, the initial dispersion solution, + the line list (the problem occurs with dense line lists used + for high resolution such as the thorium list used with lower + resolution data), and the maxfeatures and match parameters. + +STATUS: The bug fix is to winnow out the multiple identifications to + the same pixel before selecting the maxfeatures strongest + lines. The workaround most likely to work is to reduce the + match parameter so that some of the multiple identifications + are thrown out based on wavelength differences with the + dispersion function estimates. Another thing is to increase + maxfeatures but this will result in many undesired weak lines. + + +NUMBER: 142 +MODULE: testphot.daophot.psf +SYSTEM: V2.9 +DATE: Tue Feb 5 16:39:13 MST 1991 +FROM: davis + +BUG: The task psf in testphot.daophot was writing incorrect values of the + zero point position of the psf "XPSF" and "YPSF" into the psf image + header. Although this was not a problem for the constant psf fitting + code, the variable psf fitting code was interpolating in the wrong + place in the look-up table, resulting in a very strange looking psf + fit. In effect the coordinate system of the look-up table was shifted + with respect to the image. + +STATUS: The bug has been fixed in the ftp archive version of testphot and on + all our local nodes (orion, gemini, ursa). Users can either get a + new version of testphot from the archive or contact the IRAF group + for a patch since only one file is affected. + +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: 144 +MODULE: artdata +SYSTEM: V2.9.1 +DATE: Mon Mar 4 09:43:28 MST 1991 +FROM: valdes + +BUG: The tasks sometimes fail when the output image is in STF (.hhh) format. + This is due to a problem in how image header comments are put in + the image header affecting only the STF format. Note that the + original version released with V2.9 does not provide header + comments and so it does not have a problem. The newer version with + this STF header problem came as part of V2.9.1. + +STATUS: This problem has been fixed in the next version of the package. + The only workaround is to use OIF (.imh) format and then convert + to STF format with IMCOPY. + +NUMBER: 145 +MODULE: apextract +SYSTEM: V2.9 +DATE: Wed Mar 27 16:57:13 MST 1991 +FROM: valdes + +BUG: For some default background functions and sample regions a singular + solution error can occur. This is caused by defining the function + range to be the entire image dimension while the sample region is + only a small part of this range. It probably also depends on the + function type and order and the degree of curvature in the fitted + data. When apertures are read from the database or reset by the + 'b' mode in APEDIT the fitting limits are set to the limits of the + sample region. + +STATUS: The singular solution message should be harmless. Reading apertures + from a database does not have this problem. Entering the 'b' mode in + APEDIT (where the message might be seen) and exiting will fix the + fitting function properly. Of course if background subtraction + is not required this problem does not arise. The problem has + been fixed for V2.10. + +NUMBER: 146 +MODULE: images.geomap +SYSTEM: V2.9 +DATE: Tue Apr 9 14:08:45 MST 1991 +FROM: davis + +BUG: Geomap would not permit the user to fit cross-terms (terms containing + x*y) in the the x coordinate fit if xxorder=2 and xyorder=2, or in + the y coordinate fit if yxorder==2 and yyorder=2. For higher order + fits cross-term fitting was enabled. + +STATUS: This bug has been fixed in IRAF 2.10. There is no workaround. + +NUMBER: 147 +MODULE: ccdred.mkskycor ccdred.mkillumcor +SYSTEM: V2.9 +DATE: Tue Apr 16 16:42:36 MST 1991 +FROM: valdes + +BUG: The CCDMEAN parameter computed by the task MKSKYCOR and MKILLUMCOR + is computed incorrectly in the sense that it is smaller than the + correct value by a small amount. The last few lines of the image + were not accumulated before dividing by the number of pixels in + the output image. + +STATUS: This bug has been fixed for V2.10. One workaround is to use + yboxmin of 0. The other workaround is to use IMSTATISTICS and + HEDIT to compute and replace the correct value. Failing to do so + and then correcting images with CCDPROC will slightly change the + data level which may be acceptable. + +NUMBER: 148 +MODULE: ecdispcor, msdispcor +SYSTEM: V2.9 +DATE: Mon Apr 22 13:23:09 MST 1991 +FROM: valdes + +BUG: The combining options "sum", "average", "minmax" do not work correctly. + The cause is failing to clear an array between each spectrum so + that as subsequent spectra are added the preceding spectra are + multiply added. + +STATUS: The workaround is to dispcor each order to the same dispersion + with onedspec output format and then add or average the spectra + with imcombine. The problem is fixed for V2.10. + +NUMBER: 149 +MODULE: artdata.mkobjects +SYSTEM: V2.9 +DATE: Mon Jun 10 10:44:47 MST 1991 +FROM: valdes + +BUG: The PSF position angle (parameter pa) is intended to be input + as degrees and converted internally to radians. The conversion is + not being done with the effect that the input position angle is + being interpreted as radians. + +STATUS: The conversion has been added to the program; a simple use of + the DEGTORAD macro. The workaround is to specify the position + angle in radians. Note that the object position angles specified + in the object list are correctly interpreted as degrees. + +NUMBER: 150 +MODULE: dataio.wfits +SYSTEM: V2.9 +DATE: Tue Jun 11 13:04:44 MST 1991 +FROM: davis + +BUG: Wfits was setting the IRAFNAME image header keyword to a blank + string if the input image was a section. This was done originally + to avoid rfits trying to rename the output image (if parameter + oldirafname = yes) to an image section, but had the side effect + of making IRAFNAME useless for book-keeping purposes. + +STATUS: Wfits has been modified in 2.10 to write the full image specification + including the image section but minus the directory specification + in the IRAFNAME keyword. Rfits has been modified to check for and remove + any image section before renaming the output image to the orginal + iraf name. If the renaming fails for any reason, then the name + specified by the iraf_file parameter will be used as before. + +NUMBER: 151 +MODULE: noao.twodspec.longslit.fitcoords +SYSTEM: V2.6-V2.9 +DATE: Fri Jul 12 08:38:03 MST 1991 +FROM: valdes + +BUG: Fitting a single trace made along the x or horizontal axis + does not work correctly. + +STATUS: The workaround is to transpose the data and trace the feature + vertically. This is corrected in V2.10. + +NUMBER: 152 +MODULE: images.imshift +SYSTEM: V2.9 +DATE: Mon Jul 29 11:42:28 MST 1991 +FROM: davis + +BUG: Imshift was not correctly initializing the shifts file descriptor to + NULL, when the shifts_file parameter was set to "", sometimes causing + a later conditional test in the code to fail. + + This bug is triggered when a user sets shifts_file to a file name + and then sets it back to "" without flushing the process cache, + as may happen after repeated executions in a script. + +STATUS: The bug has been fixed in 2.10. There is no workaround except to + flush the process cache between executions. + +NUMBER: 153 +MODULE: digiphot.apphot.apselect +SYSTEM: V2.9 +DATE: Mon Aug 12 15:07:29 MST 1991 +FROM: davis + +BUG: Apselect can sometimes fail with a segmentation violation if the + input file has variable length records, (as can be the case for + example if the user changes the number of apertures interactively, + or if the user has defined polygons of various sizes) + if the first record is not the longest record in the file, + and if the size of the variable length record exceeds 20, the + initial guess for buffer allocation. + +STATUS: The bug has been fixed in 2.10. There is no workaround except to + ensure that the longest record comes first in the output file. + +NUMBER: 154 +MODULE: proto.fixpix +SYSTEM: V2.9 +DATE: Tue Aug 13 12:27:17 MST 1991 +FROM: valdes + +BUG: Interpolation across columns with type double images does not work. + +STATUS: Fixed in V2.10. There is no workaround other than to avoid this + rare combination of datatype and direction of interpolation. + +NUMBER: 155 +MODULE: apphot.radprof +SYSTEM: V2.9 +DATE: Mon Aug 26 11:25:36 MST 1991 +FROM: davis + +BUG: 1. Radprof was computing the total intensity of the fitted radial + profile by integrating (RP) instead of the physically meaningful + quantity 2 * PI * (r * RP). + + 2. The computed total intensity (TINORM) was too small by a factor + equal to the profile step size in pixels, although the shape of the + curve was correct. + +STATUS: Both bugs have been fixed in 2.10. Bug 1 was fixed some time ago + at the request of a user at ST, but was not previously logged. + There is no workaround. Bug 2 was only recently discovered. + The workaround is to multiply the quantity TINORM by the step size + in pixels, and compare it to the aperture photometry results. + The two numbers should be equal to within the expected errors. + +NUMBER: 156 +MODULE: images.imstatistics +SYSTEM: V2.9 +DATE: Tue Sep 24 09:17:16 MST 1991 +FROM: davis + +BUG: The mode statistic was not being computed correctly in imstatistics, + because the parabolic interpolation correction for computing the + histogram peak was being applied in the wrong direction. + +STATUS: The bug has been fixed in IRAF 2.10 and the help page which uses + dev$pix as an example has been modified appropriately. There is no + workaround. + +NUMBER: 157 +MODULE: XC compiler +SYSTEM: V2.9 Sun/IRAF, all versions +DATE: Wed Oct 9 14:22:11 MST 1991 +FROM: tody + +BUG: XC will not recognize the V1.4 Sun Fortran compiler. The bug is due + to XC looking for V1.3 and finding V1.4 instead. + +STATUS: The workaround is to do a "ln -s f77-1.4 f77-1.3" in /usr/lang, or + wherever the compiler is installed. + +NUMBER: 158 +MODULE: dataio.rfits +SYSTEM: V2.9 +DATE: Wed Oct 9 15:50:36 MST 1991 +FROM: davis + +BUG: IRAF 2.9 rfits was not reading fits files with short last logical + records correctly, i.e. records not correctly padded out to 2880 + bytes. For each output image line contained or partially contained + in the final short record, an error message was generated, + and incorrect data was written to the output image. + +STATUS: The bug has been fixed in 2.10 and was not a problem in IRAF 2.8 + and earlier. The workaround is to use Unix dd command or the IRAF + reblock task to reformat the file. + +NUMBER: 159 +MODULE: images.imstatistics +SYSTEM: V2.9 +DATE: Fri Oct 11 13:54:19 MST 1991 +FROM: davis + +BUG: The computed value of the kurtosis was 1.0 too small, i.e. a + Gaussian distribution would have a computed kurtosis of -1.0 + instead of 0.0. + +STATUS: The bug has been fixed in IRAF 2.10. The workaround is to add + 1.0 to the computed value of the kurtosis. + +NUMBER: 160 +MODULE: onedspec.standard +SYSTEM: V2.9 +DATE: Thu Oct 17 09:22:06 MST 1991 +FROM: valdes + +BUG: If the calibration bandpasses are less than a pixel wide the flux + summation is incorrectly done when both endpoints are within the + same pixel; the code assumed that the two endpoint pixels were + not the same. Generally the calibration data, in onedstds$, has + much larger bandpasses than typical spectra and so this bug has + not be seen except in one reported case where a private calibration + file with very small bandpasses was used. + +STATUS: Fixed in V2.10. The workarounds are to revise the calibration + file to larger bandpasses (if using a private version), resample + the spectra to smaller dispersion, or, the best choice, specify + the bandpass widths and separations in the task to override the + calibration file bandpasses and interpolate the calibration file + data. + +NUMBER: 161 +MODULE: apextract.apsum +SYSTEM: V2.9 +DATE: Wed Oct 30 11:02:38 MST 1991 +FROM: valdes + +BUG: If the background regions go off the image, due to tilts in the + spectrum such as with echelle data, while the object apertures + remains on the image a segmentation violation occurs. This will + only happen with one-sided background regions as otherwise this + condition could not occur. The error is caused by a failure to + check for an error condition from background fitting. + +STATUS: This error is fixed in V2.10. The workaround is to insure + at least part of the background regions are on the image while the + object aperture is on the image. This would be true if background + regions are defined on both sides of the aperture. Note that it is + ok for the object aperture and background regions to both be off + the the image. The source fix is simple and could be supplied if + absolutely necessary. + +NUMBER: 162 +MODULE: reidentify +SYSTEM: V2.9 +DATE: Mon Nov 18 10:27:25 MST 1991 +FROM: valdes + +BUG: If reference features are identified in user coordinates other than + pixels, usually Angstroms for arc lines, and the user forgets to + type 'f' to fit a dispersion function, then REIDENTIFY will + compute a very large coordinate shift and then fail to trace + any features. + +STATUS: The workaround is to recognize this behavior and then go back and + do a dispersion function fit for the reference. The logical bug + in the task is fixed in V2.10. + +NUMBER: 163 +MODULE: artdata.gallist +SYSTEM: V2.9 +DATE: Tue Nov 26 17:07:03 MST 1991 +FROM: valdes + +BUG: The randomization of the galaxy size distribution when using the + Schecter luminosity function is incorrect. Instead of a 20% range + about the scaled eradius/sradius for a given magnitude a range of + 100% is computed coupled with a reduction of the size by a factor + of 2.5. + +STATUS: There is no workaround for the increased dispersion but the factor + of 2.5 in the size can be compensated by adjusting the eradius + parameter. This has been fixed in V2.10 + +NUMBER: 164 +MODULE: artdata.gallist +SYSTEM: V2.9 +DATE: Tue Nov 26 17:11:37 MST 1991 +FROM: valdes + +BUG: The axial ratios for elliptical galaxies when a mixture of spiral + elliptical galaxies is computed are incorrect. In particular + there will be axial ratio values greater than 1 in the output + file. + +STATUS: The work around is to compute the elliptical and spiral galaxy + data separately. This has been fixed in V2.10. + +NUMBER: 165 +MODULE: plot.pvector, proto.imexamine +SYSTEM: V2.9 +DATE: Wed Dec 11 11:32:36 MST 1991 +FROM: davis + +BUG: Profiles computed and plotted using the pvector task or the 'v' + key in imexamine occasionally show glitches, where 1-3 pixels + have bad values. This bug was traced to any error in + the column limits computed by the code which reads the + image pixels. As a result the image interpolator was requesting + values off the ends of the pixel array producing bad output values. + +STATUS: The bug has been fixed in 2.10. There is no workaround. + +NUMBER: 166 +MODULE: apphot.polyphot +SYSTEM: V2.9 +DATE: Tue Feb 25 16:37:41 MST 1992 +FROM: davis + +BUG: The intersection points of an image line and a polygon could be + incorrectly translated into a list of line segments if the polygon + was concave and contained one or more sides exactly collinear with + the image line. The symptom of this problem is a larger than expected + difference (larger than can be accounted for by fractional pixel + effects) in the computed area of the polygon as it is shifted + to different positions in the image (shifting by floating point + numbers tends to remove the condition of exact collinearity); + or larger than expected differences in the area and flux + of the same object measured with the same polygonal aperture + at slightly different positions in different images (again + shifting the polygon tends to remove the condition of exact + collinearity). + +STATUS: The bug has been fixed in 2.10. There is no work around except to + alter the shape of the polygon slightly. + +NUMBER: 167 +MODULE: images.imstatistics +SYSTEM: V2.9 +DATE: Tue Mar 10 14:58:59 MST 1992 +FROM: davis + +BUG: Precision was being lost unnecessarily in the computation of the + standard deviation, skew, and kurtosis because two of the + intermediate variables in the computation were real instead of + double precision. + +STATUS: The bug is fixed in 2.10. There is no workaround. + +NUMBER: 168 +MODULE: noao.twodspec.longslit.fluxcalib +SYSTEM: V2.9 +DATE: Thu Mar 19 11:27:18 MST 1992 +FROM: valdes + +BUG: Flux calibrating a short pixel type image will produce a short + pixel type output image which is generall all zeros since the + typical flux values are of order 10e-14. + +STATUS: The workaround is to convert the images to real (with chpixtype for + instance) before flux calibrating. For V2.10 the output image + will be of type real pixels. + +NUMBER: 169 +MODULE: imred.irs.batchred, imred.iids.batchred +SYSTEM: V2.10 +DATE: Mon Jul 6 10:01:35 MST 1992 +FROM: valdes + +BUG: The PROCESS script generated by BATCHRED included parameters no + longer part of STANDARD and CALIBRATE. Running this task produces + the error + + ir> process + ERROR on line 9: parameter `recformat' not found + process () + process () + +STATUS: To be fixed in V2.10.0. The workaround is to edit the process.cl + script generated by BATCHRED and delete two cases of "recformat=yes," + and one case of "apertures='',". + +NUMBER: 170 +MODULE: apphot +SYSTEM: V2.9 +DATE: Wed Jul 8 17:43:45 MST 1992 +FROM: davis + +BUG: The apphot tasks were failing to close up the coordinate files + in the case that 1) the number of input images was greater + than one and 2) the input coords parameter was set to "default". + If the input image list was sufficiently long the task could run + out of file descriptors producing a system error. + +STATUS: The bug is fixed in 2.10.0. The workaround is to break the image + lists into smaller groups (<= ~ 60). + +NUMBER: 171 +MODULE: apextract.apfit, apextract.apflatten +SYSTEM: V2.10.0 +DATE: Thu Jul 9 16:17:01 MST 1992 +FROM: valdes + +BUG: In these tasks which output the difference, ratio, or fit + based on a profile model the profile model is low by a factor of + the gain. Thus if the gain is not one the results will not be + correct. For example APFLATTEN will produce flat field values + within the aperture which are multiplied by the gain except outside + the apertures. The workarounds are either to use a gain of 1 or + correct the output such as with IMARITH. The latter option may be + difficult to apply for APFLATTEN since special steps need to be + taken for the interaperture values. Note that using an gain of 1 + even though the true gain is higher will often be unimportant, + especially if cosmic ray cleaning is not done. + +STATUS: Fixed in V2.10.1. + +NUMBER: 172 +MODULE: onedspec +SYSTEM: V2.10.0 +DATE: Mon Jul 20 14:24:07 MST 1992 +FROM: valdes + +BUG: The ability to extract and operate on long slit images using the + dispaxis/nsum parameters does not work. There is no workaround; + which is particularly unfortunate since TOONEDSPEC is no longer + available. One must resort to APEXTRACT to extract 1D spectra + from long slit images. + +STATUS: Fixed in V2.10.1 + +NUMBER: 173 +MODULE: images.gauss +SYSTEM: V2.10 +DATE: Thu Jul 23 08:17:27 MST 1992 +FROM: davis + +BUG: An incorrect convolution kernel is computed in the case theta=90.0, + 0.0 < ratio < 1.0, and bilinear=yes. The long axis of the kernel is + aligned along the x axis instead of the y axis as intended. + + The workaround is to set bilinear=no. + +STATUS: Fixed in 2.10.1 + +NUMBER: 174 +MODULE: onedspec.dopcor +SYSTEM: V2.10.1 +DATE: Thu Jul 30 16:29:31 MST 1992 +FROM: valdes + +BUG: There is a sign error in the conversion from velocity to redshift. + Thus one has to change the sign of velocities to get the effect + described in the documentation. The documentation was also + misleading in how to add a redshift in that one needs to complement + the redshift (1/(1+z)-1) rather than reverse the sign of the + redshift. The example is therefore incorrect. + +STATUS: The task has been modified to correct the sign error and to add + consistency checks on the redshifts and velocities. The help + has been improved and the erroneous example corrected. + +NUMBER: 175 +MODULE: tv.imexamine +SYSTEM: V2.9-V2.10.1 +DATE: Fri Jul 31 12:06:34 MST 1992 +FROM: valdes + +BUG: Attempting to use a single column or line at the top or left edge + (high column/line numbers) of an image yields an out-of-bounds + message. For some reason (typo?) the simple test for out-of-bounds + had an greater than or equal to with the edge rather than a greater + than. There is no workaround. + +STATUS: Fixed for V2.10.2 + +NUMBER: 176 +MODULE: images.imsurfit +SYSTEM: V2.9.2 and later +DATE: Mon Aug 3 15:12:01 MST 1992 +FROM: davis + +BUG: There is a typo in the imsurfit code which reads the sections file, + which can result in some sections specified by the user being ignored + in the fitting process. Whether or not the code executes correctly + depends on section specifications themselves since the intended + test "if (y2 < y1)" was actually coded as "if (y2 < x1)". + +STATUS: The bug is fixed in 2.10.1. There is no workaround. + +NUMBER: 177 +MODULE: images.imcombine, ccdred.combine, onedspec.scombine +SYSTEM: V2.10-V2.10.1 +DATE: Wed Aug 12 10:30:19 MST 1992 +FROM: valdes + +BUG: The minmax rejection option when used with a final average and with + weights does not correct for the rejected pixels in the weights + normalization. For example with four images having identical + weights and rejecting the high and low the final output is the sum + of the middle pixels divided by 4 instead of 2. There is no + workaround. If the weights are equal the end result is just that + the mean intensity levels are low by a constant factor. However, + when the weights are not equal the final result will have pixel + position dependent effects. + +STATUS: Fixed for V2.10.2 + +NUMBER: 178 +MODULE: images.fmedian +SYSTEM: V2.9 +DATE: Tue Aug 18 11:31:49 MST 1992 +FROM: davis + +BUG: The fmedian task can crash with a segmentation violation or a + floating operand error if image pixel to integer mapping is turned + off (hmin = zmin and hmax = zmax) and the input image contains + data outside the range defined by zmin and zmax. The bug is not + seen often because for most ccd images the data is between -32768 + and 32767. + +STATUS: The bug is fixed in 2.10.1. The work-around is to either let zmin and + zmax default to the image minimum and maximum or set hmin and hmax + to numbers that are slightly different from hmin and hmax. + +NUMBER: 179 +MODULE: daophot.allstar +SYSTEM: V2.10 +DATE: Wed Sep 16 14:37:46 MST 1992 +FROM: davis + +BUG: If 1) cache=no, or cache=yes and memory preallocation fails for one or + more of the data, scratch or weight arrays, 2) one or more of the + groups has greater than maxgroup stars, 3) regrouping is + performed on the too large group and 4) the first star in the + next non-regrouped group has a y value less than the y value of + the first star in one of the regrouped groups, allstar can + fail with an "attempt to access the scratch, weight, or data pixels + randomly" error. + +STATUS: The bug is fixed in 2.10.2. Possible work arounds include: 1) setting + cache=yes instead of no if the machine has enough memory and swap + space 2) setting the maxgroup parameter to a larger value than the + default value of 60 3) decreasing the fitting radius somewhat since + this affects the grouping process. + +NUMBER: 180 +MODULE: identify/reidentify +SYSTEM: V2.10.1 +DATE: Wed Sep 16 16:24:05 MST 1992 +FROM: valdes + +BUG: If a spectrum is shifted using IMSHIFT with a positive shift + then the physical pixel coordinates are incorrectly computed. + The workaround is to reset the WCS with WCSRESET. + +STATUS: Fixed in V2.10.2. + +NUMBER: 181 +MODULE: ccdred.ccdproc +SYSTEM: V2.9(?) V2.10.1 +DATE: Tue Sep 22 08:40:14 MST 1992 +FROM: valdes + +BUG: When using STF images with a flat field that has been processed but + has lost the CCDMEAN keyword CCDPROC will produce an error of the + form: + + ERROR: OPEN: File does not exist (tmp4294ha.hhd) + + A flat field in this state would most likely be produced by + FLATCOMBINE with preprocessing before combining selected. The + combined flat field will lack the CCDMEAN keyword. + + The workarounds are to either use OIF images or add the CCDMEAN + keyword manually. This would be done by using IMSTAT to compute + the mean and adding the CCDMEAN keyword with that value using + HEDIT. + +STATUS: The error is ignored by CCDPROC in V2.10.2. The reason for the + error when calling imunmap with an image which has been created + but for which no pixel data has been written is under investigation. + +NUMBER: 182 +MODULE: apnormalize +SYSTEM: V2.10.1 +DATE: Tue Sep 22 13:40:26 MST 1992 +FROM: valdes + +BUG: The parameter t_nlost is missing from the parameter file apnorm1.par. + When attempting to run APNORMALIZE there will be an error message + concerning this parameter. It can be fixed if desired by adding + the following line after line 63 in the file + iraf$noao/twodspec/apextract/apnorm1.par: + + t_nlost,i,h,)aptrace.nlost,,,>aptrace.nlost + + After adding this parameter one must "unlearn apnorm1". There is + no workaround other than to add the parameter. + +STATUS: Fixed in V2.10.2 + +NUMBER: 183 +MODULE: doargus, dohydra, dofibers, skysub +SYSTEM: Newimred, V2.10.0, V2.10.1 +DATE: Wed Sep 23 15:57:40 MST 1992 +FROM: valdes + +BUG: When using the skyedit option to review and eliminate bad sky + apertures there is a limit to the number of sky apertures that + can be retained. Exceeding this limit can cause the CL to crash. + The limit is determined by how many aperture + numbers can be fit into 160 characters in a string of the form + 11,12,13,...; for 2 digit aperture numbers this would be a + little over 50 sky apertures. The workarounds are to use less + than about 50 sky apertures or to not use the sky edit option. + +STATUS: Planned to be fixed in V2.10.2. + +NUMBER: 184 +MODULE: splot +SYSTEM: V2.10.1 +DATE: Thu Sep 24 08:48:57 MST 1992 +FROM: valdes + +BUG: The '(' and ')' keys for scrolling through multiple spectra images + does not work properly in cases where the aperture numbers are + not the same as the line number. The only workaround is to use + the explicit '#' key to access particular apertures. + +STATUS: Fixed in V2.10.2 + +NUMBER: 185 +MODULE: imcombine, ccdred.combine, onedspec.scombine +SYSTEM: V2.9 +DATE: Thu Oct 1 17:06:23 MST 1992 +FROM: valdes + +BUG: When using the CCDCLIP or CRRJECT rejection option with mclip=yes + (which is the default) a minimum of 3 images/spectra is required. + This means that two image/spectrum cosmic ray rejection doesn't + work as intended. The workaround is to use mclip=no. This is + equivalent for two images/spectra since the median and average are + the same in this case. + +STATUS: Fixed in V2.10.2. + +NUMBER: 186 +MODULE: ccdred.ccdproc +SYSTEM: V2.9-V2.10.1 +DATE: Mon Oct 26 11:04:21 MST 1992 +FROM: valdes + +BUG: If an image is processed which has an unknown CCD type it will have + the minimum replace operation applied to it. This operation is + only supposed to apply to flat field types. The workarounds are + to setup/define a translation allowing the CCD types to be + determined or to set the minreplace parameter to a very large + negative value to avoid limiting the data. Note that this will + only apply to data which has low or negative values in the first + place. + +STATUS: Fixed for V2.10.2. + +NUMBER: 187 +MODULE: echelle.dofoe +SYSTEM: V2.9 +DATE: Thu Oct 29 10:32:12 MST 1992 +FROM: valdes + +BUG: When there is a second arc it is incorrectly extracted with a + .ms extension instead of a .ec extension causing downstream + processing to fail. The workaround is to rename the file + to .ec and then start again. + +STATUS: Fixed in V2.10.2. + +NUMBER: 188 +MODULE: longslit.fitcoords +SYSTEM: V2.6-2.10.1 +DATE: Wed Nov 11 10:43:43 MST 1992 +FROM: valdes + +BUG: FITCOORDS is supposed to ignore features which have an INDEF + for the line identification. This was not happening but instead + some random value was substituted for the INDEF. The workaround + is to avoid creating features with INDEF in IDENTIFY. + +STATUS: In V2.10.2 any features with INDEF line ids will be ignored. + +NUMBER: 189 +MODULE: onedspec.splot/specplot +SYSTEM: V2.10-V2.10.2 +DATE: Fri Dec 4 09:41:16 MST 1992 +FROM: valdes + +BUG: The units conversion to millimeters and centimeters is off by a + factor of 10 too large. The inverse function on these units + will be off by a corresponding amount. + +STATUS: Fixed for the next release. + +NUMBER: 190 +MODULE: longslit.fitcoords +SYSTEM: V2.10-V2.10.2 +DATE: Mon Dec 7 11:05:09 MST 1992 +FROM: valdes + +BUG: If "combine=yes" and the input images do not have the same fit axis + a segmentation error occurs. The task is supposed to ignore all + images which don't agree with the first image in the fit axis but + there is a bug where it attempts to clean up for a skipped image + using a NULL pointer. The workaround is to check that all the + images being combined have the same fit axis. Note that a likely + cause of this error is to inadvertently have combine=yes though + what is really desired is combine=no to fit all the inputs + separately in which case both fit axes can be done in one + execution. + +STATUS: It is fixed and a warning is now printed when mismatched fit axes + are encountered indicating which input image(s) are ignored. + Currently expected to be released with V2.10.3. + +NUMBER: 191 +MODULE: apextract.apscatter (and in related packages) +SYSTEM: V2.10-V2.10.2 +DATE: Tue Dec 8 17:24:34 MST 1992 +FROM: valdes + +BUG: If interactive=no then the smooth parameter is ignored and the + scattered light subtraction will not apply the smoothing along + the dispersion. There is no way around this. The only suggested + partial workaround is to leave interactive=yes, set fitsmooth=no + and fitscatter=no, and then answer NO for the queries. With + a list of images this will then process all further images with + no queries. + +STATUS: Fixed for the next release of the APEXTRACT package (expected to be + V2.10.3). + +NUMBER: 192 +MODULE: photcal.fitparams +SYSTEM: V2.10 +DATE: Thu Dec 17 17:22:04 MST 1992 +FROM: davis + +BUG: The fitparams task could produce incorrect weight, chi, and fitted + parameter error estimates in the case that weighting=photometric, + nreject > 1, and low_reject > 3.0 || high_reject > 3.0. + This problem was occuring because the weight array was not + being reinitialized correctly after each iteration of the rejection + cycle. The actual problem was in the inlfit package routine + inlfit$inreject.gx. + +STATUS: The bug is fixed for the next release of IRAF. The work around is + to use interactive bad point deletion with the graphics cursor instead + of the automatic iterative rejection algorithm. + +NUMBER: 193 +MODULE: sensfunc +SYSTEM: V2.9-2.10.2 +DATE: Mon Dec 21 13:01:36 MST 1992 +FROM: valdes + +BUG: SENSFUNC will not work when the standards file has a starting + wavelength greater than the ending wavelength. The workarounds + are to linearize the spectra with an increasing wavelength, + flip the spectra in STANDARD (i.e. standard spec[-*]), or + edit the standards file to reverse the starting and ending + wavelengths. In the latter two cases the sensitivity function will + then have a reversed sense from the data but the calibration will + still correctly match wavelengths. + +STATUS: It is the intention that no spectral task care which way the + wavelength runs relative to the pixels. SENSFUNC has been + modified to work in either case for the next release. + +NUMBER: 194 +MODULE: splot +SYSTEM: V2.10.2 +DATE: Thu Dec 31 10:34:52 MST 1992 +FROM: valdes + +BUG: The 'e' key in SPLOT either produces a floating operand error or + a nonsensical equivalent width when the data values are less than + about 1e-10 such as is the case with flux calibrated spectra. + This problem was introduced due to a change in a system routine. + The workaround is to scale the data, say with IMARITH or SARITH, + to yield pixel values near unity. The equivalent width and + wavelengths will be independent of the scaling and the other flux + quantities will simply have the same scale factor. + +STATUS: Fixed for the next release. + +NUMBER: 195 +MODULE: daophot.allstar +SYSTEM: V2.10 +DATE: Sun Jan 3 11:04:59 MST 1993 +FROM: davis + +BUG: In crowded regions allstar could occasionally refuse to 1) fit a + bright star or group of bright stars, or 2) fail to converge to + reasonable x,y, and magnitude values for a group of bright + stars by the time the number of iterations equaled maxiter, + resulting in a group of stars with very poor subtractions and + large chi values. + + The problem was caused by a bug in the code which steps through the + stellar groups, subtracting off the current best fit for all the + stars, to produce a residuals image. Due to this bug, on occasion + stars which should have been subtracted from the residuals image + were not being subtracted. Since the residuals image is used to + determine the relative errors and weights, which in turn are used + to control the bad data rejection algorithm, allstar sometimes + refused to fit stars because the residuals were too big or could + not converge to a reasonable value. This bug is data dependent + but is most likely to be a problem if, 1) the stellar detection + threshold is very low, 2) allstar has to do a lot of regrouping to + get the groups below maxgroup in size 3) the fitting radius is + large resulting in very large groups. + +STATUS: This bug is only a problem in 2.10 (not in the external testphot + package) and has been fixed for the next release of IRAF. There + is no reliable workaround for allstar, but the nstar task which fits + fixed groups does not have this problem. + +NUMBER: 196 +MODULE: splot +SYSTEM: V2.10.2 +DATE: Fri Jan 8 16:39:01 MST 1993 +FROM: valdes + +BUG: Use of "zero" in the option parameter (or ymin=0.) or the 'b' key + with flux calibrated data causes a plot with limits -0.01 and 0.01 + making the data appear all zero. The workaround is to set the + minimum value to a number much smaller than the data but not + exactly zero. For example setting ymin=1e-30 when the data + is around 1e-14. This plot limit behavior applies to all tasks + (GRAPH, IMPLOT) but is most likely to appear in SPLOT with flux + calibrated data. + +STATUS: A change to a system routine is required and has been requested. + +NUMBER: 197 +MODULE: images.imcombine, ccdred.combine (and related scripts) +SYSTEM: V2.10.2 +DATE: Wed Jan 20 15:54:28 MST 1993 +FROM: valdes + +BUG: When reject=[avsigclip|sigclip|ccdclip|crreject|pclip], combine=average, mclip=yes, and nkeep!=0 there is a rare possiblity of a segmentation + error. This is more likely the fewer pixels are allowed to be + rejected. This occurs in the step where the pixels with the lowest + residuals are added back after too many are rejected and the + pattern of rejections is such that only low pixels have been rejected. + The sure workaround is to change the combine option to a median + or mclip=no. However, changing other parameters such as nkeep, + the sigma thresholds, or the combining algorithm is likely to + avoid the problem. + +STATUS: Fixed for V2.10.3. + +NUMBER: 198 +MODULE: images.imcombine +SYSTEM: V2.10.2 +DATE: Wed Jan 20 16:30:10 MST 1993 +FROM: valdes + +BUG: The CCDCLIP and CRREJECT algorithms quietly fail to reject any pixels. + The basic source code is actually correct but due to a dependency + condition based on file dates the wrong derived code wes used + resulting in a mismatched argument list. This mismatch generally + results in the rejection algorithm seeing that there are zero + images to process and so no rejection is done. The workarounds + are to use a different rejection option or the CCDRED.COMBINE + version which is the same except for the ccdtype, keyword + mapping, and filter subset features. + +STATUS: Fixed in V2.10.3. + +NUMBER: 199 +MODULE: tv.wcslab +SYSTEM: V2.10 +DATE: Thu Jan 28 11:10:51 MST 1993 +FROM: davis + +BUG: Wcslab was failing with the error "error processing newline" for + images which were sections of a higher dimensioned parent images, + and whose coordinate system was "physical" or not recognized + recognized by wcslab, e.g. glon,glat. The actual error message + was coming from the cl and was due to a trailing \n in the + string passed to the error trapping routine. The actual problem was due + to an error in the wcslab axis mapping code which was failing + to take proper account of an existing axis map. + +STATUS: The bug is fixed in 2.10.3. A possible workaround is to temporarily set + the wcsdim parameter in the image header to be equal to the dimension + of the image. + +NUMBER: 200 +MODULE: astutil.rvcorrect +SYSTEM: V2.10-V2.10.2 +DATE: Mon Feb 1 10:31:22 MST 1993 +FROM: valdes + +BUG: When using RVCORRECT with a list of input images that don't have + the OBSERVAT keyword, the observatory name supplied by the user in + the parameter file is truncated to two characters. An error + message is printed and a prompt is issued for another name. + Replying to this prompt allows the task to complete; i.e. the reply + to the prompt is not truncated. This is caused by a typo in + RVCORRECT which reads only the first two characters from the + observatory parameter. The workarounds are to either enter the + proper observatory when prompted or set the observatory in the + image headers under the keyword OBSERVAT. + +STATUS: Fixed for the next release (currently expected to be V2.10.3). + +NUMBER: 201 +MODULE: identify +SYSTEM: V2.10-V2.10.2 +DATE: Wed Feb 3 16:49:36 MST 1993 +FROM: valdes + +BUG: The 'i' initialize key fails to initialize the wavelength scale. + +STATUS: Fixed in V2.10.3. + +NUMBER: 202 +MODULE: apscatter, doecslit +SYSTEM: V2.10-V2.10.2 +DATE: Fri Feb 5 15:25:52 MST 1993 +FROM: valdes + +BUG: When using the APSCATTER option (either directly or in the + DOECSLIT script) without specifying an output name instead + of a temporary image name being used for intermediate results + the name ".imh" is used. This is a hidden file and if the + task aborts or is aborted it will be left behind and prevent + any further use of this task. The workaround is to recognize + that this is why it fails to work and delete the image + ".imh". + +STATUS: Fixed in V2.10.3. + +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. + +NUMBER: 204 +MODULE: daophot +SYSTEM: V2.10 +DATE: Tue Feb 16 09:08:48 MST 1993 +FROM: davis + +BUG: The parameters psfrad, fitrad, and matchread were being written + to the daopars parameter set in pixel units instead of scale units + if the daophot task update parameter was on. + +STATUS: Fixed for the next release of iraf. There is no workaround except + to turn off the update parameter or always check the input + parameters using the verify parameter. + +NUMBER: 205 +MODULE: imslice +SYSTEM: V2.9 +DATE: Tue Feb 16 13:52:34 MST 1993 +FROM: davis + +BUG: Removed a check that was preventing imslice from being used to reduce + the dimensionality of images where the length of the slice_dimension + = 1. + +STATUS: Fixed for the next version of iraf. The work around is to use imcopy. + +NUMBER: 206 +MODULE: photcal.obsfile +SYSTEM: V2.10 +DATE: Mon Mar 1 15:18:47 MST 1993 +FROM: davis + +BUG: The obsfile task was not decoding the image names correctly from the + obsparams file, when obsfile was being called directly from the cl + rather than from the script tasks mknobsfile and mkobsfile. Since + obsfile could not match the names of the images in obsparams with + those in imsets it simply ignored the contents of the obsparams + file. + +STATUS: The bug is fixed for the next release of iraf. There is no workaround. + +NUMBER: 207 +MODULE: splot +SYSTEM: V2.10-V2.10.2 +DATE: Tue Mar 2 14:47:45 MST 1993 +FROM: valdes + +BUG: When doing arithmetic between two spectra and an invalid image + name is entered for the second spectrum , usually because of a + typo, the correct error message is returned. However, attempting + to repeat the operation, say with the correct image name, results + in a segmentation error and the task aborts. This will continue + to happen until the task is flushed from the process cache. The + workaround is simple to flush the processes cache with + the command "flpr splot". + +STATUS: Fixed for the next release (V2.10.3) + +NUMBER: 208 +MODULE: adccdrom.catalog +SYSTEM: adccdrom external package: archive prior to March 4, 1993 +DATE: Thu Mar 4 16:03:16 MST 1993 +FROM: valdes + +BUG: Use of the "evsptype" function results in a segmenation or bus + error. This was caused by using a wrong pointer datatype. + There is no workaround other than to not use this function. + However the external package archive was updated. + +STATUS: Fixed in the archive version of March 4, 1993. + +NUMBER: 209 +MODULE: doslit, doecslit +SYSTEM: V2.10-V2.10.2 +DATE: Wed Mar 17 11:10:30 MST 1993 +FROM: valdes + +BUG: The input list of arcs is sorted alphabetically and first sorted + arc is used as the arc reference rather than the first specified + by the user. The workaround is to rename the desired reference + arc to be first alphabetically. + +STATUS: Fixed in V2.10.3. + +NUMBER: 210 +MODULE: photcal.mknobsfile,photcal.mkobsfile,photcal.obsfile +SYSTEM: V2.10 +DATE: Fri Apr 2 11:45:11 MST 1993 +FROM: davis + +BUG: The mknobsfile,mkobsfile, and obsfile task were occasionally dropping + stars from the output observations file in the case that: 1) the + parameter allfilters=no, 2) there were multiple matches to a + given star in 1 or more filters, and 3) the closet matching star was + not the first candidate star found. + + This bug was occuring because the code was correctly matching to + the nearest of the possible candidate stars, but was not resetting + the matching index from the previous star, confusing the indexing + scheme, and causing the incorrectly matched star to be dropped + from the list. + +STATUS: The bug is fixed in 2.10.3. There is no fullproof workaround but + accurately determining the shifts between frames and using small + matching tolerances will minimize the problem. + + +NUMBER: 211 +MODULE: longslit.fitcoords +SYSTEM: V2.10 - V2.10.2 +DATE: Mon Apr 5 10:01:12 MST 1993 +FROM: valdes + +BUG: When there are many samples to be fit an 'Out of memory" error can + occur. This is caused by repeatedly opening an image section + for each sample and failing to close it. If there are enough + samples this can cause memory to run out. If this happens on + other than the first invocation of FITCOORDS then the workaround + is to flush the process cache between executions, "flpr fitcoords". + If it happens on the first execution then the only workaround is to + reduce the amount of data being fit by using a larger step size, + and avoiding multiple runs of REIDENTIFY (since redoing an + IDENTIFY appends to the database rather than replacing resulting + in multiple entries). For marginal cases it might be possible to + make sure the process has the maximum amount of memory + available by minimizing memory use by other processes. + +STATUS: This is a rather severe bug which is fixed in V2.10.3. + +NUMBER: 212 +MODULE: scombine +SYSTEM: V2.10-V2.10.2 +DATE: Thu Apr 22 09:54:07 MST 1993 +FROM: valdes + +BUG: When combining spectra which have log sampling (DC-FLAG=1) and + one chooses log=yes the dispersion per pixel parameter is incorrectly + computed in the output. The workaround is to use the + first=yes option. + +STATUS: Fixed in V2.10.3 + +NUMBER: 213 +MODULE: images.imcombine ccdred.combine +SYSTEM: V2.9-V2.10.2 +DATE: Mon May 10 14:57:05 MST 1993 +FROM: valdes + +BUG: When using a median combining operation, no rejection or with + mclip=no, and outputing a sigma image, the sigma image is incorrect. + This is due to the median computation destroying some of the + input data values before the sigma is computed. The workaround + when both output median and sigma images are desired is to used + one the rejection options with mclip=yes. By choosing the + rejection option sigclip with low and high sigma thresholds + of 1000 no pixels will be rejected and the results are the + same as not specifying a rejection algorithm. + +STATUS: Fixed in V2.10.3. + +NUMBER: 214 +MODULE: scopy, sarith +SYSTEM: V2.10-V2.10.2 +DATE: Thu May 20 17:07:53 MST 1993 +FROM: valdes + +BUG: When using SCOPY or SARITH with a specified wavelength range, + w1 and w2 not equal to INDEF, and rebin=yes the spectra are + correctly resampled to the requested wavelength interval but + the coordinate system in the header is updated incorrectly. + The coordinates may be off by a fraction of a pixel. For + example if w1=6400 and w2=6600 the output data will have + the first pixel at 6400 but the coordinate reported by + LISPIXEL or any other task might be 6400.25 (where the + dispersion is, say, 3 Angstroms per pixel). This error + is caused during the conversion from logical to physical + pixel coordinates when the physical coordinates are treated + as integer; i.e. a wavelength of 6400 for the first logical + pixel might be physical pixel 185.325 but it is then + truncated to 185 and the coordinate system is set so + that physical pixel 185 is 6400 and pixel 185.325 is + 6400.25. This is a subtle error which may be discovered + by looking at the coordinate of the first pixel with LISTPIX + and comparing it with the requested wavelength of the first pixel. + +STATUS: Fixed in V2.10.3. + +NUMBER: 215 +MODULE: imcombine, ccdred.combine +SYSTEM: V2.10-V2.10.2 +DATE: Wed May 26 14:06:15 MST 1993 +FROM: valdes + +BUG: The following combination of parameters give a floating divide + by zero due to an error in the code. Rejection is CRRJECT or + CCDCLIP, grow is greater than zero, and the images are offset. + The simplest workaround is to not use a growing factor (grow=0). + +STATUS: Fixed in V2.10.3 + +NUMBER: 216 +MODULE: noao.astutil.asttimes +SYSTEM: V2.9 +DATE: Thu May 27 15:01:18 MST 1993 +FROM: valdes + +BUG: The epoch printed is not clearly defined and the siderial time is + incorrect by a few seconds. There is also a gross error at the + new year for observatories with a negative time zone. The epoch + used is the day of the year, including the fraction of the day, + divided by a Julian year of 365.25 days. However the siderial + time calculation assumes a J2000 Julian epoch which is not the + same as the previous definition. The previous epoch definition + is also no smoothly continuous at the new year since some years + have 366 days and other 365 and no years have 365.25 days. + Other tasks in the ASTUTIL package also use the astronomical + time routines but it appears that generally the error cancels + out (because the date->epoch->julian date transformations use + the same epoch definition) or is insignificant (such as in + precession or air mass calculations). + +STATUS: For V2.10.3 the routines have been modified to consistently use + J2000 epochs. ASTTIMES will print these epochs and the + sideral times will not have the errors of a few seconds. + +NUMBER: 217 +MODULE: identify +SYSTEM: V2.9 +DATE: Fri Jun 4 10:00:06 MST 1993 +FROM: valdes + +BUG: The labels associated with marked features are not correctly + updated when a feature is deleted. The effect is that the + wrong labels get associated with the features after deletion. + There is no workaround though the labels are informational + so the main job of determining dispersion functions is unaffected. + +STATUS: Fixed in V2.10.3. + +NUMBER: 218 +MODULE: fitprofs +SYSTEM: V2.9 +DATE: Tue Jun 8 09:11:06 MST 1993 +FROM: valdes + +BUG: When the dispersion axis is 2 and the number of lines is greater + than the number of columns a floating operand error can occur. + This is caused by dimensioning an array by the number of columns + rather than the number of elements along the dispersion axis. + The workaround is to either use an image section to make the + number of lines equal to the number of columns or to transpose + the image. Transposing the image also requires reseting some + of the WCS keywords. + +STATUS: Fixed in V2.10.3. + +NUMBER: 219 +MODULE: images.geomap +SYSTEM: V2.9 +DATE: Wed Jul 7 11:04:31 MST 1993 +FROM: davis + +BUG: If the input coordinate file contains fewer than 3 stars geomap + dies with a segmentation violation. The problem was caused by + some missing errchk statements in the error handling code, with the + result that geomap tried to evaluate a non-existent solution. + +STATUS: The problem has been fixed in 2.10.3. + +NUMBER: 220 +MODULE: ptools.pconvert +SYSTEM: V2.9 +DATE: Wed Jul 28 08:34:39 MST 1993 +FROM: davis + +BUG: In append mode the pconvert task was refusing to append data to + columns derived from multi-valued quantities in the original + apphot/daophot text output, e.g. MAG[1]. + + The problem was due to an extraneous escape character "\" + infront of the "[" in the column specification (this is required + for column template expansion, but not for column definition). + +STATUS: Fixed in 2.10.3. There is no work-around. + +NUMBER: 221 +MODULE: images.imcombine, ccdred.combine +SYSTEM: V2.9-V2.10.2 +DATE: Wed Aug 4 15:48:03 MST 1993 +FROM: valdes + +BUG: When the number of input images + number of output images + + logfile (if used) is exactly 60 the task fails with error 757. For + example if there are 59 input images, an output image, and no + logfile this error occurs. The workaround is to add or eliminate + the logfile or else change the number of input or output images. + +STATUS: Fixed in V2.10.3. + +NUMBER: 222 +MODULE: images.fit1d, generic.background, longslit.background +SYSTEM: V2.10-V2.10.2 +DATE: Fri Aug 6 10:36:36 MST 1993 +FROM: valdes + +BUG: When the input and output images are the same the last part of + the image will not be modified. The workaround is to use + a different output image and then, if desired, delete the + original and rename the new image to the original image. + +STATUS: Fixed for V2.10.3. + +NUMBER: 223 +MODULE: photcal.fitparams +SYSTEM: V2.10 +DATE: Sun Aug 8 15:05:17 MST 1993 +FROM: davis + +BUG: Errors in the catalog and observations variables were not being + added to the total error computed for an observation by the fitparams + task if these variables were used in a set equation, the set equation + was then used in one or more of the transformation equations, and the + weighting parameter was set to photerrors. + +STATUS: The bug is fixed in iraf 2.10.3. Possible workarounds include use of + the weighting=equations option and avoiding the use of the set + equations in transformations equations. + +NUMBER: 224 +MODULE: apnormalize +SYSTEM: V2.10 - V2.10.2 +DATE: Fri Aug 27 18:40:27 MST 1993 +FROM: valdes + +BUG: When the dispersion axis is 1 and the "cenorm" option is selected + the result is not correct. One workaround would be to transpose + the image and the other is to not use the "cenorm" option. + +STATUS: Fixed in V2.10.3 + +NUMBER: 225 +MODULE: apfit, apnormalize +SYSTEM: V2.10 - V2.10.2 +DATE: Fri Aug 27 18:42:14 MST 1993 +FROM: valdes + +BUG: The results of the "fit" and "difference" in APFIT and of + APNORMALIZE are incorrect by a factor of the gain. This is + basically the same bug as 171 which was not correctly fixed. + The workarounds are to use a gain of 1. + +STATUS: Fixed in V2.10.3 + +NUMBER: 226 +MODULE: artdata.mkobjects +SYSTEM: V2.9-V2.10.2 +DATE: Fri Sep 17 14:13:24 MST 1993 +FROM: valdes + +BUG: The scales of the "expdisk" and "devauc" images are incorrect due + to an integer truncation error. The error is such that the actual + output radius for a given input radius is given by the formulas: + + expdisk: rout = rin * int(ln(D)/1.6783) / ln(D)/1.6783 + devauc: rout = rin * int(ln(D)/7.67)**4) / (ln(D)/7.67)**4 + + where D is the dynamic range parameter in the ARTDATA package + parameters, ln() is the natural logarithm, int() is the integer + truncation function, and ** is the exponentiation operator. + From this one can, fudge the input radii to give the + desired output radii, select a dynamic range where the correction + factor is 1, or account for this as needed when the artificial + image is analyzed. The simplest thing is to adjust the dynamic + range; for example, a dynamic range of 126514 for the "expdisk" + model is the closest to the default value of 10000 which will give + correct output scales. + +STATUS: Fixed in V2.10.3 + +NUMBER: 227 +MODULE: longslit.transform +SYSTEM: V2.8-V2.10.2 +DATE: Sun Sep 19 14:21:35 MST 1993 +FROM: valdes + +BUG: If the requested output coordinates extend outside of the input + data range, the interpolated output data very near the edge + may suffer a small stretch distortion. The error is confined + to the end 50th of the image and the magnitude of the stretch + depends on the specifics of the requested output sampling. + The workaround is to either creating an output image + which extends beyond the input data range. + +STATUS: Fixed in V2.10.3 + +NUMBER: 228 +MODULE: images.imsurfit +SYSTEM: V2.9 +DATE: Wed Sep 22 13:29:23 MST 1993 +FROM: davis + +BUG: Bugs in the bad pixel rejection code were causing the imsurfit task + to either 1) hang or crash with a segmentation violation or 2) + display oscillating behavior (sigmas which would decrease then + increase again after succesive iterations), if the number of + detected bad pixels was very large. The first problem was caused + by a failure of the code to allocate sufficient space for the bad + pixel list. The second problem was caused by a failure of the code + to correctly resolve overlapping regions in some circumstances, + causing the same pixels to be alternately rejected and included + in the fit. + +STATUS: Fixed in 2.10.3. + +NUMBER: 229 +MODULE: images.imcombine, ccdred.combine +SYSTEM: V2.9 +DATE: Fri Sep 24 10:40:31 MST 1993 +FROM: valdes + +BUG: If an offset file is specified as containing absolute offsets + but with all the offsets equal then the combining acted like + relative offsets except the output image size would be that + of the absolute offsets and garbage appears in the final + lines/columns. The workaround is to either not have + identical offsets or combine the images without offsets + and then paste the result into a bigger empty image at + the desired offset with IMCOPY. + +STATUS: Fixed in V2.10.3. + +NUMBER: 230 +MODULE: images.imcombine, ccdred.combine +SYSTEM: V2.9 +DATE: Fri Sep 24 10:45:00 MST 1993 +FROM: valdes + +BUG: The documentation says that scale and zero offset factors specified + by an @file of header keyword are multiplicative and additive. + However they are used as divisive and subtractive. The workaround + is to know the values should be input as divisive and + subtractive. + +STATUS: In V2.10.3 this has been fixed so the input is as defined in + the documentation. + +NUMBER: 231 +MODULE: imcombine, ccdred.combine +SYSTEM: V2.10.2 +DATE: Tue Nov 9 09:17:12 MST 1993 +FROM: valdes + +BUG: If there are fewer pixels at some point than that specified by nkeep + parameter, such as caused by offsetting, thresholding, or masking, + then the tasks try to add data from the nonexistent images resulting + either in garbage or a segmentation violation. The workaround + is to use nkeep or 1 or 0 rather a higher value unless there + are no offsets or other factors that will result in a smaller + number of points than the number of images at some points. + +STATUS: This has been fixed for V2.10.3. This also resulted in a change + in how a negative nkeep is used. In the new version, if one + specifies a maximum number to reject, that number applies to + the initial set of pixels rather than to the total number of + images. + +NUMBER: 232 +MODULE: images.geomap +SYSTEM: V2.9 +DATE: Wed Dec 29 16:39:24 MST 1993 +FROM: davis + +BUG: Geomap was computing an incorrect coordinate transformation if the + functional form of the coordinate transformation was "chebyshev" + or "legendre" x fit x or y order was > than 2 and the y fit was + linear (x and y order equal to 2), or if the y fit x or y order + was > 2 and the x fit was linear (x and y order equal to 2). + This was occurring because geomap was incorrectly redefining the + functional form of the linear fit to be "polynomial". + +STATUS: Fixed in 2.10.3. There is no direct workaround but setting the + cross terms parameter of the linear fit to "yes" will avoid + the problem at the expense of computing one extra term in the fit. + +NUMBER: 233 +MODULE: apphot package tasks +SYSTEM: V2.9 +DATE: Fri Dec 31 14:46:23 MST 1993 +FROM: davis + +BUG: If the number of input images is greater than one, the number of + output files is exactly equal to one, and the input coordinate + file(s) do not contain any decodable coordinates, the input coordinate + file rather than the empty output file is deleted. The problem + occurs because the output file name is not being correctly stored + as the tasks looped through the input image list. + +STATUS: The bug is fixed in 2.10.3. The workaround is to make sure at least + one of the coordinate files contains valid coordinates. + +NUMBER: 234 +MODULE: onedspec.standard +SYSTEM: V2.10-V2.10.2 +DATE: Fri Jan 7 09:38:51 MST 1994 +FROM: valdes + +BUG: When using STANDARD on a long slit spectrum with a dispersion axis + of 2 (where each column is treated as a spectrum) the task uses the + length of the second axis rather than the first axis to define the + number of spectra. If the second axis length is greater than the + first axis then the last column is processed repeatedly. One may + limit this by using the apertures parameter to specify just the + columns; i.e. 1-250 in a 250x800 images. If the number is smaller + then some of the columns will not be processed. On workaround is + to transpose the image but then some fudging of the WCS will be + necessary. Another workaround would be to use SCOPY to extract all + the spectra to a multispec format. + +STATUS: Fixed for the next release. + +NUMBER: 235 +MODULE: digiphot.apphot.fitpsf +SYSTEM: V2.9 +DATE: Mon Jan 17 14:18:33 MST 1994 +FROM: davis + +BUG: In cases where the fitting box was entirely off the image or there + were too few pixels in the fitting box to fit the psf model (e.g. + < 5 in the case of function=radgauss), the output fitted parameter + and parameter error arrays were not being initialized correctly. + Instead, although the fit was correctly tagged with the appropriate + error code, the results of the previous fit were written to the + output file. + +STATUS: Fixed in 2.10.3. There is no workaround except to make sure that + the fitting box contains enough pixels and/or to check the error + codes of the fitted objects. + +NUMBER: 236 +MODULE: digiphot.photcal.invertfit +SYSTEM: V2.10 +DATE: Wed Jan 19 08:03:42 MST 1994 +FROM: davis + +BUG: On VMS systems the invertfit task will crash with an adjustable + array dimension error if the user has no defined set equations + in his/her configuration file. In this case invertfit passes a + 2D array with a zero length first dimension to a subroutine, + triggering a run time error under VMS, even though the array is + never accessed. + +STATUS: Fixed in 2.10.3. The workaround is to include a dummy set equation + in the transformation section of the configuration file. + +NUMBER: 237 +MODULE: IEEE NaN support +SYSTEM: Sun/IRAF V2.10, V2.10.1, V2.10.2 +DATE: Fri Jan 21 15:55:46 MST 1994 +FROM: tody + +BUG: When converting native floating point to IEEE floating point (as + when writing FITS files), V2.10 IRAF has a feature which allows + pixels with a reserved floating point value to be replaced by IEEE + NaN on output. In V2.10 Sun/IRAF, the code which does this was + correct, but the wrong version of the affected object module was + present in the system library (libvops.a) and in the IRAF shared + image (S6.e). This would cause zero to be written as the output + IEEE value instead of NaN. + +STATUS: Fixed in V2.10.3 or later. So far as I know the core IRAF system + does not use this feature but it is used by some layered packages, + e.g., STWFITS. The bug only comes into play when mapping of NaNs on + output is enabled by the application being used. This is probably + not a serious bug in most cases, but if the zeros are a problem the + bug can be fixed by rebuilding the IRAF shared library S6.e. Contact + the IRAF group for advice on how to do this. + +NUMBER: 238 +MODULE: ccdred.combine +SYSTEM: V2.10 +DATE: Tue Feb 15 14:04:14 MST 1994 +FROM: valdes + +BUG: When combining images with separate exposure and dark times the + final dark time recorded in the header is actually the exposure + time; so the final dark time and exposure time will always be the + same. The correct dark time is computed but the wrong thing + is being written to the image. This is likely to be of relevance + for combining dark frames when the dark times of the individual + frames are not the same as the exposure times. The workaround + is to copy the dark time to the exposure time with HEDIT in + the dark frames before combining. Note that this bug + applies to the script DARKCOMBINE since it calls COMBINE. + +STATUS: This is a simple typo code fix which has been made for the V2.11 + release. + +NUMBER: 239 +MODULE: onedspec tasks +SYSTEM: V2.10 - V2.10.2 +DATE: Sat Mar 5 16:05:55 MST 1994 +FROM: valdes + +BUG: Applying IMSHIFT with a positive shift can cause errors in + the ONEDSPEC tasks. Negative shifts do not cause a problem. The + same problem has been noted previous in bug log number 180 for + IDENTIFY and REIDENTIFY. Errors occur when a wavelength is + transformed to a pixel coordinate. This happens in a number of + operations in SPLOT. There are various workarounds depending on + what is desired. A WCSRESET of the physical coordinate system can + be used though this will cause the dispersion coordinates to also + shift; i.e. then the shift will move the pixel relative to the + image data array and the wavelength coordinate system. As a + general rule use of IMSHIFT with spectra, particularly dispersion + calibrated spectra, should be avoided. + +STATUS: The problems have been fixed for V2.11. + +NUMBER: 240 +MODULE: ptools.pexamine +SYSTEM: V2.10 +DATE: Tue Mar 15 08:43:20 MST 1994 +FROM: davis + +BUG: If either or both of the columns specified by the pexamine task + parameters xcolumn or ycolumn is undefined in the input image data, + then pexamine will crash with a segmentation violation if the user + types the o keystroke command in image cursor input mode. The problem + occurs because the o keystroke command switches the task to graphics + cursor mode, and tries to move the graphics cursor to a point in the + default x-y plot which is undefined. + +STATUS: The bug is fixed in 2.11. The workaround is to set the xcolumn and + ycolumn parameters to a column that is defined in the input data. + +NUMBER: 241 +MODULE: sarith, scopy +SYSTEM: V2.10 +DATE: Tue Apr 12 13:56:49 MST 1994 +FROM: valdes + +BUG: If a spectrum is "multispec" with more than 127 APID keywords the + tasks will fail with a segmentation violation. This is due to + a limit in a keyword template expansion step. The work around + is to delete some of the keywords with: + + cl> hedit <images> apid1?? del+ + + Note that you can't delete them all since HEDIT has the same + limit. The APID strings can be restored from an aperture + identification file using SAPERTURES at a later time. + +STATUS: In V2.11 the limit on the number of keywords in a template + expansion has been increased to 1024. + +NUMBER: 242 +MODULE: sarith +SYSTEM: V2.10-2.10.2 +DATE: Thu Apr 28 13:51:04 MST 1994 +FROM: valdes + +BUG: Contrary to the help documentation, SARITH fails to allow a single + second spectrum operand to be repeated when the first operand + is a list. This is a bug. The workaround is to repeat the + second operand as often as necessary even if it is the same + name. + +STATUS: Fixed for V2.11. + +NUMBER: 243 +MODULE: rotate/imlintran/geotran +SYSTEM: V2.10 +DATE: Wed May 11 10:36:18 MST 1994 +FROM: davis + +BUG: Geotran was erroneously overriding the output image size requested by + the user if: 1) no geomap database was defined, 2) the output size + requested by the user was larger the size required to see the whole + input image assuming no origin shift. The tasks rotate/imlintran + were also affected by this problem. + + +STATUS: The bug has been fixed for the next release. There is no workaround. + +NUMBER: 244 +MODULE: imcombine, combine, scombine +SYSTEM: V2.10 +DATE: Wed May 25 11:10:50 MST 1994 +FROM: valdes + +BUG: When combine=average, reject=(sigclip, avsigclip, ccdclip, or pclip), + and mclip=yes (the value of mclip does not matter for pclip) the + average will be incorrect if the number of low pixels rejected is + greater than the number of unrejected pixels. For example if 3 low + pixels are rejected and only 2 pixels remain then the final average + will be incorrect for that pixel. There is no workaround other + than to avoid this combination of parameters. + +STATUS: Fixed in V2.11. + +NUMBER: 211.1 +MODULE: longslit.fitcoords +SYSTEM: V2.10 - V2.10.2 +DATE: Sat Jun 4 09:49:39 MST 1994 +FROM: valdes + +BUG: When there are many samples to be fit an 'Out of memory" error can + occur. This is caused by repeatedly opening an image section + for each sample and failing to close it. If there are enough + samples this can cause memory to run out. If this happens on + other than the first invocation of FITCOORDS then the workaround + is to flush the process cache between executions, "flpr fitcoords". + If it happens on the first execution then the only workaround is to + reduce the amount of data being fit by using a larger step size, + and avoiding multiple runs of REIDENTIFY (since redoing an + IDENTIFY appends to the database rather than replacing resulting + in multiple entries). For marginal cases it might be possible to + make sure the process has the maximum amount of memory + available by minimizing memory use by other processes. + + A second manifestation of this problem occurs when using STF + format (the SDAS group format). The error is + + ERROR: 827 <image> + + where <image> is the image section. This message means that + the task has opened too many files and could not open the file + which translates the error code. This behavior occurs because + STF format image keep the image header open unlike the .imh + format. The workarounds are the same as decribed previously. + + +STATUS: This is a rather severe bug which is fixed in V2.11. + +NUMBER: 246 +MODULE: images.imcombine, ccdred.combine, onedspec$scombine +SYSTEM: V2.10.2 +DATE: Mon Jun 6 17:03:15 MST 1994 +FROM: valdes + +BUG: In rare circumstances when using one of the clipping algorithms + nkeep > 0 the task will not complete because it has entered + a nonterminating loop. This occurs when too many + pixels are rejected and two or more rejected pixels have + equal residuals the equal residual points are added back. + However this is done within the iterative loop and after + adding back the pixels the task finds there are now more than + nkeep pixels and so repeats the loop with the same result. + The work around is to change nkeep. A change is likely + to fix the specific case. A value of zero for nkeep will + avoid the problem entirely but with the possibility of + rejecting all pixels. + +STATUS: The adding back of pixels should be done outside the iterative + loop and this change has been made for the next release (V2.11). + +NUMBER: 247 +MODULE: photcal.fitparams +SYSTEM: V2.10 +DATE: Mon Jun 13 16:12:33 MST 1994 +FROM: davis + +BUG: If the fitparams task parameter weighting is set to "photometric" + or "equations", the addscatter parameter is set to "yes", and + either the number of parameters to be fit equals the number of data + points, or the fit has no scatter, fitparams will crash with a + floating operand error. This occurs because the expression used + to estimate the additional scatter to be added to the weights in the + next iteration of the fit goes to 0 in the denominator, causing a + divide by zero error. + +STATUS: The bug is fixed in 2.11. The workaround is to set weighting to + "uniform" or set the addscatter parameter to "no". + +NUMBER: 248 +MODULE: image.imcombine,ccdred.combine,onedspec.scombine +SYSTEM: V2.10.2 +DATE: Mon Jun 13 18:50:46 MST 1994 +FROM: valdes + +BUG: When the rejection algorithm is avsigclip, sigclip, avsigclip, or + crreject and mclip=no and nkeep is not zero there is the rare + possibility of a segmentation violation. This occurs when more + than the maximum number of pixels is rejected and several of the + rejected pixels have the same residual relative to the average. + The workarounds are to reduce nkeep (possibly to zero), use + mclip=yes, use another rejection algorithm, or adjust the sigma + values. + +STATUS: This problem is fixed for V2.11. + +NUMBER: 249 +MODULE: sarith +SYSTEM: V2.10 +DATE: Tue Jun 21 14:35:17 MST 1994 +FROM: valdes + +BUG: When doing a binary operation with a constant second operand and + "onedspec" output format the constant used is incorrect due + to a bug in which the number is used as a real number but is + actually a double precision number. The incorrect value can + be seen in the verbose output. For example: + + cl> sarith specin - 48.5 specout format=onedspec verbose+ + specin[1] - 3.128906 --> specout.0001 + + The workaround is to use multispec output format for the operation. + A later SCOPY can then be used to convert formats if desired. + +STATUS: Fixed in V2.11. + +NUMBER: 250 +MODULE: photcal.mknobsfile,mkobsfile,obsfile +SYSTEM: V2.10 +DATE: Wed Jun 22 17:16:03 MST 1994 +FROM: davis + +BUG: The mknobsfile/mkobsfile/obsfile tasks were omitting stars from the + output observations file for image sets where there was only a single + image per image set, and that image was not the last image in the + image set. + +STATUS: The bug has been fixed in 2.11. One possible work around is to + set the tolerance parameter to 0, run mknobsfile/mkobsfile/obsfile on + image sets with only one defined image separately from the other image + sets, and concatenate the results from the two runs. + +NUMBER: 251 +MODULE: sarith, scopy +SYSTEM: V2.10.0 - V2.10.2 +DATE: Wed Jun 29 17:32:20 MST 1994 +FROM: valdes + +BUG: For multispec spectra which have a doppler factor in the coordinate + system description (a non-zero value for the 7th field following + the number of pixels) making a copy or doing arithmetic will + cause the wavelength zero point to be off by a factor of + 1/(1-z*z). The workarounds are to either avoid introducing + a doppler factor, accounting for the error, or explicitly + setting w1,w2 (but note bug #214). + +STATUS: Fixed 10/92 and included in V2.11. + +NUMBER: 252 +MODULE: utilities.polyfit +SYSTEM: V2.10 +DATE: Mon Jul 11 09:17:27 MST 1994 +FROM: davis + +BUG: The computation of chisqr and stdev are too large by a factor + if yavg ** 2 if the weighting parameter is "instrumental" and + abs(yavg) if the weighting parameter is "statistical". + +STATUS: Fixed in 2.11. There is no workaround except to apply the + correction factors manually. + +NUMBER: 253 +MODULE: transform, apall, apsum +SYSTEM: V2.9 +DATE: Mon Jul 25 14:14:57 MST 1994 +FROM: valdes + +BUG: The extraction of dispersion calibrated long slit data, the + result of TRANSFORM, does not properly pass on the dispersion + information. One symptom of this is that if the dispersion axis is + 2 then the final extracted spectrum will have a wavelength per + pixel corresponding to the first axis in the CD1_1 keyword. Note + that there is also a correct WPC and CDELT1 keyword. This does not + cause a problem when using V2.9 ONEDSPEC routines because WPC has + precedence over CD1_1. However in taking this data to V2.10 the + precedence was changed and CD1_1 is used in preference to WPC or + CDELT1. So a task like V2.10 SPLOT will plot the spectra with an + incorrect dispersion. The work around to update the header for + V2.10 is update the CD1_1 keywords or delete them: + + cl> hedit <1D spectra> cd1_1 '(wpc)' + cl> hedit <1D spectra> cd1_1 del+ + +STATUS: The aperture extraction in V2.10 correctly passes on the + dispersion coordinates produced by TRANSFORM during the + long slit reductions. + +NUMBER: 254 +MODULE: longslit.transform +SYSTEM: V2.10-V2.10.2 +DATE: Sat Aug 6 12:14:32 MST 1994 +FROM: valdes + +BUG: If DISPAXIS=2 and one specifies log sampling (ylog=yes) + then the specified sampling is done correctly but the header + coordinate description is incorrect. Specifically the starting + wavelength, CRVAL2, is given as a linear wavelength rather + than a log wavelength. Display of this spectrum, say with + SPLOT, produces a wavelength scale which is very compressed + at the starting wavelength. The workaround is to fix the header + of the transformed image with + + cl> hedit <images> crval2 "(log10(crval2))" update+ + +STATUS: Fixed in versions after V2.10.2 + +NUMBER: 254 +MODULE: longslit.transform +SYSTEM: V2.10-V2.10.2 +DATE: Sat Aug 6 12:54:42 MST 1994 +FROM: valdes + +BUG: If DISPAXIS=2 and one specifies log sampling (ylog=yes) + then the specified sampling is done correctly but the header + coordinate description is incorrect. Specifically the starting + wavelength, CRVAL2, is given as a linear wavelength rather + than a log wavelength. Display of this spectrum, say with + SPLOT, produces a wavelength scale which is very compressed + at the starting wavelength. The workaround is to fix the header + of the transformed image with + + cl> hedit <images> crval2 "(log10(crval2))" update+ + + This was caused by a typo where parameter xlog was used + where ylog should have been. Another thing to be aware + of is that extraction of a 1D spectrum from the 2D + spectrum with the APEXTRACT tasks will propagate the error. + For such data SPLOT crashes because it tries to evaluate + an impossibly large decimal exponent. + +STATUS: Fixed in versions after V2.10.2 + +NUMBER: 255 +MODULE: apall, apsum +SYSTEM: V2.10-V2.10.2 +DATE: Tue Aug 9 10:47:21 MST 1994 +FROM: valdes + +BUG: When extracting spectra with dispaxis=1 (spectra horizontal) using + variance weighting and/or cleaning with a gain other than 1 then + occasionally a "floating operand error" or some arithmetic + exception can occur. This is caused by reference to unitialized + memory during application of the gain. The uninitialized memory + does not affect the results but if an invalid arithmetic value + is encountered it will cause the extraction to abort. The + workarounds in this case are to use a gain of 1 if it is + reasonable otherwise to transpose the image and reset the + wcs (with wcsrest <image> wcs=physical) and the dispaxis + value. + +STATUS: Fixed after V2.10.2. + +NUMBER: 256 +MODULE: ccdproc +SYSTEM: V2.8-V2.10.3 +DATE: Mon Aug 29 13:57:03 MST 1994 +FROM: valdes + +BUG: If the calculation datatype is set to short, calculation of the + CCDMEAN value is incorrect and, if used during flat fielding, will + give incorrect scaling for the flat fielding. The workarounds are + to not use short for the calculation datatype though it is ok to + use short output datatype to save diskspace. Note that if no + calculation datatype is specified it defaults to real so it takes + an explicit setting of pixeltype="short short" or "real short" to + force this bug to appear. + +STATUS: Fixed after V2.10.3. + +NUMBER: 257 +MODULE: mkfringe, mkillumcor, mkillumflat, mkskycor, mkskyflat +SYSTEM: V2.8-V2.10.3 +DATE: Mon Aug 29 16:25:11 MST 1994 +FROM: valdes + +BUG: If the tasks are run more than once without flushing the process + then a segmentation violation or error attempting to access an + unopened file is likely to occur. The workaround is to flush the + process cache with "flpr" before running any of these tasks. + +STATUS: Fixed future versions. + +NUMBER: 258 +MODULE: reidentify +SYSTEM: V2.10-V2.10.3 +DATE: Thu Sep 15 10:29:50 MST 1994 +FROM: valdes + +BUG: If a step of zero is specified the task will hang in an infinite + loop. The way the step is used is to increment/decrement the starting + line until the ends of the image are reached. With a step of + zero this will never happen. However, if one is interested in + only reidentifying a single line in a 2D image it seems + reasonable to set the step to zero. The actually method is + to set the step to a very large number. + +STATUS: For the next release the case of a zero step is checked and + causes REIDENTIFY to only reidentify the reference line in + other images. + +NUMBER: 259 +MODULE: images.tv.tvmark +SYSTEM: V2.10 +DATE: Mon Oct 3 09:01:29 MST 1994 +FROM: davis + +BUG: The tvmark append (a) keystroke command does not function correctly + under Solaris IRAF 2.10.3 BETA. The objects to be appended to the + coordinate list are marked correctly on the image display but are not + appended to the output coordinate file. + + The problem is apparently caused by a failure to call the flush + command before doing a seek to EOF. On SunOS systems the seek to + EOF appears to force a flush, while on Solaris systems it + does not, resulting in the appended objects never being written + to the output file. + +STATUS: Fixed for the next release of IRAF. There is no workaround. + +NUMBER: 260 +MODULE: digiphot.daophot.seepsf +SYSTEM: V2.10 +DATE: Mon Oct 3 13:08:46 MST 1994 +FROM: davis + +BUG: The seepsf task was forcing the output psf image to be less than or + equal 23 pixels square, corresponding to a psfrad less than or equal + to 11 pixels, no matter what the actual psfrad in the input image + psf was. The computed portion of the output psf image was correct. + The problem was that seepsf was using the wrong quantity to compute + the default size of the output psf image. + +STATUS: Fixed in 2.10.3. There is no workaround. + +NUMBER: 261 +MODULE: apphot package tasks +SYSTEM: V2.10 +DATE: Tue Oct 4 09:21:04 MST 1994 +FROM: davis + +BUG: The directory information was inadvertantly being stripped from + the default input/output file specifications. For example the phot + task would look for the default input coordinate file in the + current directory even though, the file specification was dir$default. + Similarly the default output file was being written to the + current directory, even though the file specification was dir$default. + Directory information was not being stripped from fully specified + file names. + +STATUS: Fixed in the next release of iraf. + +NUMBER: 262 +MODULE: echelle.doecslit +SYSTEM: V2.10-V2.10.2 +DATE: Thu Oct 6 16:21:57 MST 1994 +FROM: valdes + +BUG: DOECSLIT fails to actually use the recentered and (optionally) + retraced apertures determined for each object spectrum when + it extracts the orders. Instead it ignores the object apertures + and uses the reference spectrum apertures. This can be seen + since the actual apertures used for extraction are saved in + the database and they will be the same as the reference + aperture. There are no workarounds other than to modify + the script or to do the extractions separately with APALL + and then use DOECSLIT for the remainder of the operations. + +STATUS: This fixed in versions after V2.10.2. + +NUMBER: 263 +MODULE: photcal.mkapfile +SYSTEM: V2.10 +DATE: Thu Oct 13 11:37:48 MST 1994 +FROM: davis + +BUG: If there was more than one photometry file in the input file list + mkapfile was quitting with the error "ERROR on line 187: cannot open + `file'" for writing. This was caused by the script trying to append + to an existing file with "> file" instead of ">> file". + +STATUS: Fixed for the next release of IRAF. + +NUMBER: 264 +MODULE: rv.fxcor +SYSTEM: V2.10 +DATE: Thu Oct 13 15:32:33 MST 1994 +FROM: fitz + +BUG: The batch processing code was not initializing the task structure + properly and a "Memory has been corrupted" error can occur when + processing in batch and the template spectrum has to be rebinned. + The bug is not seen if it's the object spectrum that is rebinned. + Possible workarounds include rebinning the data to a common disp- + ersion and starting wavelength before correlating, setting the + 'rebin' parameter to force it to rebin to the object's dispersion, + or else just process interactively. The code change is trivial + for sites who wish to fix it. + +STATUS: Fixed in versions after V2.10.3beta. + +NUMBER: 265 +MODULE: expanding file templates on Solaris +SYSTEM: SunOS/IRAF V2.10.2 executing on Solaris +DATE: Fri Oct 14 13:27:26 MST 1994 +FROM: tody + +BUG: Various users have reported a subtle problem in IRAF which occurs + when SunOS/IRAF version 2.10.2 is run on a Solaris system in + compatibility mode. On occasion IRAF code which reads host + directories may not "see" all the files in a directory. Hence file + and image templates may not expand correctly, omitting some of the + files in a directory. + +STATUS: This problem is not present in the native Solaris version of IRAF, + Solaris/IRAF V2.10.3BETA. The solution is to update to this version. + If V2.10.2 must be used, use host system facilities (e.g. ls, provided + as a foreign task in unix/iraf systems) to expand file templates. + +NUMBER: 266 +MODULE: apphot.daofind +SYSTEM: V2.10 +DATE: Thu Oct 20 13:57:31 MST 1994 +FROM: davis + +BUG: If the sigma parameter was left at its default value of INDEF, a + floating point overflow value would result when daofind was run + from the apphot package. The problem was the result of a missing + check for INDEF in the code. + +STATUS: This bug was not a problem for versions of IRAF prior to 2.10.3 BETA + and has been fixed for the next release of IRAF. The workaround is to + set the sigma parameter to some reasonable value. + +NUMBER: 267 +MODULE: rv.rvidlines +SYSTEM: V2.10.3beta +DATE: Thu Oct 20 14:44:50 MST 1994 +FROM: valdes + +BUG: The intent of this program is that if the header information + does not exist to compute heliocentric velocities it should + simply compute observed velocities. However, the trap for + this conditions in not correct so instead the program quits. + The only workaround is to add dummy keywords for those + missing and ignore the heliocentric results. + +STATUS: Fixed after version V2.10.3beta. + +NUMBER: 268 +MODULE: imexpr +SYSTEM: V2.10.3 +DATE: Tue Oct 25 11:42:52 MST 1994 +FROM: tody + +BUG: The "imexpr @file" way of invoking imexpr doesn't work; imexpr + reports a syntax error due to the newline at the end of the text + file containing the expression. + +STATUS: Fixed in the V2.10.3 patch. To workaround the bug, either put the + expression on the command line or enter it as a macro function in + an expression database file. + +NUMBER: 269 +MODULE: artdata.gallist +SYSTEM: V2.9-V2.10.3beta +DATE: Sat Oct 29 16:56:56 MST 1994 +FROM: valdes + +BUG: The internal absorption model for disk galaxies is not being applied + as described in the help. Regardless of the absorption parameter + there is no absorption correction to the magnitudes of the disk + galaxies at any inclination. There is no workaround. + +STATUS: Fixed after V2.10.3beta. + +NUMBER: 270 +MODULE: imshift, magnify, xregister, geotran +SYSTEM: V2.10 +DATE: Fri Dec 9 10:48:34 MST 1994 +FROM: davis + +BUG: Flux may not be conserved when the IMSHIFT, MAGNIFY, XREGISTER, or + GEOTRAN tasks are run on undersampled data using the spline3 + interpolant. In the worst case situation, completely undersampled + data, fractional y shifts of 0.4-0.6, and placement near the top or + bottom of the data buffer, the discrepancy is ~ +/- 0.3%. For + well-sampled data the discrepancy is negligible. For y shifts which + are exactly 0.0 there is no problem. + + The cause of the problem was that the number of edge lines being + allocated for the spline3 buffers was too small for undersampled + data and some of the power in the high frequency components of the + interpolant was being lost. + +STATUS: Fixed for next release of iraf. + +NUMBER: 271 +MODULE: photcal.mknobsfile,photcal.mkobsfile,photcal.mkapfile,ptools.pdump +SYSTEM: V2.10.3BETA +DATE: Tue Dec 20 10:47:32 MST 1994 +FROM: davis + +BUG: A reference was being to a tables.ttools.tdump task parameter outside + the loop for processing ST binary tables in the pdump and mkapfile + scripts, resulting in an "unknown task tdump" error when the tables + package was undefined or defined incorrectly. The pdump error could + in turn produce the same error in the mknobsfile and mkobsfile tasks. + +STATUS: Fixed for the next release in iraf. The workaround is to install the + tables package. If this is not feasible contact the iraf group for + a fix. + +NUMBER: 272 +MODULE: dispcor +SYSTEM: V2.10.3BETA +DATE: Mon Jan 16 13:01:54 MST 1995 +FROM: valdes + +BUG: When the input spectra are in equispec format (all spectra with the + same linear dispersion relation) and there are aperture numbers + which are greater than the number of image lines then the error + "WFMSPEC: Coordinate out of bounds" may occur. Such a situation + will only occur when resampling an an already dispersion corrected set + of spectra and not when using an IDENTIFY or ECIDENTIFY database. + This is due to a logical error in the code concerning mapping of + aperture numbers to line numbers. The workarounds are to use + SARITH if simply extracting a region, extract the spectra to + onedspec format with SCOPY, or change the WCS with: + + cl> hedit <images> cd2_2,cdelt2 1000 update+ + cl> hedit <images> crpix2 1 add+ + +STATUS: Fixed for the next release. + +NUMBER: 273 +MODULE: dopcor +SYSTEM: V2.10.3BETA +DATE: Wed Jan 18 17:22:38 MST 1995 +FROM: valdes + +BUG: For multispec spectra which have independent wavelengths for each + spectrum (identified by system=multispec in the header) there + is a bug such that if there are more than 8 spectra the message: + + Warning: MWCS: too many coordinate transformation (ctran) descriptors + ERROR: segmentation violation + + appears. Most commonly this will affect echelle data. The + workaround is to apply DOPCOR with the aperture parameter + in groups of 8 or less spectra. For example: + + cl> dopcor obj.ec obj1.ec -120 isvel+ add- ap=1-8 + cl> dopcor obj1.ec obj1.ec -120 isvel+ add- ap=9-16 + ... + + Note the second and subsequent steps work in place. + +STATUS: This bug, which is a typo in the code, is fixed for a release after + V2.10.3BETA (possibly the Solaris patch) and V2.11. + +NUMBER: 274 +MODULE: doslit (specred, kpnocoude, kpnoslit) +SYSTEM: V2.10.3BETA +DATE: Tue Jan 24 13:56:11 MST 1995 +FROM: valdes + +BUG: If the first object spectrum has more than one object on the + slit and apertures are defined for them then after doing + the dispersion solution on the reference arc the following + error occurs: + + ERROR ... - Missing reference for aperture 2 + + This is a bug, introduced in V2.10.3BETA, since the intent of the + task is to allow multiple apertures per long slit spectrum. It is + caused by using the apertures from the first object as the + apertures for the arc reference. The workarounds are 1) make the + first object image be one that has only one aperture (other objects + can have multiple apertures) or 2) when in IDENTIFY doing the arc + reference dispersion solutions do 'k' after finishing the + dispersion solution to step to the other (unnecessary) apertures + and do a solution with 'a' 'c' and 'f' (all center and fit). + +STATUS: Fixed in later versions. + +NUMBER: 275 +MODULE: apnormalize +SYSTEM: V2.10.3BETA +DATE: Fri Jan 27 17:16:35 MST 1995 +FROM: valdes + +BUG: In bug numbers 171 and 225 it was noted that when using variance + weighting or cleaning in APNORMALIZE the result would end up + scaled by the gain value. The fix was to divide the result + by the gain. However, the default parameters for APNORMALIZE + do not call for variance weighting or cleaning and so the + gain and readnoise are not read. The uninitialized value + of the gain used to divide the result of APNORMALIZE is + zero causing a divide by zero error. The workaround is + to set the weights paraemter to "variance". The actually + weighting and gain and readnoise parameters are not important + to this algorithm. + +STATUS: This only affects version V2.10.3BETA and will be fixed in + later versions. + +NUMBER: 276 +MODULE: imexamine +SYSTEM: V2.8-V2.10.2 +DATE: Tue Jan 31 15:06:41 MST 1995 +FROM: valdes + +BUG: The standard deviation values returned by the 'm' key in IMEXAMINE + can be inaccurate when the mean data value is large and the standard + deviation is relatively small. This is due to calculation + of the standard deviation formula using the difference in the sum of + squares and the square of the sum with real precision. The + workarounds are to use IMSTATISTICS with an image section or + to first subtract something like the mean value from the image + before using IMEXAMINE. + +STATUS: In V2.10.3 and after the calculation is done in double precision + and the standard deviation is as accurate as IMSTATISTICS. + +NUMBER: 277 +MODULE: photcal.mknobsfile,mkobsfile,obsfile +SYSTEM: V2.10.3BETA +DATE: Thu Feb 9 13:25:36 MST 1995 +FROM: davis + +BUG: The time of observation and airmass columns are switched in the + output observations file if position matching is turned off, + resulting in the airmass being written under the otime column + and vice versa. + +STATUS: Fixed for the next release of iraf. One possible workaround is + to simply switch the column numbers in the configuration file + since the number can still be read in correctly. + +NUMBER: 278 +MODULE: splot, fitprofs +SYSTEM: V2.10.3BETA +DATE: Thu Feb 16 18:17:59 MST 1995 +FROM: valdes + +BUG: The new error estimates for Gaussian profile fitting and deblending + computed if a noise model is given are incorrect when there is more + than one line being fit; though they are roughly correct. This is + caused by an indexing error such that the error is not always the + 68% (1 sigma) point and the error on a particular line is really a + mixture of measurements from all the lines. There estimates are + valid for single line Gaussian fits. There is no workaround. + +STATUS: Fixed in subsequent versions. + +NUMBER: 279 +MODULE: doslit, doecslit +SYSTEM: V2.10-V2.10.2 +DATE: Fri Feb 17 10:06:09 MST 1995 +FROM: valdes + +BUG: If no arc image or standard star image is specified an error such as + + ERROR on line 103: OPEN: File does not exist (tmp$iraf1665j) + doecslit () + + will appear. This is true even if one is not dispersion correcting + or standard star fluxing. Thus, even if dispcor=no or fluxcal=no + you must put a placeholder image name in the arcs and standard + parameters. + +STATUS: Fixed in V2.10.3 and later such that not specifying arc and standard + star images is ok if not dispersion or flux calibrating. + +NUMBER: 280 +MODULE: sensfunc +SYSTEM: V2.6-V2.10.3 +DATE: Wed Feb 22 11:18:52 MST 1995 +FROM: valdes + +BUG: Deleted points and deleted stars are not excluded from the grey + shift calculation. This is a bug in the sense that this is not + what most users would expect. In particular, if a star is + deleted and it is the one with the highest apparent sensitivity + one would not expect the rest of the data to be shifted to match + this deleted star. For the case of deleting a star and excluding + it from the grey shift calculation the workaround is to delete + the data from the input data file. + +STATUS: Deleted points are excluded from the grey shift calculation in + future versions. + +NUMBER: 281 +MODULE: splot +SYSTEM: V2.10.3beta +DATE: Thu Feb 23 16:10:43 MST 1995 +FROM: valdes + +BUG: The 't', '/' combination for continuum flattening spectra fails for + flux calibrated data and instead produces a spectrum which is + identically 1. A check to avoid division by zero fails to + discriminate flux calibrated data (any value less than about 1E-8) + as different from zero. The resultant value of 1 is used when + the divide by zero condition is detected. + +STATUS: Fixed in future releases. + +NUMBER: 282 +MODULE: fit1d +SYSTEM: V2.10.3beta +DATE: Thu Feb 23 16:16:41 MST 1995 +FROM: valdes + +BUG: The ratio output does not work in V2.10.3beta due to a typo error + in the code. The workaround is to output the fit and use + IMARITH to take the ratio. + +STATUS: Fixed in future releases. + +NUMBER: 283 +MODULE: ptools.pexamine +SYSTEM: V2.10 +DATE: Thu Feb 23 16:23:12 MST 1995 +FROM: davis + +BUG: On Dec Alpha systems pexamine will crash with an invalid floating + point operation error if the user tries to plot the histogram + of an array with the h keystroke command. + +STATUS: The problem was caused by a typo in a statement which resulted in + a memory access of the end of an array. The bug is fixed for the + next release of iraf. There is no workaround. + +NUMBER: 284 +MODULE: photcal.mknobsfile,photcal.mkobsfile +SYSTEM: V2.10 +DATE: Wed Mar 22 07:56:37 MST 1995 +FROM: davis + +BUG: A very serious problem has been found in the iraf 2.10.3 and digiphotx + mknobsfile/mkobsfile scripts. Running mknobsfile/mkobsfile on files + written by the allstar/nstar tasks (but not the phot task) may corrupt + the input files. This is definitely not problem for + mknobsfile/mkobsfile in 2.10.2 and earlier version of iraf or for + digiphotx linked with versions 1.2.1 and earlier of the tables package. + + The problem crept in when the tables package was modified to support + text tables. The error check in mknobsfile/mkobsfile previously + used to detect whether an input file was a text file or binary + table began to fail for allstar/nstar files. The code thought the + text file was a binary table, opened it as such, and attempted to + edit it. Although the code was smart enough to detect that the + proper columns etc were not present and did not do any actual editing, + simply opening and closing the file as a table in READ_WRITE mode + caused to file to be rewritten and its format corrupted. + +STATUS: This problem has been fixed for the next release of iraf and in the + forth-coming 2.10.3 patch as well as in the ftp archive version of + digiphotx. If you are running later versions of tables there is no + workaround except installing the patch and/or the new version of + digiphotx. We have confirmed that there is a problem running + mknobsfile/mkobsfile with tables 1.3.2 and 1.3.3 and that there + was definitely not a problem with tables 1.2.1 and earlier but are + not certain of the status of intermediate versions. + + +NUMBER: 285 +MODULE: echelle.ecidentify +SYSTEM: V2.9-V2.10.3 +DATE: Tue Apr 11 10:55:54 MST 1995 +FROM: valdes + +BUG: The 'x' key to find a shift between a set of features and the peaks + in the data fails with a memory access error (i.e. segmentation + violation). There is no workaround to use this key though the + 's' key can be used with a known line to set and apply a shift. + +STATUS: Fixed for the next release. + +NUMBER: 286 +MODULE: onedspec.sbands +SYSTEM: V2.10.3 +DATE: Wed Apr 12 09:33:20 MST 1995 +FROM: valdes + +BUG: The output formating for the flux column produces 0.00 when the + spectra are flux calibrated; i.e. have very small values of + order 1E-14. The workaround is to multiply the spectrum by + an appropriate large number and remember the scaling used. + +STATUS: The formating will be changed to allow exponential notation + in a future release. + +NUMBER: 287 +MODULE: photcal.mkapfile,photcal.apfile +SYSTEM: V2.10 +DATE: Fri Apr 28 10:00:14 MST 1995 +FROM: davis + +BUG: The filter id keyword read from the input photometry files was + not being written correctly to the output magnitudes file, resulting + in a filter id of INDEF for all images. + +STATUS: Fixed for the next release iraf release. There is no workaround. + +NUMBER: 288 +MODULE: ptools.pexamine +SYSTEM: V2.10 +DATE: Mon May 1 09:16:17 MST 1995 +FROM: davis + +BUG: The colon commands :rinner and :router were incorrectly defined as + :rin and :rout in the pexamine definitions file. In addition the + new router value was being written back into the rinner parameter, + a bug that was masked by the previous problem. + +STATUS: Fixed for the next release of iraf. The workaround is to use the + :epar radplot command and edit the parameter set as a whole. + +NUMBER: 289 +MODULE: apscatter +SYSTEM: V2.9-V2.10.3 +DATE: Wed May 3 16:50:54 MST 1995 +FROM: valdes + +BUG: When not smoothing the scattered light surface along the dispersion, + smooth=no, and there are multiple apertures the task may abort + with the error "Range descriptor undefined". This occurs when + the number of scattered light points being fit across the + dispersion changes as the spacing between apertures changes. + This is probably a rare event. The only workaround is to + add the smoothing along the dispersion. + +STATUS: Fixed in after V2.10.3. + +NUMBER: 290 +MODULE: scopy, sarith +SYSTEM: V2.10.3 +DATE: Sat May 13 13:54:11 MST 1995 +FROM: valdes + +BUG: When spectra are modified with SPLOT and then written out, the + current display units are also recorded. SCOPY and SARITH + incorrectly create new spectra with the dispersion units set to the + display units. For units which are linearly related (such as any + between wavelength units or between energy/frequency units) this + causes no problem. However, for other pairs of units, such as + dispersion units of angstroms but display units of EV, the new + coordinate system will not match the spectrum pixels. The + workarounds are to avoid this situation or change the "units" in + the copied/output spectrum back to the original units with + WCSEDIT. + +STATUS: Fixed in V2.10.4 + +NUMBER: 291 +MODULE: argus.msresp1d, hydra.msresp1d +SYSTEM: V2.10.2 +DATE: Mon May 22 09:38:27 MST 1995 +FROM: valdes + +BUG: The task MSRESP1D in the ARGUS and HYDRA packages will produce + an error reporting that there is no param file. This is caused + by an error in specifying a directory name. The workaround + is either to interactively type the following after loading + the desired package: + + ar> redefine msresp1d=specred$msresp1d.cl + + or change the system files argus$argus.cl and hydra$hydra.cl so + that "msred" becomes "specred". + +STATUS: Fixed in V2.10.3 and later. + +NUMBER: 292 +MODULE: imexamine +SYSTEM: V2.10-V2.10.4 +DATE: Wed May 31 10:08:47 MST 1995 +FROM: valdes + +BUG: The output of the 'x' and 'y' keys is not written to the logfile + if one is used. There is no workaround other than copying + the terminal output in some way. Note the task RIMCUR can + be used to get coordinates from an image in both pixel and + world coordinates. + +STATUS: Fixed in subsequent releases. + +NUMBER: 293 +MODULE: register, geotran +SYSTEM: V2.10 +DATE: Fri Jun 9 16:43:56 MST 1995 +FROM: davis + +BUG: If the xsample or ysample parameters are greater than 1 and + the nxblock or nyblock parameters are smaller than the image + dimensions, register/geotran may fail with a memory corruption + error. + + The error was due to a buffering error in the y coordinate + interpolation surface. + +STATUS: Fixed for the next release of iraf. The workaround is to set + xsample and ysample back to 1, which makes coordinate evaluation + slower for high order surfaces but does not make much difference + for simple surfaces, or set nxblock and nyblock to be larger than + the input image size. + +NUMBER: 294 +MODULE: photcal.mkapfile,photcal.apfile +SYSTEM: V2.10 +DATE: Tue Jun 13 17:25:01 MST 1995 +FROM: davis + +BUG: Mkapfile/apfile may terminate prematurely or hang with a floating + overflow exception if the input data is such that it is difficult + to determine a good value for the Moffat function radius parameter + RO. In this case RO can be driven towards and beyond 0 which produces + the overflow. + +STATUS: A check was added to the code to trap this condition and report a + fitting error. Possible work arounds including upping the default + number of parameters to be fit from 3 to 4 and/or deleting the + suspect data from the input file. + +NUMBER: 295 +MODULE: dofibers, dohydra, doargus +SYSTEM: V2.10-V2.10.4 +DATE: Wed Jun 14 14:44:15 MST 1995 +FROM: valdes + +BUG: The use of subapertures does not work and aborts with the error + + ERROR on line 28: Bad aperture/column/line list + + This is caused by an incorrect aperture range in the script + code. There is no workaround other than not use subapertures + or modifying the script code. + +STATUS: Fixed for the next release. + +NUMBER: 296 +MODULE: digiphot.apphot.daofind +SYSTEM: V2.10 +DATE: Mon Jun 19 09:34:40 MST 1995 +FROM: davis + +BUG: If the datamin parameter is set above the sky level of the image + the code which computes the x and y positions of the detected + objects can crash with a floating divide by zero error for the + fainter objects. + +STATUS: Fixed for the next release of iraf. The workaround is to set the + datamin parameter to a more reasonable value. + +NUMBER: 297 +MODULE: longslit, longslit.identify, longslit.reidentify +SYSTEM: V2.10.0 +DATE: Mon Jun 19 14:08:46 MST 1995 +FROM: valdes + +BUG: This is a tardy bug report since I noticed this major bug is not + actually in the bug log. In the first release of V2.10 there was + a serious bug in the ONEDSPEC tasks which apply to 2D images such + as long slit data. The tools would not access dispersion lines + beyond 2. The most common symtom is that IDENTIFY will only + show lines 1 and 2 in long slit data. Normally one encounters + this in the LONGSLIT package. If one uses a section parameter of + "middle lines" IDENTIFY will show the image section [*,2]. + REIDENTIFY is similarly limited to the first two dispersion lines. + There is no workaround other than to upgrade V2.10 to any + higher version. It was first fixed in V2.10.1 + + +STATUS: Fixed in V2.10.1 and later. + +NUMBER: 298 +MODULE: onedspec.sbands +SYSTEM: V2.10-V2.10.4 +DATE: Fri Jun 30 09:25:30 MST 1995 +FROM: valdes + +BUG: When the number of input bandpasses is greater than 10 a segmentation + violation error occurs. This is a bug in the memory allocation + logic of the task. The workaround is to break up the bandpasses + into groups of 10 or less (it might work up to 20 but is not + guarenteed). + +STATUS: Fixed in later versions. + +NUMBER: 299 +MODULE: daophot.seepsf +SYSTEM: V2.10 +DATE: Mon Jul 3 17:24:04 MST 1995 +FROM: davis + +BUG: Seepsf was crashing with a floating operand error if the input psf + image was a purely analytic function, keyword varorder=-1. This + error was accidentally introduced when the previous seepsf error + (bug log # 260) was fixed. + +STATUS: Fixed in 2.11 and in the external addon package digiphotx. One + possible workaround is make the psf image with varorder=0, then + make a copy of it setting all the pixel values to 0.0 with + imarith, and inputing the new image to seepsf. + +NUMBER: 300 +MODULE: dispcor +SYSTEM: V2.10.4 +DATE: Thu Jul 13 11:08:04 MST 1995 +FROM: valdes + +BUG: A new capability was added in V2.10.4 to allow DISPCOR to work + with IDENTIFY database files containing only a shift and no + dispersion function. This would occur when using IDENTIFY to + compute a shift to previously dispersion corrected spectra. This + does not work correctly when there is more than one aperture in an + image. The workaround is to separate multiaperture images into + single aperture images with SCOPY and then do the + IDENTIFY/REIDENTIFY and DISPCOR. + +STATUS: Fixed in later versions. + +NUMBER: 301 +MODULE: daophot.seepsf (Dec Alpha) +SYSTEM: V2.10 +DATE: Tue Jul 18 10:14:50 MST 1995 +FROM: davis + +BUG: Seepsf will terminate with an FPE error on the Dec Alpha machine + if the the psf model is not analytic. The problem was caused by + as missing test which resulted in an out-of-bounds array reference + in some cases. On other systems the FPE error did not occur + but pixels outside the psf radius were not being set to 0 as intended + but were instead were interpolated in the noisy edges of the + look-up table. Pixels inside the psf radius are correct. + +STATUS: Fixed for the next release of iraf and in the ftp archive version. + There is no workaround. + +NUMBER: 302 +MODULE: apscatter +SYSTEM: V2.10-V2.10.4 +DATE: Tue Jul 18 17:35:37 MST 1995 +FROM: valdes + +BUG: If the aperture trace functions cross or cause the apertures + to overlap then the algorithm for finding the scattered light + pixels outside the apertures gets confused. This can have the + consequence of either using data within an aperture or a memory + error (memory corrupted or segmentation violation). The workaround + is to insure the aperture definitions and traces do not behave in + this way. One way to check this is with APEDIT after the apertures + have been defined and traced. In APEDIT you can examine various + lines with ":line #" and the data line and apertures will be + shown. Look at the first line and last line in particular. The + interactive option of APSCATTER selecting various lines can also be + used though this may crash in the same way. + +STATUS: A different algorithm will be used in the next release to + correctly find the scattered light points even in the unreasonable + case where the apertures cross. + +NUMBER: 303 +MODULE: rv.fxcor +SYSTEM: V2.10-V2.10.4 +DATE: Wed Jul 26 15:59:57 MST 1995 +FROM: fitz + +BUG: In rare cases a Gaussian fit would converge to a nonsensical result + (e.g. a sigma of 3e10) and would cause a "floating overflow" error + when the results were written out. The fix requires a trivial + code change, as a workaround select a different set of points for + the initial fit by adjusting the 'width' parameter or interactively + with the 'g' or 'y' keystrokes. + +STATUS: Fixed for the next release. + +NUMBER: 304 +MODULE: proto.wcsreset +SYSTEM: V2.10 +DATE: Tue Aug 1 09:12:11 MST 1995 +FROM: davis + +BUG: Wcsreset was refusing to reinitialize the world coordinate system + of any image whose world coordinate system was not support by the + iraf mwcs system, mostly images with unrecognized sky projection + types. + +STATUS: Fixed in 2.11. There is no workaround except to edit the headers + directly with hedit or hfix. + +NUMBER: 305 +MODULE: apextract tasks +SYSTEM: V2.10-V2.10.4 +DATE: Wed Aug 2 13:57:09 MST 1995 +FROM: valdes + +BUG: If the image header has an invalid DISPAXIS value, for example + a value of -9999, there is no warning and bad things happen. If + the value is less than 0 then the editing plot will show a flat + line with an X range 1-2. If the value is 0 or greater than 2 then + the aperture axis will be shown as either 1 (for even values) or 2 + (for odd values) but tracing will fail and extraction will produce + a floating operand error. The workaround is to either delete the + invalid keyword and use the "dispaxis" parameter or fix the image + header value. + +STATUS: In subsequent releases there will be a warning message and the + invalid value will be ignored. The "dispaxis" value will then + be used. + +NUMBER: 306 +MODULE: identify +SYSTEM: V2.10-V2.10.4 +DATE: Thu Aug 3 13:12:43 MST 1995 +FROM: valdes + +BUG: The rarely used :add command to add lines can cause a segmentation + violation when exiting. The results are still valid and the error + can be ignored. A workaround is that after adding the lines and + doing whatever is desired, a stored past solution can be read or an + intialization be done. + +STATUS: Fixed in later versions. + +NUMBER: 307 +MODULE: splot +SYSTEM: V2.10.3-V2.10.4 +DATE: Fri Aug 11 18:54:55 MST 1995 +FROM: valdes + +BUG: When writing out a spectrum with the 'i' key an error about + the keyword WAT1_002 not being found or cannot be deleted may + occur. Because this occurs in graphics mode the error may flash by + too fast to see (with XGTERM) and you may be repeatedly prompted + for an output image. This loop can only be killed by killing the + CL. The cause of this is a bug in SPLOT which occurs if there are + BANDIDn keywords as produced by extraction with the APEXTRACT + package. This problem has been reported with DEC ALPHA but could + potentially affect any V2.10.3-V2.10.4 system. + + The workaround is to delete the BANDID keywords, which are + only used for documentation currently, using HEDIT. You + can then use SPLOT and write out modified spectra with 'i'. + +STATUS: Fixed in future versions. + +NUMBER: 308 +MODULE: artdata.mkobjects +SYSTEM: V2.9-V2.10.4 +DATE: Mon Aug 14 09:55:27 MST 1995 +FROM: valdes + +BUG: When using an image either as a PSF model or as an object + model the result is very subtly wrong in the fluxes. + The problem showed up when using a symmetrical PSF model + and the resulting star or galaxy profile was not symmetric + at a low level. The measured centroid was off by 0-0.05 + pixels. This is caused by a numerical precision error + that occasionally adds an extra subpixel to the flux + computed for an output pixel. There is no workaround + though the effect can be minimized by using a larger + number of subpixels. However, the effect is very small + and simulations with added noise would likely swamp the + error. + +STATUS: Fixed in later versions. + +NUMBER: 309 +MODULE: sfit, continuum +SYSTEM: V2.10.3-V2.104 +DATE: Tue Aug 15 18:33:59 MST 1995 +FROM: valdes + +BUG: When the capability to select on bands was added the logic to + check whether all lines and bands have been fit to simple. The + effect is that if a subset of lines is fit covering all bands then + later attempts to fit other lines will fail because the task will + see that all bands have been done but doesn't realize some + lines have not been done. The workaround is to set the + override parameter to yes. + +STATUS: In later versions the check on the bands is not done. The user + is responsible for dealing with multiband data. + +NUMBER: 310 +MODULE: daophot.psf +SYSTEM: V2.10 +DATE: Mon Aug 28 08:55:09 MST 1995 +FROM: davis + +BUG: Using the 'd' or ':d' keystroke commands will cause a segmentation + violation on Solaris systems and may cause problems on other systems, + although apparently not on SunOS systems. The problem was caused + by a subroutine which was being called with an unused output variable + set to a constant + +STATUS: Fixed for the next release of iraf. One possible workaround is to + fit the psf with the 'f' keystroke command and then use the 's' + or ':s' keystroke command to examine and optinally delete the star. + +NUMBER: 311 +MODULE: ccdred.cosmicrays +SYSTEM: V2.10.3-V2.10.4 +DATE: Mon Sep 25 16:14:16 MST 1995 +FROM: valdes + +BUG: The bad pixel output file is no longer just the coordinates of the + replaced pixels but it also includes the flux and ratio values. + These extra columns were intended only for development of the + interative training option but accidentally were included in the + release. The problem this causes is that it is no longer correct + to simply use this file with ccdred.badpiximage. The workaround is + to use the FIELDS tasks to select the first and second columns and + then use that in BADPIXIMAGE. + +STATUS: The extra output is eliminated in the next release. + +NUMBER: 312 +MODULE: slist, bplot +SYSTEM: V2.10.3-V2.10.4 +DATE: Tue Sep 26 14:27:26 MST 1995 +FROM: valdes + +BUG: A segmentation error may occur when running SLIST and BPLOT (the + latter calls SLIST). This error has been reported with LINUX + IRAF but could occur with other versions. The output of SLIST + is correct and the error occurs when the task finishes and + frees memory. When running SLIST separately you can just + ignore the error. This is more of a problem with BPLOT. + There is no workaround for BPLOT. Contact iraf@noao.edu + for assistance with the BPLOT problem. + +STATUS: Fixed for the next patch or release of IRAF. + +NUMBER: 313 +MODULE: badpiximage +SYSTEM: V2.9-V2.10.2 +DATE: Mon Oct 2 18:10:45 MST 1995 +FROM: valdes + +BUG: If the output bad pixel image is specified as a pixel list format + image, the .pl extension, the image is likely to contain bad values + or cause a system exception (segmentation violation or bus error). + This is due to a problem in the system code that writes the pl + data to disk. The workaround is to output the bad pixel + image in one of the other image formats (such as .imh) and then + use IMCOPY to copy to the .pl format if desired. + +STATUS: This problem is fixed in V2.10.3 and later versions. For reference + see the system notes for imwrpx.x on 3/7/94. + +NUMBER: 314 +MODULE: apphot centering routines +SYSTEM: V2.10.2 and earlier +DATE: Thu Oct 5 11:15:21 MST 1995 +FROM: davis + +BUG: A bug in the centering algorithms thresholding code resulted in the + cthreshold parameter being interpreted as the threshold in counts + above (below) which pixels were used for centering rather than + the threshold in counts above (below) the local data minimum + (maximum). The problem occurred because the local data minimum + maximum was being computed but not entered into the appropriate + data structure. + +STATUS: This bug is not a problem for 2.10.3 and later versions of apphot + or for the version of apphot in digiphotx. + +NUMBER: 315 +MODULE: photcal.mkapfile +SYSTEM: V2.10 +DATE: Sat Oct 7 12:04:01 MST 1995 +FROM: davis + +BUG: Mkapfile could terminate prematuringly with a floating divide by zero + error in interactive mode or a fit did not converge error in non- + interactive mode, if the input photometry files were binart ST tables. + The problem was caused by missing commas in the tables column + template string which resulted in some of the input aperture radii + not being correctly read in to mkapfile. + +STATUS: Fixed in 2.11 and in the external addon package digiphotx. There is + no workaround but using input photometry files written in text format + instead of ST tables will avoid the problem. + +NUMBER: 316 +MODULE: images.imcombine, ccdred.combine, onedspec.scombine +SYSTEM: V2.10 - V2.4 +DATE: Thu Oct 19 12:24:43 MST 1995 +FROM: valdes + +BUG: In the PCLIP rejection option, if more than the maximum number + of pixels that are allowed to be rejected (set by the nkeep + parameter) are rejected at some point along the output line then + for all subsequent pixels in that line the rejection threshold will + be much higher. Thus there may be pixels that should be rejected + but will not be. The workaround is to set nkeep to zero. Note + that since the sigma is estimated based on the difference between + the median and some percentile pixel you are guarenteed never to + reject all the pixels. + + +STATUS: Fixed in later versions. + +NUMBER: 317 +MODULE: dofibers,dohydra,doargus +SYSTEM: V2.10-V2.10.4 +DATE: Fri Oct 27 11:08:16 MST 1995 +FROM: valdes + +BUG: The option to divide each fiber aperture into subapertures for + independent dispersion calibration before combining them (that is + nsubaps > 1) does not work correctly. The first subapertures are + all correctly put on the specified same dispersion scale. However, + subsequent subapertures are put on a different dispersion scale so + that combining them is incorrect. There is no workaround other + than to not use the subaperture option. The code change is a + simple script change. In files srcfibers$proc.cl and + srcfibers$batch.cl the value of samedisp (only occurs once in each + file) in the calls to DISPCOR needs to be changed to a value of + yes. + +STATUS: Fixed in subsequent versions. + +NUMBER: 318 +MODULE: apall, apedit +SYSTEM: V2.10 - V2.10.4 +DATE: Fri Oct 27 15:34:14 MST 1995 +FROM: valdes + +BUG: When an aperture identification file is used and the user changes + the aperture number with the 'i' or 'o' keys the beam number of + the changed aperture was not changed. This would cause the beam + number for these apertures to disagree with the aperture + identification file. These keys are used when the initial + guess as the ordering of multiple apertures, such as with + multifiber data, is off due to a missing initial fiber. The + apertures could be correctly reordered with 'o' except for the + aperture used as the fiducial. For the reductions which use + the beam number to identify the type of data (such as in + DOFIBERS) this will cause the fiducial aperture to possibly be + treated incorrectly. The workaround is to use 'o' twice from + two different apertures or use 'j' to reset the beam number of + the fiducial aperture. + +STATUS: The software was modified so that an 'i' or 'o' resets the beam + number to that specified in the aperture identification file + for the new aperture number. + +NUMBER: 319 +MODULE: ptools.tbdump,ptools.pdump +SYSTEM: V2.10 +DATE: Thu Nov 2 08:59:26 MST 1995 +FROM: davis + +BUG: If the input photometry file is an ST binary table and the expression + parameter is not equal to "yes", then an intermediate binary + table file is left in the tmp$ area on task termination. This + problem was occurring because the script was calling delete instead + of tdelete, and delete does not know about the .tab extension. + +STATUS: Fixed in the next release of IRAF. There is no workaround except to + delete the files from the tmp$ directory. + +NUMBER: 320 +MODULE: sfit, continuum +SYSTEM: V2.10-V2.10.2 +DATE: Wed Nov 8 13:54:36 MST 1995 +FROM: valdes + +BUG: If one has a list of images containing multiple spectra per image, + such as with echelle or multifiber data, + and one uses the SKIP option for a particular aperture followed + by selection of skip the spectrum, then instead of just skipping the + same aperture in all the images it will skip all the spectra in + all the images. The report will be a warning that there are no + spectra to fit in the subsequent images. + + A related bug is that one may not specify a single aperture + in the list of apertures. + +STATUS: Fixed in V2.10.3 and later. These bugs were caused by an error in + the ranges package. + +NUMBER: 321 +MODULE: calibrate (in onedspec, longslit, and imred spectral packages) +SYSTEM: V2.10.3-V2.10.4 +DATE: Mon Dec 4 17:48:49 MST 1995 +FROM: valdes + +BUG: If the AIRMASS keyword is not in the image header but other + keywords from which the airmass may be computed (RA,DEC,ST or + DEC,HA) are present, the computation of the airmass is not properly + returned causing a floating point exception. Note that if + it can't compute the airmass at all the user prompted for + the airmass as intended. + + The workaround is to set the airmass keyword in the header + using either SETAIRMASS or ASTHEDIT. + +STATUS: Fixed for the next release. + +NUMBER: 322 +MODULE: daophot.nstar +SYSTEM: V2.10.3 and later +DATE: Fri Jan 5 11:48:10 MST 1996 +FROM: davis + +BUG: In rare circumstances nstar can fail with floating operand errors due + to a singular fitting matrix. This circumstance is most likely to occur + when the fitting radius is small, the sky is being refitted, and the + initial guesses for the parameters to be fit are very poor. + + If a group is too large to be fit, e.g. the group size is greater + than the value of the maxgroup parameter, nstar may fail with + memory corruption errors. This occurs because the error code + array is not being properly reallocated in this circumstance and + the error code values run off the end of the error code array. + +STATUS: Fixed for iraf 2.11 and in the ftp archive version of digiphot. A + workaround for the second problem is to increase the value of the + maxgroup parameter. Tweaking the fitting parameters, e.g. increasing + the value of fitrad, may workaround the first problem. + +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: 324 +MODULE: photcal.mkapfile,photcal.apfile +SYSTEM: V2.10 +DATE: Mon Jan 29 17:13:22 MST 1996 +FROM: davis + +BUG: The mkapfile/apfile tasks can go into an infinite loop while + fitting the seeing radius RO for an image if the input image objects + are not stars, e.g. are cosmic rays or galaxies. Objects for which + there is no good data at all can produce a floating point error in the + plotting code because the data limits of the plot are not + being set properly. + +STATUS: Both problems have been fixed for the next release of IRAF and + in the version of photcal in the external addon package digiphotx. + For both problems the workaround is to eliminate the bad data + from the input photometry file. + +NUMBER: 325 +MODULE: onedspec tasks, splot +SYSTEM: V2.10.3-V2.10.4 (before patch 1) +DATE: Tue Jan 30 10:01:17 MST 1996 +FROM: valdes + +BUG: In V2.10.4 patch 1 the syntax for storing the coordinate system + keywords (WAT...) was changed such that the closing quote occurs + at the end of the string rather than the end of the card. This + makes the multispec format spectra incompatible with V2.10.3 + and V2.10.4 before patch1 in various tasks such as SPLOT. The + behavior is: + + In V2.10.3: + ERROR: Unknown coordinate system `multispec'' + In V2.10.4: + WARNING: Unknown coordinate system `multispec'' - assuming `linear'. + + In V2.10.3 this is a fatal error while in V2.10.4 this is a warning + (however it will then not correctly interpret the coordinates). + The workaround is to edit the image header as follows: + + cl> hedit <images> wat0_001 "system=multispec x" + + The extra " x" is needed to force a space after the system name. + After this the data will be compatible with all V2.10 versions. + +STATUS: There is no "fix" to this backward compatibility problem. When + moving to earlier versions users must apply the workaround. + +NUMBER: 326 +MODULE: identify, ecidentify +SYSTEM: V2.10 - V2.10.4 +DATE: Thu Feb 8 11:23:32 MST 1996 +FROM: valdes + +BUG: The 'y' key to find all peaks in a spectrum has a bug where none + or only some of the peaks will be found. When any peak, found by a + peak finding algorithm, fails to be centered then all subsequent + peaks are skipped. There is no workaround though adjusting + parameters that control the centering (threshold, fwidth, cradius, + minsep) and/or decreasing "maxfeatures" to find the strongest + features which should be less likely to fail. + + +STATUS: Fixed for the next release. + +NUMBER: 327 +MODULE: apphot interactive tasks +SYSTEM: V2.10.3 and later +DATE: Mon Feb 12 14:37:55 MST 1996 +FROM: davis + +BUG: The m keystroke command was performing a "measure next object" + operation (the n keystroke command) instead of a "move to next + object operation" as intended. + +STATUS: Fixed for the next release of iraf. The work around is to use the :m + keystroke command. + +NUMBER: 328 +MODULE: images.imexpr +SYSTEM: V2.10 +DATE: Thu Feb 15 15:34:52 MST 1996 +FROM: davis + +BUG: The imexpr task was incorrectly decoding image name operands of the + form "#.extension" (where # stands for a number, e.g. 123.imh) and + "../path/image.extension" (e.g. ../dev/pix.im) as numbers, 123.0 + in the first case, 0.0 in the second. + +STATUS: Fixed for the next release of iraf. The only workaround is to rename + the image if it has the form "#.extension", and avoid image path + names that begin with "..". + +NUMBER: 329 +MODULE: daophot tasks +SYSTEM: V2.10 +DATE: Tue Feb 20 15:52:30 MST 1996 +FROM: davis + +BUG: If one of the numerical fields to be read from the input photometry + file (e.g. ID) is adjacent to another numerical field and there + is no white sapce between them, then the numerical field could be + extracted incorrectly. This most likely to occur when the id numbers + are large, e.g. 10003, and the image and / or coordinate file name + begins with a number, e.g. 8649.imh or 8649.coo.1. + +STATUS: Fixed for the next release of iraf. The workaround is to replace + the numerical part of the image or coordinate file name with an + alphabetic one of the same length. + +NUMBER: 330 +MODULE: imexamine +SYSTEM: V2.10 - V2.10.4 +DATE: Tue Feb 27 08:49:27 MST 1996 +FROM: valdes + +BUG: The 1D gaussian fitting options, j and k, do not work with world + coordinates (wcs = world). The workaround is to do the fitting + in logical coordinates (wcs=logical) and separately translate the + fit parameters to the desired world coordinates. + +STATUS: Fixed for the next release. + +NUMBER: 331 +MODULE: daophot.allstar +SYSTEM: V2.10 +DATE: Thu Mar 7 13:27:11 MST 1996 +FROM: davis + +BUG: Allstar may crash with a floating point exception error if the + input readout noise value is exactly zero. The cause of the crash + is uninitialized memory in the scratch image. Most of the time the + bug is harmless as the affected pixels are never used in the fitting + process. However if the affected portion of memory happens to contain + illegal floating point numbers then a crash may occur. Users are + most likely to encounter this problem if they run the daophot + test script daotest, although so far such crashes have only been + reported for allstar under iraf 2.10.4 on the Dec Alpha. + +STATUS: Fixed for the next release of iraf and in the version of daophot in + the external addon package digiphotx. The workaround is to set the + readout noise to a positive number. + +NUMBER: 332 +MODULE: apphot.daofind, daophot.daofind +SYSTEM: V2.10 +DATE: Mon Mar 18 09:06:06 MST 1996 +FROM: davis + +BUG: The is a bug in the daofind centering code which results in incorrect + fractional pixel corrections being computed for the detected objects. + This error can most easily be detected by plotting the histogram of + the fractional pixel corrections for an image with a large number + of detected objects. The histogram will be modulated at around the + 20% level with "peaks" around the 0.33 and 0.66 fractional pixel + values. + + This bug is also present in the standalone version of daophot ii. + Users concerned about this bug should obtain a fix from Peter + Stetson. + +STATUS: This bug is fixed for the next release of iraf and in the external + addon package digiphotx version of daofind. There is no workaround + although it should be emphasized that this bug does not affect + the centers computed by the psf fitting code in the peak, nstar, + and allstar tasks. Users concerned with precision in the find + step should upgrade their software, or recenter the objects with + the phot "centroid" (fast) or "gauss" (more precise) routines. + +NUMBER: 333 +MODULE: daophot.psf +SYSTEM: V2.10 +DATE: Wed Mar 20 13:59:27 MST 1996 +FROM: davis + +BUG: If the daopars function parameter is set to auto and the best fitting + function is either moffat25 or moffat15, the psf model look-up tables + if any will be computed incorrectly. The problem occurs because + only the 3 fitted parameters (the beta parameter is held fixed) are + being saved and restored correctly. The array element that should + hold the fixed beta value is instead occupied by the equivalent + parameter for the last computed function the penny function. + +STATUS: Fixed for the next release of iraf and in the version of daophot in the + external addon package digiphotx. The workaround is to run psf twice, + once to determine the best fitting function (as this is being + determined correctly), and then again with the function parameter + set to the selected function. + +NUMBER: 334 +MODULE: ccdred.ccdproc +SYSTEM: V2.10 +DATE: Fri Mar 22 11:43:30 MST 1996 +FROM: valdes + +BUG: If the subset keyword used by CCDPROC (the image header keyword + defined in the translation file as something such as FILTERS) + has a value whose first word is longer than 15 characters an error + will given: "No flat field calibration image of subset ... found". + The two simplest workarounds are to edit the subsets file + (the file name is in the CCDRED package parameters) so that + the translation of the subset string given in the first column is a + short unique name in the second column. The other solution is to + edit the image headers with HEDIT to make the first word of the + subset string be less than 15 characters. + +STATUS: Fixed for the next release. + +NUMBER: 335 +MODULE: tv.imedit +SYSTEM: V2.9-V2.10.4 +DATE: Tue Mar 26 11:59:02 MST 1996 +FROM: valdes + +BUG: When the search radius is not zero and an aperture center for + a circular aperture is nearer the bottom or left edge of the image + than half the radius of the circular aperture the replacement + region will be incorrectly defined. This is most apparent with + constant replacement. The work-around is to turn off the search + option (search=0.) or to keep the replacement aperture far + enough from the edge. + +STATUS: Fixed in the next release. + +NUMBER: 336 +MODULE: plot.implot +SYSTEM: V2.10 - V2.10.4p1 +DATE: Wed Mar 27 09:26:36 MST 1996 +FROM: valdes + +BUG: When line or column from a 2D image which is constant (all pixels + with the same value) is plotted, selecting another line or + column with the 'l' or 'c' using the right plot axis does not + work. The workarounds are to either use :l or :c to select + the desired line or set a y range with unequal limits using + :y. + +STATUS: Fixed in the next release. + +NUMBER: 337 +MODULE: images.xregister +SYSTEM: V2.10 +DATE: Wed Apr 3 14:36:35 MST 1996 +FROM: davis + +BUG: Xregister was dying with a floating point error on the Dec Alpha + if the coords parameter was defined. + +STATUS: The bug was caused by a type conversion problem in an array reference. + There is no workaround other than to set the initial shifts using + the xlag and ylag parameters rather than the coords parameter. This + bug could potentially cause problems on other machines, although + so far this has not been observed. + + +NUMBER: 338 +MODULE: scopy, sarith, dohydra, dofibers, and possibly other onedspec tasks +SYSTEM: V2.10 - V2.10.4p1 +DATE: Thu Apr 18 11:47:29 MST 1996 +FROM: valdes + +BUG: When working with "multispec" format data (echelle data or + multiple spectra with different dispersion functions as would + occur if DISPCOR is used without linearizing the spectra to + the same dispersion system) the SCOPY and SARITH task + may fail with a floating point exception. This is caused + by use of an uninitialized array. Because it depends on + what values are in the array it can be sporatic. It appears + to be more likely to occur with the Dec/Alpha/OSF1 version. + There are other tasks which may, in rare cases, also encounter + this. This will only occur with tasks that are creating a new + output spectrum. The workarounds are to avoid cases with differing + dispersions in the same image such as by linearizing all + spectra to the same dispersion function in multifiber or + multislit data. This particularly applies to using DOHYDRA and + DOFIBERS with params.linearize=no. For echelle data there is no + good option other than to avoid having to use SCOPY/SARITH after + dispersion calibration. + +STATUS: Fixed in later versions. + +NUMBER: 339 +MODULE: photcal.invertfit +SYSTEM: V2.10 +DATE: Thu May 2 11:11:20 MST 1996 +FROM: davis + +BUG: Due to a floating point precision problem, the invertfit task could + occasionally go into an infinite loop on Linux systems. + +STATUS: Fixed for the next release of iraf and in the ftp archive version + of digiphotx. There is no workaround. + +NUMBER: 340 +MODULE: standard +SYSTEM: V2.10.4p2 Solaris +DATE: Mon Jun 10 16:47:38 MST 1996 +FROM: valdes + +BUG: In V2.10.4p2 for Solaris there is an optimizer bug in the executable + for the task STANDARD. The flux values are incorrectly + calculated. This will be seen if the bandpasses are plotted. The + boxes will not cover the spectrum. Other indications of trouble + will be the flux values in the output data file will be + monotonically increasing and the sensitivity function solution will + be odd. The only workaround is to get a corrected executable (see + ftp://iraf.noao.edu/pub/x_onedspec.ssolp2.readme). + +STATUS: Fixed for the next release. Another patch may be considered. + +NUMBER: 341 +MODULE: rv.fxcor +SYSTEM: V2.10 +DATE: Wed Jun 26 16:27:30 MST 1996 +FROM: fitz + +BUG: There is a bug in the rv correction code in which images that do + not have an OBSERVAT keyword in the header have the heliocentric + correction computed using KPNO as the observatory regardless of the + task 'observatory' parameter setting. The only workarounds are to + either add an OBSERVAT keyword to each image, or create a dummy + observatory database where the 'kpno' entry contains the information + for the observatory you're really using, you would need to define + an "obsdb" environment variable to this file to make use of it. + A code change fixing this bug is available from iraf site support. + +STATUS: Fixed for versions after V2.10.4p2 + +NUMBER: 342 +MODULE: dohydra, doargus, dofibers +SYSTEM: V2.10-V2.10.4p2 +DATE: Fri Jun 28 16:30:04 MST 1996 +FROM: valdes + +BUG: The fiber extraction task will produce funny results in various ways + if the "apidtable" file does not have the format + + aperture beam title + + WITH THE TITLE QUOTED if there are blanks in the title. The problems + will still only occur if the first part of the title is numeric + so that the task SAPERTURES, used in the script, interprets the + value as dispersion information. + +STATUS: This is warning and indication of what to check if funny results + are obtained. How problems with bad formating of the file + can be avoided is under investigation. + +NUMBER: 343 +MODULE: apphot.daofind, daophot.daofind +SYSTEM: V2.10.4 patch2 +DATE: Mon Jul 22 08:29:12 MST 1996 +FROM: davis + +BUG: In rare circumstances daofind can fail with a floating operand + error. This bug is caused by a divide by zero error in the + new (2.10.4 patch2) roundness statistic computation. + +STATUS: Fixed for the next release of iraf and the addon package digiphotx. + There is no workaround. + +NUMBER: 344 +MODULE: imcombine, combine +SYSTEM: V2.10.2-V2.10.4 +DATE: Thu Aug 1 09:00:22 MST 1996 +FROM: valdes + +BUG: When there are exactly three images, mclip=yes, and scales, zero + levels, or weights are computed and are not all the same there is a + bug that will confuse the scales and weights for about 1/6 of the + pixels. This becomes more significant as the scales/zeros/weights + differ more from each other. This affects computation of the + weighted average (combine=average) and the sigma clipping + algorithms (ccdclip, crrej, sigclip, avsigclip, and pclip). + In addition, even if the scales/zeros are all the same but the + gains and read noise values are different for the ccdclip or + crrej algorithms the gains and read noise values will be misapplied + in 1/6 of the cases. + + The bug is that when mclip=yes the pixels are sorted and the + idenification of which image each pixel came from is kept. When + there are exactly three images an explict sort is done but in one + of the six possible orders of the 3 pixels the identification + mapping to the image is wrong for two of the pixels. Thus the + wrong scale, zero, weight, gain, or read noise will be used. If + they are equal there is no problem but if they are not equal the + weighted average and the scaling of the sigmas in the clipping + rejection algorithms will be wrong. If the values are close there + is still little error. + + The effects of this are probably negligible in most cases + unless the scales or CCD parameters of the images are grossly + different. The only workaround is to set mclip=no. + +STATUS: Fixed for the next release expected to be V2.11. + +NUMBER: 345 +MODULE: rv.rvcorrect, astutil.rvcorrect +SYSTEM: V2.10 +DATE: Mon Aug 26 21:43:48 MST 1996 +FROM: fitz + +BUG: The KEYWPARS pset is not declared for the RVCORRECT task even though + it is available for use. + +STATUS: Fixed for versions later than V2.10.4p2. The workaround is to add the + line + keywpars,pset,h,"",,,"Header keyword translation pset" + + to the file astutil$rvcorrect.par and rv$rvcorect.par. Declarations + in the help page for RVCORRECT should be made in the + rv$doc/rvcorrect.hlp and astutil$doc/rvcorrect.hlp files if needed, + users can cut-n-paste the entry from the rv$doc/fxcor.hlp page if + needed. + +NUMBER: 346 +MODULE: nmisc.psfmeasure, nmisc.starfocus, nmisc.kpnofocus +SYSTEM: NMISC V12-p1 and earlier +DATE: Thu Aug 29 13:32:30 MST 1996 +FROM: valdes + +BUG: If the scale parameter is set to other than one and the PSF + being measured is sufficiently small then the computed PSF + sizes will be incorrect. The workaround is to use a scale + of 1 to compute widths in pixels and then convert to some + other scale separately. + +STATUS: Fixed in NMISC V12-p2 + +NUMBER: 347 +MODULE: noao.rv.fxcor +SYSTEM: V2.10p2 and earlier +DATE: Thu Sep 12 14:52:16 MST 1996 +FROM: fitz + +BUG: The normalized reference spectrum was being copied from the object + spectrum when the image names were the same as a form of optimization. + This could fail in cases where the 'n' key was used to move through + a list to get the next object and the object spectrum was previously + rebinned at a different dispersion causing artificial shifts in + the data. The code was modified to always compute a normalization + to avoid this in all cases. Workarounds include rebinning all + spectra to a common dispersion or setting the 'rebin' param to be + 'object'. + +STATUS: Fixed in versions after V2.10.4p2. + +NUMBER: 348 +MODULE: artdata.mkobjects +SYSTEM: V2.10-V2.10.4p2 +DATE: Tue Oct 1 10:35:05 MST 1996 +FROM: valdes + +BUG: The routine for computing Poisson deviates does not check for + negative input values which can lead to a floating point + exception. This routine can be called with negative values if the + objects being created have negative values and the "poisson" + parameter is yes. Negative values in the model objects can occur + if image template models are used either for the objects or for the + PSF. The workarounds are to make sure the object models do not + have negative values, to use a "background" parameter sufficiently + large to make the object+background be non-negative, or to not add + Poisson noise. The first option is the rigorously correct + solution. The case that identified this bug was with an + empirically generated PSF that produced some negative values at the + edge of the PSF template. + +STATUS: The Poisson deviate routine now returns zero if the input + Poisson mean is negative. + +NUMBER: 349 +MODULE: astutil.pdm +SYSTEM: -V2.10.4p2 +DATE: Tue Oct 1 16:49:49 MST 1996 +FROM: valdes + +BUG: When there are fewer than 100 input data points the calculation of + theta is incorrect. This is because the calculation does not take + into account use of overlapping period bins for the small N case. + The theta plot values will be incorrect (negative) but the shape + appears to be approximately correct. It is not clear how the error + acts in detail. One workaround is to increase the number of data + points, say by replication, to greater than 100 points. Note that + the shape of the theta curve will be different even if the error + was not present because of the change in binning from overlapping + bins to non-overlapping bins. + +STATUS: Fixed for the next release. + +NUMBER: 350 +MODULE: echelle.doecslit +SYSTEM: V2.10.4 +DATE: Thu Oct 3 13:29:40 MST 1996 +FROM: valdes + +BUG: In V2.10.4 the batch option of DOECSLIT does not work. The + workaround is to run DOECSLIT with the batch option turned on + until it tries to run the background processing and fails with + an error. At this point all the interactive things have been done. + Now run DOECSLIT directly in the background with: + + ec> doecslit <images> splot- >& dev$null& + + Be sure the list of images is the same or at least includes + images previously used in the interactive step. + +STATUS: Fixed for the next release. + +NUMBER: 351 +MODULE: center1d +SYSTEM: V2.9-V2.10.4 +DATE: Thu Oct 24 13:11:29 MST 1996 +FROM: valdes + +BUG: This subroutine algorithm is used in many places such as APFIND, + APRECENTER, APEDIT, APTRACE, IDENTIFY, REIDENTIFY, ECIDENTIFY, and + ECREIDENTIFY (and possibly more). One feature of this algorithm is + that if the centering width parameter is less than or equal to one + pixel it will find the nearest local maximum (minimum) to the + starting point. The bug was that unless the starting point is a + local minimum (maximum) it would simple return the nearest pixel to + the starting point. There is no workaround. + +STATUS: Fixed for the next release. + +NUMBER: 352 +MODULE: starfocus, kpnofocus +SYSTEM: nmisc external package earlier than V12-p3 +DATE: Thu Oct 24 17:27:55 MST 1996 +FROM: valdes + +BUG: The routine that fits a parabola to the three lowest points when + estimating the best FWHM could crash or give poor results when + the focus values are large. For example focus values around + 10000. The workaround is to use focus values which are + small (less than 1000). + +STATUS: Fixed in NMISC V12-p3 + +NUMBER: 353 +MODULE: astutil.pdm +SYSTEM: -V2.10.2 +DATE: Wed Nov 6 11:32:16 MST 1996 +FROM: valdes + +BUG: PDM will only draw graphs with points. The points are often very + difficult to see. There is a parameter, which is not documented + in the help page up to V2.10.4p2, called "pluspoint" that is + supposed to define the maximum number of data points for which + plus symbols are used before going to points. However there + is a bug that prevents this feature from working. + +STATUS: The pluspoint parameter works in V2.10.3 and later and is documented + in versions later than V2.10.4p2. + +NUMBER: 354 +MODULE: scombine +SYSTEM: V2.10-V2.10.4p2 +DATE: Mon Nov 11 11:39:41 MST 1996 +FROM: valdes + +BUG: The option to use image header keywords for the scale, zero, + and weight values by specifying the parameter values as + "!<keyword>" does not work. The symptoms are either an error that + the image header keyword does not exist or all the scale, zero, or + weight values come out the same. The workaround is to put the + values into a file and use the file input option. For example one + cannot use 'weight="!wtkeyword" but one can do the following: + + on> hselect <spectra> wtkeyword yes > wts + on> scombine <spectra> weight="@wts" + + where <spectra> are the list of spectra and "wtkeyword" is the + keyword in the images to use for the weights. + +STATUS: Fixed for the next release. + +NUMBER: 355 +MODULE: apall, apsum +SYSTEM: V2.10-V2.10.4p2 +DATE: Tue Nov 12 16:36:10 MST 1996 +FROM: valdes + +BUG: If dispaxis=1 and using cleaning or variance weighted extraction + with a gain > 1 and with a large number of apertures which have + differing widths it is possible to get a floating overflow error. + The workarounds are to either multiply the images by the gain + and then set the gain to 1 for the extraction or transpose + the images so that dispaxis=2. + +STATUS: Fixed in the next release. + +NUMBER: 356 +MODULE: splot +SYSTEM: V2.10.4 (including p1 and p2) +DATE: Tue Dec 3 12:02:39 MST 1996 +FROM: valdes + +BUG: Any units string in the "units" parameter that contains whitespace, + such as "km/s 400 ang" "inv cm", will fail to be recognized. This + is because the whitespace is removed to check for a null string. + This means such units cannot be specified for SPLOT to start up + with. The work around is to change the units interactively + with :units. + +STATUS: Fixed for the next release. + +NUMBER: 357 +MODULE: splot +SYSTEM: V2.10-V2.10.4p2 +DATE: Fri Jan 10 16:33:32 MST 1997 +FROM: valdes + +BUG: The 'a' key for expanding a region with y scaling based on the + values in the selected region can be wrong if the dispersion is + non-linear. This is because the inversion from dispersion + coordinate to pixel is done assuming a linear dispersion. The + symptom is that the y scale will not cover the data. If the data + is sufficiently sloped and the dispersion sufficiently non-linear + it is possible the graph window will be outside the range of the + data yielding an empty plot. The workaround is to use the 'w' + windowing keys such as 'e'. + +STATUS: Fixed for the next release. + +NUMBER: 358 +MODULE: dofibers, dohydra, doargus +SYSTEM: V2.10-V2.10.2 +DATE: Wed Jan 15 09:32:23 MST 1997 +FROM: valdes + +BUG: When there are more than 127 fibers and the aperture identification + file has titles for all the fibers these script tasks will fail + either with a segmentation violation or the error + "Too many field names in image header field name template". + This is caused by calls to SCOPY and SARITH in the scripts + which trigger the previously recorded Bug #241. The only + work around is to not use aperture titles. At the end of + the processing one may associate titles with the apertures + using SAPERTURES. + +STATUS: Fixed in version 2.10.3. + +NUMBER: 359 +MODULE: calibrate (onedspec, longslit, imred spectral packages) +SYSTEM: V2.10.3-V2.10.4p2 +DATE: Wed Jan 22 11:18:52 MST 1997 +FROM: valdes + +BUG: The flux calibration of spectra with non-linear dispersion is + incorrect. Instead of dividing by the wavelength width of each + pixel the width of the pixel corresponding to the image line is + used for all pixels at a given line; (i.e. the width of pixel 2 is + used for all pixels in the spectrum of the second line in a + multispec image). Since a linear dispersion has constant pixel + width by definition, this bug does not affect linearized spectra. + The magnitude of the error depends on how non-linear the dispersion + is; i.e. how much the widths of the pixels vary. The workaround + is to linearize the spectra first with DISPCOR. + +STATUS: Fixed for 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. + +NUMBER: 361 +MODULE: scombine +SYSTEM: V2.10.3-V2.10.4p2 +DATE: Wed Feb 19 11:19:14 MST 1997 +FROM: valdes + +BUG: If several multispec images with the "equispec" coordinate system + (headers "WAT0_001 = 'system=equispec'" and with APNUM keyword) + are being combined by aperture where the set of apertures in each + image are not the same and if the first image in the input list + does not contain all the apertures then an error about a missing + aperture will occur. For example: + + ERROR: Image header parameter not found (APNUM79) + + More precisely, the problem occurs if the output image will + have more apertures than in the first input image. + + The workarounds are to either put an image which has all the + apertures first in the input list or use the "aperture" parameter + to select fewer or an equal number of apertures to the first + image. For example: + + cl> scombine a,b,c,d out1 apertures=1-50 + cl> scombine a,b,c,d out2 apertures=51-100 + cl> scopy out1,out2 out + + where the input images contain apertures 1 to 60 but there with + missing apertures in each image. Image a has 50 apertures. + Note that it is alright to specify apertures that do not exist + as long as the number of existing apertures does not exceed + the number in the first input image. + +STATUS: Fixed for the next release. + +NUMBER: 362 +MODULE: daophot.pstselect, daophot.psf +SYSTEM: V2.10 +DATE: Fri Feb 21 13:17:11 MST 1997 +FROM: davis + +BUG: The pstselect and psf task were not reinitializing the psf star list + correctly when more than one image was being analyzed in a single + execution of either task. In the case of pstselect, psf stars whose ids + were identical to the ids of psf stars in previous images were being + arbitrarily rejected from the psf star list. In the case of psf, psf + stars from previous lists could be retained in the list, although + this was unlikely because the positions and magnitudes would usually + result in the star being severely down-weighted or rejected from the + fit. + +STATUS: Fixed for 2.11 and in the ftp archive version of the addon package + digiphotx. The workaround is to use pstselect and psf on a single + image at a time. The z keystroke command in the psf task will also + reinialize the list properly. + +NUMBER: 363 +MODULE: dispcor +SYSTEM: V2.10.2-V2.10.4p2 +DATE: Tue Mar 4 09:17:37 MST 1997 +FROM: valdes + +BUG: Input spectra which are in two dimensional images, have an "equispec" + coordinate system, and log sampled (DC-FLAG=1), are not properly + resampled by DISPCOR. One dimensional images and "multispec" + coordinate systems do not have this problem. The workaround is to + convert all the spectra to one dimensional images with SCOPY and + format="onedspec". + +STATUS: Fixed for the next release. + +NUMBER: 364 +MODULE: onedspec +SYSTEM: V2.10-V2.10.4p2 +DATE: Tue Mar 4 11:55:48 MST 1997 +FROM: valdes + +BUG: The coordinate function driver, the system software that evaluates + coordinates, for multispec format spectra incorrectly inverts + wavelengths to pixels for the case of log sampled coordinates + with a doppler shift. This will cause various tasks to misbehave + such as equivalent width measurements in SPLOT. The log + sampling occurs when using DISPCOR with log=yes and the doppler + shift is added to the coordinate system when DOPCOR is run. + The workaround is to not run DOPCOR on log sampled multispec + spectra (such as echelle data) and correct any measurements + made for doppler shifts after the fact. To determine if + you have this type of format you will "specN=" strings in + WAT keywords. In these strings the third number will be 1 + for log sampling and the seventh number will be non-zero + for the doppler correction. + +STATUS: Fixed in the next release. + +NUMBER: 365 +MODULE: apall, apsum +SYSTEM: V2.10.4 +DATE: Wed Apr 2 12:27:20 MST 1997 +FROM: valdes + +BUG: The "strip" format option may fail with the error + + No write permission on file (String_File) + + Unfortunately there is no workaround for this error. + Contact iraf@noao.edu for a fix. + +STATUS: Fixed for the next release. + +NUMBER: 366 +MODULE: implot +SYSTEM: V2.10.4 Dec Alpha OSF1 +DATE: Thu Apr 3 11:36:07 MST 1997 +FROM: valdes + +BUG: Attempting to plot a 3D image, even if the third dimension is only + 1 (i.e. [512,512,1]), results in "ERROR: FPE" on Dec Alpha/OSF1. + This does not occur on the Sun versions. The workaround is + to use an image section: + + cl> implot im3d[*,*,1] + +STATUS: To be fixed in a future version. + +NUMBER: 367 +MODULE: images.tv.tvmark +SYSTEM: V2.10 +DATE: Thu Apr 17 15:02:40 MST 1997 +FROM: davis + +BUG: The 'a' keystroke command can produce a segmentation violation + when 1) the coordinates file does not exist at task startup time, + and 2) the label parameter is set to "yes". So far this bug + has only been reported on Sun Solaris systems. + + The bug is due to a failure to initialize the label string to "" + in the call to the routine which actually draws the mark. + +STATUS: Fixed for the next release of IRAF. The workaround is to create + an empty coordinates file before starting tvmark or to avoid + use of the label feature. + +NUMBER: 368 +MODULE: images.geotran +SYSTEM: V2.10 +DATE: Tue Apr 29 16:46:38 MST 1997 +FROM: davis + +BUG: Geotran fails if the user: 1) sets any of xmin, xmax, ymin, ymax + explicitly, and 2) xmin > xmax or ymin > ymax. The failure is + occuring because the computed number of columns or lines is + negative in that case. + +STATUS: Fixed for 2.11. The workaround is to always ensure that xmin < xmax + and ymin < ymax and perform any image flipping after the fact. + +NUMBER: 369 +MODULE: images.median,images.mode +SYSTEM: V2.10 +DATE: Fri May 16 10:22:26 MST 1997 +FROM: davis + +BUG: The pixels in alternating lines on the far right side of an image + may be in error due to a bug in the merge-sort algorithm indexing + code that is triggered when the sliding median filter turns the + corner. + +STATUS: This bug is fixed in iraf 2.11 and was never a problem for the median + and mode tasks in the mfilters addon package or in any of the other + mfilters tasks. + +NUMBER: 370 +MODULE: standard +SYSTEM: V2.10-V2.10.4 +DATE: Tue May 27 10:09:21 MST 1997 +FROM: valdes + +BUG: The task is supposed to only include bandpasses which are entirely + within the spectrum data. However, this turns out not to be the + case and partial bandpasses are used without any corresponding + correction to the calibration fluxes. This means the end points + may cause a spurious behavior in the sensitivity function + calculation unless the endpoints are ignored. The workarounds + are either to delete the points in the standard data file or + when fitting the sensitivity function in SENSFUNC. + +STATUS: Fixed for V2.11. + +NUMBER: 371 +MODULE: apphot.daofind, daophot.daofind +SYSTEM: V2.10 +DATE: Tue Jun 24 10:50:44 MST 1997 +FROM: davis + +BUG: Daofind can fail with a divide by zero error in rare cicumstances + due to a failure to trap a potential divide by zero in the + x and y centering code. The problem is most likely to occur if + the detection threshold is very low, or if very bad values of + sigma, gain, or readout noise are supplied. + +STATUS: Fixed for 2.11. + +NUMBER: 372 +MODULE: images.imexpr +SYSTEM: V2.10 +DATE: Mon Jun 30 10:00:41 MST 1997 +FROM: davis + +BUG: Expressions involving the J, K, etc operands may be evaluated + incorrectly if the I operand does not preceed them in the expression. + +STATUS: Fixed for 2.11. The workaround is to include a dummy term containing + I in the expression, e.g. 0.0 * I, before the J, K, etc appear. + +NUMBER: 373 +MODULE: longslit.response +SYSTEM: V2.11Beta +DATE: Thu Jul 10 11:47:18 MST 1997 +FROM: valdes + +BUG: The Beta version of V2.11 has a bug such that if the dispersion + axis is 1 and the threshold parameter is not INDEF then the + resulting response image will be incorrect. The error is a typo + that reversed the column and line indices in the division by the + normalization spectrum. + +STATUS: Fixed for the V2.11 release. + +NUMBER: 374 +MODULE: sarith +SYSTEM: V2.10-V2.11Beta +DATE: Tue Jul 15 10:27:11 MST 1997 +FROM: valdes + +BUG: The power option ^ does not work. The workaround is to use + the multiple steps of taking the log, multiplying, and taking + the anti-log. + +STATUS: Fixed in V2.11. + +NUMBER: 375 +MODULE: images.xregister, immatch.xregister +SYSTEM: V2.10 +DATE: Fri Jul 25 14:59:18 MST 1997 +FROM: davis + +BUG: The xregister task was failing if: 1) the correlation parameter was + set to "fourier" and, 2) at least one of the correlation regions was + entirely off the input image. If this circumstance occurred all + subsequent region shifts for the current and succedding images + are set to INDEF, and if all the shifts for a given image were + INDEF, the total shift was set to 0.0. + +STATUS: Fixed in 2.11 and in the version of the external addon package + immatch, now renamed to immatchx. + +NUMBER: 376 +MODULE: images.imhistogram, plot.phistogram +SYSTEM: V2.10 +DATE: Thu Jul 31 16:08:51 MST 1997 +FROM: davis + +BUG: Images with pixel values outside the legal integer range can produce + invalid floating point operation errors in the imhistogram and + phistogram tasks in some circumstances. + +STATUS: Fixed for 2.11. In most but not all cases modifying the histogram + binning parameters z1 and z2 will work around the problem. + +NUMBER: 377 +MODULE: splot, identify, and all onedspec tasks operating on 2D images +SYSTEM: V2.10.3-V2.11beta +DATE: Wed Aug 6 14:39:37 MST 1997 +FROM: valdes + +BUG: Beginning with V2.10.3 the ONEDSPEC tasks allow using previously + transposed 2D images. However if the image is also flipped, say + with the command: + + cl> imtranspose im1[-*,*] im2 + + then these tasks can fail with an arithmetic error such as + "floating operand" depending on the dispersion axis. The + workaround is to reset the physical and/or world coordinates with + WCSRESET. + +STATUS: Fixed for V2.11. + +NUMBER: 378 +MODULE: onedspec.sfit, onedspec.continuum +SYSTEM: V2.10-V2.11 +DATE: Wed Sep 3 10:56:08 MST 1997 +FROM: valdes + +BUG: When there is an error accessing an input image, such as specifying + a non-existant image, the error given is: + ERROR: With range specification for `lines or bands' + This is due to the structure of the program that first uses the + the image sizes to set the acceptible limits of the lines and + bands to be fit. If there are no images the limits are zero + lines and bands and the above error occurs. + +STATUS: This bug log documents the behavior as of V2.11. Modifications have + yet to be determined. + +NUMBER: 379 +MODULE: plot.phistogram +SYSTEM: V2.11 +DATE: Sat Oct 4 14:58:58 MST 1997 +FROM: davis + +BUG: Phistogram fails with a segmentation violation for text file input. + This bug was inadvertantly introduced by the fixmade to bug 376. + +STATUS: Fixed for the next release of IRAF. There is no workaround. + +NUMBER: 380 +MODULE: imcombine/combine +SYSTEM: V2.11 +DATE: Tue Oct 21 14:09:34 MST 1997 +FROM: valdes + +BUG: With STF format images (GEIS files) there is a limit of 58 images + that can be combined. More than this will produce a cannot + open file error on an image. The workaround is to either + convert the images to another format or stack the images + using IMSTACK and then combine with the "project" option. + + +STATUS: Fixed for the next patch or release. + +NUMBER: 381 +MODULE: dimsum +SYSTEM: V2.11 +DATE: Wed Oct 22 09:20:46 MST 1997 +FROM: valdes + +BUG: When using DIMSUM with V2.11 you must have image type inheritance + enabled; for example 'reset imtype="imh,inherit"'. This may + be set in your login.cl or loginuser.cl or on the command line + (type "flpr" when resetting on the command line). If inheritance + is not enabled then mask files will be converted to non-mask + files causing the reductions to fail. + +STATUS: A solution is being determined. + +NUMBER: 382 +MODULE: splot +SYSTEM: V2.11 +DATE: Thu Oct 23 09:23:46 MST 1997 +FROM: valdes + +BUG: When doing a profile fit on data that has negative values and + using the default INDEF values for sigma0 and invgain that turn off + error computations the error message "Cannot compute errors with + non-zero gain and negative pixel values" is produced. The warning + can be ignored. To eliminate it (remembering that this only occurs + with negative values in the spectrum) the workaround is to set + invgain to zero and sigma0 to a positive value. + +STATUS: This is fixed for a future patch or release. + +NUMBER: 383 +MODULE: dataio.rfits +SYSTEM: V2.11 +DATE: Tue Nov 4 09:38:35 MST 1997 +FROM: davis + +BUG: Header listing as slow because rfit is reading through the data instead + of skipping it if: 1) the make_image parameter is no, 2) there are + no fits extensions in the file, and 3) the tapecap parameter fe is + undefined. This bug affects the 2.11 version of rfits only, and was + introduced when support for fits image extensions was added. + +STATUS: Fixed for the next release of iraf. If fast header listing is required + the workaround is to use the old version of rfits, orfits in the + obsolete package. + +NUMBER: 384 +MODULE: artdata: mkobjects, mknoise, mk2dspec +SYSTEM: V2.9 - V2.11 +DATE: Wed Nov 19 10:40:55 MST 1997 +FROM: valdes + +BUG: The ARTDATA tasks which can record comments from an input data + file in the image header will produce improper headers if the input + data has tab characters. The consequence of this only affects FITS + files produced directly through the FITS kernel or using WFITS to + write a FITS file from some other image format. Such FITS files + will have malformed headers and when using the FITS kernel a possible + error is "Pixel storage file is truncated". The most common + way this problem can occur is with MKOBJECTS using object lists + produced by STARLIST or GALLIST which generate comments with tab + characters in them. The workarounds are to turn off the "comments" + parameter in the task to eliminate the writing of the data file + comment information to the header or not producing a FITS file from + the created image. + +STATUS: Fixed after the initial V2.11 release. + +NUMBER: 385 +MODULE: dataio.import +SYSTEM: V2.11 +DATE: Fri Dec 12 13:43:33 MST 1997 +FROM: fitz + +BUG: Use of the red(), green(), or blue() functions in the outbands + expression parameter can cause the size of the output image to + be incorrectly computed, resulting in a "Negative or zero length + dimension" error. + +STATUS: Fixed for the next patch or release. There is no workaround. + +NUMBER: 386 +MODULE: immatch.linmatch +SYSTEM: V2.11 +DATE: Mon Dec 15 12:24:52 MST 1997 +FROM: davis + +BUG: Linmatch could crash with a floating operand error if the bscale scaling + algorithm was one of "mean", "median", or "mode", and the reference + image contained one or more regions with a zero-valued mean, median, + or mode. The error was in the computation of the error in the bscale + value. + +STATUS: Fixed for the next release of iraf. The only work around is to choose + the regions used for scaling carefully. + +NUMBER: 387 +MODULE: identify,autoidentify,reidentify +SYSTEM: V2.10.4 - V2.11.1 +DATE: Mon Jan 12 14:39:26 MST 1998 +FROM: valdes + +BUG: If the coordinate list has duplicate values it is possible to + get a floating divide by zero error when using the automatic + line identification algorithm. For example using the 'x' + key in IDENTIFY or using the autoidentify algorithm in + REIDENTIFY. + +STATUS: A change in V2.11.2 eliminates duplicate lines automatically as + well as no longer requiring the line lists to be sorted. + +NUMBER: 388 +MODULE: doecslit +SYSTEM: V2.10-V2.11.1 +DATE: Tue Jan 27 10:54:07 MST 1998 +FROM: valdes + +BUG: If dispcor=no, splot=no, and batch=yes, so the task will go directly + to batch extraction without needing to do any dispersion calibration, + the following error will occur. + + ERROR on line 475: Attempt to access undefined local variable `arcref'. + + This is due to failing to initialize this variable when dispcor=no + but attempting to pass it's value to the batch stage. The + workaround is to not use batch execution in this case. + +STATUS: Fixed for a future release. + +NUMBER: 389 +MODULE: proto.fixpix +SYSTEM: V2.11-V2.11.1 +DATE: Thu Jan 29 16:27:19 MST 1998 +FROM: valdes + +BUG: Depending on the details of the regions being fixed and the + interpolation directions it is possible that some regions that are + specified to be fixed will not be fixed. This is caused by + subtleties of how the image is both read and written during the + processing. The only workaround is to try doing the fixing in + several steps; such as by going back to the regions that were not + changed and using FIXPIX with the regions separated to one at a + time. + +STATUS: This is fixed for the next release. + +NUMBER: 390 +MODULE: dataio.export +SYSTEM: V2.11 +DATE: Mon Feb 2 19:46:41 MST 1998 +FROM: fitz + +BUG: The outbands expression + + setcmap(zscale(i1,@"i_minpixval",@"i_maxpixval"),"heat") + + will fail to find the colormap name properly because of a confusion + in counting the quotes when parsing the expression resulting in a + "Cannot open requested colormap file" message. + +STATUS: Fixed in V2.11.2. A code change is required to fix this bug. As a + workaround users can first use export to create an IRAF image of + the scaled values, and then again to apply to colormap. For example + + cl> export dev$pix foo imh \ + >>> outbands="zscale(i1,@"i_minpixval",@"i_maxpixval")" + cl> export foo bar gif outbands="setcmap(i1,"heat") + +NUMBER: 391 +MODULE: splot, fitprofs +SYSTEM: V2.10-V2.11.1 +DATE: Thu Feb 12 10:29:40 MST 1998 +FROM: valdes + +BUG: A mixture of profile types in deblending or profile fitting + may result in a floating point error. The only mixture that + will work is if the first profile is "voigt". So what works is all + profiles of the same type or voigt first plus anything else. This + means the only combination that will not work and for which there + is no workaround is a combination of "lorentz" and "gaussian". + +STATUS: Fixed in the next release. + +NUMBER: 392 +MODULE: splot, fitprofs +SYSTEM: V2.10-V2.11.1 +DATE: Thu Feb 12 11:01:44 MST 1998 +FROM: valdes + +BUG: This is an amendment to buglog 391. The error reported in buglog + 391 will only occur when computing errors with the bootstrap + method. The fitting without the error computation can use any + combination of profiles. + +STATUS: The error is fixed in the next release. + +NUMBER: 393 +MODULE: rv.fxcor +SYSTEM: V2.11.1 +DATE: Tue Feb 17 14:57:11 MST 1998 +FROM: fitz + +BUG: When computing a deblended fit to the correlation peak the task + may trigger a "floating overflow" exception when quitting the + deblending routine. + +STATUS: The bug occurs only when the velocities for each component cannot + be computes and are returned as INDEF values. Starting with V2.11 + the double-precision value of INDEF was changed to 10e308 and will + cause an overflow when it's converted to real when saving values in + the task structure. A code change is required to fix this. As a + workaround be sure that all necessary keywords are in the image + header prior to the correlation so velocities can be computed. A + list of missing keywords is printed in the verbose output listing + generated by the 'v' keystroke when the 'verbose' parameter is + 'long' or 'txtonly', use the initial fit of a single function to + get these keywords prior to deblending. + + Fixed for the next release. + +NUMBER: 394 +MODULE: apall, apsum +SYSTEM: V2.11 - V2.11.1 +DATE: Thu Feb 19 15:11:13 MST 1998 +FROM: valdes + +BUG: When the output format is "echelle" and the "extras" information is + produced (extras=yes and background subtraction or cleaning or + variance weighting) then the header information may come out + for a 2D images instead of a 3D image. The consequence of this + is that SPLOT or other ONEDSPEC tasks will not be able to find + and use the extra data. This appears to happen with Solaris + and not with SunOS so there is some system dependence on whether + this happens or not. The workaround is to edit the header to + change WCSDIM to 3 and add the keywords CD3_3 and LTM3_3 with + value of 1: + + cl> hedit <ec images> wcsdim 3 + cl> hedit <ec images> cd3_3 1. + cl> hedit <ec images> ltm3_3 1. + + Another workaround is to set the output format to "multispec" + instead of "echelle". If nsubaps=1 then there is no difference + except for the image name extension between the two formats. + +STATUS: Fixed for the next patch or release. + +NUMBER: 395 +MODULE: IMFORT +SYSTEM: PCIX V2.11.1, DUNX V2.11.1 +DATE: Tue Feb 24 09:51:19 MST 1998 +FROM: tody + +BUG: When run on a byte-swapped platform (e.g. the DEC Alpha or a PC) + IMFORT can generate images that have the byte swap flag set + incorrectly in the image headers, causing the image pixels to be + improperly byte swapped: image reads either return wildly invalid + pixels or abort with a floating invalid exception. + +STATUS: The temporary fix is to install a new libimfort.a. New versions of + this library are available in the archives for PCIX (PC-IRAF) and + DUNX (Digital Unix for the DEC Alpha). This will be fixed more + formerly in the upcoming V2.11.2 patch. See the section at the end + of the README file in each distribution directory for additional + comments or other platform specific notes. + +NUMBER: 396 +MODULE: setjd +SYSTEM: V2.11.1 (affects Linux/Slackware and possibly other systems) +DATE: Tue Mar 10 12:38:29 MST 1998 +FROM: valdes + +BUG: There is an incorrect procedure declaration. For some systems this + does not cause a problem but at least with IRAF V2.11 for Linux + (Slackware) this produces a "floating point exception" error. + Contact iraf@noao.edu for either a code fix or a binary upgrade. + +STATUS: Fixed for the next patch or release following V2.11.1. + +NUMBER: 397 +MODULE: ccdproc, fixpix +SYSTEM: V2.11 - V2.11.1 +DATE: Fri Mar 20 15:10:23 MST 1998 +FROM: valdes + +BUG: When using "fixpix=yes" in CCDPROC or using the FIXPIX task on a + a single long list of input images in one execution + the error "ERROR: 757 <filename>" will occur. This error + means that too many files have been opened and not closed. This is + caused by a bug in accessing the mask that fails to close the mask + after each image is finished. The limit is about 58 images + when using a text file description of the bad pixels and 116 + images when using a bad pixel mask (a .pl file). The workaround + is to break up the processing into smaller sets of images. + If using a text file bad pixel description one can increase + the number of images by converting to a pixel mask file using + the task PROTO.TEXT2MASK. + +STATUS: This will be fixed in future releases. + +NUMBER: 398 +MODULE: daophot.psf +SYSTEM: V2.11 and earlier +DATE: Wed Apr 15 09:12:38 MST 1998 +FROM: davis + +BUG: If a path name is including in the output psf image specification + then the psfimage image name written in the output group and psf + star photometry files may include a control character which is + expressed as ^P. This causes trouble for those daophot tasks which + try to read the group file, e.g. nstar. + +STATUS: The bug was caused by accessing the psf image template list with a file + template command and has been fixed for the next release of IRAF + and in the external addon package digiphotx. The work around is + to remove the ^P character from the photometry files with the editor. + +NUMBER: 399 +MODULE: IMEDIT on FITS files +SYSTEM: V2.11 - V2.11.1 +DATE: Thu Apr 16 09:31:26 MST 1998 +FROM: valdes + +BUG: If multiple FITS format images are edited the output FITS image + may have the header of an earlier input image rather than the + header of the image which was edited. The workaround is to + edit images one at a time and type "flpr" between executions. + +STATUS: This is a problem with the FITS kernel image caching which will + be fixed in a future patch or release. + +NUMBER: 400 +MODULE: scopy, sarith +SYSTEM: V2.10-V2.11.1 +DATE: Fri Apr 17 16:04:13 MST 1998 +FROM: valdes + +BUG: When using SCOPY or SARITH with rebin=yes on spectra which have + non-linear dispersion functions the resulting spectra will have + an incorrect dispersion function. The problem is the dispersion + function will be linear but the dispersion type value is still + set to non-linear. Attempting to use this spectrum will cause + an error, such as a segmentation violation, because the software + will look for the non-linear dispersion coefficients which do + not exist. One may use rebin=no to extract a desired wavelength + range without rebinning the spectra or use DISPCOR to resample + the spectra to a specific dispersion range. + +STATUS: Fixed for the next patch or release. + +NUMBER: 401 +MODULE: astutil.asthedit +SYSTEM: V2.10-V2.11.1 +DATE: Fri May 15 11:44:19 MST 1998 +FROM: valdes + +BUG: The if-else-endif syntax does not work correctly. The following + example shows what doesn't work even though correctly specified. + + if (dec > 45) + print ("above 45") + else + print ("below 45") + endif + + This will only execute the if part if dec > 45 and do nothing if + dec < 45. The bug is that a single word is considered to be + a keyword and so "else" and "endif" are interpreted as keywords + and not statements. The workaround is as shown below using the same + example. + + if (dec > 45) + print ("above 45") + else = else + print ("below 45") + endif = endif + + The same applies to the special statment "quit" which needs to + be issued as "quit = quit". + +STATUS: Fixed for a future release. + +NUMBER: 402 +MODULE: reidentify +SYSTEM: V2.11-V2.11.1 +DATE: Mon Jun 1 10:08:25 MST 1998 +FROM: valdes + +BUG: When using REIDENTIFY to trace spatial positions in long slit data + for distortion calibration, an incorrect shift is used when + switching from tracing in decreasing line/column numbers to tracing + in increasing numbers. The shift used is that between the + reference point and the lowest line/column and it is applied to the + next increasing point from the reference position. If this shift + is significant then this can cause the features to either fail to + be found or to have the wrong features found. + + Normally for long slit distortion calibration in the initial + identifications of features to trace (with IDENTIFY) no function is + fit between the measured positions and the reference positions + (which are usually the same as the measured positions). By fitting + a function the problem will be avoided. Any function will do since + FITCOORDS later fits its own function and the IDENTIFY/REIDENTIFY + function is never used. + +STATUS: This is fixed for future releases. + +NUMBER: 403 +MODULE: fixpix, ccdproc, display +SYSTEM: V2.11-V2.11.1 +DATE: Fri Jun 5 09:45:47 MST 1998 +FROM: valdes + +BUG: When fixing regions by interpolation along columns/across lines, + which may be set by the user or automatically by finding the + narrowest direction across a region of bad pixels, it is possible + to get a segmentation error or error related to referencing invalid + memory. Whether this error occurs depends on the contents + of memory. If no error occurs the result is correct. + + One workaround is to use only interpolation across columns/along + lines if this makes sense. Another workaround is to add a dummy + region with interpolation along columns covering all the columns. + For example the first or last line as in "1 3072 1 1" for an image + with 3072 columns. It is also possible to break up the operation + in FIXPIX using multiple passes. For example if a bad pixel region + is described by the rectangle "2000 3024 510 512" then two passes + using "2000 2500 510 512" and "2500 3024 510 512" may work. + +STATUS: Fixed in the next release. + +NUMBER: 404 +MODULE: dohydra +SYSTEM: V2.11 - V2.11.1 +DATE: Thu Jun 25 08:51:47 MST 1998 +FROM: valdes + +BUG: A segmentation error can occur when using a WIYN/HYDRA image for the + aperture identification information. The workaround is to use a text + aperture identification file rather than the image. One can use + the supplied ".iraf" file or create a file from the header. The + following command can easily generate an aperture identification + file from the contents of the image header. + + cl> hselect <image> SLFIB* yes | translit STDIN '"' '\n' > apid + + This will have blank lines between the entries but they are ignored + by DOHYDRA. + +STATUS: Fixed for the next release. + +NUMBER: 405 +MODULE: splot +SYSTEM: V2.10.3-V2.11.1 +DATE: Tue Jul 14 10:52:39 MST 1998 +FROM: valdes + +BUG: For multispec data where the number of pixels is different for each + spectrum, such as can occur with echelle orders, the last pixel + is corrupted when writing out with the 'i' key. The last pixel + value is replaced by the value of the first pixel outside the + defined range of the spectrum. This value is usually zero. + For echelle data the different length orders would occur when + dispersion correcting with fixed dispersion for all orders rather + than having each order take a dispersion that preserves the full + wavelength range and the same number of pixels. There is no + simple workaround. + +STATUS: Fixed for the next release. + +NUMBER: 406 +MODULE: dataio.import +SYSTEM: V2.11 +DATE: Tue Jul 14 12:02:31 MST 1998 +FROM: fitz + +BUG: When IMPORTing formats with native colormaps such as GIF and when + not specifying the 'outbands' parameter images will be converted + without applying the colormap and converting to grayscale. The + resulting image looks like garbage and is simply the color indices + of the image. The error is caused by a bad flag initialization, + the workaround is to explicitly set the outbands parameter so the + processing initializes the flag correctly. For example + + cl> import foo bar outbands="b1" + + 'b1' is the default image operator and it's use in the outbands + param will cause the colormap to be applied. + +STATUS: Fixed for V2.11.2 + +NUMBER: 407 +MODULE: ccdproc, fixpix, display +SYSTEM: V2.11 - V2.11.1 +DATE: Mon Jul 20 11:41:47 MST 1998 +FROM: valdes + +BUG: When fixing pixels by interpolation with a non-empty mask that has only + interpolation along lines there is the possibility of getting + a segmentation violation at the end of the processing. A parameter + used when freeing memory is not initialized in this case. + There is no workaround except adding a dummy region that + interpolates along columns or setting FIXPIX to interpolate + only along columns. + +STATUS: Fixed for next release. + +NUMBER: 408 +MODULE: ccdred.ccdmask +SYSTEM: V2.10-V2.11.1 +DATE: Fri Aug 14 10:11:44 MST 1998 +FROM: valdes + +BUG: Single bad pixels are not found. There is no workaround. The code + fix is simple. In file noao$imred/ccdred/src/t_ccdmask.x change + line 198 + + from: if (data[i,j] < low && data[i,j] > high) { + to: if (data[i,j] < low || data[i,j] > high) { + + Contact iraf@noao.edu for instructions on how to update an + IRAF package, in this case CCDRED. + +STATUS: Fixed for next release. + +NUMBER: 409 +MODULE: dispcor +SYSTEM: V2.10-V2.11.1 +DATE: Tue Aug 25 14:43:55 MST 1998 +FROM: valdes + +BUG: When users directly add (with HEDIT rather than using REFSPECTRA) + both REFSPEC1 and REFSPEC2 keywords without weights (where the + weights are assumed to be 1) or the specified weights do not + add up to 1, the resulting dispersion is wrong. The dispersion + values used are the weighted sum from the reference spectra but + the bug is that the weights are not normalized to unit sum. + Thus if both weights are 1 then the computed dispersion value + is twice what it should be. The workaround is to make sure + that the weights have a unit sum. When only a single reference + spectrum is used it is fine to simply specify the reference + spectrum image name since the default weight is 1. However, if + two reference spectra are specified then both weights must be + specified. The format for the REFSPEC keywords is image name + followed by weight with a space between; for example, + + REFSPEC1 = 'arc1 0.5' + REFSPEC2 = 'arc2 0.5' + + +STATUS: Fixed in the next release. + +NUMBER: 410 +MODULE: crutil.crmedian +SYSTEM: V1.1: May 1998 +DATE: Fri Sep 4 09:59:20 MST 1998 +FROM: valdes + +BUG: On images with more than about 500K pixels the median operation is + done in overlapping blocks of lines. The amount of overlap is + half of the line median size "lmed". The bug is that on output + the overlap regions end up being zero. There is no workaround + except to reinstall the new version of the package. + +STATUS: Fixed in V1.2: Sep 4, 1998. + +NUMBER: 411 +MODULE: imutil.imarith +SYSTEM: V2.11 +DATE: Wed Sep 16 08:44:02 MST 1998 +FROM: davis + +BUG: Imarith fails with a segmentation violation if the noact parameter + is set to "yes". The bug was occurring because the code was trying + to update the header of a non- existent output image. + +STATUS: Fixed for the next release of IRAF. There is no workaround. + +NUMBER: 412 +MODULE: imcombine +SYSTEM: V2.11 +DATE: Tue Oct 13 11:16:46 MST 1998 +FROM: valdes + +BUG: Updating of the image coordinate system when combining offset images + is not being done correctly. The effect is that the header of the + combined image corresponds to the first image. One workaround is + to look at the offsets printed by IMCOMBINE. Then redo the + combining putting the image which shows offsets of (0,0) (if there + is one) as the first in the list to combine. A more general + workaround is to look at the first image listed and get the offsets + (for example (220,50)) and use these to update the header. To + update the header using the offsets printed for the first image + + cl> hedit outimage crpix1 '(crpix1+220)' + cl> hedit outimage crpix2 '(crpix2+50)' + + where 220 and 50 would be replaced by the offsets from the IMCOMBINE + listing. This will fix the work coordinate system. If the + physical coordinate system also needs to be correct do the + same with the keywords LTV1 and LTV2 replacing CRPIX1 and CRPIX2. + Note that this extends to higher dimensions if combining images + with more than 2 dimensions. + +STATUS: Fixed for the next release. + +NUMBER: 413 +MODULE: fitprofs +SYSTEM: V2.10-V2.11 +DATE: Thu Nov 5 16:38:02 MST 1998 +FROM: valdes + +BUG: If the maximum difference of the spectrum to the initial background + over the fitting region is less than 1 and no peak value or a value + of INDEF is given in the "position" file then a floating overflow + type of error will occur. This is a bug in the code. The + workarounds are to explicitly give a peak value in the position + file or scale the spectrum (such as by multiplying spectrum by + some number) so that the peak to background is greater than 1. + +STATUS: Fixed for the next release. + +NUMBER: 414 +MODULE: dispcor +SYSTEM: V2.10-2.11.1 +DATE: Tue Nov 17 10:20:38 MST 1998 +FROM: valdes + +BUG: If the weights when interpolating between two dispersion reference + solutions are given to more than three digits in the REFSPEC + keywords they are internally truncated to three digits. Using + DISPCOR to produce non-linear dispersion coefficients in the image + headers will have the three digit weights which may not add up to 1 + to the level of 0.1%. This can cause small shifts in the evaluated + wavelengths. If DISPCOR is used to linearize the dispersion the + same effect will apply. This bug is related to bug 409. The + workaround solution is to make sure the weights in the REFSPEC + keywords add up to 1 within the first three digits. THIS BUG + CAN CAUSE SYSTEMATIC ERRORS IN RADIAL VELOCITY MEASUREMENTS + WHEN USING MULTIPLE WEIGHTED DISPERSION SOLUTIONS. + +STATUS: In future releases all occurences of the weight values in the + REFSPEC keywords and in the non-linear coefficients will use + eight significant digits. Furthermore, the dispersion function + evaluation for multiple weighted dispersion functions will + normalize the weights to avoid any systematic error regardless + of the weight values. + + +NUMBER: 415 +MODULE: reidentify +SYSTEM: V2.11 - V2.11.1 +DATE: Thu Dec 3 11:19:10 MST 1998 +FROM: valdes + +BUG: When interactive=yes and the task starts on the first image in + the "images" list (that is after doing the "reference" image) + in interactive mode (that is an aswer of "NO" has not been given + during the reidentification of the "reference" image), the dispersion + function parameters are reset to "spline3" of order 1 with no + rejection rather than inheriting the reference solution parameters. + The workarounds are to not use the "interactive" except of + the reference image or enter the interactive identify stage + for the first solution of each image and in the fitting reset the + function parameters to the desired values. + +STATUS: Fixed for the next release. + +NUMBER: 416 +MODULE: dataio.import +SYSTEM: V2.11.0-V2.11.1 +DATE: Thu Dec 10 14:24:37 MST 1998 +FROM: fitz + +BUG: One dimensional raw data is not converted properly, resulting in + an image with no pixel data. The fix requires a code change, sites + needing this should contact site support. As a workaround the + 'dims' parameter should be set to a 2-D string such as + + cl> import foo bar format=raw dims="1024,1" + + The resulting image will be a [1024,1] and can be reduced to 1-D + if needed using the IMSLICE task. + +STATUS: Fixed for V2.11.2 + +NUMBER: 417 +MODULE: astutil.ccdtime +SYSTEM: V2.10-V2.11.1 +DATE: Mon Jan 4 12:01:27 MST 1999 +FROM: valdes + +BUG: The extinction value is ignored and a value of 1 mag/airmass + is used. There is no work around other than to adjust the results + by hand. The version of CCDTIME used through the NOAO Web page + exposure time calculator (for NOAO instruments) is correct as of + Sept 1998. + +STATUS: Fixed for future releases. + +NUMBER: 418 +MODULE: immatch.wcscopy +SYSTEM: V2.11 +DATE: Thu Jan 7 13:57:57 MST 1999 +FROM: davis + +BUG: Wcscopy does not copy the reference image RADECSYS, EQUINOX, and + MJD-WCS keywords to the input image. The resulting numerical + coordinate system will be correct but the coordinate system + definition may be lost. + +STATUS: Fixed for the next release of IRAF. The workaround is to update + the RADECSYS, EQUINOX, and MJD-WCS keywords by hand or use the + ccmap or ccsetwcs tasks to do the updating. + +NUMBER: 419 +MODULE: images.immatch.xyxymatch,images.imcoords.ccxymatch +SYSTEM: V2.11 +DATE: Mon Feb 22 16:43:19 MST 1999 +FROM: davis + +BUG: When the number of reference files is greater than one and equal to + the number of input files, xyxymatch and ccxymatch are using the + last file in the reference file list as the reference file, instead + of matching the input and reference files one to one. + +STATUS: The problem was caused by a missing break statement in both cases. + The work-around is to run xyxyatch and ccxymatch once for every + reference and input file pair or use a script to do the file + management. Fixed for the next patch. + +NUMBER: 420 +MODULE: identify +SYSTEM: V2.10-2.11.1 +DATE: Mon Mar 8 13:27:24 MST 1999 +FROM: valdes + +BUG: If one uses the 'l' key to identify lines from a line list in a + spectrum that is wavelength calibrated and has physical coordinates + different from logical coordinates, wrong results or a system error + (such as a segmentation error) will occur. This is due to + conversion of the line list coordinate to a physical pixel + coordinate and attempting to use this to find a peak in the + spectrum where the routine expects a logical coordinate. This + situation is quite rare and does not occur in normal data + reductions. + + Logical and physical pixel coordinates become different if a + section of a spectrum is extracted; such as with IMCOPY or SCOPY. + The workaround is to reset the physical coordinates to be the same + as the logical coordinates with the command + + cl> wcsreset <image> wcs=physical + +STATUS: Fixed for the next release. + +NUMBER: 421 +MODULE: daophot.peak, daophot.nstar, daophot.allstar +SYSTEM: V2.11 +DATE: Mon Apr 12 13:43:18 MST 1999 +FROM: davis + +BUG: The daophot peak, nstar, and allstar tasks can crash with a floating + divide by 0 (Solaris) or floating exception (Linux) if the predicted + error computation goes to 0.0. This can happen if the predicted + model is 0.0 (most likely to occur at large radii from the object + being fit) , the readout noise is 0.0, and the profile error is + 0.0. + +STATUS: Fixed for the next release of IRAF. The workaround is to make sure + that the readout noise is set > 0.0. + +NUMBER: 422 +MODULE: daophot.psf +SYSTEM: V2.11 +DATE: Mon Apr 19 10:49:29 MST 1999 +FROM: davis + +BUG: In rare circumstances the psf task can crash with a floating point + error when computing the analytic portion of the psf. So far this + has only been observed on Linux systems but it could potentially be + a problem for other machines as well. + +STATUS: The problem is caused by division by a very small number in the + weight computation and happens when the point being added to the + fit is very close to fitrad pixels from the center of the analytic + function. There is no true workaround but changing the value of + fitfit slightly or choosing another analytic function may avoid the + problem. + +NUMBER: 423 +MODULE: astcalc, asthedit +SYSTEM: V2.11-V2.11.1 +DATE: Thu Apr 22 13:41:41 MST 1999 +FROM: valdes + +BUG: The "imdel" function name in ASTHEDIT and ASTCALC is not recognized + because of an error in the program. Instead this function is + recognized with the name "imde". + +STATUS: Fixed for the next release. + +NUMBER: 424 +MODULE: rv.fxcor +SYSTEM: V2.10-V2.11.1 +DATE: Thu Apr 22 14:07:13 MST 1999 +FROM: fitz + +BUG: The verbose output listing for a deblended fit reports only the + first velocity component. There is no workaround. The code + fix required is to edit line 298 of rv$rvvfit.x and change + + from: call pargd (rv_shift2vel(rv,DBL_SHIFT(rv,1))) + to: call pargd (rv_shift2vel(rv,DBL_SHIFT(rv,i))) + + Contact iraf@noao.edu for instructions on how to update an + IRAF package, in this case RV. + +STATUS: Fixed for next release. + +NUMBER: 425 +MODULE: focas +SYSTEM: external package +DATE: Fri May 21 10:28:59 MST 1999 +FROM: valdes + +BUG: The command FDISPLAY in the IRAF FOCAS external package fails to + find the command. There is an error in the focas.cl file which + defines how FOCAS tasks are called by IRAF. + + Within IRAF the FOCAS display command was changed to be "fdisplay" + to avoid conflict with the IRAF display command. Initially this + was done by translating the command FDISPLAY in IRAF to execute the + command DISPLAY in Unix (which was the name of the executable). + However, in Unix there was also a common conflict with another + command having the name DISPLAY. So the Makefile was modified to + create an executable fdisplay (from the display.c source). So now + IRAF needs to call fdisplay in Unix when fdisplay is typed. + + The file focas.cl needs to be changed from + + task $fdisplay = $display + + to + + task $fdisplay = $foreign + + Bye out of the package and reload it after making the change to + have it take effect. + + +STATUS: Will be fixed in a future release. + +NUMBER: 426 +MODULE: sarith +SYSTEM: V2.10-V2.11.1 +DATE: Fri May 28 16:31:04 MST 1999 +FROM: valdes + +BUG: The option to have a single second operand when operating on a + list of first operands does not work. For example to divide a set + of spectra by a constant value or a single image. The behavior + will be to print the message "Warning: Error in second operand". + The output will still be created but with a value of zero + everywhere. The workaround is to make the second operand match the + first. For example: + + cl> sarith a,b,c / 10,10,10 d,e,f + cl> sarith @list1 / @list2 @list3 + + In the second example list2 might have the same image or constant + repeated as many times as there are entries in list1. + +STATUS: Fixed for the next release. + +NUMBER: 427 +MODULE: imcoords.wcsctran +SYSTEM: V2.11 +DATE: Thu Jun 3 15:14:39 MST 1999 +FROM: davis + +BUG: The units are not always correctly initialized on successive runs + of the wcsctran task. For example if units are set to + "hours native" on the first run and then reset to "" on the + second run, the units used will be the initial units "hours native". + +STATUS: Fixed for the next release of IRAF. The work around is to do a flpr + between runs. + +NUMBER: 428 +MODULE: display +SYSTEM: V2.11-V2.11.1 +DATE: Tue Jun 15 10:00:10 MST 1999 +FROM: valdes + +BUG: For large images when the fill option is used, bad pixel overlays + do not work correctly. The image data or bad pixel masks will + appear scrunched up and the image data may appear streaked as the + last line is replicated from the scrunched edge to the edge of the + display. The behavior depends on whether the overlay mask is given + in the "overlay" parameter or in the "bpmask" parameter with + "bpdisplay=overlay". There is no workaround other than to avoid + the fill option until the next release. + +STATUS: Fixed for the next release. + +NUMBER: 429 +MODULE: immatch.geotran +SYSTEM: V2.11 +DATE: Fri Jun 18 14:20:06 MST 1999 +FROM: davis + +BUG: Geotran was not decoding the transforms list correctly in the + case that the number of images > 1 and the number of transforms + is 1. In that situation geotran is supposed to use the same + transform for all the input images. Instead it was complaining + about not being able to find the transform for the second image. + + This bug was introduced when geotran was modified to use the + image template expansion code to manage the transform list + (part of supporting the mosaic image name syntax) instead of the + file template expansion code. + +STATUS: Fixed for the next release of IRAF. The workaround is to create + a transform list with one entry for each image, even if the entries + are the same. + +NUMBER: 430 +MODULE: fitcoords +SYSTEM: V2.10-V2.11.1 +DATE: Wed Jul 21 16:52:49 MST 1999 +FROM: valdes + +BUG: When the fitting orders are higher than the data allow the task + should report "No degrees of freedom" and abort but instead the + error is not caught and the task proceeds causing various errors + including segmentation violations, crashing the cl, and + "task cursor not found". One way this can be triggered inadvertently + is if one forgets to trace the feature(s) with REIDENTIFY. + The solutions are to remember to trace the features and to use + orders that are lower than the number of points traced. + +STATUS: In the next release the task will report "No degrees of freedom" + and abort rather than mysteriously crashing. It will also + report "Only one line or column measured" and abort if the + feature(s) have not been traced to other lines or columns. + + +NUMBER: 431 +MODULE: dispcor +SYSTEM: V2.10-V2.11 +DATE: Mon Jul 26 13:35:54 MST 1999 +FROM: valdes + +BUG: If an error occurs when reading echelle dispersion functions from the + database a segmentation violation or related error will occur. The + error prompting this log is when the image uses two dispersion + functions (there are REFSPEC1 and REFSPEC2 keywords) and the + echelle dispersion functions do not have the same offset and + slope. The workaround for this particular error is to insure in + ECIDENTIFY that the dispersion functions have the same offset using + the 'o' key. + +STATUS: Fixed in V2.11.1 + +NUMBER: 432 +MODULE: dataio.export +SYSTEM: V2.11.0-V2.11.2 +DATE: Fri Aug 20 20:10:42 MST 1999 +FROM: fitz + +BUG: Use of the cmap() function for combining 3 images into an 8-bit + PseudoColor image results in a garbage line at the top or bottom + of the image (depending on format), this line is some random color. + The problem is that the last image line processed is not flushed + properly to the temp image used in the conversion. The solution + requires a code change to properly flush the image buffer. + +STATUS: Fixed for the next release. The IMCNV external package version of + the task is updated with the fix or sites can contact site support + for instructions on patching the system. Workarounds are to write + a 24-bit image instead and do the conversion using host tools, e.g. + write a 24-bit rasterfile and convert to GIF afterwards. + +NUMBER: 433 +MODULE: fitprofs +SYSTEM: V2.10-V2.11.2 +DATE: Thu Aug 26 12:00:09 MST 1999 +FROM: valdes + +BUG: The option to output an image of the fit or residuals only includes + the last profile component regardless of the "components" + parameter value. + +STATUS: Fixed for the next release. + +NUMBER: 434 +MODULE: tv.wcslab +SYSTEM: V2.11.2 and earlier +DATE: Sat Aug 28 11:03:21 MST 1999 +FROM: davis + +BUG: Wcslab was failing with the message "ERROR: MWCS: coordinate system + not defined (physical)" on the Dec Alpha when usewcs=yes, and with + a segmentation violation on Sun systems when the input image was + undefined. + +STATUS: Fixed for the next release of IRAF. There is no work-around. + +NUMBER: 435 +MODULE: photcal.fitparams +SYSTEM: V2.11.2 only +DATE: Mon Aug 30 08:22:45 MST 1999 +FROM: davis + +BUG: The fitparams task quits with a cannot write to string file error. + The problem was caused by a missing file dependency in the package + mkpkg file, which resulted in a routine not being rebuilt. + +STATUS: Fixed for next patch/release of IRAF. Contact the IRAF group for a fix. + +NUMBER: 436 +MODULE: astcalc, asthedit, rvcorrect +SYSTEM: V2.11.2 +DATE: Mon Aug 30 10:17:18 MST 1999 +FROM: valdes + +BUG: The year is incorrectly determined as yy+1900+1900 when DATE-OBS + is in the old FITS format (dd/mm/yy). In other words, an extra + 1900 is added to the two digit year. This is caused by a + misunderstanding of where the 1900 is added. This will make + further calculations which use the year grossly incorrect. The + workaround is to manually edit the image headers to convert them to + the new FITS format (yyyy-mm-dd). + +STATUS: Fixed for a future patch or release. + +NUMBER: 437 +MODULE: astcalc +SYSTEM: V2.10-V2.11.2 +DATE: Tue Aug 31 10:48:49 MST 1999 +FROM: valdes + +BUG: When ASTCALC is run on more than one image at a time the image + is incorrectly opened twice and only closed once. This has + one consequence, if the list of images is large (greater than + about 60) and they are in the Space Telescope Geiss format + (the files with ??h and ??d extensions) then the task will + run out of file descriptors with an error message such as + + ERROR: 757 noao/lib$obsdb.dat + ERROR: 787 pix61.c0h4451ef + + The workarounds are 1) use smaller lists of images per execution, + 2) change the image format to imh or fits, 3) run the task in + a script loop using one image at a time. + +STATUS: Fixed for the next release. + +NUMBER: 438 +MODULE: mscred.mscimatch +SYSTEM: V3.0-V3.2 +DATE: Fri Sep 3 11:07:46 MST 1999 +FROM: valdes + +BUG: The iterative rejection step (niterate > 0) produces a floating + operand error on some systems such as Linux. This was cased by + an incorrect argument declaration which so whether is affects + a system depends on the byte order used by the system. The + workarounds are to not use iterative rejection by setting + niterate to zero, update to the latest distribution of MSCRED, + or work on a machine where this error does not occur (such as + Suns). + +STATUS: Fixed in V3.2.1. + +NUMBER: 439 +MODULE: ccdred.cosmicrays +SYSTEM: V2.11.2 +DATE: Fri Sep 17 13:56:16 MST 1999 +FROM: valdes + +BUG: Changes in include files related to graphics where not applied + in the V2.11.2 update resulting in the graphics being garbled. + The workarounds are 1) to delete the ccdred object libraries + and rebuilt the executable (not recommended unless you really + know what you are doing), 2) installing new binaries obtained + from NOAO (contact iraf@noao.edu), or 3) installing the CRUTIL + external package which also contains a version of COSMICRAYS. + +STATUS: Fixed for the next release. + +NUMBER: 440 +MODULE: tv.wcslab +SYSTEM: V2.11 +DATE: Fri Sep 17 15:06:47 MST 1999 +FROM: davis + +BUG: Wcslab could produce garbled plots if the projection was set to + tnx, especially if the ra ~ 0 hours. + +STATUS: Fixed for the next patch / release of IRAF. A workaround is to + change the wtype parameter to tan using wcsedit, make the plot, + and then reset wtype to tnx. The wcslab overlay will lose a bit + of accuracy but for most display purposes this should not matter. + +NUMBER: 441 +MODULE: utilities.curfit +SYSTEM: V2.11.2 (only) +DATE: Tue Sep 21 14:01:15 MST 1999 +FROM: cheselka + +BUG: If run in non-interactive mode (in scripts, for example), a + segmentation fault occurs. + + A workaround is to run the task interactively, set the 'cursor' + parameter to a disk file containing the command 'q', send graphics + output to dev$null, and the text output to a disk file. + + From the command line: + + cl> curfit dev$pix inter+ cursor=quit_command >G dev$null >& fit.info + + Or from a script: + + utilities.curfit (input="dev$pix", inter+, cursor="quit_command", \ + >G "dev$null", >& "fit.info") + + The resulting file (fit.info) will have a single line of junk at + the top of the file, but will otherwise contain the fit data. + +STATUS: Fixed for the next release. + +NUMBER: 442 +MODULE: doslit, dofibers, dohydra, doargus +SYSTEM: V2.11.1-V2.11.2 +DATE: Fri Sep 24 17:01:26 MST 1999 +FROM: valdes + +BUG: When the new feature was added to allow an attempt to automatically + determine the dispersion function, values of the parameters "crval" + and "cdelt" both set to INDEF (the default parameter values) was + supposed to skip the automatic identification. An oddity of the CL + prevented these tasks from seeing this case and so they always try + to do an automatic solution. With a large spectrum and a large + line list and no guidelines as to the correct dispersion this can + cause the tasks to take a very long time at the step where the + dispersion is determined. The workarounds are to set these values + to something close to what is expected or to use a short line + list. + +STATUS: Fixed for the next release. + +NUMBER: 443 +MODULE: digiphot.daophot, digiphot.photcal +SYSTEM: V2.11 +DATE: Tue Sep 28 08:43:02 MST 1999 +FROM: davis + +BUG: If the tables pacakge is undefined the daophot and pphotcal package + scripts will hang which may require terminating the IRAF session. The + problem is a missing ; in the daophot and photcal scripts which trips + a cl bug. + +STATUS: Fixed for the next patch release of IRAF. The fix is to add the ; + to the daophot script as follows. Change the 4 lines + + } else { + type "daophot$lib/warning.dat" + } + } + + to 5 lines as follows + + } else { + type "daophot$lib/warning.dat" + } + } + ; + + The same fix will work for the photcal script. The workaround + is to install the tables package. + + + +NUMBER: 444 +MODULE: imedit +SYSTEM: V2.10-V2.11.2 +DATE: Fri Oct 1 09:03:48 MST 1999 +FROM: valdes + +BUG: The output image type will be that set by the "imtype" + variable regardless of the image type of the input image or any + explicit image type in the input and output image names. + When the temporary editing buffer is created it is always created + with the "imtype" value and when the output image is created + from the edited temporary image it retains the image type of + the temporary image. The two workarounds are either to set + "imtype" to the type desired for the output or copy the output + image to the desired type after it is created. + +STATUS: In the next release if an explicit image type extension is specified + for the output image name then that image type will be created for + the temporary editing image and the final output image. If no + explicit type is given then the output will be that specified + by the "imtype" variable. In no case is the image type of the + input image automatically used. + +NUMBER: 445 +MODULE: ared.quad.quadproc +SYSTEM: V2.11.2 +DATE: Fri Oct 8 16:25:14 MST 1999 +FROM: valdes + +BUG: ARED external package versions prior to "Rev 1.32 - Oct 8, 1999" + installed with IRAF V2.11.2 cause the QUADPROC task to produce + the error: + + ERROR: parameter `output' not found + quadproc (images=tryme.fits) + + QUADPROC is a script that calls CCDPROC and the parameter "output" + is a new parameter in that task. Installation of ARED includes + copying the CCDPROC executable but not the parameter file. + The workaround is either to get the latest version of ARED or + edit the file quad$ccdproc.par (quad is defined after loading + the quad package) to add the line: + + output,s,h,"",,,List of output CCD images + + after the first line. + +STATUS: ARED package updated to include the revised ccdproc.par file. + +NUMBER: 446 +MODULE: rv.rvidlines, rv.rvreidlines +SYSTEM: V2.11.2 (only) +DATE: Tue Oct 12 11:34:07 MST 1999 +FROM: valdes + +BUG: For 1D spectra the error + + PANIC in `/iraf/iraf/noao/bin.ssun/x_rv.e': Salloc underflow + + may occur due to an incorrect change in memory management. This + error may cause the CL to abort. A workaround is to turn the 1D + image into a 2D image of 1 line with the command: + + cl> imstack spec spec2d + + where spec is the 1D spectrum and spec2D is the spectrum to use + with RVIDLINES/RVREIDLINES. + +STATUS: Fixed for the next release. + +NUMBER: 447 +MODULE: crutil.crnebula +SYSTEM: CRUTIL V1.2 and earlier +DATE: Tue Oct 19 15:04:41 MST 1999 +FROM: valdes + +BUG: The rin and rout parameters are ignored and the default values are + hardwired in the task. The only workaround is to edit the script + crutil$src/crnebula.cl and in the rmedian statement replace the + "1.5" with rin and the "6." with rout. + +STATUS: Fixed in V1.3: Oct 19, 1999 release. + +NUMBER: 448 +MODULE: mscred.msccmatch +SYSTEM: -V3.2 +DATE: Mon Oct 25 15:00:04 MST 1999 +FROM: valdes + +BUG: If the specified image name is more than 19 characters then the + task will fail to center on the objects. When verbose is yes you + will see the same numbers printed for each object; i.e. one line is + repeated many times. The workarounds are to shorten the names by + renaming, logical links, or possibly eliminating the ".fits" + in the specified name. In the latter case a name such as + "abcdefghijklmnopqrs" will be ok but "abcdefghijklmnopqrs.fits" or + "abcdefg*" will not work. + +STATUS: Fixed in a future version. + +NUMBER: 449 +MODULE: ared.quad.quadproc +SYSTEM: V2.0 +DATE: Fri Oct 29 12:52:13 MST 1999 +FROM: valdes + +BUG: This task assumes the image data is in "imh" format. If it is + not in this format then overscan and trim will not occur and + further in the processing the following message will appear. + + ERROR on line 173: Bias section not specified or given as full image. + + The workaround is to change the image format to "imh". Also change + the "imtype" variable with "reset imtype=imh; flpr". Getting the + latest version of the ARED package source (ared.tar) will also fix + this problem. In this version the "imtype" variable must be set to + match extension of the image type being used; e.g. "fits" for + *.fits data. The binaries do not need to be updated since the fix + applies only to a script task. + +STATUS: Fixed in the current distribution from iraf.noao.edu. + +NUMBER: 450 +MODULE: imfilter.fmedian,imfilter.frmedian,imfilter.fmode,imfilter.frmode +SYSTEM: V2.11 +DATE: Fri Nov 19 14:20:16 MST 1999 +FROM: davis + +BUG: The fast median / mode filtering tasks will overflow producing + pathological pixel values if the size of the filtering kernel + xfilter * yfilter > 32767 and the number of pixels in 1 histogram + bin happens to be > 32767 as may happen in bad pixel regions. + + The problem was due to the fact that for historical reason the + algorithm histogram was stored as a short instead of an int. + +STATUS: Fixed for 2.11.3. The workaround is to try and keep the filter size + < 32767 pixels in size, or to use the much slower median task. + +NUMBER: 451 +MODULE: imcombine,ccdred.combine,mscred.combine,sflatcombine,flatcombine,zerocombine +SYSTEM: V2.11.2-V2.11.3 +DATE: Tue Dec 7 10:33:32 MST 1999 +FROM: valdes + +BUG: The 2D grow option introduced in V2.11.2 and in MSCREDV3.2 + does not work with "minmax" rejection. There is no workaround. + +STATUS: Fixed in later releases. + +NUMBER: 452 +MODULE: mscred.msczero +SYSTEM: MSCRED V3.2.3 (releases between Nov 17 and Dec 2) +DATE: Fri Dec 10 12:14:10 MST 1999 +FROM: valdes + +BUG: A change made to allow MSCZERO to work on single images, such as + after resampling and stacking, introduced the error + + Warning: MWCS: dimension mismatch (mw_open) + + when attempting to apply a zero point correction update. While + the message says warning actually the coordinate system is + not updated at all. There is no workaround and requires + the package to be updated. + +STATUS: Fixed in the Dec. 10, 1999 release. + +NUMBER: 453 +MODULE: scopy +SYSTEM: V2.11-V2.11.3 +DATE: Tue Dec 14 11:48:12 MST 1999 +FROM: valdes + +BUG: When copying out a region of a spectrum which is log-linear sampled + (DC-FLAG=1) the coordinate system of the copied region is wrong. + This applies whether or not the "rebin" parameter is set. The + workaround is to use DISPCOR; set "w1" and "w2" to the desired + limits and set "log=yes". This will do the same thing as + SCOPY with "rebin=yes". To extract a region without rebinning + the simplest thing is to use an image section. The pixel limits + corresponding to the desired wavelength range will have to be + determined in some way such as with SPLOT, LISTPIX, or calculated + from the CRVAL/CDELT keywords (these are in log units for log-linear + sampled spectra. + +STATUS: Fixed for the next release. + +NUMBER: 454 +MODULE: proto.fixpix, ccdproc +SYSTEM: V2.11-V2.11.3 +DATE: Wed Dec 15 14:30:44 MST 1999 +FROM: valdes + +BUG: Tasks which allow a text file description of bad pixels in addition + to a bad pixel mask, which include fixpix and ccdproc, will fail + with a 757 error when a large number of files are processed. This + might occur with a large @file or in many repeated calls without + an intervening flushing of the process cache such as with flpr. + This problem is caused by a system error that fails to free a file + descriptor. After a sufficient number of executions the number of + available free file descriptors is depleted and the 757 error (too + many open files ) is reported. The workarounds are to either use + bad pixel masks or to limit the number of images in each execution + and to use flpr after a 50 or so images are processed. + +STATUS: A system fix is under investigation for the next release. + +NUMBER: 455 +MODULE: mscrfits +SYSTEM: MSCRED up to V3.2.3: December 10, 1999 +DATE: Thu Dec 16 11:46:48 MST 1999 +FROM: valdes + +BUG: If the original file names include a '.' other than that for + the ".fits" extension it is correctly stored by MSCWFITS. However, + reading the tape with MSCRFITS either to list the contents + or to restore the original file names will cause the part of + the file name following the last '.' to be stripped. Therefore + the FITS tape files are correct but restoring or listing them + by their disk file names when the tape was written will fail. + + For example, suppose the file name is "n1.abc.def.fits". Then when + it is written to tape the FILENAME keyword will contain + "n1.abc.def". Reading this tape file to list or restore the + original name will consider the original file name to be "n1.abc". + This bug is caused by stripping the extension (anything after the + last '.' including the period) both when the file is written (a + correct and useful behavior) and then when reading the stored + FILENAME keyword (the incorrect behavior). + + The workarounds are 1) don't use '.' in the original file names, 2) + read the files to disk without restoring the original file names + and then use the FILENAME keyword in the primary header to identify + the original file name and restore the name. There is no workaround + for getting a listing of the tape contents with the correct full + original name other than using the fixed version. + +STATUS: Fixed for the next release. + +NUMBER: 456 +MODULE: rv.fxcor +SYSTEM: V2.11.3 +DATE: Thu Dec 23 13:43:57 MST 1999 +FROM: fitz + +BUG: Images with a DATE-OBS keyword value of the form CCYY-MM-DD with + no associated time information will cause and floating point + exception when computing the heliocentric corrections. + +STATUS: The bug is caused by an incorrect Y2K fix which didn't properly + check for this form of the DATE-OBS keyword in which the time + returned as INDEF. Workarounds include editing the keyword to + include the UT time information with a command such as + + hedit *.imh date-obs '(@"date-obs"//"T"//str(@"ut"))' + + A trivial code change and recompilation instructions are available + by contacting site support. + + Fixed for the next release. + +NUMBER: 457 +MODULE: crutil.crmedian +SYSTEM: -V1.3: Oct 19, 1999 +DATE: Thu Jan 6 09:28:33 MST 2000 +FROM: valdes + +BUG: If the number of columns in the image is not an exact multiple + of the sigma block size uninitialized values is used for the + sigma values at the end of the lines. This can cause floating + point exceptions. The only workaround is to use an image section + to trim the number of columns in the image to a multiple of + the sigma block size and adjust the sigma block size to minimimze + the amount of trimming required. + +STATUS: The is fixed in a new version of the CRUTIL package now available. + +NUMBER: 458 +MODULE: imcombine, combine +SYSTEM: V2.11.3 +DATE: Wed Jan 12 13:32:54 MST 2000 +FROM: valdes + +BUG: When combining input images that have been dimensionally reduced + (those have a WCSDIM keyword greater than the logical dimension + of the image and having a WAXMAP01 keyword) and using offsets + the error + + Warning: MWCS: dimension mismatch (mw_gltermd) + + will appear. Even though it says it is a warning it is really a + fatal error and the task will quit. Dimensional reduction occurs + with copying out a lower dimensional section of an image; i.e. + copying a 2D plane from a 3D image. The workaround is to reset the + headers of the input image to remove the dimensional reduction. + This is done by deleting the keywords WCSDIM and WAXMAP01. + +STATUS: Fixed for the next release. + +NUMBER: 459 +MODULE: apall/apsum +SYSTEM: V2.11.2-V2.11.3 (sparc, ssun, redhat, linux, sol7) +DATE: Thu Jan 20 11:16:14 MST 2000 +FROM: valdes + +BUG: The extraction tasks in APEXTRACT for the distributions of + Sun/SunOS, Sun/Solaris, PC-IRAF/Slackware, PC-IRAF/Redhat, and + PC-IRAF/Solaris7 accidentally used an older version (V2.10) of the + extraction code. For most purposes this simply means a couple + of minor bugs fixed in V2.11 will be back. The only significant + change is that the feature to allow selection of the apertures + to be extracted with the "aperture" parameter will be broken. + + There is no workaround other than to install new executables. + These are available at ftp://iraf.noao.edu/misc/apextract2113/ + (and in the misc directory in the IRAF ftp mirror sites). + The README file in the directory gives installation instructions. + +STATUS: Fixed in future releases. + +NUMBER: 460 +MODULE: dispcor +SYSTEM: V2.11.3 +DATE: Thu Jan 27 13:07:38 MST 2000 +FROM: valdes + +BUG: In V2.11.3 DISPCOR was enhanced to work on 2D (long slit) data. + In the processes the "global" option was broken resulting + in a segmentation violation if selected. There is no workaround + other than not to use the global option and, instead, manually + set the target dispersion sampling to be the same for all + spectra. + +STATUS: Fixed for the next release. + +NUMBER: 461 +MODULE: apall/apsum +SYSTEM: V2.11.2-V2.11.3 (sparc, ssun, redhat, linux, sol7) +DATE: Thu Jan 27 13:32:50 MST 2000 +FROM: valdes + +BUG: This is an addendum to buglog #459. Another aspect of the incorrect + source being used is that with "format=onedspec" the output names + will be of the form root.0001.0001 instead of root.0001 where the + root name and the number will differ. The workarounds are to + either rename the images after extraction or extract to multispec + format and use SCOPY to separate the apertures into separate 1D + images. As noted in the previous buglog a fixed executable may + be obtained and installed if desired. + See ftp://iraf.noao.edu/misc/apextract2113/README. + +STATUS: Fixed in future releases. + +NUMBER: 462 +MODULE: dispcor +SYSTEM: V2.11.3 +DATE: Tue Feb 1 16:16:57 MST 2000 +FROM: valdes + +BUG: DISPCOR does not work correctly when linearizing spectra if there + is more than one aperture in the file (that is multispec format + data) and the aperture numbers are different than the line + numbers. This was found in the reduction of multifiber data where + the aperture numbers are set to the fiber numbers. What happens is + that the dispersion solution from the wrong spectrum is applied + during the linearizing. There is no indication that the dispersion + correction is incorrect. The workarounds are to make sure that + the aperture numbers correspond to the line numbers, to + separate the spectra into individual 1D format, or to use + "linearize=no". + +STATUS: This is a serious bug, particularly since there is no obvious + indication of producing the wrong result. A patch to V2.11.3 + is required to fix this problem. + + +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 + <measure the line> + + 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. + +NUMBER: 464 +MODULE: proto.imextensions +SYSTEM: V2.11-V2.11.3a +DATE: Thu Feb 24 12:34:36 MST 2000 +FROM: valdes + +BUG: When using IMEXTENSIONS to expand a file with many extensions and + including a image section or image kernel specification it is + possible to overrun a string resulting in either a system error or + an incomplete output list. Each '[', ',', '*' character + contributes to the possiblity of overrunning the string. The + maximum number of extensions that can be expanded without problem + depends on the specific "input" list. The workarounds are to avoid + using image sections and image kernal specifications for large + lists or to expand the list in pieces using the "index" parameter. + +STATUS: To be fixed in a future release. + +NUMBER: 465 +MODULE: identify/reidentify +SYSTEM: V2.11-V2.11.3p1 +DATE: Thu May 4 08:59:41 MST 2000 +FROM: valdes + +BUG: When using velocity units the database is written without the + velocity reference point. For example, units of "km/s 1 micron" + will be written as "km/s". Attempting to use the database will + then not work since the velocity unit is not fully specified. + The workarounds are either to use other units or edit the + database file to restore the missing reference information. + +STATUS: Fixed for the next release. + +NUMBER: 466 +MODULE: ared.quadproc +SYSTEM: V2.1 +DATE: Tue Jun 20 13:47:03 MST 2000 +FROM: valdes + +BUG: When the imtype environment variable contains a comma, e.g. + when imtype="fits,inherit", the following error occurs: + + ERROR on line 108: Attempt to access undefined local variable `len' + + The workaround is to change imtype to only include the extension + being used; i.e. imtype=fits. + +STATUS: Fixed in version "2.2: 20 June 2000". + +NUMBER: 467 +MODULE: dataio.export +SYSTEM: V2.11 - V2.11.3a +DATE: Fri Jun 23 09:51:22 MST 2000 +FROM: fitz + +BUG: The header text for the PGM and PPM formats is incomplete (i.e. + missing the Y-dimension and max pixel value) for byte-swapped + systems such as PCIX and Dec Alpha. There is no workaround for + this, contact site support for a code change or patched binary. + +STATUS: Fixed for future releases. + +NUMBER: 468 +MODULE: astcalc, asthedit +SYSTEM: -V2.11.3a +DATE: Thu Jun 29 11:14:56 MST 2000 +FROM: valdes + +BUG: The "clput" function does not work and results in the error: + + ERROR: function `clput' requires 1 arguments + + This is caused by a typo in the source such that the function + is not correctly interpreted. There is no workaround other + than fixing the source. + +STATUS: Fixed for the next release. + +NUMBER: 469 +MODULE: specplot +SYSTEM: -V2.11.3p1 +DATE: Mon Aug 14 11:01:13 MST 2000 +FROM: valdes + +BUG: You cannot specify units using the "units" parameter that consist + of more than one word. For example "log angstroms", "inv + centimeter", or "km/s 4000 ang" will not work. There is no error + message and instead the default display units (the "units_display" + attribute in the WAT keywords) are used. The units can be set + interactively with the ":units" colon command. If you want to get + such units running SPECPLOT non-interactively the only workaround + is to set the "units_display" attribute. This can be done either + with careful header editing (HEDIT or HFIX) or by displaying with + SPLOT, setting the units, and then writing out the spectrum. + +STATUS: Fixed in future releases. + +NUMBER: 470 +MODULE: display / cursor readback +SYSTEM: V2.11-V2.11.3 +DATE: Tue Sep 5 14:15:18 MST 2000 +FROM: valdes + +BUG: When an odd sized image is displayed into a frame buffer that is + smaller than the image without filling, thus letting the display + task trim the image to fit, the y cursor readback from the display + server will be off by one. The same behavior will also occur in x + if the image is loaded with a flipped image section such as + image[-*,*]. The error can be avoided in several ways. One is to + use a frame buffer size which is larger than the image, another is + to use an image section that 1) is smaller than the frame buffer, + 2) is an even number of pixels in y, or 3) flips the + image in y. + +STATUS: The is fixed in V2.11.4. + +NUMBER: 471 +MODULE: mscred.mscsetwcs +SYSTEM: -V4.1: September 15, 2000 +DATE: Mon Sep 18 09:32:46 MST 2000 +FROM: valdes + +BUG: This task will fail with the message + + ERROR on line 81: No write permission on file (String_File) + + when a long list of images is used. The workaround is to + break the operation up into smaller sets of images. + +STATUS: Fixed in the next release. + +NUMBER: 472 +MODULE: mscred.ccdproc +SYSTEM: V4.0 - V4.1: September 20, 2000 +DATE: Mon Oct 2 10:27:34 MST 2000 +FROM: valdes + +BUG: When a dependent calibration exposure, one that is not being processed + directly but needs to be processed to continue with the specified + target exposure, is processed a query + + List of output bad pixel masks: + + is given. The workaround is to respond with carriage return or + the equivalent of a null string "". There will be two queries + per calibration image. + +STATUS: Fixed in the V4.1: October 2, 2000 release. + +NUMBER: 473 +MODULE: rv.fxcor +SYSTEM: V2.11 - V2.11.3b PC-IRAF +DATE: Wed Oct 18 12:39:59 MST 2000 +FROM: fitz + +BUG: The main correlation plot would sometimes not be drawn when + using long spectra on a Linux system. With spectra of ~10000 + points or more the main plot of the task would not display + the ccf but would show the fit points and fit function. This + was traced to a bug improperly moving data to the plotting arrays. + There is no reliable workaround, contact site support for a code + change or patched binary. + +STATUS: Fixed for the next release. + +NUMBER: 474 +MODULE: mscred.ccdproc +SYSTEM: -V4.1: December 5, 2000 +DATE: Thu Dec 7 14:22:10 MST 2000 +FROM: valdes + +BUG: When a flat field is processed in a certain way as noted below, + applying it to object data with CCDPROC will cause each flat field + extension to be normalized differently. This will be evident in + the log file where the scale factor for the flat field extensions + will be listed with different values rather than the same value. + The flat fielded object image will then appear with different gain + levels of the same relative magnitude as the flat field in each + extension. Note that small residual gain differences are normal + due to dome flats not exactly matching the sky and these are + removed by using sky flats. + + The incorrect behavior occurs when the flat field is processed + after combining to a master flat field followed by making a + new version of the flat field, such as when making a pupil ghost + corrected flat field. The error occurs because a time stamp for + the CCDMEAN scaling keyword, the keyword CCDMEANT, is added by + CCDPROC and checked against the time the image was last modified. + After the first processing all the CCDMEAN keywords will correctly have + the same value. However, any modified version of the flat field + will then invalidate the time stamp causing the next execution of + CCDPROC that applies the flat field to compute new CCDMEAN values + separately for each extension. If the CCDMEANT keyword is absent + then CCDPROC will not recompute the normalization value. Thus the + workaround is to delete the CCDMEANT keyword from all extensions + either before making a new version of the flat field or in the flat + field version to be applied by CCDPROC. + + In the most common case where individual flat fields are processed + with scaling followed by combining to a master flat using the task + FLATCOMBINE the bug does not occur because the scaling and + combining operation eliminates the CCDMEANT keyword. Also when the + flat field is not modified after it has been processed by CCDPROC + the error will not occur. So almost all users will not have + encountered this problem. + +STATUS: The MSCRED release of December 7, 2000 fixes this problem by + having CCDPROC eliminate the CCDMEANT keyword when the flat + field is first processed. + +NUMBER: 475 +MODULE: mscred.ccdproc +SYSTEM: V4.1 for Solaris (September 20 through December 7 releases) +DATE: Tue Dec 12 14:28:14 MST 2000 +FROM: valdes + +BUG: Using BPM for the "fixfile" parameter when doing bad pixel mask + corrections does not work with the prebuilt binaries. Symptoms + are that the bad pixels are not removed and the logfile, verbose + output, and header processing keyword will indicate an EMPTY + mask was used. The workaround is to use !BPM for the value of + the keyword or link the package yourself. + + This problem occured because the binaries were built using + development libraries rather than the latest IRAF release + libraries. An error was introduced in the development system + that causes the reported bug. + +STATUS: Fixed in releases after December 11. + +NUMBER: 476 +MODULE: mscred: ccdproc zerocombine flatcombine darkcombine +SYSTEM: - V4.1: December 7, 2000 +DATE: Wed Dec 13 09:57:43 MST 2000 +FROM: valdes + +BUG: When using bad pixel masks with fixpix=yes in CCDPROC (or when + CCDPROC is called in the scripts ZEROCOMBINE, DARKCOMBINE, and + FLATCOMBINE that do both processing and combining) the memory + used internally for the masks is not released. When doing many + images this leads to a growing memory usage possibly resulting in + an out-of-memory error. People with machines having large amounts + of memory may not notice this problem. The workaround if this + problem is encountered is to break up the processing into small + groups of mosaic exposures and use "flpr" between executions of + CCDPROC. Releases after December 7, 2000 fix this problem so + updating MSCRED is the other solution. + +STATUS: There is a two stage resolution of this bug. Until a new version + of IRAF is released, the current release of MSCRED.CCDPROC includes a + flpr between the processing of each mosaic exposure. Under a + new version of IRAF the problem is also fixed at the system level. + +NUMBER: 477 +MODULE: rvcorrect +SYSTEM: -V2.11.3p1 +DATE: Wed Jan 31 12:15:37 MST 2001 +FROM: valdes + +BUG: If an image is specified in the "files" parameter instead of + the "images" parameter it can cause an exception, erroneous + output, or no output at all. + +STATUS: In future releases the task will detect images in the "files" + list and print a warning. + +NUMBER: 478 +MODULE: proto.fixpix +SYSTEM: V2.11-V2.11.3p2 +DATE: Thu Feb 8 11:39:09 MST 2001 +FROM: valdes + +BUG: FIXPIX may report an out-of-memory error. This is caused by an + inefficient use of memory (using more memory without reclaiming + previously used memory). This behavior only occurs when interpolation + along columns is performed. One workaround is to use multiple passes + with fewer regions to be fixed per pass. Another option is to + use only line interpolation if that is reasonable. + +STATUS: Fixed for the next release. + +NUMBER: 479 +MODULE: mscred.ccdproc +SYSTEM: V4.2: January 30, 2001 (only) +DATE: Thu Feb 8 14:23:08 MST 2001 +FROM: valdes + +BUG: In V4.2 the default for CCDPROC was changed to "merge=yes" with the + idea being that if data did not require merging then it would not + affect the data. However, the change was such that if an input + list includes some previously processed and some unprocessed + files then when a new image is processed the last skipped processed + image in the list will be deleted. If you have the backup option + turned on the orignal data for the deleted processsed image will + still be available otherwise the data will need to be retrieved + from tape. The workarounds are not to mix processed and + unprocessed data in the input list or turn off the merge option. + +STATUS: Fixed in the V4.3: February 8, 2001 version. + +NUMBER: 480 +MODULE: pdm +SYSTEM: -V2.113b +DATE: Thu Feb 22 16:36:42 MST 2001 +FROM: valdes + +BUG: If the input data does not begin with the minimum x value (when + there are two or three columns) then a memory corruption error may + occur. Even if it does not occur, the theta statistic will come + out wrong and so all results will be invalid. The workaround is to + make sure the first data point of the input file(s) is the minimum + value. One could also sort the files, though if multiple files are + being merged they should be merged externally into one sorted file + or else insure the first input file has the proper minimum. + +STATUS: A fix was made to fix the immediate problem. It is not clear + whether there are other possible problems due to lack of a + sorted input. + +NUMBER: 481 +MODULE: mscred.combine (flatcombine, etc.) +SYSTEM: V4.3: February 8, 2001 - V4.4: March 6, 2001 +DATE: Tue Mar 20 10:20:33 MST 2001 +FROM: valdes + +BUG: When using scaling or zero offsets the normalization of the factors + may be incorrect. This bug is compiler dependent and affects + PC-IRAF (Suse and Redhat were explicitly checked) but not Solaris + or Alpha. What is intended is that the scale and zero factors be + normalized to the first image. The incorrect behavior is that only + the first image is normalized. What you see in the terminal and + logfile report on the scale factors is the first image has a + scaling of 1 and offset of 0 and the other images have values which + are not correct and usually appear grossly wrong. There is no + workaround when scaling is needed. A new version of MSCRED is + required. + +STATUS: Fixed in V4.4: March 20, 2001. + +NUMBER: 482 +MODULE: splot +SYSTEM: -V2.11.3p2 +DATE: Wed May 16 10:25:49 MST 2001 +FROM: valdes + +BUG: When using the 'e' key to measure equivalent widths along with the + error computation, if any pixel in the spectrum is negative or zero + the errors will be printed as zero. The workaround is to replace + all the negative or zero values with a small positive value. + +STATUS: This is fixed for the next release by setting the value to zero + for computing the uncertainty in the pixel. + +NUMBER: 483 +MODULE: immatch.psfmatch +SYSTEM: V2.11 +DATE: Wed May 16 14:46:37 MST 2001 +FROM: davis + +BUG: There is a symmetry problem in the convolution step if the psf + matching kernel does not have 180 degree rotational symmetry, due + to the fact that convolution kernel is not being flipped properly + before doing the convolution. The workaround is to create the + psf matching kernel, rotate it 180 degrees, and then apply it + with psfmatch or use the psfmatching kernel directly with + fconvolve. + + A floating point error may occur in the replace algorithm in + rare cases due to the input to the log function not being checked + for 0.0 values. The only workaround is to try the filter options + "none" or "model". + + +STATUS: Fixed for the next release of iraf. A fixed version of psfmatch + is available in the external addon package immatchx. + +NUMBER: 484 +MODULE: mscimage, geotran, rotate, imlintran, [g/s/w]register, imtranspose, + im3dtran +SYSTEM: V2.11 +DATE: Fri Jun 1 11:39:39 MST 2001 +FROM: valdes + +BUG: When writing an output FITS image extension, for example, + + cl> imtranspose abc out.fits[ext2,append] + + the following type of error may occur + + Attempt to write out of bounds on file (<image>.fits_NNNN) + + where NNNN is some four digit number. This occurs when the input + data is operated upon in subblocks where the line dimension is + smaller than the output dimension. Therefore, the workaround is to + set the line buffer block size (e.g. nxblock or len_blk) to + be the size of the largest image dimension. Alternatively one + can create a single image intermediate file and then append that + to the output with IMCOPY. + + THIS ONLY APPLIES TO CREATING AN OUTPUT EXTENSION AND DOES NOT + APPLY TO SIMPLE SINGLE FITS OUTPUT IMAGES. The most common case + where output extensions are used is when running the mosaic task + MSCIMAGE which calls GEOTRAN internally. The workaround for that + task is to set "nxblock" to a value larger than the largest input + extension dimension. + +STATUS: This problem is under investigation. + +NUMBER: 485 +MODULE: longslit.fitcoords +SYSTEM: -V2.11.3b +DATE: Mon Jun 4 11:43:22 MST 2001 +FROM: valdes + +BUG: The user coordinates from IDENTIFY are double precision and + are written to the database with 9 digits of precision. FITCOORDS + reads and uses this data in real precision. The deletion point + file with the user coordinates of the delete points is written in + real precision. The comparison between the coordinates written to + the deletion list and later read again and the data read from the + IDENTIFY database is done as a direct comparison of two real + values. Because of how the conversion and rounding between text + and floating point representations are done this can result in + deleted points which are in the deletion file to not be restored as + deleted in subsequent runs of FITCOORDS. There is no easy + workaround. The only possiblity is to match the values in the + deletion file with the IDENTIFY database file and make the ascii + representation be the same. Working in units which require fewer + significant digits to represent the coordinates may improve the + behavior. For example when working in the IR use microns instead + of Angstroms in IDENTIFY/REIDENTIFY. + +STATUS: The direct equality will be replaced by a tolerance comparison in + a future release. + +NUMBER: 486 +MODULE: images.imgeom.magnify +SYSTEM: V2.11.2 and later +DATE: Thu Jun 21 15:14:56 MST 2001 +FROM: davis + +BUG: In some circumstances the previous block of output image lines may be + repeated in the output image rather than a new block computed. This + bug affects IRAF 2.11.2 and later systems, and is the result of a typo + made when the task was upgraded to use the new interpolants, image + i/o boundary extension etc. + + The problem is most likely to occur when the output image scale + is > than the output buffer size of 16 lines. + + +STATUS: Fixed for the next release. Work around include doing the magnify in + more than one step or using the imlintran task. + +NUMBER: 487 +MODULE: ccdproc +SYSTEM: V2.11 +DATE: Thu Jul 5 08:35:00 MST 2001 +FROM: valdes + +BUG: When applying a dark count correction, the dark count calibration + image is scaled to the data being calibrated using the ratio of + the dark times. The dark time for an image is the "darktime" + keyword and if this is absent "exptime", where these may be + translated to other keywords if a translation is given in the + instrument file. When a value for the dark time is found it + is used without checking for zero values. Therefore, if the + dark count image has a dark time value of zero a + floating divide or floating exception will occur. The + workaround is to edit the header to add the appropriate + values. + +STATUS: In the next release an appropriate error message will be given. + +NUMBER: 488 +MODULE: imcoords.ccmap +SYSTEM: V2.11 +DATE: Fri Jul 20 08:28:08 MST 2001 +FROM: davis + +BUG: If the input coordinate list spans 0.0 hours right ascension, and + the refpoint parameter is set to "coords", ccmap may produce a + bad estimate for the reference point and a bad solution. + +STATUS: Fixed for the next release of IRAF and in the external addon package + immatchx. The work around is to set the ccmap refpoint parameter to + "user", and either enter the reference coordinates manually, or read + them them from the associated input image header. + + +NUMBER: 489 +MODULE: identify +SYSTEM: V2.9-V2.11.3b +DATE: Thu Aug 2 09:45:58 MST 2001 +FROM: valdes + +BUG: When identified features have labels and when some features are + deleted during fitting the labels no longer correctly correspond + with the features. This only applies to deleting during fitting + and there is no error when deleting features in the identify + window. What happens is that when a feature is deleted during + fitting the internal list is compressed by shifting the higher + features down. But this is not being done with the labels so that + the label of the deleted feature becomes the label of the next + feature and all subsequent features also have the wrong label. The + result is incorrect labels for the features when labeling is turned + on for the graphs and in the database files. There is no effect on + dispersion calibration. If one does not care about the labels then + there is nothing to be concerned about. There is no work around + other than to avoid deleting features in the fitting mode or + editing the database file after the fitting. + +STATUS: Fixed for the next release. + +NUMBER: 490 +MODULE: scombine +SYSTEM: -V2.113b +DATE: Thu Aug 9 11:22:15 MST 2001 +FROM: valdes + +BUG: If only the number of desired output pixels is given then one + would expect that the dispersion limits of the input data would + be used and the dispersion would be adjusted to give the desired + number of pixels. Instead the minimum dispersion is used and the + ending dispersion limit is adjusted. No combination of + parameters will cause the dispersion to be adjusted to satisfy + the other parameters. The only workaround is to specify the + desired dispersion. + +STATUS: Fixed for the next release. + +NUMBER: 491 +MODULE: immatch.xregister +SYSTEM: V2.11 +DATE: Wed Oct 17 15:01:18 MST 2001 +FROM: davis + +BUG: In interactive mode xregister is only using the first correlation + region to compute the shifts, rather than averaging the shifts + computed for all the regions. + +STATUS: Fixed for the next release of IRAF and in the external addon package + immatchx. The woraround is to use non-interactive mode if possible. + +NUMBER: 492 +MODULE: imcoords.wcsctran +SYSTEM: V2.11 +DATE: Sat Dec 8 10:32:24 MST 2001 +FROM: davis + +BUG: Wcsctran may fail with a "Cannot write to string_file" error if + the input image is dimensionally reduced, i.e. a section of higher + dimensioned parent image. The bug is caused by an uninitialized + array. If the array is accidentally initialized to 0 the bug will + not occur. + +STATUS: Fixed for IRAF 2.12. There is no workaround. + +NUMBER: 493 +MODULE: mscred.ccdproc +SYSTEM: V4.6 +DATE: Thu Feb 21 14:31:03 MST 2002 +FROM: valdes + +BUG: When the "xtalkcor" option is selected but no corrrection is + performed, either because it was done previously or an error + occurs, then various warning messages about deleting non-existent + files will occur. One way the crosstalk operation will fail is if + the crosstalk calibration file is not found due to a missing + XTALKFIL keyword, an error in specifying the file to use, or the + file is not available. When the error in ccdproc happens in the + various combine scripts (zerocombine, flatcombine, etc.) with + process=yes, this will abort these scripts. + + When the error occurs in running ccdproc directly, the warnings can + be ignored or the crosstalk option can be turned off. When this + occurs in the combine scripts, causing them to abort, turn off the + process option or the xtalkcor option in ccdproc. + +STATUS: The bug is due to a typo introduced during the last change to this + task. The bug is fixed in V4.7 of mscred. + +NUMBER: 494 +MODULE: ccdmask +SYSTEM: -V2.11.3 +DATE: Thu Feb 28 09:09:49 MST 2002 +FROM: valdes + +BUG: If the last line or column is found to be a bad pixel but the + pixel has no interior neighbor which is bad, then the mask pixel + value will be a number corresponding to the number of contiguous + bad pixels along the last line or column which includes that + pixel. In other words the pixel will not be set to the specified + linterp, cinterp, or eqinterp value. Since the pixel is correctly + identified as bad the mask may be used though if control over the + direction of interpolation is needed the values should be reset as + needed. + +STATUS: Fixed in V2.12. + +NUMBER: 495 +MODULE: imcombine, ccdred.combine, mscred.combine +SYSTEM: -V2.11.3 +DATE: Thu Apr 18 11:44:40 MST 2002 +FROM: valdes + +BUG: When combining with "offsets=wcs" or "offsets=world" and the + LTV/LTM keywords are different between the images the offsets are + incorrectly computed. The workaround is to reset the physical + coordinate sysetm with "wcsreset <images> wcs=physical". + +STATUS: Fixed in V2.12. Version of combine in mscred prior to the + date of this report also have this bug and later releases + are fixed. + +NUMBER: 496 +MODULE: guiapps.spectool +SYSTEM: All +DATE: Wed May 29 09:39:07 MST 2002 +FROM: valdes + +BUG: When spectool (or tutorial) is run multiple times without + resetting the executable with "flpr", it is possible to get a + segmentation violation before displaying any spectrum on the second + or later executions in certain situations. The main situation + where this might occur is running spectool without a spectrum + filename argument and then using the "Read" panel to browze for a + spectrum to display. The specific case where this bug was found + was modifying the file template. This bug is caused by an + uninitialized pointer. Note that after you have displayed a + spectrum any error (including a segmentation error) will not be due + to this bug. The workaround is simply to use flpr between + executions. If an error occurs use flpr and continue though + occasionally the terminal window may become locked and the xgterm + might need to be restarted. + +STATUS: Fixed in distributions after the date of this report. + +NUMBER: 497 +MODULE: imcombine, mscred.combine, mscred.mscimage +SYSTEM: V2.12, mscred V4.7: May 2002 +DATE: Fri Jun 14 15:23:16 MST 2002 +FROM: valdes + +BUG: A segmentation violation (a reference to an invalid memory address) + is possible because of a bug in a array length calculation. This + problem was seen with mscred.mscimage (which calls mscred.combine) + on PC-IRAF. Whether this occurs with other systems is unknown. + The error occurs almost immediately. There is no workaround if the + error occurs. + +STATUS: A new version of mscred is available with the fix. The next + patch version of IRAF will fix the problem in imcombine. + +NUMBER: 498 +MODULE: nmisc.starfocus, nmisc.specfocus, nmisc.psfmeasure +SYSTEM: NMISC Jan 01, 2000 version for Redhat/Linux +DATE: Tue Jun 18 14:48:36 MST 2002 +FROM: valdes + +BUG: Running the PSF and focus tasks in the NMISC package on some + systems can result in an immediate segmentation violation. This + was reported on PC-IRAF for RedHat, though it will likely occur + on other similar systems. There is no workaround but a new + June 2002 distribution corrects this problem. Note that + in V2.12 these tasks are included in the package noao.obsutil + and it is not necessary to install the nmisc package. The + bug is not present in the V2.12 obsutil version. + +STATUS: Fixed in a June 2002 distributions of the NMISC external package. + +NUMBER: 499 +MODULE: immatch.xregister +SYSTEM: V2.12 +DATE: Thu Jun 20 13:15:59 MST 2002 +FROM: davis + +BUG: If the xregister task parameter interactive = yes and the output + images are defined then the computed shifts are not applied. This + occurs because the reinitialization routine triggered by the 'n' + keystroke command is in the wrong place. + +STATUS: Fixed for the next patch / release of IRAF. The work around is to + run xregister twice, once interactively to compute the shifts, and + again non-interactively to apply them. + +NUMBER: 500 +MODULE: apphot package +SYSTEM: V2.12 and earlier +DATE: Fri Jun 21 09:21:08 MST 2002 +FROM: davis + +BUG: In interactive mode the v keystroke will not update the aperture + size or algorithm parameters correctly for the next measurement if + the cursor position does not change significantly. + +STATUS: Fixed for the next patch / release of IRAF. The work around is to + use the equivalent colon commands or move the cursor significantly + after the last measurement. + +NUMBER: 501 +MODULE: quadred.quadproc +SYSTEM: V2.12 +DATE: Fri Jul 5 11:16:30 MST 2002 +FROM: valdes + +BUG: The QUADPROC task, which is essentially the same as the + ARED.QUAD.QUADPROC external package version, can fail with + a divide by zero error. This is due to an script error where + the multiamp data is not split into pieces. The workarounds + are to either use QUADRED.CCDPROC (which is the recommended + replacement for QUADPROC anyway) or to copy, edit, and + redefine the script subtask qproc. For the latter workaround + contact iraf support (iraf@noao.edu) for instructions. + +STATUS: Fixed for the next release. + +NUMBER: 502 +MODULE: pl files and fixpix, imreplace, and others +SYSTEM: V2.12 +DATE: Mon Jul 22 08:42:45 MST 2002 +FROM: valdes + +BUG: Between IRAF versions 2.11 and 2.12 there was a change in the + structure of pixel list (pl) files to allow for larger images. The + change was made so that old format pl files can be read. However, + updating of old format files is not supported. This means some + tasks that truly work in-place, such as IMREPLACE, will fail. + (Tasks that replace the input file by their result using a + temporary intermediate file, which are more common, are not truly + in-place operations and so do not have this problem.) It is a bug + that in-place update operations will result in the file being + deleted. Some tasks don't actually write out a pl file but + internally modify it. The task FIXPIX is in this class. This will + result in the same type of error. Typically the error is "Cannot + update image header". The workaround is to use IMCOPY to create a + new version of the pl files when starting with V2.11 or early files + but working with V2.12. + +STATUS: There is currently no plan to support pl update operations on + the older pl format. + +NUMBER: 503 +MODULE: ccdred: mkfringe, mkillumcor, mkillumflat, mkskycor, mkskyflat +SYSTEM: V2.11.2 - V2.12.1 +DATE: Wed Jul 31 11:47:49 MST 2002 +FROM: valdes + +BUG: In V2.11.2 the CCDPROC task added an "output" parameter. Because + the tasks listed above have the option to call CCDPROC to do + preprocessing and also have a parameter "output" there can be + confusion about the output parameter. If the task output + parameter is given explicitly on the command line; i.e. + + cc> mkillumcor in out + + Then the correct output is produced. However, if the task + is excuted in hidden mode (such as with a :go from EPAR) or + without the output on the command line where one expects a + query, then the CCDPROC.OUTPUT parameter is used instead which + can lead to either the input being replaced by the output or + whatever is set in that parameter being used. + + The workarounds are 1) put the output name explicitly on the + command line or 2) set the desired output name in the CCDPROC + parameters. + + +STATUS: Fixed for the next release. + +NUMBER: 504 +MODULE: nproto.objmasks +SYSTEM: V2.12-V2.12.1 +DATE: Tue Aug 6 16:03:28 MST 2002 +FROM: valdes + +BUG: This task may abort with a floating divide error. This is caused + by the first pass estimate of the background sigma using a + planar fit. The can produce zero or negative sigma values. + The workaround is to set the "fitxorder" and "fityorder" + parameters to 1 in the hidden parameters set objmasks1; + i.e. epar objmasks1. + +STATUS: In the next release the initial sky will still be fit by a surface of + some specified order but the initial sigma will be purely a + constant. + +NUMBER: 505 +MODULE: data.export +SYSTEM: V2.11 - V2.12.1 +DATE: Fri Aug 9 15:03:10 MST 2002 +FROM: fitz + +BUG: The task was failing to write a PPM file properly when the input + image contained an odd number of columns, resulting in a corrupted + image. + +STATUS: PPM files interleave the pixels, but when there are an odd number of + columns in the image the resulting line contains an odd number of + bytes/line. IRAF file I/O cannot properly write data and the task + was not structured to buffer lines for a case such as this. The + task will now truncate the last column of the input image so the + output will contain an even number of bytes. The workaround is + simply to copy out a new image with an even number of columns before + running the task. + + Fixed for future releases or contact site support for a code change. + +NUMBER: 506 +MODULE: imalign +SYSTEM: -V2.12.1 +DATE: Mon Aug 19 11:36:28 MST 2002 +FROM: valdes + +BUG: The error "parameter ` 7' not found" may occur, where the number + may vary. This is caused by a corruption of the centroiding + information by the warning messages. The workaround requires + making a private copy of the script with a small change: + + cl> immatch # load package + im> copy immatch$imalign.* home$ # copy to home directory + im> edit home$imalign.cl # edit private copy + Change: verbose=verbose, >& tmpfile) + To: verbose=verbose, > tmpfile) + im> redefine imalign=home$imalign.cl # redefine imalign + + The warnings, which can be ignored, will now appear on the terminal. + Contact iraf@noao.edu for more information. + +STATUS: The problem is fixed in the next release. + +NUMBER: 507 +MODULE: imreplace +SYSTEM: -V2.12.1 +DATE: Wed Sep 4 09:52:48 MST 2002 +FROM: valdes + +BUG: When using IMREPLACE with integer images and with a grow radius, + the specified lower limit is not properly adjusted to include the + lower limit if given as an integer. With radius=0 a different + subroutine is used and so it works correctly. The workarounds are + to use a fractional lower limit; i.e. 0.5 to include values of 1 or + to convert to real images. + +STATUS: Fixed for the next release. + +NUMBER: 508 +MODULE: imshift +SYSTEM: -V2.12.1 +DATE: Thu Sep 12 17:05:20 MST 2002 +FROM: valdes + +BUG: Using a shift smaller than the precision of a real value + (~10^-6) causes the image output to actually have a shift of 1 + pixel except at the edges. This is caused by the fact that while + the shift is seen as non-zero, one plus the shift is not + seen as different from 1. There is no workaround other than + avoiding using very small shifts. Note that using such small + shifts is computationally not significant. + +STATUS: Fixed in the next release by doing computations in double + precisions when appropriate. + +NUMBER: 509 +MODULE: APPHOT: CENTER, FITPSF, FITSKY, PHOT, QPHOT, POLYPHOT, RADPROF, WPHOT +SYSTEM: V2.12.1 and earlier +DATE: Tue Oct 1 11:28:22 MST 2002 +FROM: fitz, valdes + +BUG: The handling of the "default" parameter value for coordinate lists + failed when the input list had more than one image, resulting in + either an "Illegal file descriptor (bad fd or file not open)" + message or the task silently re-using the coordinate list from the + first image. The workaround is to explicitly specify the coordinate + file list using a template, for example + + cl> phot *.fits coords="*.coo.1" + + +STATUS: Fixed for the next release. Contact site support for a patched + binary or code changes. Note that all tasks in this package which + allow this value are affected and have been modified. + +NUMBER: 510 +MODULE: mscred.ccdproc +SYSTEM: -V4.7: June 14, 2002 +DATE: Wed Oct 23 14:56:41 MST 2002 +FROM: valdes + +BUG: The syntax for the "bleed" parameter of the form + saturation-<constant> or saturation/<constant> is not recognized. + This is due to a bug in parsing the string. There is no workaround + other than to use an explicit value, mean+<constant>, or + mean*<constant>. + +STATUS: Fixed for the next release. + +NUMBER: 511 +MODULE: crutil.craverage +SYSTEM: -V2.12.1 +DATE: Wed Oct 23 15:49:21 MST 2002 +FROM: valdes + +BUG: If a new output mask is specified, as opposed to updating an existing + mask, then the grow option will fail to grow the detected pixels. + The workaround is to do the growing in a separate call to CRGROW. + +STATUS: This is revised for the next release. + +NUMBER: 512 +MODULE: imcombine, mscred.combine (and related combine scripts) +SYSTEM: V2.12, MSCRED V4.7 +DATE: Fri Oct 25 09:50:21 MST 2002 +FROM: valdes + +BUG: The log output from the combining when using masks will incorrectly + show all the images using the same mask (the one for the last image). + This is an error in the output formating and the correct masks will + actually be used. There is no workaround other than to ignore + the incorrect output. + +STATUS: This is fixed in V2.12.1 and will be fixed in the next release + of MSCRED. + +NUMBER: 513 +MODULE: icfit (apextract, curfit, ...) +SYSTEM: V2.12-V2.12.1 +DATE: Mon Nov 18 16:11:42 MST 2002 +FROM: valdes + +BUG: When a single fitting (sample) region is defined and binning is used + (|naverage| > 1) such that only a single binned fitting point + results, then incorrect results or a segmentation error may occur. + + A case where this occurs is in apall/apsum when a single background + region is defined and a large binning value is set to use the + median or average of the background sample regions. An inobvious + situation resulting in this is when there are actually two + background regions on either side of an aperture which are defined + relative to the aperture. If the aperture is defined or moves too + close to the edge of the image such that one of the background + regions goes entirely off the image, then this error can be + triggered. + + This problem behavior was introduced in V2.12 when the stability of + the fit was improved by only fitting only over the range of the data + selected in by the sample region(s) rather than over the entire + data set. + + The only workaround is to avoid this case. For apall/apsum one + needs to check for a background region going off the edge or be + sure to use |naverage| smaller than the width of the background + regions to insure at least two fitting points. + +STATUS: The case of a single fitting point in binned data will be handled + properly in the next release. + +NUMBER: 514 +MODULE: sensfunc +SYSTEM: All +DATE: Fri Nov 22 11:56:05 MST 2002 +FROM: valdes + +BUG: This report is not actually a bug but a guide as to the source of + the error "no degrees of freedom" from the task SENSFUNC. If the + standard star file used with the task STANDARD has the standard + values in flux units instead of magnitudes there will be no + apparent error from that task. But the file produced will have + zero or very small numbers for the points to be fit by SENSFUNC. + Using this file with SENSFUNC produces the error "no degrees of + freedom". So if you see this error and it is not solved by using + lower fitting orders then it is probably the values in the file + produced by STANDARD were generated from an incorrect standard data + file given in flux. + + Why this has come up is that if you retrieve standard star data + from the ESO web pages be sure to get ones given in magnitudes + and not in flux. + +STATUS: No change is contemplated at this time. + +NUMBER: 515 +MODULE: ahedit/awcspars +SYSTEM: -V2.12.1 +DATE: Tue Dec 3 09:27:02 MST 2002 +FROM: valdes + +BUG: The parameter awcspars.wraunits used by the task ahedit may take + the values "", "degrees", "radians", and "hours". However, the + value "hours" is incorrectly interpreted as "degrees". So to + specify that the reference ra/longitude coordinate is in hours use + the value "" which defaults to hours. + +STATUS: Fixed for the next release. + +NUMBER: 516 +MODULE: xdimsum.xmosaic +SYSTEM: - August 8, 2002 +DATE: Fri Jan 24 15:41:15 MST 2003 +FROM: valdes + +BUG: When defining the shifts interactively IMEXAMINE is used in a mode + where it determines the maximum number of frames available in the + display server (XIMTOOL, DS9, SAOimage, etc). However, this was + not working correctly and it would attempt to use frames which are + not available with DS9 (currently up to V2.2) and servers other + than XIMTOOL. There is no workaround other than to update the + software. (After installing the new version be sure to + reset the parameters for xdshifts; "unlearn xdshifts"). + +STATUS: The script XDSHIFTS was modified in XDIMSUM version January 24, 2003 + to allow control of the maximum number of frames with a default + value suitable for all display servers. + +NUMBER: 517 +MODULE: rv.rvidlines +SYSTEM: V2.12-V2.12.1 +DATE: Thu Feb 6 15:01:26 MST 2003 +FROM: valdes + +BUG: The task first parses the date keyword given in KEYWPARS which + sets the year, month, day, and optionally the UT. But then + it parses the UT keyword given in KEYWPARS in the same way + as for the date. If this keyword is not in YYYY-MM-DDTHH:MM:SS.S + format then the year, month, and day are clobbered the program + crashes. So in this version there is no substitue to using + this format for the date and setting the UT keyword to + be the same as the date keyword. + +STATUS: Fixed in the next release. + +NUMBER: 518 +MODULE: guiapps.spectool +SYSTEM: V1.1: December 2000 +DATE: Mon Feb 17 10:17:03 MST 2003 +FROM: valdes + +BUG: The Voigt profile fitting will crash with a segmentation error + (or possibly just produce a bad fit). This is a programming error + where a subroutine return argument was mistyped. There is no + workaround other than updating. + +STATUS: Fixed in next release of the GUIAPPS package. + +NUMBER: 519 +MODULE: spectool +SYSTEM: -V1.2: February 2003 +DATE: Wed Feb 19 12:28:59 MST 2003 +FROM: valdes + +BUG: This is not exactly a bug but a limitation. The Voigt profile fitting + requires a minimum value for the width parameters to avoid + numerical problems. The limit is the value, in the current + dispersion units, corresponding 3.3% of a pixel. Attempting to set + the value any smaller, say with fitting of the parameter turned + off, will still result in a returned value corresponding to the + minumum. If you want one of the values to be zero then the profile + type should be set to Gaussian or Lorentzian. If you want a fixed + value smaller than the minimum the only workaround is to resample + the spectrum to finer pixels. + +STATUS: A smaller minimum could be put into the code but there will always + be some point and so no changed is currently planned. + +NUMBER: 520 +MODULE: onedspec.telluric +SYSTEM: -V2.12.2 +DATE: Mon Feb 24 12:18:04 MST 2003 +FROM: valdes + +BUG: When an error, such as invalid parameters or missing images, occurs + the task first does some error clean up operations before reporting + the error. The problem with this is that the actual error message + can get lost and a misleading message, such as environment variable + or image header parameter not found, will be given. Avoid this + requires a code change. One way to sometimes get to the true error + is to eliminate the misleading error by setting a value for the + missing evironment or header parameter. Also check carefully all + the task parameters since most error are the result of problems + with them. + +STATUS: The error handling will be improved in the next release. + +NUMBER: 521 +MODULE: mscred.ccdproc +SYSTEM: V4.8: November 4, 2002 +DATE: Fri Mar 14 14:59:49 MST 2003 +FROM: valdes + +BUG: When using the "merge" option in conjunction with "bpmasks" output + and "fixpix" the merged masks are not properly created. They will + have names "tmp...", will not contain the right pixels, nor will + the BPM pointers in the data images be correct. The workarounds + are either not merge the amplifiers or do the merging first and + then do the fixpix and saturation/bleed trail masking after the + extensions are merged. + +STATUS: The latest version of MSCRED has this bug fixed. + +NUMBER: 522 +MODULE: mscred +SYSTEM: V4.8: March 2003 releases +DATE: Fri Apr 11 15:40:16 MST 2003 +FROM: valdes + +BUG: A bug was introduced in the coordinate conversions between pixels + and celestial coordinates in the March 2003 releases. The bug + affects MSCCMATCH, MSCZERO, MSCCTRAN, MSCTVMARK, MSCPIXAREA, + MSCGETCAT, and MSCIMAGE. The bug was to not deproject the + tangent plane correctly. There is no workaround other than + to update. + + +STATUS: The bug has been fixed a a new release made. + +NUMBER: 523 +MODULE: dohydra, doargus, dofibers, do3fiber +SYSTEM: V2.11-V2.12 +DATE: Wed May 21 15:16:02 MST 2003 +FROM: valdes + +BUG: When dispersion linearization is selected and the dispersion + parameters are modified in response to "Change wavelength + coordinate assignments?" the new parameters are not applied to the + extractions. One workaround is to not linearize and then later use + DISPCOR to linearize. + + The code fix is simple. In the directory srcfibers$ + ($iraf/noao/imred/src/fibers) change samedisp=yes to samedisp=no in + proc.cl. There is only one occurrence. If you don't have + permissions to modify the installed version you can copy this file + to your working directory, modify it, and redefine it (after + loading the package) with "redefine proc=proc.cl". If you use the + batch option you need to do the same thing to the file batch.cl. + +STATUS: Fixed for V2.12.2. + +NUMBER: 524 +MODULE: reidentify +SYSTEM: -V2.12.1 +DATE: Tue May 27 15:16:39 MST 2003 +FROM: valdes + +BUG: When doing REIDENTIFY with refit=no the "User Shift" shown in the + log output is wrong after the first reidentifications. This is + because the previous shift was being applied inappropriately when + doing the next case. This only affects the log output and not the + results in the database. + +STATUS: Fixed for the next release. + +NUMBER: 525 +MODULE: guiapps.xapphot.xguiphot +SYSTEM: -V1.1 (Feb03) +DATE: Fri May 30 13:34:46 MST 2003 +FROM: valdes + +BUG: When changing the directory in the Files->Files panel a memory + corruption or segmentation error can occur. This is caused by + closing the previous information but not marking it as closed. + The only workarounds are to avoid using the directories and + file panel if this occurs. + +STATUS: Fixed in V1.2 (May03). + +NUMBER: 526 +MODULE: disptrans +SYSTEM: V2.11.3 - V2.12.1 +DATE: Wed Jun 4 10:53:33 MST 2003 +FROM: valdes + +BUG: The option to resample to constant steps in the transformed dispersion + units (linearize=yes) was broken in V2.11.3 due to a change in + subroutine arguments. The workaround is to use linearize=no + to change the dispersion function associated with the pixels and + then use DISPCOR to resample to linear increments. + +STATUS: Fixed for V2.12.2. + +NUMBER: 527 +MODULE: mscred.ccdproc +SYSTEM: - V4.8 April 11, 2003 +DATE: Tue Jun 24 13:30:57 MST 2003 +FROM: valdes + +BUG: The "fixpix" option suffers from a bug in the system mask code + which can cause large segments of the image to be marked and/or + interpolated as bad. This happens when there are bad pixels near + the right edge of the mask. There is no workaround other than + not using the fixpix option or making masks with the bleed trail + and saturation options. In recent versions this bug has been fixed + in RedHat systems (using the distributed binaries) but not on + Solaris. + +STATUS: The system bug has been fixed for the next IRAF patch release. + It is also fixed in the June, 2003 version of the ssun binaries + for mscred. + +NUMBER: 528 +MODULE: ARTDATA tasks using random numbers and URAND +SYSTEM: -V2.12.2 +DATE: Thu Aug 7 12:38:19 MST 2003 +FROM: valdes + +BUG: Many tasks using random numbers in ARTDATA (GALLIST, STARLIST, + MKNOISE, MKOBJECTS, MK1DSPEC, MKECHELLE) as well as UTILITIES.URAND + have a parameter to provide the seed value and a feature to specify + it as INDEF to set it based on the system clock. This is to allow + generation of different results each time the task is called. + However, the clock-based seed only changes each second so if the + same task is called rapidly enough the seed may not change between + executions. The workaround is to include some delay beween calls, + such as using sleep in scripts and CL loops. + +STATUS: The tasks listed above have been modified for the next release + to avoid the behavior described above. + +NUMBER: 529 +MODULE: imcombine +SYSTEM: V2.11-V2.11.3 +DATE: Mon Aug 11 12:13:29 MST 2003 +FROM: valdes + +BUG: When specifying a bad pixel mask output with the "plfile" parameter + it is possible to get + + Warning: Operation would overwrite existing image (<name>.pl) + + This occurs when a problem is encountered and the task tries again + with a different parameters to avoid the problem. The bug is that + the pl file is not deleted before tryng again. This retry behavior + occurs for several reasons, most commonly when the number of images + being combined exceeds a limit of about 250 images. The workaround + is to "reset imclobber=yes". Note that this resets the clobber + policy for all IRAF tasks so one should probably reset it to "no" + after working around this IMCOMBINE bug. + +STATUS: This is fixed in V2.12. + +NUMBER: 530 +MODULE: apall, apsum +SYSTEM: -V2.12.1 +DATE: Tue Oct 21 14:00:15 MST 2003 +FROM: valdes + +BUG: When DISPAXIS=1 there is a potential for a segmentation violation + due to referencing outside an array. This is more likely with + variance weighting and cleaning but is not limited to this case. + The bug does not affect the results if the task completes without + error. The only workaround is to transpose the image so that + DISPAXIS=2. + +STATUS: Fixed for the next release. + +NUMBER: 531 +MODULE: mkheader +SYSTEM: -V2.12.1 +DATE: Mon Nov 10 15:57:28 MST 2003 +FROM: valdes + +BUG: The error + + Old format = "%s%*t<>\n") + ERROR: No write permission on file (String_File) + + occurs when the number of keywords being added exceeds the internal + limits of the header. The workaround is to ignore this error, + clean up any problems in the last keyword added, and add more + headers in additional steps. + +STATUS: The unclear error has been replaced by the warning "Possibly failed + to add all keywords". This change was added for V2.12.2. + +NUMBER: 532 +MODULE: apextract tasks +SYSTEM: V2.11.2 - V2.12.1 +DATE: Wed Dec 3 14:20:07 MST 2003 +FROM: valdes + +BUG: Support for extractions on image sections added in V2.10.4 was + lost in the V2.11.2 release. By lost we mean that any image + section specified for the input data is automatically stripped. + +STATUS: The ability to specify input images sections is restored in the + V2.12.2 release. + +NUMBER: 533 +MODULE: sarith, scopy +SYSTEM: V2.12.2 +DATE: Tue Mar 9 14:15:08 MST 2004 +FROM: valdes + +BUG: In V2.12.2 a bug was introduced such that the "merge" option no + longer works. It produces a segmentation violation type of error. + The workaround is to produce a temporary file and then use SCOPY. + + DOES NOT WORK: + sarith a - b a clobber+ merge+ + WORKAROUND + sarith a - b c + scopy a,c a clobber+ + imdel c + +STATUS: Fixed for the next release. + +NUMBER: 534 +MODULE: test +SYSTEM: V2.12 +DATE: Thu Mar 25 11:37:43 MST 2004 +FROM: fitz + +BUG: ...bug + +STATUS: ...fixed + +NUMBER: 535 +MODULE: imcombine +SYSTEM: V2.12.1-V2.12.2 +DATE: Thu Apr 8 16:48:28 MST 2004 +FROM: valdes + +BUG: When combining one-dimensional images usng offsets the result is wrong. + The workaround is to promote the images to 2D using IMSTACK; i.e. + "imstack im1 im2" where im1 is the 1D image and im2 is the 2D + image with one line. + +STATUS: Fixed for the next release. + +NUMBER: 536 +MODULE: apall, apsum +SYSTEM: -V2.12.2 +DATE: Fri May 21 16:14:31 MST 2004 +FROM: valdes + +BUG: When an aperture trace is lost the region of the trace fit is less + than the range of the dispersion. However, during extraction the + trace is evaluated at all points along the dispersion. The + extrapolation of the fit can cause problems resulting in errors + such as out of memory or salloc underflow. The only workaround + is to eliminate the aperture with the bad trace or use the + interactive trace fitting options to constrain the fit, such as + by adding dummy points, to give a well behaved trace fit. + +STATUS: In future releases evaluation of the trace will use + fit at the end point when extrapolating outside the range of + the fit. + +NUMBER: 537 +MODULE: fixpix +SYSTEM: -V2.12.2 +DATE: Tue Jun 22 14:19:28 MST 2004 +FROM: valdes + +BUG: Column interpolation does not work except under special circumstances. + The bug is that a count is made of the number columns containing + pixels to be replaced. This number is incorrectly used in place of + the number of columns in the image. For instance if the + description of the pixels to be fixed is a single column then the + task only allows column interpolations in the first column. + Knowing this one crude workaround is to specify one region to be a + whole line; for instance the region consisting of the first image + line. The other workaround is to transpose the image, use line + interpolation, and then transpose back. + +STATUS: Fixed for the next release. + +NUMBER: 538 +MODULE: mscred.msccmatch +SYSTEM: V4.8: November 6, 2003 - +DATE: Thu Jul 15 13:59:37 MST 2004 +FROM: valdes + +BUG: In the November 6th release of MSCRED the task MSCCMATCH calls + GEOMAP with the parameter "maxiter". This parameter was added + to GEOMAP in V2.12 IRAF. Therefore, MSCCMATCH will abort with + an error about "maxiter" when a recent version of MSCRED is + installed and used with V2.11 IRAF. The workarounds are to + update IRAF, go back to an earlier version of MSCRED, or patch + the immatch$geomap.par file to add the line + + maxiter,i,h,0,,,Maximum number of rejection iterations + +STATUS: Currently no changes are planned to maintain recent versions of + MSCRED which are compatible with V2.11 IRAF. + +NUMBER: 539 +MODULE: ccmap, ccsetwcs, msctpeak +SYSTEM: -V2.12.2a +DATE: Tue Aug 31 09:24:53 MST 2004 +FROM: valdes + +BUG: The code which updates image headers with a TNX/ZPX WCS solution + produced by CCMAP could fail so that evaluation of coordinates from + the image would not be correct or agree with CCTRAN. The failure + is more likely to occur with small pixel scales and higher order + distortion functions. The problem is due to an incorrect check for + a singular matrix when determining the TNX coefficients for the + header. When the code decides the matrix is singular, coefficients + are set to zero and the evaluation is wrong. Since this either + happens or doesn't happen it means that there is no problem with + accuracy until the bug is triggered. The problem is in the GSURFIT + math library which could also affect other tasks built on it, + though no problems related to it are known currently. + +STATUS: The bug was identified and fixed in the math library. + +NUMBER: 540 +MODULE: ecidentify/ecreidentify +SYSTEM: -V2.12.2a +DATE: Fri Sep 10 13:02:53 MST 2004 +FROM: valdes + +BUG: ECIDENTIFY and ECREIDENTIFY are supposed to work in terms of "physical" + coordinates which are independent of different image sections + applied to the data at different stages in the reduction process. + However, there was a bug where a transformation was applied in the + wrong direction. A symptom would be that marking a feature would + put the tick mark in the wrong place. The only workaround is to + either avoid any image sections in the reduction steps leading up + to these tasks or to make the two coordinate systems the same by + resetting the physical coordinate system with WCSRESET + (i.e. wcsreset <images> wcs=physcial). For those less familiar + with the logical and physical coordinate systems, if there are + keywords beginning with LTV and LTM keywords in the header then + there is a physical coordinate system defined which would usually + be different than the image based logical coordinate system. + +STATUS: Fixed for the next release. + +NUMBER: 541 +MODULE: ccsetwcs +SYSTEM: -V2.12.2 +DATE: Fri Oct 8 13:49:01 MST 2004 +FROM: valdes + +BUG: The help says that one may specify a list of images and a single WCS + database record but this does not work. The workaround is to + repeat the record name to match the number of images. + +STATUS: Fixed to work as described in the help for the next release. + +NUMBER: 542 +MODULE: allstar +SYSTEM: -V2.12.2a +DATE: Thu Nov 18 13:37:44 MST 2004 +FROM: valdes + +BUG: When a field contains broad objects a divide by zero error can + occur when computing the sharpness parameter. There is no + workaround when this happens. + +STATUS: This has been fixed for the next release. An early release + binary is available from the IRAF group (iraf@noao.edu). + +NUMBER: 543 +MODULE: craverage +SYSTEM: -V2.12.2 +DATE: Wed Nov 24 10:26:57 MST 2004 +FROM: valdes + +BUG: A segmentation violation will occur when the "crmask" parameter is + set to an existing mask. The intent was to allow an existing mask + to be used to exclude known bad pixels from the calculation and then + add the detected cosmic rays to the mask. But a bug in the code + prevents this from working. The workaround is to not use an + existing mask in "crmask". If one wants to end up with a mask + describing the detected cosmic rays as well as the previously + determine bad pixels then specify a new mask and merge the + detectected cosmic rays with the previous mask. There is no + workaround to allow using the pre-existing mask to exclude pixels + from the calculation. + +STATUS: Fixed for the next release. + +NUMBER: 544 +MODULE: echelle.scombine +SYSTEM: V2.12.2 +DATE: Wed Jan 19 08:44:47 MST 2005 +FROM: valdes + +BUG: Changes to SCOMBINE in V2.12.2a made it a separate executable. The + ECHELLE package definitions, however, failed to be updated so when + trying to run SCOMBINE from the echelle package the following error + message is produced. + + ERROR: task `scombine' has no param file + + The solution is editing the echelle$echelle.cl file so that it + reads as shown below. A simpler workaround is to load the onedspec + package and run scombine from that package. + +STATUS: Fixed for the next release. + +Modifications to echelle$echelle.cl: + +... +task continuum, + deredden, + dispcor, + dopcor, + ecidentify, + ecreidentify, + refspectra, + sapertures, + sarith, + sflip, + slist, + specplot, + specshift, + splot = "onedspec$x_onedspec.e" +task scombine = "onedspec$scombine/x_scombine.e" +... + +Note that scombine has to be removed from the first block of task +definitions and added as a separate task statement. + +NUMBER: 545 +MODULE: sarith +SYSTEM: -V2.12.2a +DATE: Tue Mar 8 10:46:27 MST 2005 +FROM: valdes + +BUG: When an output wavelength range is selected which does not overlap + the input data and the output format is onedspec a segmentaion + error occurs. The correct warning message, "No pixels to extract" + is printed but then the error cleanup was not handled correctly. + This problem does not occur with multispec output which is, + therefore, a workaround. However, it is likely that the wavelength + range was accidentally set incorrectly since an operation outside + of the data is probably not intended. Note that the correct + behavior is to not produce an output spectrum in this case. + +STATUS: Fixed for the next release. + +NUMBER: 546 +MODULE: mscred.ccdproc, mscred.mscmerge +SYSTEM: -V4.8: May 11, 2004 +DATE: Fri Apr 15 16:55:02 MST 2005 +FROM: valdes + +BUG: CCDPROC produces a "Pixel subscript out of bounds" error when + applying calibrations produced from binned and merged data. + In other words, mosaic data with multiple amplifiers per + CCD, which are taken with binning, will produce this error + after running ZEROCOMBINE with merging enabled and applying + this calibration to flat fields or objects. This problem + is caused by CCDPROC incorrectly updating the physical WCS + for binned data. This causes the merging of multiple amplifiers + to produce incorrect section keywords. This is particularly + important for the CCDSEC keyword. Attempting to apply merged + calibrations with the invalid CCDSEC keyword causes the error. + There are two workarounds. One is to not merge the amplifiers + at all or until all calibrations have been applied. The other + is to edit the CCDSEC keywords for merged calibration images + produced by ZEROCOMBINE and FLATCOMBINE to reflect the true + CCD section. The error is normally that the first pixel in + CCDSEC is zero rather than one. + +STATUS: Fixed for the next release of MSCRED. + +NUMBER: 547 (see also 544) +MODULE: argus, ctioslit, hydra, iids, irs, kpnocoude, kpnoslit +SYSTEM: V2.12a-V2.12b +DATE: Mon Apr 25 10:59:24 MST 2005 +FROM: valdes + +BUG: Changes to SCOMBINE in V2.12.2a made it a separate executable. The + package definitions for the packages listed above (see also number + 544 concerning the ECHELLE package) failed to be updated so when + trying to run SCOMBINE (or a task that calls SCOMBINE such as + DOHYDRA) the following error message is produced. + + ERROR: task `scombine' has no param file + + The solution is editing the <package>$<package>.cl file, where + <package> is one of the modules listed above, so that it reads as + shown below. A simpler workaround is to load the onedspec package + and run scombine from that package. + +STATUS: Fixed for the next release. + +Modifications to <package>$<package>.cl: + +... +task ..., + [scombine,] <-- Delete line + ..., + ... = onedspec$x_onedspec.e +task scombine = "onedspec$scombine/x_scombine.e" <-- Add line +... + +Note that scombine has to be removed from the first block of task +definitions and added as a separate task statement as shown. + + +NUMBER: 548 +MODULE: specplot +SYSTEM: -V2.12.2a +DATE: Mon May 2 11:03:20 MST 2005 +FROM: valdes + +BUG: When using a file for the cursor input the colon commands + must include the x, y, and system values even if the spectrum + is explicitly selected. For example: + + 0 0 1 :color[2] 2 + + If this is not done then a floating exception results. This is + because the search for the nearest spectrum to the cursor position + is always done even if the spectrum is specified explicitly. + +STATUS: In the next release the cursor position is optional. + +NUMBER: 549 +MODULE: spectool +SYSTEM: SPT V1.2: February 2003 +DATE: Tue Jun 21 11:35:40 MST 2005 +FROM: valdes + +BUG: When the arithmetic function needs to interpolate the spectrum it + needs a parameter "interp" which was left out. The workaround is + to type 'string interp="poly5"' after loading the SPT package and + before running SPECTOOL. + +STATUS: Fixed for a future release. + +NUMBER: 550 +MODULE: spectool +SYSTEM: SPT V1.2: February 2003 +DATE: Tue Jun 21 11:38:36 MST 2005 +FROM: valdes + +BUG: Use of spectra with the lookup world coordinate system, as produced + by RSPECTEXT with "non-linear", causes various failures such as + segmentation violations and memory corruption. the workarounds are + to use SPLOT and other equivalent tasks from the ONEDSPEC package. + +STATUS: The task is currently frozen. This will be studied further if + resources allow. + +NUMBER: 551 +MODULE: doecslit +SYSTEM: -V2.12.2 +DATE: Mon Nov 14 14:56:06 MST 2005 +FROM: valdes + +BUG: The sparams.refit parameter is not actually used during the arc + reidentification step. Instead doecslit will always attempt to + refit the dispersion function. There is no workaround other than + fixing the appropriate script task doecslit$sdoarcs.cl to change + the refit value from yes to sparams.refit. + +STATUS: Fixed for the next release. + +NUMBER: 552 +MODULE: imcombine +SYSTEM: V2.12.2 +DATE: Tue Feb 28 14:07:30 MST 2006 +FROM: valdes + +BUG: When the combine option is sum and weighting is selected an exception + occurs. The sum option was added as a later feature and a + flag needed for weighting was not set. There is no workaround to + combine weighting and summing directly. One can use "average" and + the scale the result to the equivalent of a sum. + +STATUS: Fixed for V2.12.3. + +NUMBER: 553 +MODULE: splot +SYSTEM: -V2.12.3 +DATE: Tue May 16 11:08:14 MST 2006 +FROM: valdes + +BUG: If SPLOT is run more than once without flushing the process (flpr) + then the default aperture will be that from the last execution. + The consequence is that use of an image section to select an + aperture in a multiaperture file may not display the intended + spectrum. The workaround is to use the command "flpr" before + using an image section. + +STATUS: Fixed for the next release. + +NUMBER: 554 +MODULE: dopcor +SYSTEM: V2.13 +DATE: Tue May 23 16:11:05 MST 2006 +FROM: valdes + +BUG: The verbose output only prints information based for the last + spectrum in a multispec file. When a single correction is being + applied to all apertures this is correct but when different + corrections are being generated for different apertures, say when + adding a correction to apertures which had different initial + corrections applied this can be concerning. The actual corrections + are being applied correctly for each aperture but the verbose output + may be misleading. There is no workaround though it is not a data + calibration error just a logging error. + +STATUS: To be fixed in a future release though no fix has yet been implemented. + +NUMBER: 555 +MODULE: longslit.fitcoords +SYSTEM: V2.13-Beta[12] +DATE: Wed Jun 14 10:41:50 MST 2006 +FROM: valdes + +BUG: If the fitting axis is 2 (the identify/reidentify features are defined + by cuts along the second axis) the y coordinate for the 2D fitting + will be wrong. You will notice this if data are plotted with one + axis being the y coordinate. The other way you would notice this + is that the transformation won't correctly remove the distortions + and make a correct wavelength solution. + + The only workaround is to transpose the data early before doing + the feature identification and tracing. Note that you must then + also reset the physical WCS after the transpose with the command + "wcsreset <images> wcs=physical". + +STATUS: Fixed for the next V2.13 release. + +NUMBER: 556 +MODULE: splot, sarith, scombine, standard +SYSTEM: -V2.13Beta +DATE: Fri Oct 27 09:33:16 MST 2006 +FROM: valdes + +BUG: When matching one spectrum to another, the reference spectrum, + for some operation (e.g. arithmetic, combining, standard star + calibration) the first spectrum is converted to its natural + WCS units. If the reference spectrum is in different units + the result will be wrong. This is rare but a particular case + is when SPLOT displays a spectrum in some units, possibly set + by the display units in the header or by the task parameter, + and then a binary arithmetic operation is performed using a + second spectrum. Even if the second spectrum has the same + display units it may be resampled to match the reference + spectrum in the wrong units. The code solution is to always + resample in the current units of the reference spectrum. + + The workaround for the SPLOT example is to use the ":units" + command to put the initial spectrum into the natural units + of the second spectrum. After the arithmetic you can changes + the units back if desired. + +STATUS: Fixed for a future release. + +NUMBER: 557 +MODULE: splot +SYSTEM: -V2.13beta +DATE: Mon Dec 4 15:29:44 MST 2006 +FROM: valdes + +BUG: When the dispersion function for a spectrum is log sampled, + e.g. DC-FLAG=1, and there is also a logical/physical pixel offset, + i.e. LTV1 is not zero, then writing out a new spectrum with the + 'i' key the results in a wrong WCS. There is no workaround. + +STATUS: Fixed for a future release. + +NUMBER: 558 +MODULE: mscimage +SYSTEM: all release up to date +DATE: Fri Mar 30 11:04:18 MST 2007 +FROM: valdes + +BUG: MSCIMAGE defines the resampled output world coordinate system + (WCS) using a reference image WCS. If this reference image + has a ZPN projection an error will occur. This is because when + the output WCS is set the ZPN projection is inherited from the + reference image but MSCIMAGE does correctly setup the output ZPN + projection from the reference image. So one must use a reference + image with another projection such as TAN. + + What is confusing is that wcssource="parameters" implies that + the output WCS is entirely defined by the task parameters. + This is true for everything but the WCS projection type which is + taken from the input image. There is no parameter to set the + projection explicitly and the MSCIMAGE script would need to be + edited to access the projection parameter in the underlying call + to a hidden task MSCWTEMPLATE. MSCIMAGE automatically changes + input projections of "tnx" and "zpx" (distorted projections) to + "tan" since the point of MSCIMAGE is to resample to a simpler + undistorted WCS. A change will be made to also do this for "zpn". + + The workarounds when the input data uses ZPN are to use a reference + image that doesn't have a ZPN WCS or edit mscsrc$mscimage.cl + to change projection="" to projection="tan" in the call to + MSCWTEMPLATE. The code change to MSCWTEMPLATE could also be + made and the MSCRED package recompiled but this is a more complex + process and users should contact iraf.net for help. + + The recommendation for users with the most recent version of IRAF + is to use the task imcoords.mkcwcs to create a reference WCS. + This task creates a dataless image with the desired WCS. It is + basically like defining the WCS using the MSCIMAGE parameters + except you have control over the projection and the tangent + position. The only thing that is less obvious is that you must + set a reference pixel. When building a mosaic you might set this + to be roughly in the middle of the field. For instance if the + final image will be roughly 4Kx4K you might choose a reference + pixel at (2100,2100). + + If you don't have MKCWCS you can call MSCWTEMPLATE directly to do + the same thing. Leave the input and reference image parameters + empty, set wcssource="parameters" and fill in the parameters + including the projection as "tan". This will leave the reference + pixel at (0,0) so you would use HEDIT to set CRPIX1 and CRPIX2 + to the desired point. Alternatively, you could make a list of + all the extensions in the input and specify that as the input + in MSCWTEMPLATE. This then does exactly what mscimage would do + put give you access to the projection parameter. In other words + making the reference image manually this way is equivalent to + editing the mscimage.cl script. + + +STATUS: Future releases of MSCRED will convert input ZPN WCS to TAN WCS + automatically. + +NUMBER: 559 +MODULE: longslit.transform +SYSTEM: -V2.12.3 +DATE: Tue Aug 7 10:39:13 MST 2007 +FROM: valdes + +BUG: When using log resampling (xlog=yes or ylog=yes) it is possible to + get a segmentation error. This is caused by taking the log and + anti-log of coordinates and not getting back exactly the same value + due to real precision problems. This process caused an attempt to + go outside the valid range of the interpolator. This may be a + rare problem but if it does happen one may be able to use the + x1, x2, y1, y2 values to work around the problem. The workaround + for a future release is to use double precision and to impose + range limits on data passed to the interpolator. + +STATUS: Fixed for the next release. + + +NUMBER: 560 +MODULE: CCFIND +SYSTEM: V2.14 +DATE: Wed Jan 23 15:56:04 MST 2008 +FROM: fitz + +BUG: For an image with a ZPN projection, the transform code in mwcs tries + to reference the parent image to get the PV matrix keywords. This task + called sk_decwcs() to open the WCS, but this routine then unmaps + the image. When the task later uses the saved 'mw' pointer to + transform coords the ZPN reference to the parent image is invalid + and results in a segfault. Changed the code to call sk_decim() + directly and operate on the currently open image instead. + + There is no workaround other than to not set the 'usewcs' parameter + and to set the WCS using the other parameters. Contact iraf.net for + a new binary if needed. + +STATUS: Fixed for the next release. + + + +NUMBER: 561 +MODULE: imstatistics, mimstat +SYSTEM: V2.14 +DATE: Tue Jul 15 11:03:18 MST 2008 +FROM: valdes + +BUG: The user supplied upper and lower data limits may be exceeded if + clipping is used. For instance, if the limits exclude all pixels + the clipping with behave as if no pixels are excluded. If not + all pixels are excluded and the clipping thresholds computed + (number of sigma * standard deviation) exceed the limit then + the clipping threshold is used. The only workaround is to not + use clipping if the limit values are supplied or check first + with no clipping to see if all pixels are excluded. + +STATUS: Fixed for the next release. + +NUMBER: 562 +MODULE: mscred.ccdproc +SYSTEM: V4.8 +DATE: Tue Aug 12 12:19:30 MST 2008 +FROM: valdes + +BUG: The fix for bug number 546 was not fully correct. It works for + binned data but results in an error for data which is flipped + (e.g. when CCDSEC/DETSEC have a starting column greater than + the ending column as in '[2048:1025,1:2048]'. The error + is that the resulting CCDSEC in the processed image will + be off by one. This can result is losing a column when + merging multiple amps. + +STATUS: Fixed for mscred V4.9. + +NUMBER: 563 +MODULE: imexpr +SYSTEM: -V2.14 +DATE: Tue Aug 12 15:12:04 MST 2008 +FROM: valdes + +BUG: Literal (quoted) strings cannot be used in expressions stored in the + expression database. The quotes are stripped and then the error is + that an operand by that name is not found. As a warning, single + quotes in the database are not interchangable with double quotes as + they are on the command line. They are interpreted as character + constants and something like 'abc' will be expanded to 'a bc'. + +STATUS: Double quoted strings allowed in next release. + +NUMBER: 564 +MODULE: ccdmask +SYSTEM: -V2.14.1 +DATE: Fri Aug 22 09:27:06 MST 2008 +FROM: valdes + +BUG: The output mask from ccdmask is incorrect if the task has been run + previously without starting the executable fresh. The workaround + is to type "flpr ccdmask" before executing this task to force a + fresh executable. + +STATUS: Undiagnosed at present. Only the workaround has been defined. + + +NUMBER: 565 +MODULE: imextensions +SYSTEM: V2.13-V2.14 +DATE: Mon Aug 25 16:24:33 MST 2008 +FROM: valdes + +BUG: Specifying an extension version or range of versions results in an + integer divide by zero. This is a bug for which there is no + around. + +STATUS: Fixed for the next release. + +NUMBER: 566 +MODULE: display +SYSTEM: V2.12.4/V2.14 +DATE: Tue Aug 26 17:10:07 MST 2008 +FROM: valdes + +BUG: The "ocolors" parameter was being used in place of the "bpcolors" + parameter. There is no workaround. + +STATUS: Fixed for the next release. + +NUMBER: 567 +MODULE: apall, apedit +SYSTEM: V2.11-V2.14.1 +DATE: Tue Oct 7 10:53:14 MST 2008 +FROM: valdes + +BUG: The :parameters and :apertures commands cause the task to exit with + an error that parameter "apertures" isn't found. This problem has + existed for a long time due to a missing parameter in the hidden + parameter sets. + +STATUS: Fixed for the next release. + +NUMBER: 568 +MODULE: imcombine +SYSTEM: -V2.14.1 +DATE: Tue Oct 7 12:52:35 MST 2008 +FROM: valdes + +BUG: When using avsigclip, ccdclip, or sigclip rejection around the + median (mclip=yes) the resulting final median may be incorrect. + This will generally only occur if unusually small low sigma values, + such as lsigma=1, are used. This was due to using a wrong + variable. + +STATUS: This is fixed for the next release. + + +NUMBER: 569 +MODULE: cosmicrays +SYSTEM: -V2.14.1 +DATE: Mon Oct 13 10:33:15 MST 2008 +FROM: valdes + +BUG: The message + + ERROR: PLIO: reference out of bounds on mask + + occurs when the image is not 2D. This can be a conceptual problem + for data which define a higher dimensionality but with length of 1; + e.g. [2048,2048,1]. This is effectively a 2D image but some + IRAF tasks designed for 2D images can have problems with this. + + The workaround is simply to use a 2D image section: + + cosmicrays image[*,*,1] + + Of course one can also convert the image to 2D with imcopy or imslice. + +STATUS: No updates are currently planned and users should use the workarounds + noted above. + +NUMBER: 570 +MODULE: imexpr, mskexpr, or tasks other asks using the expression evaluator +SYSTEM: -V2.14.1 +DATE: Mon Nov 3 22:16:41 MST 2008 +FROM: valdes + +BUG: Use of the built-in functions mod, min, max, and median produce an + "incompatible types" error even though the types of the arguments are + correct. This is a due to a coding error. There is no workaround + other than using alternative ways to express the desired + expression. + +STATUS: Fixed for the next release. + +NUMBER: 571 +MODULE: IMAGES.IMUTIL.HSELECT +SYSTEM: V2.14 +DATE: Fri Jan 2 21:41:53 MST 2009 +FROM: fitz + +BUG: The use of a '$' in a field name was causing the 'missing' value + to always be printed even if the field exists in the image. This + was caused by a failure to check for the character and removing it + prior to getting the value from the header. There is no workaround, + the code change is trivial. + +STATUS: Fixed for the next release. + +NUMBER: 572 +MODULE: dotasks +SYSTEM: -V2.14 +DATE: Tue Apr 28 11:19:41 MST 2009 +FROM: valdes + +BUG: It is likely that the DO tasks (e.g. doslit) will not work correctly + if the input image names have a path. This is because + internal database filenames are derived from the image names. + The recommended action is to work in the data directory. + +STATUS: Work on these and related tasks is currently frozen and since + there is a basic workaround (working in the data directory) + nothing may be done for some time. + +NUMBER: 573 +MODULE: mscimage +SYSTEM: - V4.9 August, 2008 +DATE: Fri Sep 18 08:36:30 MST 2009 +FROM: valdes (discovered and diagosed by Thomas de Boer) + +BUG: The task ignores the parameters "boundary" and "blank" which are + fixed to be "constant" and "0." respectively. + +STATUS: This is fixed for the next release. + +NUMBER: 574 +MODULE: daophot.psf +SYSTEM: -V2.14 +DATE: Tue Apr 13 22:01:52 MST 2010 +FROM: fitz + +BUG: The ":function" command was not properly saving the new function + when refitting is done with the 'f' keystroke. This is because the + fitting function reinitializes the parameters to the startup + values without first saving the modified function. + +STATUS: Fixed for the next release + +NUMBER: 575 +MODULE: all tasks using the icfit tools +SYSTEM: - V2.14 +DATE: Mon Jun 28 14:08:48 MST 2010 +FROM: valdes + +BUG: The icfit tools are used in many tasks involving 1D function fitting. + These include onedspec tasks like continuum and identify. The + tools provide for a grow radius where any sigma rejected points + have neighbors also rejected. The logic was wrong + in two ways; one where if a neighbor was also a rejected point + it did not also reject neighbors of that point, and another where + the grow radius units were used both as in pixels and in user + coordinates. In reality the grow is supposed to be in user + coordinate units. In addition some tasks, like continuum, incorrectly + described the units adding to the confusion. + +STATUS: Fixed for the next IRAF release. + +NUMBER: 576 +MODULE: imcombine +SYSTEM: V2.14 +DATE: Wed Nov 17 15:20:16 MST 2010 +FROM: valdes + +BUG: The addition of the image names using imcmb="$I" does not work for + input images with a square bracket; e.g. foo[1], foo[im1], foo[*,*]. + The IMCMB value, in order to allow long filenames, is stripped of + any path. For an obscure reason related to VMS directories this + code failed to find a rootname. + +STATUS: This has been fixed for the next release. + +NUMBER: 577 +MODULE: dohydra, dofibers, doargus, do3fiber +SYSTEM: -V2.15.1 +DATE: Fri Feb 11 12:30:46 MST 2011 +FROM: valdes + +BUG: The tasks will shorten root input image names to six characters by + using the first five and last characters. Depending on the style + of image names this can result in name conflicts. The reason for + this shortening is no longer known so it is now considered a bug. + Workarounds are to be aware of this and rename image names to avoid + conflicts. + +STATUS: This is fixed in the next release. The fix is to modify the file + $iraf/noao/imred/src/fibers/proc.cl as shown (replace lines 125 to + 129 with "extn = extn // ".ms"). If you don't have permission + to make this change then copy the file to your iraf "home$" + directory, edit it, load the desired package, and then override + the definition of the file with "redefine proc = home$proc.cl". + + 125,129c125 + < i = strlen (extn) + < if (i < 7) + < extn = extn // ".ms" + < else + < extn = substr (extn, 1, 5) // substr (extn, i, i) // ".ms" + --- + > extn = extn // ".ms" + + +NUMBER: 578 +MODULE: splot, scombine, fxcor, identify tasks, dispcor, disptrans +SYSTEM: v2.15-V2.15.1a (64-bit platforms only) +DATE: Tue Mar 8 21:57:38 MST 2011 +FROM: fitz + +BUG: The 64-bit port changes to smw.h improperly added a P2R() macro to + the APLOW/APHIGH macro declarations. This was causing tasks with + 2-D data to make an out-of-bounds request for data and leading to + and error message such as + + ERROR: Pixel subscript out of bounds (spec.fits) + + Normal onedspec data or use on 32-bit platforms is not affected. + +STATUS: Fixed for the next release. A re-application of the v2.15.1a patch + file will replace the affected binaries on 'linux64' and 'macintel' + platforms. + + +NUMBER: 579 +MODULE: onedspec.specplot +SYSTEM: V2.15 +DATE: Thu Mar 31 10:41:56 MST 2011 +FROM: fitz + +BUG: SPECPLOT can sometimes throw a segmentation violation or not + recognize valid input spectra due to an incorrect macro definition + on 64-bit platforms (linux64 and macintel only). + +STATUS: This has been fixed for the next release. Patched x_onedspec.e + binaries can be installed from + + ftp://iraf.noao.edu/iraf/v215/support/<arch>/x_onedspec.e + + where the <arch> is either 'linux64' or 'macintel'. + + +NUMBER: 580 +MODULE: imcombine and variants +SYSTEM: -V2.15.1 +DATE: Fri Apr 1 10:53:41 MST 2011 +FROM: valdes + +BUG: When the grow options is used with masks or partially overlapping + data a segmentation could occur. This is because when data is + absent (because of non-overlap) or excluded (because of mask) an + identifier value was not initialized. The only workaround is to + not use the grow options. + +STATUS: Fixed for future patches and releases. + +NUMBER: 581 +MODULE: splot +SYSTEM: V2.15- +DATE: Mon Jun 6 17:21:27 MST 2011 +FROM: valdes + +BUG: When using the deblending options a memory free error occurs with + 64-bit versions. This is caused by allocating an integer array and + freeing it as a real array. + +STATUS: Fixed in future patches and releases. +NUMBER: 582 +MODULE: utilities.curfit +SYSTEM: -V2.15.1 +DATE: Fri Jul 29 12:40:08 MST 2011 +FROM: valdes + +BUG: For input data with two or more values having the same x value + there is an arithmetic exception when setting the niterate parameter + greater than zero during interactive fitting. This occurs because + a check for the distance between two points for the purpose of the + grow option divides by the distance. This is done even if no growing + is requested (grow=0). The workaround is to edit the input so that + the values are not exactly the same. + +STATUS: This condition has been eliminated for the next release. + +NUMBER: 583 +MODULE: apall, +SYSTEM: V2.15 +DATE: Mon Mar 5 08:51:03 MST 2012 +FROM: valdes + +BUG: The optimal extraction for significantly tilted spectra, the Marsh + algorithm, has bug which manifests only under 64-bit architectures. + The symptom is a crash, usually a memory or segmentation panic. + The only workarounds are 1) go to an 32-bit system or 2) don't + use the optimal extraction option. + +STATUS: Fixed for V2.16. + + +NUMBER: 584 +MODULE: cosmicrays +SYSTEM: -V2.16 +DATE: Thu Aug 2 14:55:18 MST 2012 +FROM: iraf + +BUG: A pointer to a an array of pointers was used in one place as a real. + This is an error (e.g. segmentation error) when integer and real + arrays are not of the same size; i.e. on 64-bit architectures. + There is no workaround other than using a 32-bit architecture. + +STATUS: Fixed in future updated. + +NUMBER: 585 +MODULE: mscred.mscfinder.msctpeak, nfextern.msctools.mscfinder.msctpeak +SYSTEM: V2.16 +DATE: Wed Aug 8 19:26:21 MST 2012 +FROM: valdes + +BUG: The IRAF system core version of the tables library now used changed + in its default behavior when creating and reading tables without + an explicit extension. This results in the error: + + ERROR: Table `/tmp/iraf?????' does not exist or cannot be opened. + + This requires a change to the script to use an explicit extension. + A workaround is possible by editing the script but it is recommended + that you just update the appropriate external package. + +STATUS: Fixed in the latest version of the packages. + +NUMBER: 586 +MODULE: apsum/apall +SYSTEM: V2.16 +DATE: Tue Mar 12 12:55:34 MST 2013 +FROM: valdes + +BUG: When cleaning or weighting and an aperture runs off the edge of the + there was a bug that could allow referencing outside of the image + data array. The value would then be arbitrary which could produce + errors such as floating or arithmetic exceptions. The workaround + is to eliminate apertures that go off the edge. + +STATUS: Fixed for the next release. |