# BUGS.V25 -- Known bugs in the frozen IRAF Version 2.5. (start 7 July 1987)
#
# 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: 1
MODULE: images.imheader
SYSTEM: V2.5, V2.4, V2.3
DATE: Wed Jul 8 21:10:54 MST 1987
FROM: tody
BUG: When listing the header of an image where the pixel file has been
created in the same directory as the header file using the imdir=HDR$
syntax, the pixel file status is always given as [NO PIXEL FILE]
regardless of whether or not the pixel file exists. This is of course
due to the HDR$, which is a special syntax significant only to IMIO
and which does not correspond to an actual FIO logical directory.
STATUS: This has been known about for some time, but is not serious and was
overlooked in preparing V2.5. The workaround for the moment is to
simply list the directory containing the image header file. If there
is a pixel file (extension .pix, same root name as the header file)
it will appear in the directory listing.
NUMBER: 2
MODULE: system.deallocate
SYSTEM: V2.5 Ultrix/IRAF
DATE: Fri Jul 10 13:21:01 MST 1987
FROM: rooke
BUG: In Ultrix/IRAF, if a TK50 tape cartridge on a MicroVAX is physically
removed from the tape drive before executing DEALLOCATE, and one
subsequently attempts to execute DEALLOCATE, either from the same or
another process, that process hangs and has to be killed from outside.
STATUS: To be investigated when time permits.
NUMBER: 3
MODULE: cl
SYSTEM: V2.5
DATE: Fri Jul 31 14:53:14 MST 1987
FROM: tody
BUG: This bug affects CL SCRIPTS which access the CL global parameters
i,j,k, x,y,z, etc. The bug is more likely to occur the shorter the
parameter name. The bug occurs when the CL searches for a parameter
specified using the simple form of the parmeter name "param" rather
than "task.param". When a parameter name is specified in this way,
and the named parameter is not defined locally to the task being
executed, then the CL must search all pfiles in the search path for
the named parameter.
The problem would occur when the parameter name given was an
abbreviation for one or more of the local parameters of the task.
If the parameter name was an ambiguous abbreviation the task would
abort with the misleading error
ERROR: task `' has no param file
If the parameter name given was an unambiguous abbreviation then
the LOCAL parameter would be referenced rather than the global CL
parameter, which is probably not what was intended.
For example, if the task had a local parameter "xmin", the assignment
statement "x = 1" would assign 1 to "xmin". If the task had a second
local parameter "xmax", the same assignment statement would result in
the above error message.
STATUS: The bug has been fixed in V2.6. The workaround for older versions of
the CL is to define all local variables locally (this is more sensible
and more efficient in any case), and always spell out parameter names
fully. When referencing a parameter belonging to another task, use the
unambiguous form of the parameter name, i.e., "task.param".
NUMBER: 4
MODULE: onedspec - combine, dispcor, rebin
SYSTEM: V2.2 - V2.5
DATE: Wed Aug 5 15:11:39 MST 1987
FROM: valdes
BUG: The specific bug leading to the change was when combining three
spectra with identical wavelength scales but with some spectra
having zero values to indicate missing data the zero value data
was not ignored in the average as intended. This occured because
of two factors. First, COMBINE always rebins the data even if
all the wavelength scales are the same. In this process the
output grid was very slightly different from the input grid
due to truncation errors. This allowed the interpolation to
pull the point with zero value next to a valid nonzero value
pixel slightly away from zero. When combining only points
which are exactly zero are ignored. Thus, the combined
point with input values of 9, 9, and 0 had rebinned values of
9, 9, and 0.0001 and an averaged value of 6 instead of 9.
STATUS: The fundamental problem is failure to properly propagate the
missing data value during rebinning. This problem should be
thought out careful in a revision of the ONEDSPEC package. The
immediate fix made was to 1) ignore the interpolation
if the output rebinning grid is close to the input grid (within
0.001 pixels) and 2) to set any interpolated point which uses
a missing data point (0 value) to 0. These changes mainly are
for COMBINE but it also affects DISPCOR and REBIN which use the
same rebinning routine. This problem probably occurs very
infrequently but those without this fix should be aware of this
effect.
NUMBER: 5
MODULE: onedspec.splot
SYSTEM: V2.5, V2.4, V2.3, V2.2
DATE: Thu Aug 6 17:14:25 MST 1987
FROM: valdes
BUG: In function mode when applying a second spectrum, for example
adding a second spectrum, which doesn't exist there is no error
message and the plot is redrawn as if the operation had been performed.
STATUS: This has been fixed to report the error and not redraw the plot.
For systems without this fix the only remedy is to be alert and note
whether the operation has changed the original spectrum.
NUMBER: 6
MODULE: dataio.reblock
SYSTEM: V2.5
DATE: Wed Aug 12 13:52:09 MST 1987
FROM: davis
BUG: The reblock task was not adding the offset parameter to the physical
tape number before creating the output file name.
STATUS: The problem was that the reblock task was not querying for the offset
parameter which was by default being set to zero. This bug has been
fixed and the help page updated.
NUMBER: 7
MODULE: CL
SYSTEM: V2.5
DATE: Mon Aug 17 09:01:23 MST 1987
FROM: valdes
BUG: Foreign tasks are supposed to participate in I/O redirections just
like regular IRAF tasks. However, appending the output of a foreign
task to a file (i.e. >>file) does not append but instead overwrites
the file without any warning or error message.
STATUS: [placed on TODO list (DCT)].
NUMBER: 8
MODULE: CL, noao.imred.generic.darksub
SYSTEM: V2.5
DATE: Thu Aug 20 11:05:33 MST 1987
FROM: valdes
BUG: Tasks which write values to their parameter files do not do so when
run in the background. This means that scripts which rely on this
feature will fail, or worse yet, give incorrect results! The
incorrect results occur because the value in the parameter file
is not that put by the task when run in the background script but
that put the last time the script or task ran in the foreground.
This problem arises in the task imred.generic.darksub which uses
the task images.imgets to get a image header parameter for the
exposure time of the dark count image.
THE TASK DARKSUB WILL POSSIBLY GIVE INCORRECT RESULTS IF RUN IN THE
BACKGROUND!
STATUS: This property of background jobs in the CL has not been dealt with yet.
[The solution is not so simple as merely updating the pfile as if the
task were run in the foreground, as this could cause subtle runtime
context dependent errors in concurrent jobs which attempt to access
the same pfile (DCT)]. Scripts which use images.imgets to get header
parameters and images.sections to get the number of files or images
in a template will work only in the foreground. The DARKSUB task has
been rewritten in V2.6 to avoid this problem; a bugfix is available
for the V2.5 release via the IRAF Hotline, if desired.
NUMBER: 9
MODULE: register, geotran
SYSTEM: V2.5
DATE: Thu Sep 3 10:08:24 MST 1987
FROM: davis
BUG: The register and geotran tasks can sometimes produce output images
which have the correct geometric transformation but fluxes which
are the negative of the original image. Two conditions are necessary
to produce this result: 1) the transformation is of a higher order
than a simple translation, rotation, magnification and axis flip and
2) one of the axes has been flipped. The flux correction is computed
by calculating the Jacobian of the coordinate transformation. When
an axis flip occurs this coordinate surface turns upside down
producing a negative Jacobian.
STATUS: The appropriate absolute value statements have been added to the code.
A temporary solution to the problem is to multiply the output image
by -1 as the absolute values of the output fluxes are correct.
NUMBER: 10
MODULE: longslit.extinction
SYSTEM: V2.5
DATE: Mon Sep 14 09:49:56 MST 1987
FROM: valdes
BUG: Due to an oversight and infrequent use of this task, debugging output
consisting of a list of numbers relating to the extinction function
was not removed and appears when users run this task.
STATUS: The debugging statement has been removed. As a workaround users
may discard all output (since this task does not produce any normal
output to the terminal) as follows:
cl> extinction images >& dev$null
The output is on the standard error stream (STDERR) so the '&'
is required.
NUMBER: 11
MODULE: apextract.apnormalize
SYSTEM: V2.5
DATE: Tue Sep 22 16:51:19 MST 1987
FROM: valdes
BUG: For reasons of memory managment the task APNORMALIZE breaks
up its work into groups of apertures. The number of apertures
is a defined constant in the source and is set to 20. The
bug occurs when there are more than this number of apertures.
The task first sets all output pixels to unity and then fills in
the normalized apertures. This makes all points outside the
apertures have a value of 1. The bug arises because it does
this for each set of apertures rather than only once. The
effect is then to output an image with only the last set
of apertures. For example with 28 apertures only the last
eight will have the normalized aperture data.
STATUS: The reported bug is now fixed by only setting the points
outside the apertures to 1 once. The work around is to do the
the normalization in groups of 20 (there are no problems if
there are 20 or less apertures). The resulting flat field
images may then be multiplied together (since the missing
apertures are set to 1) or applied to the data to be flattened
successively. If this is a serious problem contact us for a
bug fix.
NUMBER: 12
MODULE: apextract.apnormalize
SYSTEM: V2.5
DATE: Tue Sep 22 16:53:05 MST 1987
FROM: valdes
BUG: APNORMALIZE does not work when DISPAXIS=1. Since it is rare to
have this orientation the task was never tested with this dispersion
axis.
STATUS: It has been fixed. The work around is to transpose the flat
field data, normalize, and transpose the normalized flat field.
You must also change or set DISPAXIS whenever you transpose an
image.
NUMBER: 13
MODULE: ki_gnode
SYSTEM: V2.5, V2.3
DATE: Wed Sep 30 16:55:27 MST 1987
FROM: rooke
BUG: In the Kernel Interface, code in ki_gnode() checks to see if
a requested node is the same as the local node. However, it
does so by comparing the first n chars of the requested node
against those of the local node (strncmp()). If both nodes
have the same first n chars, but differ beyond that, ki_gnode
thinks it is on the local node. (UCSD, nodes "cass05" and "cass").
STATUS: The workaround is to simply use a different node name (alias) until
the bug is fixed.
NUMBER: 14
MODULE: sgi2vqms
SYSTEM: V2.5
DATE: Mon Oct 12 14:01:11 MST 1987
FROM: sjacoby
BUG: Line 230 of the source file $iraf/vms/gdev/sgidev/sgi2vqms.f is
missing the character 'x'. As a result, the x coordinate of an
SGI_MOVE instruction is not being output. This character must
have been accidentally deleted by someone browsing through the file.
Any VMS site with a QMS will be affected; all such sites will recompile
the executable because we don't supply it on our distribution tapes.
A second bug in the translator, reported earlier today by Zoltan Levay,
is also being investigated. He reports the Y window limits supplied by
dev$graphcap are not being used in the translator.
STATUS: The workaround for the first problem is to add the missing character
to line 230 and recompile. The second problem is still under
investigation. The best solution is to obtain the latest version of
this source file from us before setting up the SGI/QMS interface.
NUMBER: 15
MODULE: onedspec: dispcor, combine, rebin
SYSTEM: V2.5
DATE: Fri Oct 16 16:54:28 MST 1987
FROM: valdes
BUG: The reported bug was that applying DISPCOR to spectra which ran
from red to blue using SPLINE3 interpolation produced a spectrum
of all zeros. Further investigation showed that anything which
which rebinned spectra with the wavlength sense reversed using
either the SUMS or SPLINE3 interpolation mode had the same
effect. This includes DISPCOR, REBIN, and COMBINE. An additional
bug was that SPLINE3 interpolation was mapped into SUMS mode
so that SPLINE3 interpolation was never possible.
There were two errors involved:
1. SPLINE3 interpolation mode was mapped into SUMS mode.
2. SUMS mode only worked when the rebinning was in the same
wavelength sense as the data. Otherwise an all zero
spectrum was produced.
STATUS: These bugs have been fixed on V2.6. This code badly needs to be
rewritten.
1. The work around is to rebin or dispersion correct in the
same sense as the data and later flip the spectrum if needed.
Note that DISPCOR defaults to wavelength increasing when the
original spectra has wavelength decreasing with pixel. In this
case the user must explicitly reverse the default starting
wavelength and change the sign of the wavelength per pixel.
Automatic mode will fail since it uses the defaults.
2. Users using SPLINE3 interpolation must be aware that actually
SUMS mode interpolation is used. Some users may be unaware
of this since the data is still correct.
NUMBER: 16
MODULE: onedspec.splot
SYSTEM: V2.5
DATE: Thu Oct 22 19:03:00 MST 1987
FROM: valdes
BUG: Deblending in SPLOT is unstable when the data is in FNU and
FLAMBDA units. In fact, a user demonstrated that it crashes
almost every time on VMS with either divide by zero or floating
overflows. It was also found that the 'e' key was not returning
a center. The results of deblending are not consistent and depend
on the prior deblending history; it is recommended in the
documenation that one start by fitting an isolated line to get
a first guess at the width of the lines.
STATUS: These problems are due to the very small numbers when spectra are
in FLAMBDA (~10E-14) and FNU (~10E-27). In this regime it is very
important to be careful with powers and operations which may
underflow.
A workaround in V2.5 is to multiply the spectrum either externally or
with the SPLOT arithmetic function to values near unity.
These bugs were fixed in the development V2.6. The input to
the complex, imported Fortran math routine used for the
deblending is now first scaled to a maximum value of 1. For
the 'e' equivalent width the same scaling is done when
computing the sum of values to the 1.5 power for determining
the centroid of the marked region. I also made the deblending
more consistent by iterating the fit three times; it is no
longer necessary to fit an unblended line first. This can be
done manually by the user as a workaround in V2.5 to achieve
the same result.
The long term solution requires more careful consideration of
intensity units in all the ONEDSPEC tasks (such as by keeping a
scale factor in the header and leaving the pixel values near
unity) plus a more careful study of deblending routines (the
current one is considered a prototype).
NUMBER: 17
MODULE: images.imsurfit
SYSTEM: V2.5
DATE: Mon Nov 2 13:48:52 MST 1987
FROM: davis
BUG: A bug exists in the regions fitting code of the task IMSURFIT.
If the user sets the regions parameter to "sections" and specifies
sections which overlap the program will crash with a segmentation
violation. The modified ranges package used by IMSURFIT was not
handling the overlap condition correctly and sometimes computed
a number of points to be added to the fit that was incorrect.
STATUS: This bug has been fixed in Version 2.6. Version 2.5 users should be
careful when specifying the regions to be fit that the columns and
rows do not overlap.
NUMBER: 18
MODULE: longslit.fluxcalib
SYSTEM: V2.5 & V2.3
DATE: Thu Nov 5 18:16:27 MST 1987
FROM: valdes
BUG: FLUXCALIB behaves incorrectly when the input and output images
are the same; i.e. in place correction. A error message about
a bad file descriptor is given and the task aborts. However,
the image has been correctly calibrated! Multiple images are
not done because the error terminates the task after the first
image is calibrated.
STATUS: The error occurs when an attempt is made to close the nonexistent
second image though the input image has been corrected in place.
This error is not trapped and terminates the task. For one image
at a time simply ignore the error. For multiple images you
must either do them one at a time or generate new output images.
It is a little surprising that this bug has never been reported
since it has been present since the task was written two years ago.
I apparently never tested this feature myself. People must rarely
flux calibrate 2D images and when they do they are cautious and
create new calibrated images. This bug has been fixed in V2.6.
NUMBER: 19
MODULE: astutil.galactic
SYSTEM: V2.5 & V2.3
DATE: Fri Nov 6 16:15:13 MST 1987
FROM: valdes
BUG: The task GALACTIC prints incorrect galactic coordinates on
SUN/IRAF (probably also AOS/IRAF).
STATUS: The galactic coordinates are computed in double precision. The
bug occurs because it is printed assuming it is single
precision; PARGR instead of PARGD. This does not affect the
answers on VAXs but it does on the SUNs and others with the
same byte order. There is no work around but the code fix is
trivial for those able to edit and recompile the procedure.
Contact us for details.
NUMBER: 20
MODULE: dataio$rfits
SYSTEM: V2.5
DATE: Sun Nov 8 12:25:30 MST 1987
FROM: davis
BUG: A serious bug in the way that rfits handles negative declinations
was found by the MIT site when trying to read their CTIO tapes.
Decs of the form -20:35:46 were being transformed to -20:05:06.
The reason for this problem is historical. First it should be
noted that NOAO does not follow the FITS standard in encoding
RAs and DECs on the mountain. These number should technically
be encoded as floating point numbers but for obvious reasons
astronomers are not enthousiastic about seeing dec = -23.6281
etc. The way IRAF distinguishes between legal and NOAO decs
is to search for the presence of the colon character. In
addition at some time not far back the mountain was producing
things like dec= -20: 3:5 and even -20:-3:-5. which other
iraf programs were not able to interpret or modify. RFITS
tried to clean up these old formats. Apparently NOAO mountain
formats have been fixed and IRAF RFITS did not handle the fix
correctly.
STATUS: The problem has been fixed in version 2.6. There is no work
around at present. Users should compare the output of rfits
with the make_image parameter turned off to the results of
actually reading in the data. The results in the header listing
which do not alter the data should be correct. If this problem
seriously affects their data reduction then contact the IRAF
group on how to get the fix installed.
NUMBER: 21
MODULE: apextract.apsum, apextract.apstrip
SYSTEM: V2.5
DATE: Mon Nov 9 08:55:17 MST 1987
FROM: valdes
BUG: The variance weighted extraction assumes variances of the
form
V = V0 + V1 * (S + B)
where S are the counts due to the spectrum and B are the counts of
the background. For very weak spectra with negligible background
(such as when the detector sensitivity is very low) it is possible
that the variance approaches zero or becomes negative; especially
if the zero level variance or readout noise is small or zero such
as in photon counting detectors. Since the weights are the
inverse of the variance this may result in spikes in the extracted
spectrum.
STATUS: There is no workaround other than to ignore the extracted data
that is nearly nonexistant. The fix is to replace the variance
formula by a suitable positive definite quantity. My solution
is:
1. If V0 is 0 (such as with photon counting detectors)
V = V1 * max (1, S + B))
2. If V0 is not 0
V = V0 + V1 * max (0, S + B)
where max is the maximum function. Thus, if V0=0 then the
minimum variance is V1 and otherwise the minimum variance is
V0. Case 2 makes no assumptions about the data while case 1
assumes that the spectra is actually in counts and has not been
normalized in such a way as to have significant intensity
values less than 1. If you wish to change the source code and
recompile contact us for details.
NUMBER: 22
MODULE: apextract.apsum
SYSTEM: V2.5
DATE: Mon Nov 9 17:15:18 MST 1987
FROM: valdes
BUG: When running APSUM the incorrect error message "apio package not found"
is printed when the dispersion axis has not been set. Continuing with
a list of images causes other problems.
STATUS: This bug is the result of not having the dispersion axis set. Since
the message is incorrect one must be aware that this message means
you have forgotten to run SETDISP to set the dispersion axis.
The source of this bug is that the task is failing to take appropriate
action when it finds the dispersion axis parameter is missing
and actually triggers another more fatal error. This screws up the
error reporting and causes further errors when processing a list of
images. This has been fixed so that the error is caught and the task
gracefully reports the correct error.
NUMBER: 23
MODULE: imdelete
SYSTEM: V2.5
DATE: Fri Nov 13 08:59:58 MST 1987
FROM: davis
BUG: The imdelete task crashes the CL on Lyra in the following situtation:
a set of images out10a.imh, out10b.imh, ... exists on disk
an erroneous image template of the form out10[a-g].imh is
given to the imdelete task and the verify switch is set to yes.
STATUS: This bug was traced to the VOS routine imio.imaccess which is called
to see if the named image exists before attempting to delete it.
The workaround is to avoid the use of the erroneous image template
when calling tasks such as IMDELETE. Like all tasks which process
a list of images, IMDELETE uses the image template facilities to
specify the list of images to be deleted. Character classes such as
[a-g] are not supported in image templates since the [] are reserved
for image sections. The syntax "out10![a-g]" is a valid way to
specify a character class in an image template. (dct)
NUMBER: 24
MODULE: imlintran
SYSTEM: V2.5
DATE: Wed Nov 25 11:18:33 MST 1987
FROM: davis
BUG: A bug was found in the boundary extension = wrap option of the
IMLINTRAN task. The task was computing very large pixels values
for the output image which then caused subsequent tasks such
as imstat to fail. Out of bounds pixel values in the range
0.0 < x < 1.0, ncols < x < ncols + 1.0, 0.0 < y < 1.0 and
nlines < y < nlines + 1.0 were falling off the ends of the
interpolation array producing erroneous output values.
STATUS: The problem has been fixed for version 2.6. For the time being
users should avoid the boundary = wrap extension. Note
that the tasks ROTATE, REGISTER and GEOTRAN are also affected
by this bug as they all use the same code.
NUMBER: 25
MODULE: rfits
SYSTEM: V2.5
DATE: Fri Dec 11 09:13:31 MST 1987
FROM: davis
BUG: A bug was found in the rfits disk file list handling code. If the
user successfully read a single disk file, for example fitsdat,
and then tried to execute rfits with a file name template which
did not match any disk files the program would try to reread
fitsdat.
STATUS: The problem arose because the program was not checking correctly
for a zero length file list in the case of disk files. The bug
has been fixed in Version 2.6.
NUMBER: 26
MODULE: mtlocal.rcamera
SYSTEM: V2.5
DATE: Thu Dec 17 15:28:41 MST 1987
FROM: davis
BUG: Rcamera was giving bus errors when run on our Sun 4 machine. The
problem was traced the routine bitpak being called with a short
integer argument when it was expecting an integer argument.
STATUS: The bug has been fixed and the Lyra version has been updated.
NUMBER: 27
MODULE: dataio.t2d
SYSTEM: V2.5
DATE: Thu Dec 17 16:14:00 MST 1987
FROM: lytle
BUG: T2D has a bug in the code for interpreting the input file name.
If the user enters an input name of the form `mta[7]' the program
would die with a `segmentation violation' message.
STATUS: This has ben corrected in V2.6. The workaround is never to use
this form of input filename, the user can just enter `mta' for
the input name and then enter `7' when asked for the list of files.
NUMBER: 28
MODULE: all iraf tasks (networking bug)
SYSTEM: V2.5 UNIX/IRAF, V2.5-V2.6 Sun/IRAF and Ultrix/IRAF
DATE: Sat Dec 19 15:59:03 MST 1987
FROM: tody
BUG: A bug in the network driver for UNIX/IRAF was causing a host file
descriptor to be opened on every call but never used nor closed.
This could eventually cause the client process to run out of file
descriptors.
STATUS: The bug is harmless unless the process runs out of file descriptors.
This is unlikely since once a server node is connected to a process
it tends to stay connected for the lifetime of the process, and a
client process is unlikely to connect to very many server nodes.
Nonetheless we found one case where the bug was serious. On our
diskless Sun nodes, images were being read from tape to disk on the
server node and then accessed from a diskless client node. The user
did not have a .irafhosts file, hence every image access would result
in a failed attempt to connect to the remote node, consuming a file
descriptor in each attempt. The workaround is to minimize network
connections, e.g., by using a valid .irafhosts file, or by reading
the images to disk on the client node.
The bug is fixed in V2.6 UNIX/IRAF. In addition, the network driver
and default host login file dev$hostlogin were modified to make it
unnecessary for the user to have a .irafhosts file.
NUMBER: 29
MODULE: all image tasks involving image rename or in-place image operations
SYSTEM: V2.5
DATE: Sat Dec 19 17:39:27 MST 1987
FROM: tody
BUG: The imio.imrename image renaming operator was not working properly
for OIF format images (the default) when renaming an image to a new
directory and the imdir=HDR$ option is in effect (pixel file stored
in header file directory or subdirectory). This would affect not only
obvious image rename operations such as the IMRENAME task, but also
most in-place image operations when run on an image not in the current
directory while imdir=HDR$ is in effect, since such in-place operations
are implemented by creating a temporary output image in the current
directory and then renaming it to replace the old image upon successful
completion of the operation.
STATUS: The workaround is to avoid in-place operations on images not in the
current directory, and avoid using IMRENAME to move OIF format images
to a new directory. An installable bug fix is available from IRAF
site support if desired (update file imio$iki/oif/oifrename.x).
NUMBER: 30
MODULE: imfort.imps3r
SYSTEM: V2.5
DATE: Sun Dec 20 11:57:39 MST 1987
FROM: tody
BUG: This IMFORT routine will appear to work but does not output the data
properly. The line pointer into the input buffer was being incremented
in the K loop (outer loop over Z) rather than the J loop (inner loop
over Y), causing each input line to be replicated to fill each output
band.
STATUS: Fixed in V2.6. Do not use this routine to output a section for which
J2-J1 > 1 (Y-size of section greater than one line) or it will fail.
The best workaround is to avoid use of the routine entirely. None of
the other routines, e.g, imps3s, imgs3r, etc., contain the bug (all
were checked).
NUMBER: 31
MODULE: KI (iraf networking)
SYSTEM: V2.5
DATE: Mon Dec 21 22:52:02 MST 1987
FROM: tody
BUG: If 20 or more nodes are entered in to the network table dev$hosts,
and iraf networking is enabled (the table contains an alias matching
the name of the local node), the network tables are corrupted during
process startup, and no IRAF process can be started, preventing even
logging into the CL!
STATUS: As far as I know, NOAO is the first site to enounter this bug, since
[1] few sites use the iraf networking facilties presently, and [2] few
sites have more than 20 nodes in the local network. Sites with V2.5
which wish to use the IRAF networking facilities should not place the
names of more than 19 nodes in the dev$hosts file. The bugs are fixed
in V2.6, and the default size of the network tables are increased to
a maximum of 64 nodes.
NUMBER: 32
MODULE: mtlocal.widstape
SYSTEM: V2.5
DATE: Tue Dec 22 14:47:43 MST 1987
FROM: sjacoby
BUG: Task widstape (in the x_onedutil.e executable but mtlocal package)
writes incorrect data values to the output file on non byte swapped
machines such as a Sun. The pixel array is passed to procedure
dtoc3 as type real, where dtoc3 expects a double precision input
argument.
STATUS: This has been fixed in version 2.6. There is no workaround;
contact us for the bug fix.
NUMBER: 33
MODULE: mtlocal.ridsout
SYSTEM: V2.5
DATE: Tue Dec 29 10:45:59 MST 1987
FROM: sjacoby
BUG: These two bugs exist in V2.5 of task ridsout: [1] The values of
airmass, starting lambda and delta lambda are written to stdout
during the execution of ridsout as single precision reals, not
double precision. [2] Negative pixels and the pixel that follows
them are not read correctly, as ridsout requires whitespace
separated fields, and the minus sign causes the fixed field width
to be completely filled.
STATUS: Both bugs have been repaired in V2.6. The workaround for [1] is
simply to ignore those three printed values when running ridsout.
The discrepancy is noticed only on non byte swapped machines, and
the values are written to the image header correctly. Use slist
or imhead to verify this. No workaround exists for [2]. Negative
pixels should be rare; contact us if you require the fix.
NUMBER: 34
MODULE: images.fit1d, generic.background, longslit.background
SYSTEM: V2.5
DATE: Mon Jan 4 10:26:01 MST 1988
FROM: valdes
BUG: When a nonexistent input images is specified (usually the result of
a typo in the input specification) the task hangs up instead of
reporting a warning about failure to find the requested image.
STATUS: This bug is caused by a missing error check on the procedure which
opens the images, which means the task continues as if the
image was successfully opened and leads to reported behavior. The
source code fix is to add an ERRCHK declaration. The work
around is to kill the task and fix the input image specification.
NUMBER: 35
MODULE: apextract.apsum
SYSTEM: V2.5
DATE: Tue Jan 5 11:05:52 MST 1988
FROM: valdes
BUG: 1. When extracting apertures which go off the edge using PROFILE
WEIGHTING the part of the extracted spectrum off the edge is garbage
rather than set to zero as intended.
2. When extracting apertures which go off the edge using PROFILE
WEIGHTING and BACKGROUND SUBTRACTION the task may crash if the
background regions also go entirely off the edge.
STATUS: 1. This is only an esthetic problem which has now been fixed to set the
extracted spectrum to zero when it is off the image. Just ignore the
meaningless part of the extracted spectrum.
2. There is no direct work-around for this problem other than to avoid
extracting spectra WITH BACKGROUND SUBTRACTION where the
background regions also go entirely off the edge. One
possiblity is to extract a background region as a separate
aperture and then subtract it later with IMARITH. The code fix
is simple; contact us if you really need this capability.
NUMBER: 36
MODULE: all tasks using floating point
SYSTEM: V2.5 Sun/IRAF
DATE: Tue Feb 2 14:59:30 MST 1988
FROM: tody
BUG: In V2.5 Sun/IRAF the default configuration of the IEEE hardware
floating point unit is used. A floating divide by zero, floating
overflow, etc., does NOT produce an exception, but instead produces
one of the special numbers NaN or Inf (not a number or infinity),
which do not behave like ordinary floating point numbers, and which
IRAF does not know how to deal with. In particular, if one attempts
to print the value of such a number, an infinite loop results. This
can occur when attempting to write an image to tape with WFITS, when
attempting to update the min and max pixel values in an image, and
in many other places where formatted output occurs. An easy way to
test if your system has this bug is to enter the following command:
cl> = 1.0 / 0.0
If this hangs in a loop, the bug is present in your system and tasks
may hang if they encounter data containing NaN or Inf values.
STATUS: Fixed in V2.6 Sun/IRAF (by enabling the divide by zero and other
exceptions in the hardware floating point unit). If an image is
somehow generated which contains NaN or Inf pixels, it may be possible
to use the REPLACE task to fix up the bad pixel values. Alternatively,
the data must be reprocessed in such a way that the bad pixels are not
generated, e.g., in a way which does not lead to a divide by zero.
NUMBER: 37
MODULE: proto.toonedspec
SYSTEM: V2.5
DATE: Fri Feb 12 17:03:09 MST 1988
FROM: valdes
BUG: When extracting spectra with no summing (i.e. one line or column at
a time) and when the last extracted line or column from one image is
the same and that of the first line or column of the next image
garbage results are obtained. The specific example was extracting
the first line from a set of 2D spectra.
STATUS: The bug only occurs under the conditions described above. The source
of the bug is that if the line or column is unchange from one call to
the next the task believed that the data it used the previous time
was still valid even though the data pointer had been freed and
and reallocated for the new image. This bug has been fixed as of
this date. The workaround is to flush the process between each image
or extract more than one line. For example if lines 1 and 2 are
extracted from image1 and image2 then the output sequence will be
image1.0001, image1.0002, image2.0001, image2.0002 and the line for
each extraction always differs from the previous extraction.
NUMBER: 38
MODULE: identify
SYSTEM: V2.5
DATE: Thu Feb 18 15:46:47 MST 1988
FROM: valdes
BUG: The 't' key fails on the SUNs.
STATUS: This bug has been present since IDENTIFY was converted to double
precision. This little used key was passing the cursor position
to a procedure as a real value when the procedure was expecting
a double value. This bug is benign on the VAXes but is, presumably,
also present on the MVs. There is no workaround though the code
fix is simple.
NUMBER: 39
MODULE: images.imsurfit
SYSTEM: V2.5
DATE: Mon Feb 29 10:19:04 MST 1988
FROM: davis
BUG: If the regions parameter has been set to any of "columns", "circle"
"border" or "sections" and the type type_output parameter is "residual"
"response", imsurfit may produce an erroneous output image.
The the imio input buffer was being altered if the
regions parameter was set to anything other than all or rows,
and was not being flushed when the input image was reread.
The problem would only occur for small images and depends on
the relationship between the size of the fileio buffers and
the image size and has been present since the task was
written.
STATUS: The bug has been fixed in version 2.6. The workaround is to always
compute the fit if the regions parameter is set to anything
but all or rows and use imarith to compute the residual, or
response images.
NUMBER: 40
MODULE: dtoi.hdtoi
SYSTEM: V2.5, Sun/IRAF V2.6
DATE: Thu Mar 10 14:21:32 MST 1988
FROM: sjacoby
BUG: An error exists in the equations used to generate the look up table
used in task hdtoi for the 'k75' and 'k50' transformations.
Incorrect:
ind_var[i] = density[i] * .50 * log10(1. - 10. ** (-density[i]))
ind_var[i] = density[i] * .75 * log10(1. - 10. ** (-density[i]))
Correct:
ind_var[i] = density[i] + .50 * log10(1. - 10. ** (-density[i]))
ind_var[i] = density[i] + .75 * log10(1. - 10. ** (-density[i]))
STATUS: The fix is to edit file hdtoi.x and replace the incorrect equations
(lines 319 and 323). Then type 'mkpkg update'. These transformation
types are accurately calculated in task hdfit; only task hdtoi shows
the error.
NUMBER: 41
MODULE: longslit.extinction
SYSTEM: V2.5 & V2.3
DATE: Thu Mar 24 09:06:53 MST 1988
FROM: valdes
BUG: EXTINCTION behaves incorrectly when the input and output images
are the same; i.e. in place correction. A error message about
a bad file descriptor is given and the task aborts. However,
the image has been correctly calibrated! Multiple images are
not done because the error terminates the task after the first
image is calibrated.
STATUS: The error occurs when an attempt is made to close the nonexistent
second image though the input image has been corrected in place.
This error is not trapped and terminates the task. For one image
at a time simply ignore the error. For multiple images you
must either do them one at a time or generate new output images.
It is a little surprising that this bug has never been reported
since it has been present since the task was written three years
ago. This bug has been fixed in V2.6. See also Bug #18.
NUMBER: 42
MODULE: geotran
SYSTEM: V2.5
DATE: Thu May 5 11:43:33 MST 1988
FROM: davis
BUG: A bug was found in the coordinate subsampling code in geotran. If
xsample or ysample were greater than 1 and the output image was
greater than nxblock and nyblock then the program would quit with
an access violation. The problem was that in the code revision
the calling sequence of the subroutine had been changed but the
arguments to the call had not. I also found and fixed another
bug in the coordinate subsampling code that had not so far been
reported.
STATUS: The bug has been fixed. The workaround is to leave xsample and
ysample = 1 and live with the increase in execution time for
high order distortion corrections.
NUMBER: 43
MODULE: CL
SYSTEM: V2.5, V2.6 Sun/IRAF
DATE: Mon May 16 13:58:08 MST 1988
FROM: tody
BUG: If one submits a background job from the CL running in a terminal
window under SunView, and then selects "Exit Suntools" in the root
menu with the foreground CL still running, the background CL job is
killed.
STATUS: The workaround is to logout of the foreground CL before exiting
suntools. The solution, implemented in versions 2.7 and greater,
is to put the background CL in its own process group (an even better
solution, not yet implemented, might be to open a new terminal window
for the background job to run in).
NUMBER: 44
MODULE: proto$bscale
SYSTEM: V2.6
DATE: Fri Jun 10 16:06:20 MST 1988
FROM: davis
BUG: The bscale task was going into an infinite loop during the mode
computation, if the computed sigma was less than or equal to zero.
This can occur can occur due to finite machine precision in the
situation where the rms is much less than the mean of the
distribution.
STATUS: A check for a negative or zero valued sigma has been added in V2.7.
NUMBER: 45
MODULE: images$minmax
SYSTEM: V2.5
DATE: Fri Jun 10 16:56:43 MST 1988
FROM: davis
BUG: Minmax was not printing the position of the minimum and maximum
pixel if the input image contained a section specification
and update was set to yes.
STATUS: This bug has been fixed in version 2.7. The work around is to
turn off the update switch since minmax will not allow the user
to update the image header based on image sections in any case.
NUMBER: 46
MODULE: blkavg
SYSTEM: V2.5
DATE: Wed Jul 13 15:34:53 MST 1988
FROM: davis
BUG: Blkavg would not work on 1D images. The header file was being created
correctly but no pixels were written to the pixel file. For 1D images
the number of output image lines was being incorrectly set to 0.
STATUS: The bug has been fixed. There is no direct workaround but users can
use proto.imstack to create an n by 1 image and run blkavg on that.
NUMBER: 47
MODULE: curfit
SYSTEM: V2.5
DATE: Thu Jul 14 10:51:30 MST 1988
FROM: davis
BUG: The errors of the computed coefficients returned by curfit were
incorrect when points were rejected from the fit by setting the
weights to zero. The problem was in the math package curfit
routine cverrors. The code to compute the variance and the reduced
chi-square was not checking for 0 valued weights. Cverrors saw that
the variance and reduced chi square were different, concluded
that the fit was weighted, not uniform and did not scale the
coefficient errors by the variance. The solution was to add a check
for 0 weights and a new argument npts to the calling sequence for
cverrors.
STATUS: This bug has been fixed. There is no workaround except to delete
points manually before entering curfit. Affected code in imred$dtoi,
utilities$curfit and xtools$icfit has been updated.
NUMBER: 48
MODULE: proto$irmosaic
SYSTEM: V2.6
DATE: Sat Jul 23 12:10:00 MST 1988
FROM: davis
BUG: Irmosaic was not computing the column and row spacing between
adjacent subrasters of the output image if the parameters
nxoverlap and nyoverlap were < -1. The problem showed up in the
alignment stage in the forms of horizontal and vertical
streaks in the output image.
STATUS: This bug has been fixed. The workaround is to leave nxoverlap and
nyoverlap at their default values.
NUMBER: 49
MODULE: local$apphot/polyphot
SYSTEM: V2.5
DATE: Fri Jul 29 13:18:12 MST 1988
FROM: davis
BUG: The polyphot task was going into an infinite loop when supplied
with a polygons file containing comment lines preceeded by the
character # such as those generated by imtool.
STATUS: This bug has been fixed. The work around is to remove the
comment lines manually before running polyphot. The other apphot
tasks are not affected by this problem.
NUMBER: 50
MODULE: utilities.curfit
SYSTEM: V2.5
DATE: Fri Aug 5 13:51:57 MST 1988
FROM: sjacoby
BUG: The curfit task requires input data sorted in x and gives no
indication if this is not the case. Sorted data is required by
the rg_ranges procedure (even in the default case of sample=*)
or else data points will be ommitted from the fit. The only
indication in curfit that all data points are not being used is
that the value of 'total' doesn't equal 'sample' in the plot header.
STATUS: Repaired in V2.7, such that for list input only, curfit will sort
the input array before fitting.
NUMBER: 51
MODULE: system.directory
SYSTEM: V2.5
DATE: Thu Aug 11 11:45:54 MST 1988
FROM: sjacoby
BUG: When directory is called with sort=no, long=no and an extension
matching template like "*.tab", the task fails. On VMS/IRAF,
"no files found" is reported; on SUN/IRAF a segmentation violation
is seen.
STATUS: The bug has been traced to a single line of code and will be
fixed in IRAF V2.7. A workaround would be to use directory
with "sort=yes", which is the default.
NUMBER: 52
MODULE: images.imcombine, ccdred.combine
SYSTEM: V2.6
DATE: Tue Aug 16 13:05:26 MST 1988
FROM: valdes
BUG: The median option of the combine routines is incorrect when the number
of images is odd. Instead of selecting the (N+1)/2 value, where N is the
number of images, it was selecting the N/2 value. It was also reported
as a bug that for N even it was not selecting the average of the
middle two values. This is not a bug but the intended behavior when
N is even.
STATUS: The bug was fixed as of this date. There is no work around. Though
the image produced is not the true median it will still be a useful
statistic. The help pages have been clarified to define the behavior
when the number of images is even.
NUMBER: 53
MODULE: binfil
SYSTEM: V2.5
DATE: Mon Sep 19 13:53:04 MST 1988
FROM: davis
BUG: The short optional header was being incorrectly written to the
output file on the sun machines. The integer parameters ncols,
nrows and datatype were being passsed to short integer fields.
STATUS: The bug has been fixed in version 2.7. The work around is to
avoid use of the header=yes option if possible.
NUMBER: 54
MODULE: longslit$transform
SYSTEM: V2.5
DATE: Wed Sep 21 13:47:34 MST 1988
FROM: davis
BUG: The longslit package task transform was writing the keyword "W0"
in wavelength units when log10 (wavelength) units were requested.
STATUS: The bug has been fixed in 2.7. The work around is to be aware of
the problem and use hedit to edit in the correct value.
NUMBER: 55
MODULE: galactic
SYSTEM: V2.6
DATE: Thu Sep 22 16:25:35 MST 1988
FROM: davis
BUG: The galactic task was not precessing the ra and dec to 1950
coordinates before converting to galactic coordinates. Therefore
all computations were only valid for epoch 1950 input. This bug
is only present in v2.6.
In addition the new code was using the ra and dec of the galactic
pole and the ra and dec of the galactic center to compute the
transformation. The IAU definition specifies the ra and dec of the
galactic pole and the galactic longitude of the north celestial
pole introducing a small error. This bug is only present in v2.6.
STATUS: Both bugs have been fixed in version 2.7. The only work around is
to be aware of the problem and only use 1950.0 ras and decs. The
error introduced by problem 2 is very small.
NUMBER: 56
MODULE: median, fmedian
SYSTEM: V2.5
DATE: Tue Oct 4 13:50:34 MST 1988
FROM: davis
BUG: If an error occurred during the execution of fmedian or median
and the input image name was the same as the output image name
the input image was deleted during the error recovery. The most
common source of error is insufficient disk space for the scratch
pixel file.
STATUS: The bug in the error handling code has been fixed. The work around
is to avoid using inplace operation if disk space is known to
be limited.
NUMBER: 57
MODULE: astutil.rvcorrect
SYSTEM: V2.6- (From Oct87)
DATE: Wed Oct 5 14:25:15 MST 1988
FROM: valdes
BUG: The radial velocity component due to the Earth's rotation was in
error by 0.5% (too small). This bug appears in DOPSET from which
parts of RVCORRECT were transcribed.
STATUS: Bug and documentation fixed.
NUMBER: 58
MODULE: astutil.rvcorrect
SYSTEM: V2.5
DATE: Tue Oct 18 09:17:12 MST 1988
FROM: valdes
BUG: Some of the radial velocity correction components are grossly in error
on Sun and other IEEE byte ordered systems (Alliant, DG). This is not
a problem on Vaxes.
STATUS: A constant was being used as an argument to a subroutine expecting a
double precision value. By default constants without the D exponent
notation are real numbers and so an argument type mismatch occured.
For Vaxes this is not critical since the most significant part is
correctly interpreted. There is no work around short of checking and
changing all the calls to ast_coords and recompiling.
NUMBER: 59
MODULE: ccdred.mkskyflat
SYSTEM: V2.5
DATE: Thu Oct 20 10:15:34 MST 1988
FROM: valdes
BUG: This task produced the error "Cannot open image".
STATUS: The task correctly produced the sky illumination image but failed
when it attempted to multply this by the flat field image,
given in the CCDPROC parameters, to create the sky flat. The
message concerned not being able to open the flat field image.
Instead of the sky flat the resultant output image was a sky
correction image. One could make the sky flat using IMARITH
"imarith flat * skyflat skyflat" where flat and skyflat are
the appropriate images. The bug has now been fixed.
NUMBER: 60
MODULE: ccdred.mkillumcor, ccdred.mkillumflat
SYSTEM: V2.5
DATE: Thu Oct 20 10:27:25 MST 1988
FROM: valdes
BUG: If the flat field image which is smoothed to produce a large scale
illumination has negative or zero values (something which should not
be the case for reasonable data) it is possible to obtain an arithmetic
divide by zero exception. Even worse if in some cases where the
mechanics of trapping this error have not been solved (in the latest
Sun systems) infinite loops may result.
STATUS: The arithmetic error, while clear that it is a division by zero, may
not be obvious to the user that the data is suspect. The user must be
aware of this. As a solution the tasks have been modified to count the
number of divisions by zero and print a warning summary at the end.
New task parameters specify what value to use as the result of
division by zero. A work around is to use IMREPLACE to put a
floor in the flat field data. Note that zero division checking
is not done in CCDPROC for efficiency but in these tasks efficiency
is not a problem since they are used at most a few times per
data set.
NUMBER: 61
MODULE: onedspec.bswitch
SYSTEM: V2.3-2.5
DATE: Tue Nov 1 14:34:50 MST 1988
FROM: valdes
BUG: The task aborts if it cannot determine the airmass even if it does not
actually need this quantity.
STATUS: The airmass is now required only if the extinction correction is
requested. The work around is to use HEDIT to add a dummy airmass
under the keyword AIRMASS.
NUMBER: 62
MODULE: images.geotran
SYSTEM: 2.5
DATE: Wed Nov 9 08:00:00 MST 1988
FROM: davis
BUG: Geotran quits with the error message "GSRESTORE: Invalid x or y order"
if one of the x or y coordinate surfaces is linear (xorder = 2
yorder = 2) and the other is higher order (xorder > 2 or yorder > 2).
The gsrestore command was not being error checked in the case
where one of the higher order surfaces was null.
STATUS: The bug has been fixed in 2.7. There is no work around except to
make sure that both higher order surfaces are null or both are non
null. Contact the iraf group for a bug fix.
NUMBER: 63
MODULE: onedspec.dispcor
SYSTEM: V2.7
DATE: Thu Dec 8 13:32:02 MST 1988
FROM: valdes
BUG: The new DISPCOR of V2.7 produces incorrect results (noticable high
frequency component) in very high resolution data (lambda /
delta lambda > 10E6).
STATUS: The bug was the result of a calculation using real arithmetic which
requires double precision for high resolution data. For lower
dispersions there is no problem. For high dispersion one must
either not use flux conservation or use wavelengths with the
large offset subtracted (for example use 76.321 instead of 4876.321
where 4800 is subtracted from all wavelengths). This bug is fixed
in V2.8.
NUMBER: 64
MODULE: apextract.apnormalize
SYSTEM: V2.5-V2.7
DATE: Thu Dec 15 17:31:22 MST 1988
FROM: valdes
BUG: Deleted points during interactive fitting of the normalization spectrum
remain deleted in later apertures.
STATUS: This has been fixed. Generally this would not cause any problems
since only a few points would be missing and the fit is over the
relatively smooth quartz spectrum.
NUMBER: 65
MODULE: reblock
SYSTEM: V2.5
DATE: Sat Jan 28 12:56:27 MST 1989
FROM: davis
BUG: The copyn parameter was being ignored for tape to tape copies where
the physical block size was not being altered.
STATUS: This bug has been fixed in 2.8.
NUMBER: 66
MODULE: apphot.polyphot
SYSTEM: V2.6
DATE: Sat Feb 4 11:15:56 MST 1989
FROM: davis
BUG: Polyphot can return an incorrect result if the user inputs a polygonal
aperture which is not convex and if an image line happens to
intersect the polygon exactly on a vertex.
STATUS: This bug has been fixed in IRAF 2.8. The work around is to use only
convex polygonal apertures.
NUMBER: 67
MODULE: bscale
SYSTEM: V2.6
DATE: Tue Feb 7 17:55:08 MST 1989
FROM: davis
BUG: Bscale would sometimes crash with a memory corruption error when
the image section to be used for computing the image statistics
was specified with the sections parameter instead of using
image section notation. The problem was caused by the task
overflowing the data buffer by attempting to read beyond the
limits of the section.
STATUS: The bug has been fixed in 2.8.
NUMBER: 68
MODULE: apphot.apselect
SYSTEM: V2.6
DATE: Mon Apr 3 11:44:27 MST 1989
FROM: davis
BUG: If a none of fields selected by the user with the fields parameter
actually existed in the apphot database file, the task would
terminate with a segmentation violation.
The task was not cleaning up dynamically allocated menory in the
case that none of user selected fields were valid.
STATUS: This bug has been fixed in V2.8 The work around is to retype the
command with the correct field name.
NUMBER: 69
MODULE: noao.proto.irafil
SYSTEM: V2.7
DATE: Fri Apr 28 16:33:34 MST 1989
FROM: rooke
BUG: A user reported a segmentation violation running IRAFIL with
a large header area to skip.
STATUS: Fixed in V2.8. After allocating dynamic storage for the header,
the code was mistakenly reading the header into pixel storage
instead, so if the header was longer than a row of pixels, it
would abort.
NUMBER: 70
MODULE: images.imcombine, ccdred.combine
SYSTEM: V2.7
DATE: Fri May 5 16:47:34 MST 1989
FROM: valdes
BUG: 1. When scaling or weighting the sigma image is a factor of the
square root of the number of images too small. This does not occur
when not scaling or weighting.
2. The sigma image is incorrectly computed by image.imcombine
when the input images are of integer datatype.
STATUS: Fixed in V2.8.
NUMBER: 71
MODULE: images.imarith
SYSTEM: V2.7
DATE: Fri May 5 16:53:20 MST 1989
FROM: valdes
BUG: A command of the form
cl> imarith test[20:30] * 1.2 test[20:30]
where the output is a section of an existing image does not work as
might be expected and instead clobbers the original image by the
smaller output image.
STATUS: Operations into a subsection of an output image is not allowed by
the task and it was a bug that output image could be clobbered.
This was due to the fact that in place operations (i.e. replacing
an existing image by the result) are allowed. The current fix
is to print a warning and skip the operation if the output image
name contains an image section.
NUMBER: 72
MODULE: images.imsurfit
SYSTEM: V2.5
DATE: Thu Jun 1 11:41:24 MST 1989
FROM: davis
BUG: Imsurfit would go into an infinite loop if regions = "sections"
and the sections file was nonexistent.
STATUS: The problem was a missing errchk on the open statement. The
bug has been fixed in V2.8.
NUMBER: 73
MODULE: specplot
SYSTEM: V2.7
DATE: Tue Jun 6 08:54:50 MST 1989
FROM: valdes
BUG: Task SPECPLOT had wavelengths off by one pixel.
STATUS: This was due to an uninitialized CRPIX1 variable. The wavelength
variables refer to pixel 1 but pixel 0 was being used instead.
This only occurs if the W0 and WPC keywords are used instead of
the FITS keywords. The workaround is to change W0 by subtracting
WPC. Fixed for V2.8.
NUMBER: 74
MODULE: ccdred
SYSTEM: V2.7
DATE: Fri Jun 16 11:03:00 MST 1989
FROM: valdes
BUG: If the backup prefix is a nonexistent directory ccdproc hangs
on Suns and possibly on other systems.
STATUS: The workaround is to change the backup prefix or make the directory
with mkdir. A fix has been made to print an error and abort.
The original image will be unchanged and the processed temporary
image is deleted.
NUMBER: 75
MODULE: splot
SYSTEM: -V2.7
DATE: Fri Jun 16 15:29:14 MST 1989
FROM: valdes
BUG: If the wavelength per pixel is negative the options 'd' deblend,
'e' equivalent width, 'm' signal-to-noise, and 'x' fudge extended
over a line give incorrect results.
STATUS: This has been fixed in V2.8. The workaround is to only use positive
wavelength per channel (WPC or CRDELT1). REBIN or SFLIP
can be used to change the dispersion direction.
NUMBER: 76
MODULE: dispcor/ecdispcor/msdispcor
SYSTEM: V2.8
DATE: Mon Jul 10 13:26:08 MST 1989
FROM: valdes
BUG: The task DISPCOR does not produce the result one expects at the
endpoints of the input data.
STATUS: The IRAF convention is that the pixel value refers to the center
of the pixel. When considered as an aperture the pixel extends
between -0.5 and +0.5 of the pixel center. The way the task is
written in V2.8, an interpolation function is fit to the values
at the pixel centers and the function is not defined beyond the
center of the first and last pixels. When using the flux
conservation option (integration of the interpolation function
across the extent of the output pixel) the part of the output
pixel corresponding to the half pixel beyond the center of the
first and last pixel is not used. For the simple case of an
output dispersion such that the size of an input and output
pixel are nearly the same and the endpoints are the same this
gives about a factor of 0.5 for the endpoint pixels. When not
using flux conservation the interpolation function is evaluated
directly. However, it is often the case that the center of the
last output pixel is computed to be just slightly beyond the
center of the last input pixel (due to rounding) and so the
last output pixel is often zero.
The task has been revised to extrapolate the interpolation function
by a half a pixel on either end of the input data. The workarounds
are to avoid the endpoints when specifying the wavelength scale
during dispcor or by eliminating the endpoints after dispersion
correction using onedspec.sextract.
NUMBER: 77
MODULE: dispcor/ecdispcor/msdispcor
SYSTEM: V2.8 (Sun4)
DATE: Mon Jul 10 13:46:09 MST 1989
FROM: valdes
BUG: Using a dispersion table with INDEF values for the number of pixels
causes a floating operand error.
STATUS: An attempt is made to convert the magic value for INDEF internally
in such a way that the floating operand exception is encountered.
Note that this is only a problem when the value is read from the
dispersion table file. INDEF is fine as a task parameter.
There is no workaround for the INDEF feature though one can put
the number of pixels in explicitly in the dispersion table.
distrib
>
Mageia
>
6
>
armv5tl
>
media
>
core-release
>
by-pkgid
>
30819c093f498f9dfa6444d2407d0521
>
files
>
5316
