iraf.net

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