# 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.