# 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 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 where 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 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 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 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 cd2_2,cdelt2 1000 update+ cl> hedit 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 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 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 "!" 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 wtkeyword yes > wts on> scombine weight="@wts" where 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 wcsdim 3 cl> hedit cd3_3 1. cl> hedit 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 " 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 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 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 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 (.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 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- or saturation/ 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+, or mean*. 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 (.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 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: 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.