From fa080de7afc95aa1c19a6e6fc0e0708ced2eadc4 Mon Sep 17 00:00:00 2001 From: Joseph Hunkeler Date: Wed, 8 Jul 2015 20:46:52 -0400 Subject: Initial commit --- local/.Xauthority | Bin 0 -> 260 bytes local/.Xdefaults | 164 + local/.Xmodmap | 29 + local/.bash_logout | 3 + local/.bash_profile | 13 + local/.bashrc | 8 + local/.cshrc | 83 + local/.emacs | 25 + local/.exrc | 3 + local/.gdbinit | 56 + local/.history | 200 + local/.lesshst | 5 + local/.login | 74 + local/.ssh/known_hosts | 3 + local/.xmodmaprc | 15 + local/COPYRIGHTS | 39 + local/LICENSES/GPL | 280 + local/LICENSES/OpenSolaris_License-CDDL.pdf | Bin 0 -> 124910 bytes local/LICENSES/README | 9 + local/LICENSES/UCAR | 94 + local/bugs.log | 8527 +++++++++++++++++++++++++++ local/help.log | 1474 +++++ local/iraf_test.tar.gz | Bin 0 -> 40381 bytes local/lib/helpdb.mip | Bin 0 -> 2904 bytes local/lib/mkpkg.inc | 14 + local/lib/root.hd | 5 + local/lib/rootlocal.hd | 8 + local/lib/strip.local | 4 + local/lib/zzsetenv.def | 8 + local/login.cl | 132 + local/mkpkg | 61 + local/notes.64-bit | 565 ++ local/notes.v216 | 528 ++ local/src/README | 75 + local/src/bswap.par | 3 + local/src/bswap.x | 42 + local/src/doc/bswap.hlp | 36 + local/src/doc/pavg.hlp | 29 + local/src/local.cl | 10 + local/src/local.hd | 7 + local/src/local.men | 2 + local/src/local.par | 3 + local/src/mkpkg | 27 + local/src/pavg.par | 1 + local/src/pavg.x | 45 + local/src/x_local.x | 6 + 46 files changed, 12715 insertions(+) create mode 100644 local/.Xauthority create mode 100644 local/.Xdefaults create mode 100644 local/.Xmodmap create mode 100644 local/.bash_logout create mode 100644 local/.bash_profile create mode 100644 local/.bashrc create mode 100644 local/.cshrc create mode 100644 local/.emacs create mode 100644 local/.exrc create mode 100644 local/.gdbinit create mode 100644 local/.history create mode 100644 local/.lesshst create mode 100644 local/.login create mode 100644 local/.ssh/known_hosts create mode 100644 local/.xmodmaprc create mode 100644 local/COPYRIGHTS create mode 100644 local/LICENSES/GPL create mode 100644 local/LICENSES/OpenSolaris_License-CDDL.pdf create mode 100644 local/LICENSES/README create mode 100644 local/LICENSES/UCAR create mode 100644 local/bugs.log create mode 100644 local/help.log create mode 100644 local/iraf_test.tar.gz create mode 100644 local/lib/helpdb.mip create mode 100644 local/lib/mkpkg.inc create mode 100644 local/lib/root.hd create mode 100644 local/lib/rootlocal.hd create mode 100644 local/lib/strip.local create mode 100644 local/lib/zzsetenv.def create mode 100644 local/login.cl create mode 100644 local/mkpkg create mode 100644 local/notes.64-bit create mode 100644 local/notes.v216 create mode 100644 local/src/README create mode 100644 local/src/bswap.par create mode 100644 local/src/bswap.x create mode 100755 local/src/doc/bswap.hlp create mode 100644 local/src/doc/pavg.hlp create mode 100644 local/src/local.cl create mode 100644 local/src/local.hd create mode 100644 local/src/local.men create mode 100644 local/src/local.par create mode 100644 local/src/mkpkg create mode 100644 local/src/pavg.par create mode 100644 local/src/pavg.x create mode 100644 local/src/x_local.x (limited to 'local') diff --git a/local/.Xauthority b/local/.Xauthority new file mode 100644 index 00000000..fb525d40 Binary files /dev/null and b/local/.Xauthority differ diff --git a/local/.Xdefaults b/local/.Xdefaults new file mode 100644 index 00000000..6a99b9cc --- /dev/null +++ b/local/.Xdefaults @@ -0,0 +1,164 @@ +! Parts (C) 1996 By Greg J. Badros +! You may use this file as specified under the GNU General Public License + +! DEFINE OPTIONS: +! SMALL_SCREEN = force small screen options (automatic for <800 width) +! NO_SMALL_SCREEN = force large screen options (automatic for >=800 width) +! XAW3DCOLOR = default color for Xaw3d widget scrollbar (gray75 if not set) +! BLACK_BG_XTERMS = Use color settings to make colored text visible on +! xterms with a black background + +#define XAW3DCOLOR gray75 + +/* #define BLACK_BG_XTERMS */ +/* #define RECOLOR_XPAINT */ +#define RECOLOR_GHOSTVIEW +#define RECOLOR_XDVI + +#ifdef COLOR +*customization: -color +#endif + +#if WIDTH<800 +#ifndef NO_SMALL_SCREEN +#define SMALL_SCREEN +#endif +#endif + +#ifndef XAW3DCOLOR +#define XAW3DCOLOR gray75 +#endif + +#define WINBACK_COLOR gray75 + +emacs*Background: DarkSlateGray +emacs*Foreground: Wheat +emacs*pointerColor: Orchid +emacs*cursorColor: Orchid +emacs*bitmapIcon: on +emacs*font: fixed +emacs.geometry: 80x25 + +Seyon.modems: /dev/modem + +!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! +! xterm (and friends) + +XTerm*saveLines: 1500 +nxterm*saveLines: 1500 +rxvt*saveLines: 1500 + +XTerm*cursorColor: blue +XTerm*scrollBar: true +nxterm*cursorColor: blue +nxterm*scrollBar: true + +xterm*fullCursor: true +xterm*reverseWrap: true +xterm*titleBar: false +nxterm*fullCursor: true +nxterm*reverseWrap: true +nxterm*titleBar: false + +*visualBell: true +*scrollTtyOutput: False +*scrollKey: True +Scrollbar.JumpCursor: True +*numeric: C +*displayLang: C +*basicLocale: C +*timeFormat: C +*inputLang: C + +#ifndef BLACK_BG_XTERMS +XTerm*background: white +XTerm*foreground: black +nxterm*background: white +nxterm*foreground: black + +! This was white, which is invisible on a white background +*VT100*colorBD: black +! Underlining shouldn't be yellow for white bg xterms +*VT100*colorUL: blue + +#else + +! These defaults pulled from my /usr/lib/X11/app-defaults/NXTerm +! I don't want to rely on the defaults when a define is specifically +! set for BLACK_BG_XTERMS +*VT100*colorBD: white +*VT100*colorUL: yellow +XTerm*background: black +XTerm*foreground: white +nxterm*background: black +nxterm*foreground: white +*VT100*colorBD: white +*VT100*colorUL: yellow + +#endif + +nxterm*SimpleMenu.background: gray75 +nxterm*SimpleMenu.foreground: black +XTerm*SimpleMenu.background: gray50 +XTerm*SimpleMenu.foreground: black + +! Please email if you have a better +! way of introducing a newline into a macro expansion +! I get the NL by including an extra argument to the macro for which +! I always use a literal newline as the argument +#define FontAndLabel(cFont,sz,NL,lbl) \ +XTerm*VT100*font/**/cFont/**/: sz/**/NL \ +XTerm*fontMenu*font/**/cFont/**/*Label: lbl (/**/sz/**/)NL \ +nxterm*VT100*font/**/cFont/**/: sz/**/NL \ +nxterm*fontMenu*font/**/cFont/**/*Label: lbl (/**/sz/**/)NL + +#ifndef SMALL_SCREEN + +*SimpleMenu*font: *helvetica*r*normal*12* +XDvi*font: *helvetica*r*normal*12* +FontAndLabel(1,5x7, +,Micro) +FontAndLabel(2,5x8, +,Tiny) +FontAndLabel(3,6x10, +,Small) +FontAndLabel(4,fixed, +,Medium) +FontAndLabel(5,9x15, +,Large) +FontAndLabel(6,10x20, +,Very Large) +FontAndLabel(7,12x24, +,Huge) + +#else + +*SimpleMenu*font: *helvetica*r*normal*10* +XDvi*font: *helvetica*r*normal*10* +FontAndLabel(1,5x7, +,Micro) +FontAndLabel(2,5x8, +,Tiny) +FontAndLabel(3,6x9, +,Small) +FontAndLabel(4,7x13, +,Medium) +FontAndLabel(5,9x15, +,Large) +FontAndLabel(6,10x20, +,Huge) +FontAndLabel(7,8x16, +,Alternate Large) + +#endif + +*eightBitInput: true +remotexterm*eightBitInput: false +nxterm*Cursor: xterm + +xterm*VT100.Translations: #override\n\ + Prior : scroll-back(1,page)\n\ + Next : scroll-forw(1,page) +nxterm*VT100.Translations: #override\n\ + Prior : scroll-back(1,page)\n\ + Next : scroll-forw(1,page) diff --git a/local/.Xmodmap b/local/.Xmodmap new file mode 100644 index 00000000..304995d8 --- /dev/null +++ b/local/.Xmodmap @@ -0,0 +1,29 @@ +! *** Installed by xview3L5 *** +! F1=Help (move pointer on panel, press F1 to show help on the item) +! F2=Find (after having selected some text, press F2 to do a search) +! F3=Cut (select text, press F3 to move text into clipboard) +! F4=Copy (select text, press F4 to copy text into clipboard) +! F5=Paste (insert text from clipboard at caret position) + +! keysym F1 = Help +! keysym F2 = F19 +! keysym F3 = F20 +! keysym F4 = F16 +! keysym F5 = F18 + + +! +! LEPUS -- Initialize keyoard mapping. +! +!## Tab key becomes Control, Shift-Tab for Tab. +!remove Lock = Caps_Lock +!keysym F15 = Caps_Lock +!keysym Caps_Lock = Control_L +!add Lock = Caps_Lock +! +remove Control = Control_R +keysym Tab = Control_R Tab +add Control = Control_R +! +!## Map backspace key to delete. +keysym BackSpace = Delete BackSpace diff --git a/local/.bash_logout b/local/.bash_logout new file mode 100644 index 00000000..926eddc2 --- /dev/null +++ b/local/.bash_logout @@ -0,0 +1,3 @@ +# ~/.bash_logout + +clear diff --git a/local/.bash_profile b/local/.bash_profile new file mode 100644 index 00000000..fdd06ac2 --- /dev/null +++ b/local/.bash_profile @@ -0,0 +1,13 @@ +# .bash_profile + +# Get the aliases and functions +if [ -f ~/.bashrc ]; then + . ~/.bashrc +fi + +# User specific environment and startup programs + +PATH=$PATH:$HOME/bin + +export PATH +unset USERNAME diff --git a/local/.bashrc b/local/.bashrc new file mode 100644 index 00000000..9271cff6 --- /dev/null +++ b/local/.bashrc @@ -0,0 +1,8 @@ +# .bashrc + +# User specific aliases and functions + +# Source global definitions +if [ -f /etc/bashrc ]; then + . /etc/bashrc +fi diff --git a/local/.cshrc b/local/.cshrc new file mode 100644 index 00000000..35242235 --- /dev/null +++ b/local/.cshrc @@ -0,0 +1,83 @@ +# .cshrc - csh resource script, read at beginning +# of execution by each shell + +umask 022 +setenv iraf /iraf/build/iraf/ +setenv IRAFARCH `$iraf/unix/hlib/irafarch.csh -actual` +source $iraf/unix/hlib/irafuser.csh + +#setenv IRAFARCH macintel +#setenv XC_F77 "g95" +#setenv XC_LFLAGS "-lg95" +#setenv XC_XFLAGS "-/mfpmath=sse -/free-vectorize -/msse" +#setenv XC_FFLAGS "-mfpmath=sse -ftree-vectorize -msse" +#setenv XC_CFLAGS "-mfpmath=sse -ftree-vectorize -msse" + +setenv LC_COLLATE POSIX + + +switch (`uname`) +case FreeBSD: + set path = (. $HOME/bin /sbin /bin /usr/sbin /usr/bin /usr/games \ + /usr/local/bin /usr/local/sbin \ + /usr/X11R6/bin) + breaksw +case Linux: + set path = (. $HOME/bin /sbin /bin /usr/sbin /usr/bin /usr/games \ + /usr/local/bin /usr/local/sbin /usr/java/j2sdk/bin \ + /usr/X11R6/bin) + breaksw +case Darwin: + set path = (. $HOME/bin /sbin /bin /usr/sbin /usr/bin /usr/games \ + /usr/local/bin /opt/local/bin /usr/local/sbin \ + /usr/local/pvm/pvm3/bin /usr/local/pvm/pvm3/lib \ + /usr/X11R6/bin) + breaksw +case SunOS: + set path = (. $HOME/bin /usr/local/bin \ + /usr/openwin/bin /usr/bin /bin /sbin /usr/sbin \ + /usr/ccs/bin /usr/dt/bin /usr/ucb \ + /opt/SUNWjws/JWS/intel-S2/bin \ + /opt/Summertime_98.i386/bin \ + /opt/Summertime_98.i386/sbin \ + /opt/Summertime_98.i386/TeX/bin \ + /opt/Summertime_98.i386/Perl/bin \ + /opt/Summertime_98.i386/Python/bin \ + /opt/Summertime_97.i386/netpbm/bin) + breaksw +default: + set path = (. $HOME/bin /sbin /bin /usr/sbin /usr/bin /usr/games \ + /usr/local/bin /usr/local/sbin \ + /usr/X11R6/bin) + breaksw +endsw + +if ($?prompt) then + # An interactive shell -- set some stuff up + set filec + set history = 100 + set savehist = 100 + set mail = (/var/mail/$USER) + + set prompt = "`hostname -s`> " + + # make mail(1) happy: + setenv crt 24 +endif + +setenv XFILESEARCHPATH ":/usr/lib/X11/%T/%N%S:/usr/x11R6/lib/X11/%T/%N%S:" + + +alias del '/bin/rm -f' +alias ls 'ls -FCs' +alias m 'less' +alias p 'vi + ~/_port' +alias mk 'mkpkg' +alias po 'popd' +alias pu 'pushd' + +alias new 'find . \! -type d -mtime -7 -print' +alias newt 'find . \! -type d -mtime -7 -print | grep -v '\''\.[aoe]$'\' +alias newt2 'find . \! -type d -mtime -14 -print | grep -v '\''\.[aoe]$'\' +alias newt3 'find . \! -type d -mtime -21 -print | grep -v '\''\.[aoe]$'\' +alias newt4 'find . \! -type d -mtime -31 -print | grep -v '\''\.[aoe]$'\' diff --git a/local/.emacs b/local/.emacs new file mode 100644 index 00000000..6a521b91 --- /dev/null +++ b/local/.emacs @@ -0,0 +1,25 @@ +;; Red Hat Linux default .emacs initialization file ; -*- mode: emacs-lisp -*- + +;; Set up the keyboard so the delete key on both the regular keyboard +;; and the keypad delete the character under the cursor and to the right +;; under X, instead of the default, backspace behavior. +(global-set-key [delete] 'delete-char) +(global-set-key [kp-delete] 'delete-char) + +;; turn on font-lock mode +(global-font-lock-mode t) +;; enable visual feedback on selections +(setq-default transient-mark-mode t) + +;; always end a file with a newline +(setq require-final-newline t) + +;; stop at the end of the file, not just add lines +(setq next-line-add-newlines nil) + +(when window-system + ;; enable wheelmouse support by default + (mwheel-install) + ;; use extended compound-text coding for X clipboard + (set-selection-coding-system 'compound-text-with-extensions)) + diff --git a/local/.exrc b/local/.exrc new file mode 100644 index 00000000..ffe65b74 --- /dev/null +++ b/local/.exrc @@ -0,0 +1,3 @@ +set optimize redraw sw=4 paragraphs=XSXEIPLPPPQPP\ LIpplpipnpbp +map @ {j!}fmt }be +map ;> :.,$s/^/> / diff --git a/local/.gdbinit b/local/.gdbinit new file mode 100644 index 00000000..e876189f --- /dev/null +++ b/local/.gdbinit @@ -0,0 +1,56 @@ +#display /i $pc + +set height 0 + +define a +step +end + +define ps +call spp_printstr ($arg0) +end + +define pc +call spp_printmemc ($arg0) +end + + +dir /local/src/tcl/tcl7.5/unix +dir /local/src/tcl/tcl7.5/compat +dir /local/src/tcl/tcl7.5/generic + +dir /iraf/iraf/unix/os +dir /iraf/iraf/unix/boot/bootlib +dir /iraf/iraf/unix/boot/spp +dir /iraf/iraf/unix/boot/rtar +dir /iraf/iraf/unix/boot/mkpkg + +dir /iraf/iraf/sys/fio +dir /iraf/iraf/sys/fmio +dir /iraf/iraf/sys/fmtio +dir /iraf/iraf/sys/clio +dir /iraf/iraf/sys/etc/gen +dir /iraf/iraf/sys/etc +dir /iraf/iraf/sys/imio +dir /iraf/iraf/sys/imio/iki +dir /iraf/iraf/sys/imio/iki/fxf +dir /iraf/iraf/sys/imio/iki/oif +dir /iraf/iraf/sys/imio/iki/stf +dir /iraf/iraf/sys/gty +dir /iraf/iraf/sys/memio +dir /iraf/iraf/sys/mtio +dir /iraf/iraf/sys/symtab +dir /iraf/iraf/sys/tty +dir /iraf/iraf/sys/ki + +dir /iraf/iraf/sys/gio +dir /iraf/iraf/sys/gio/gki +dir /iraf/iraf/sys/gio/imdkern +dir /iraf/iraf/sys/gio/cursor + +dir /iraf/iraf/sys/imfort + +dir /iraf/iraf/pkg/system +dir /iraf/iraf/pkg/images/imutil/src + +dir . diff --git a/local/.history b/local/.history new file mode 100644 index 00000000..81b30069 --- /dev/null +++ b/local/.history @@ -0,0 +1,200 @@ +#+1294164956 +cd immatch/src/imcombine/src +#+1294164959 +ed generic/mkpkg +#+1294165034 +cd ../../.. +#+1294165177 +ar t libpkg.a > junk +#+1294165179 +ed junk +#+1294165234 +mkpkg -n update +#+1294165266 +mkpkg update +#+1294165300 +ar t $iraf/lib/libimc.a > junk +#+1294165302 +type junk +#+1294165305 +cat junk +#+1294165314 +ar d libpkg.a `cat junk` +#+1294165338 +ar t libpkg.a | egrep '^ic' +#+1294165366 +rm junk +#+1294165445 +mkpkg install +#+1294165473 +cd $iraf +#+1294166009 +cd /iraf/extern.v215 +#+1294166039 +ed lib/src +#+1294166041 +cd lib +#+1294166071 +cd nfextern/lib +#+1294166099 +cd ../.. +#+1294166106 +cd mscred +#+1294166139 +cd src/ccdred/src +#+1294166296 +rm mkpkg.OLD +#+1294347727 +vi Revisions +#+1294347923 +cd /iraf/iraf/noao/imred/ccdred +#+1294347930 +cd src/combine +#+1294347935 +cd src/ +#+1294348046 +mkdir combine +#+1294348078 +mv ic* combine +#+1294348080 +ls combine +#+1294348187 +ls xt* +#+1294348191 +ls ty* +#+1294348211 +cd combine +#+1294348220 +cp ../mkpkg . +#+1294348465 +mkdir generic +#+1294348474 +cd generic +#+1294348490 +mv ../../generic/ic* . +#+1294348514 +cp ../../generic/mkpkg . +#+1294348671 +ed Revisions +#+1294348882 +cd ccdred +#+1294348901 +setenv PKGENV noao +#+1294348918 +setenv noao /iraf/iraf/noao/ +#+1294348921 +ls /iraf/iraf/noao +#+1294348940 +cd src +#+1294348944 +ls icomb*h +#+1294348953 +ed mkpkg +#+1294349036 +ed src/mkpkg +#+1294349091 +mkpkg -n +#+1294350057 +cd /iraf +#+1294350076 +cd iraf +#+1294350137 +cd doc +#+1294350186 +cd /iraf/extern +#+1294350193 +ed nfextern.diff +#+1294350241 +/iraf/iraf/local/ +#+1294350245 +cd /iraf/iraf/local +#+1294350280 +ed notes.v215 +#+1294421894 +cd /iraf/iraf/sys/imio +#+1294421901 +del sz_pix +#+1294424362 +whoami +#+1294424365 +cd pkg/proto/doc +#+1294424370 +cd /iraf/iraf/pkg/proto/doc +#+1294424386 +/bin/rm -rf maskexpr masks mkpkg vol *.par *.x proto.* intrp.f ringavg.cl +#+1294677620 +ssh irafnet@iraf.net +#+1294678613 +alias ed vi +#+1294678616 +ed icaclip.gx +#+1294678808 +ed iccclip.gx +#+1294678896 +ed icmm.gx +#+1294678937 +ed icpclip.gx +#+1294678989 +ed icsclip.gx +#+1294679084 +ed iccomb.gx +#+1294679089 +ed icomb.gx +#+1294679135 +ed icsigma.gx +#+1294679229 +mkpkg +#+1294679239 +ls -lrt +#+1294679246 +ls -rt +#+1294679259 +ls -rt -1 +#+1294679276 +ed /iraf/iraf/pkg/images/Revisions +#+1295046238 +w +#+1295046240 +df +#+1295046743 +su +#+1295467961 +cd /iraf/iraf +#+1295467966 +make generic +#+1295471576 +ls l +#+1295471590 +tar zxvf /tmp/new.tgz +#+1295471726 +cd extern +#+1295471728 +ls -l +#+1295471789 +ls song +#+1295472062 +/bin/rm -rf FVfitsutil/ adccdrom iue mem0 mtools optic rvsao song sqiid stecf steward ucsclris upsqiid/ xdimsum/ +#+1295472073 +cat .zzsetenv.def +#+1295472085 +foreach i ( * ) +#+1295472115 +vi .zzsetenv.def +#+1295472161 +cd .. +#+1295472164 +ls -l bin +#+1295472167 +du bin* +#+1295472172 +ls bin.cygwin/ +#+1295472180 +make linux +#+1295472194 +pwd +#+1295472205 +ls +#+1295472215 +make +#+1295472355 +exit diff --git a/local/.lesshst b/local/.lesshst new file mode 100644 index 00000000..faac98fa --- /dev/null +++ b/local/.lesshst @@ -0,0 +1,5 @@ +.less-history-file: +.search +"rpp +"parser +.shell diff --git a/local/.login b/local/.login new file mode 100644 index 00000000..0dacea42 --- /dev/null +++ b/local/.login @@ -0,0 +1,74 @@ +# $Id: dot.login,v 1.7.2.1 1997/02/23 20:57:42 joerg Exp $ +# +# .login - csh login script, read by login shell, +# after `.cshrc' at login. +# +# see also csh(1), environ(7). +# + +set notify + +#set autologout = 1440 + +if ($TERM != "linux" && $TERM != "cons25") then + stty erase '^?' +endif +if ($TERM == "xterm") then + setenv TERM xterm-color +endif + + +setenv EDITOR vi +setenv BLOCKSIZE K +setenv PAGER "less -C -e -M" +setenv IPAGER "less -C -M +G" +setenv MANPATH "/usr/man:/usr/X11R6/man:/usr/local/man:/usr/share/man" +setenv MOZILLA_HOME /usr/local/bin/netscape +setenv TAPE /dev/nrsa0 +setenv SHELL /bin/csh + +# Uncomment for IRAF admin/prog definitions. +#setenv IRAFARCH `/iraf/iraf/unix/hlib/irafarch.csh -actual` + +# Setup the iraf environment. +setenv iraf /iraf/build/iraf/ + +foreach f ($iraf/unix/hlib/irafuser.csh ~/.alias) + if (-e $f) then + source $f + endif + unset f +end + +set prompt = "iraf> " + +# Pick up C-shell definitions. +#source ~iraf/.cshrc + +set cdpath =\ +($iraf $iraf/pkg $iraf/noao $iraf/sys $iraf/unix $iraf/unix/boot /u1/x11apps/src/x11iraf /u1/x11apps/src /u3/x11iraf /local/src ~) + +unalias ls cd pwd rm + +alias c 'clear' +alias cls 'clear;ls' +alias ls 'ls -FCs' +alias clw 'clear;w' +alias pg 'less -Cqme' +alias m 'less -Cqme' +alias his 'history 33' +if (-e /etc/X11/XF86Config-4) then + alias win 'startx -- -depth 24' + alias win8 'startx -- -depth 8' +else + alias win 'startx -- -bpp 24' + alias win8 'startx -- -bpp 8' +endif +alias rsync 'rsync -avz' +alias sp 'clear; tail -33f spool' + + +# Setup for NVOSS +#setenv NVOSS_HOME /usr/local/nvoss/ +#setenv JAVA_HOME /Library/java/Home// +#source $NVOSS_HOME/bin/setup.csh diff --git a/local/.ssh/known_hosts b/local/.ssh/known_hosts new file mode 100644 index 00000000..2a11b142 --- /dev/null +++ b/local/.ssh/known_hosts @@ -0,0 +1,3 @@ +tucana,140.252.1.86 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAnqfyv26d9OX8Ub6InGAHppw4D1YATktgEnFSa8TraxDShSO5fBC3qV6gH1lgQGOfzJD17D0wdGQPZOQQhFIY0NWV2vPjB1Dcod/8gS1tWNTRunJE3WT8t/SR1TuWCCG9cc1hBJ94ozEMTGPJRKDMZYa5HurALLKM2eWzss/pWt0= +crux,140.252.1.12 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA2/4wWEJzpIgCJRpkCyZ3a2UBgCKidW86JXZgwhvLiUfYaxSRCTHVQ6kMppfVMxyobvlwUV67d4398sxJ2/X6LG7CaPXZjMsgMgjnV6D86vlGkZBBchSwkNx9/tSxpqEgbck0KrsomzWOo+QQRAXq5Dlred+3k8B16UXqcnx2oajEa2nUB+HvVBaGTq+C9awnIKTxMIG1OLQvknQs1fL2dHlE7N/1eLlUJNVv0rTJve1i1xfYQf0tAX7UzwBnK7Um4xkNO1HruPwnAMMmF+gzIeiqijPd2W36TSkBBWU2yZ686MhRq+6n1u0UD41re0/GRYsm/Ee4udM0W3lsSIpKew== +iraf.net,69.89.27.235 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEApv7SlSXKkfnr6jTe4sld84ipbyhpdg9Be3HyZIpMIT6SXBHZYV3+ifcAb9UxbiBMDVjJa8RJC2hUbIIcpeayCX3C0fcwJHsekHsF1eShG1oLqif5pz+conCrL1BgFG3YtJf7esIJPkTOXgXY6zq3nEqWsvGELZyTbm6RBOV9lL8= diff --git a/local/.xmodmaprc b/local/.xmodmaprc new file mode 100644 index 00000000..18bb7c89 --- /dev/null +++ b/local/.xmodmaprc @@ -0,0 +1,15 @@ +! +! Initialize keyoard mapping. +! +!## Tab key becomes Control, Shift-Tab for Tab. +!remove Lock = Caps_Lock +!keysym F15 = Caps_Lock +!keysym Caps_Lock = Control_L +!add Lock = Caps_Lock +! +remove Control = Control_R +keysym Tab = Control_R Tab +add Control = Control_R +! +!## Map backspace key to delete. +keysym BackSpace = Delete BackSpace diff --git a/local/COPYRIGHTS b/local/COPYRIGHTS new file mode 100644 index 00000000..416bcafb --- /dev/null +++ b/local/COPYRIGHTS @@ -0,0 +1,39 @@ +Copyright(c) 1986 Association of Universities for Research in Astronomy Inc. + +The IRAF software is publicly available, but is NOT in the public domain. +The difference is that copyrights granting rights for unrestricted use and +redistribution have been placed on all of the software to identify its authors. +You are allowed and encouraged to take this software and use it as you wish, +subject to the restrictions outlined below. + +Permission to use, copy, modify, and distribute this software and its +documentation is hereby granted without fee, provided that the above copyright +notice appear in all copies and that both that copyright notice and this +permission notice appear in supporting documentation, and that references to +the Association of Universities for Research in Astronomy Inc. (AURA), +the National Optical Astronomy Observatories (NOAO), or the Image Reduction +and Analysis Facility (IRAF) not be used in advertising or publicity +pertaining to distribution of the software without specific, written prior +permission from NOAO. NOAO makes no representations about the suitability +of this software for any purpose. It is provided "as is" without express or +implied warranty. + +NOAO DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL +IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL NOAO +BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION +OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN +CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + + + +=============================================================================== + + The iraf$local/LICENSES directory contains text of the license files +that apply to third-party sources currently in the IRAF system. See +specifically: + + OpenSolaris_License-CDDL.pdf For the XYACC parser (boot$xyacc) + UCAR For NCAR graphics + + diff --git a/local/LICENSES/GPL b/local/LICENSES/GPL new file mode 100644 index 00000000..2bc1e36b --- /dev/null +++ b/local/LICENSES/GPL @@ -0,0 +1,280 @@ + GNU GENERAL PUBLIC LICENSE + Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Library General Public License instead.) You can apply it to +your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. + + The precise terms and conditions for copying, distribution and +modification follow. + + GNU GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The "Program", below, +refers to any such program or work, and a "work based on the Program" +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term "modification".) Each licensee is addressed as "you". + +Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does. + + 1. You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. + +You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. + + 2. You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. + + b) You must cause any work that you distribute or publish, that in + whole or in part contains or is derived from the Program or any + part thereof, to be licensed as a whole at no charge to all third + parties under the terms of this License. + + c) If the modified program normally reads commands interactively + when run, you must cause it, when started running for such + interactive use in the most ordinary way, to print or display an + announcement including an appropriate copyright notice and a + notice that there is no warranty (or else, saying that you provide + a warranty) and that users may redistribute the program under + these conditions, and telling the user how to view a copy of this + License. (Exception: if the Program itself is interactive but + does not normally print such an announcement, your work based on + the Program is not required to print an announcement.) + +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it. + +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. + +In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + + 3. You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: + + a) Accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of Sections + 1 and 2 above on a medium customarily used for software interchange; or, + + b) Accompany it with a written offer, valid for at least three + years, to give any third party, for a charge no more than your + cost of physically performing source distribution, a complete + machine-readable copy of the corresponding source code, to be + distributed under the terms of Sections 1 and 2 above on a medium + customarily used for software interchange; or, + + c) Accompany it with the information you received as to the offer + to distribute corresponding source code. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form with such + an offer, in accord with Subsection b above.) + +The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable. + +If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. + + 4. You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance. + + 5. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it. + + 6. Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. + + 7. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. + +If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. + +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 8. If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License. + + 9. The Free Software Foundation may publish revised and/or new versions +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + +Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and "any +later version", you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +this License, you may choose any version ever published by the Free Software +Foundation. + + 10. If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally. + + NO WARRANTY + + 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. + + 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. + + END OF TERMS AND CONDITIONS diff --git a/local/LICENSES/OpenSolaris_License-CDDL.pdf b/local/LICENSES/OpenSolaris_License-CDDL.pdf new file mode 100644 index 00000000..2f192632 Binary files /dev/null and b/local/LICENSES/OpenSolaris_License-CDDL.pdf differ diff --git a/local/LICENSES/README b/local/LICENSES/README new file mode 100644 index 00000000..b30a41e6 --- /dev/null +++ b/local/LICENSES/README @@ -0,0 +1,9 @@ + + This directory contains text of the license files that apply +to third-party sources in the IRAF system: + + GPL For the math$slalib and ecl$readline + OpenSolaris_License-CDDL.pdf For the XYACC parser (boot$xyacc) + UCAR For NCAR graphics + + diff --git a/local/LICENSES/UCAR b/local/LICENSES/UCAR new file mode 100644 index 00000000..f7f9a535 --- /dev/null +++ b/local/LICENSES/UCAR @@ -0,0 +1,94 @@ + + +From: "Meg McClellan" +Date: May 23, 2011 09:37:48 AM MST +To: David Silva +Cc: "Roger M. Wakimoto" , Betty Stobie , +Verne Smith , Mary Haley +Subject: Re: UCAR/NCAR copyright notice + +David: + +I am responding to the letter that you sent Roger Wakimoto with regard to +NOAO's continued use of NCAR Graphics, V.1. You can continue your use of +version 1 under the terms set forth at the following link. This allows for +your use of source code, and is not under the GPL. Let me know if you have +any further questions. + +http://www.ncl.ucar.edu/Download/NCL_source_license.shtml + +Regards, +Meg McClellan + + + + +----------------------------------------------------------------------------- +http://www.ncl.ucar.edu/Download/NCL_source_license.shtml + + +NCL Source Code License + +PLEASE READ THIS SOFTWARE LICENSE ("LICENSE") CAREFULLY. INDICATE YOUR +ACCEPTANCE OF THESE TERMS BY CHECKING THE "I have read and hereby accept the +NCL Source Code License Agreement" ON THE REGISTRATION PAGE. IF YOU DO NOT +AGREE TO ALL OF THE TERMS OF THIS LICENSE AND YOU DO NOT CHECK THE "I ACCEPT" +BOX, THE INSTALLATION PROCESS WILL NOT CONTINUE. +Copyright © 2007-2011 University Corporation for Atmospheric Research (UCAR). +All rights reserved. Developed by NCAR's Computational and Information +Systems Laboratory, UCAR, www.cisl.ucar.edu, with the following +contributions: + + +Contribution Copyright Source Link for Additional Terms + +dcdflib The Univ. of Texas, http://www.netlib.org/random/ + M.D. Anderson Cancer + Center +FFTPACK5 Copyright © 1995-2011 http://www2.cisl.ucar.edu/resources/legacy/fftpack5 + UCAR +GRIBEX Copyright © 1981-2007 http://www.ecmwf.int/products/data/software/grib.html + European Centre for + Medium-Range Weather + Forecast +LAPACK Copyright © 1999 http://www.netlib.org/lapack/lug/lapack_lug.html + Society for Industrial + and Applied Mathematics +random The Univ. of Texas, http://www.netlib.org/random/ + M.D. Anderson Cancer + Center +RANGS / GSHHS Dr. Rainer Feistel http://www.io-warnemuende.de/homepages/rfeistel/ + Baltic Sea Research + Institute Warnemunde +Spherepack Copyright © 2004-2011 http://www2.cisl.ucar.edu/resources/legacy/spherepack/ + UCAR +UDUNITS-2 Copyright © 2008, 2009 http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2.html + Univ, Corporation for + Atmospheric Research + UCAR/Unidata +Udunits David Pierce, UCSD http://meteora.ucsd.edu/~pierce/ncview_home_page.html +extensions +from ncview + + + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions are met: + +Neither the names of NCAR's Computational and Information Systems Laboratory, +the University Corporation for Atmospheric Research, nor the names of its +contributors may be used to endorse or promote products derived from this +Software without specific prior written permission. +Redistributions of source code must retain the above copyright notices, this +list of conditions, and the disclaimer below. +Redistributions in binary form must reproduce the above copyright notice, +this list of conditions, and the disclaimer below in the documentation and/or +other materials provided with the distribution. +THIS SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING, BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, INDIRECT, +INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES OR OTHER LIABILITY, +WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR +IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH THE +SOFTWARE. diff --git a/local/bugs.log b/local/bugs.log new file mode 100644 index 00000000..8b9c0c4a --- /dev/null +++ b/local/bugs.log @@ -0,0 +1,8527 @@ +# BUGS.V29 -- Known bugs in the frozen IRAF Version 2.9 (and previous +# versions). Started 15JUN90. +# +# Record Format: +# +# NUMBER: record number, decimal, sequential. +# MODULE: package.task or library.procedure or 'unknown' or ... +# SYSTEM: versions of iraf in which bug was present +# DATE: date bug logged, unix format date string +# FROM: user login name +# BUG: description of the bug +# STATUS: 'fixed in V2.X', 'unresolved', etc. +# +# New records are added to the tail of the bugfile. Left justify field labels, +# indent text to the first tab stop, one blank line between bug entries. +# ---------------------------------------------------------------------------- + +NUMBER: 120 +MODULE: apphot.daofind +SYSTEM: V2.8 +DATE: Fri Mar 30 08:02:12 MST 1990 +FROM: davis + +BUG: In rare circumstances daofind may abort with a "pixel file truncation + error" when trying to read back the convolved images it has just + written. This only occurs on certain sized images and is due to + the interaction of the read, write and boundary extension in image + i/o. For example daofind works fine on a 640 by 1024 image but fails on + one that is 641 by 1025 pixels. + +STATUS: The problem is fixed in 2.9. The solution was to add an imflush + statement to flush the image i/o buffers after the write was + complete and before initiating the read. There is no workaround. + Contact the IRAF group for a fix. + +NUMBER: 121 +MODULE: utilities.curfit +SYSTEM: V2.9 +DATE: Mon May 21 15:12:40 MST 1990 +FROM: sjacoby + +BUG: The errors in the coefficients reported by CURFIT are incorrect when + points have been rejected from the sample by the iterative rejection + algorithm. User deleted points are handled properly, but points + automatically rejected by sigma criteria are being incorrectly + included in the coefficient error calculation. + +STATUS: The bug is fixed in V2.10. There is no workaround, unless the user + can identify and delete by hand those points the algorithm would reject. + +NUMBER: 122 +MODULE: cl +SYSTEM: V2.9 DECstation/IRAF +DATE: Wed May 23 20:58:47 MST 1990 +FROM: tody + +BUG: If IRAFARCH is not defined in the user environment, an attempt + to run the CL in DECstation/IRAF will fail with the message + "... /bin.f68881/cl.e not found". This is caused by a malformed + if-else (missing else) on line 41 of hlib$cl.csh. + +STATUS: A simple workaround is to define "setenv IRAFARCH mips" in the + user environment before starting the CL. This bug is so easy to + fix however, that a permanent fix is probably the best approach. + Merely edit the file iraf/unix/hlib/cl.csh and change the "if" on + line 41 to "else if". + +NUMBER: 123 +MODULE: imtranspose +SYSTEM: V2.9 +DATE: Wed Jun 6 08:37:42 MST 1990 +FROM: davis + +BUG: Imtranspose fails with an "unknown pixel type error" on image of + type ushort. + +STATUS: The bug has been fixed in 2.10. There is no workaround except to + change the pixel type of the image to int or long. + +NUMBER: 124 +MODULE: proto.imedit +SYSTEM: V2.9, V2.8 +DATE: Wed Jun 6 09:22:54 MST 1990 +FROM: valdes + +BUG: The fixpix format input interpolates across the longer dimension + rather than the shorter dimension. If the region is a complete + column/line then no correction is made. + +STATUS: Now fixed. For square or nearly square regions the interpolation + across the longer dimension is probably adequate. Other workarounds + are to use FIXPIX itself or convert the fixpix format file to regular + cursor input to imedit (which then also allows use of any of the other + options). + +NUMBER: 125 +MODULE: apextract.apscatter +SYSTEM: V2.9 +DATE: Mon Jun 11 17:35:22 MST 1990 +FROM: valdes + +BUG: When specifying a "line" to be plotted a check is made against the + wrong image axis; i.e. if a line is specified then it forced to + be in the range 1 to the number of image columns and vice-versa + for the other axis. + +STATUS: This has been fixed. There is no workaround but the task will + still function correctly even though it is not possible to examine + some image lines or columns. The effect becomes obvious only in + significantly nonsquare images. + +NUMBER: 126 +MODULE: apphot package +SYSTEM: V2.9 +DATE: Wed Jun 27 16:47:34 MST 1990 +FROM: davis + +BUG: Due to fractional pixel effects the sky fitting routines in apphot + can fail to preallocate enough space to hold the sky pixels, resulting + in a memory corruption error or a segmentation violation on exit + from a task. This condition occurs rarely most often when the sky + fitting annulus is very narrow. All the apphot tasks which do + sky fitting are affected. + +STATUS: The bug is fixed in 2.10. There is no workaround although increasing + the width of the sky fitting annulus slightly may bypass the + problem. Contact the IRAF group for a fix. + +NUMBER: 127 +MODULE: artdata.mkobjects +SYSTEM: V2.9 +DATE: Mon Jul 2 11:41:14 MST 1990 +FROM: valdes + +BUG: Objects which fall partially off the lower edges of the image + (objects with centers near the (1,1) image origin) are shifted + by 1 pixel to larger coordinates. + +STATUS: This bug is caused by incorrect rounding of negative numbers. The + bug has been fixed. The workarounds are to either compensate + for the error in the analysis or offset the coordinates to + larger values (say by using the offset parameters) and make a + larger image which can then be trimmed with IMCOPY. The tricky + thing is knowing when the objects go off the edge since the + full object size depends on seeing and the specified dynamic range. + +NUMBER: 128 +MODULE: IMFORT +SYSTEM: V2.9 +DATE: Tue Jul 10 10:33:02 MST 1990 +FROM: tody + +BUG: In IRAF V2.9, IMFORT has a bug which prevents access to images not + in the current working directory. If one tries to access an image + using a pathname an error message such as "image not found (.imh)" + is seen. + +STATUS: The workaround is to CD (SET DEF) to the directory before accessing + the image. A patch (patch #2) is available in the IRAF network + archive which can be installed to fix the bug. Installation + instructions are given in the README files for each supported + architecture (SOS4, VMS5, etc.). + +NUMBER: 129 +MODULE: onedspec.splot, onedspec.calibrate +SYSTEM: V2.9 +DATE: Tue Jul 10 17:07:46 MST 1990 +FROM: valdes + +BUG: In SPLOT the first pixel is ignored. In CALIBRATE the wavelength + scale for extinction correction will be in error by one pixels. + +STATUS: These two bugs are related because the header parameter NP1, + which is the offset to the first valid pixel, should be zero in + most cases but a bug fix in Nov. 1989 put in a minimum value of 1. + The symptom in SPLOT is to lose the first pixel but the + wavelength scale is correctly compensated. In CALIBRATE the + wavelength scale is not compensated though the error should be + extremely small since the calibrations are interpolations from + a smooth curve. There is no easy work around for SPLOT. If + the one pixel wavelength error in CALIBRATE is a concern one + could reset the wavelength zero point parameter W0 or CRVAL1 to + be greater by WPC or CDELT1; i.e. make the starting wavelength + parameter refer to pixel 2. Note that this will make the + wavelengths wrong for SPLOT and other ONEDSPEC tasks. This bug + is corrected in V2.10. + +NUMBER: 130 +MODULE: artdata.mkobjects +SYSTEM: V2.9 +DATE: Thu Jul 19 15:14:14 MST 1990 +FROM: valdes + +BUG: The radius parameter for the "gaussian" model PSF is being used as + a full width instead of a radius as intended and described in the + documentation. The effect is to give narrower stars than expected. + +STATUS: The workaround is to give a FWHM for the gaussian model instead of + a radius at half maximum. + +NUMBER: 131 +MODULE: artdata.mkobjects +SYSTEM: V2.9 +DATE: Mon Jul 23 10:53:43 MST 1990 +FROM: valdes + +BUG: The moffat function size scaling (as set by the radius parameter) + is incorrect. + +STATUS: The shape of the function is based on the correct beta but the size + is scaled for a function with beta of: + + beta1 = 2 * beta - 2 + + Another way to look at it is that the flux level corresonding to + the specified radius is different than the half intensity. The + actual flux level is: + + F(radius) = 0.5 ** (beta / beta1) + + Finally, the radius which must be specified, rfudge, to get a + desired radius at half intensity, rhalf, is: + + rfudge = rhalf * sqrt ((2**(1/beta1)-1) / (2**(1/beta)-1)) + + Note that there is no error for beta=2, the size is too large + for beta>2, and the size is too small for beta<2. + + The workaround is to adjust the specified radius for a desired + radius at half intensity using the above formula. + +NUMBER: 132 +MODULE: utilities.curfit +SYSTEM: V2.9 +DATE: Mon Jul 30 17:37:48 MST 1990 +FROM: davis + +BUG: Curfit was crashing with a segmentation violation when it tried to + fit the second file of data or second image in a list of images. + The pointer to the icfit data structure was being freed after + the first file of data was fit and not reallocated before the + next fit resulting in a reference to an undefined pointer. + +STATUS: The bug has been fixed in 2.10. There is no workaround except + to use a script to loop over a large number of input data files. + +NUMBER: 133 +MODULE: math$gsurfit/dgsder +SYSTEM: V2.9 +DATE: Wed Aug 1 16:27:43 MST 1990 +FROM: davis + +BUG: Due to a typographical error in the file math$gsurfit/gsder.gx, + dgsder (the routine which computes the derivative of a double + precision surface) was inadvertantly calling salloc with a pointer + address instead of an array size. If the assigned pointer value + is very large this can cause an "out of memory error" in any task + which calls dgsder. + + Currently the only task affected by this bug is TRANSFORM + in the LONGSLIT package. + +STATUS: The bug is fixed in 2.10. There is no workaround. Contact NOAO for + a fix. + +NUMBER: 134 +MODULE: XC (SPP compiler) +SYSTEM: Sun/IRAF V2.9 (Sun systems only) +DATE: Wed Aug 8 10:04:34 MST 1990 +FROM: tody + +BUG: Sun/IRAF V2.9 will not work with the SunOS 1.3 or 1.3.1 Fortran + compiler (which Sun came out with after IRAF was released). The + new Sun compiler locates important executables such as f77, cc, + etc., in a nonstandard place, one of the Fortran libraries has + been done away with, the command line arguments have changed, + etc. (in short Sun has completely revamped their compiler). + +STATUS: A new version of XC is available from IRAF site support which + will work with the new compiler. Note that although this allows + the compiler to be used, and it appears to be possible to compile + and link programs, the IRAF V2.9 libraries were compiled with the + old Sun Fortran compiler and we cannot be certain that these + libraries are fully compatible with the new compiler and its + libraries. Also, the default host compiler flags supplied with + Sun/IRAF MKPKG are not necessarily what is best for the new + compiler. Most likely these are not serious problems, but + Sun/IRAF will not fully support the new compiler until we have had + time to recompile the full system for a future release. + +NUMBER: 135 +MODULE: noao.artdata.mkobjects +SYSTEM: V2.9 +DATE: Thu Aug 9 09:24:41 MST 1990 +FROM: valdes + +BUG: The general cumulative profile file input for both the PSF and a + an object type does not work. The error is can't open image + even though the file is not an image. + +STATUS: This bug is due to the inability of the image access checking routine + to distinguish images from regular files. Because of the order + of the logic the task always checks to see if the specified file + is an image template first, decides it is an image, and then + fails with the error can't open image. There is no work around. + Those requiring this capability wil have to contact site support + for help. + +NUMBER: 136 +MODULE: wfits/rfits +SYSTEM: V2.9 +DATE: Mon Aug 27 07:37:57 MST 1990 +FROM: davis + +BUG: Wfits sometimes crashed with a segmentation violation when + files were written with a non-standard block size (block_factor > 10). + The error was in the code which 0-filled the unused portion of the + last output block, and occurred if the unused portion of that + block was greater than 2880 bytes. + + Rfits sometimes reported read errors when it tried to read tapes + with a non-standard block size (blocks not a multiple of 2880 + bytes). Rfits was not always counting the number of characters read + from the tape correctly when the read attempted to cross tape record + boundaries. Tapes with small block sizes like 512 and 1024 were + the most affected. + +STATUS: Both bugs have been fixed in version 2.10 and the 2.9.1 patch. + +NUMBER: 137 +MODULE: IMDKERN +SYSTEM: V2.9 +DATE: Thu Sep 6 11:59:44 MST 1990 +FROM: tody + +BUG: There is a bug in the V2.9 version of the IMDKERN graphics kernel + (used to draw color graphics overlays on the image display) which + can cause the kernel to die on a segmentation violation when run + as a connected subkernel. + +STATUS: The workaround is to spool the graphics metacode for the plot in + a file and then plot this file using the IMDKERN task in PLOT. + The bug is fixed in the V2.9.1 patch, available from the IRAF + network archive. + +NUMBER: 138 +MODULE: images.convolve +SYSTEM: V2.9 +DATE: Wed Nov 28 13:38:17 MST 1990 +FROM: davis + +BUG: CONVOLVE was terminating with the error "Kernel rows are different + lengths" if the user supplied a 1D kernel without the terminating + delimiter character ';'. For example the valid kernel "1.0 2.0 1.0;" + would work but the equally valid "1.0 2.0 1.0" would not. 2D kernels + did not have this problem. + +STATUS: The bug is fixed in IRAF 2.10. The workaround is to always append + the delimiter character to the kernel. + +NUMBER: 139 +MODULE: noao.artdata.mkobjects +SYSTEM: V2.9-V2.9.1 +DATE: Tue Dec 4 12:00:32 MST 1990 +FROM: valdes + +BUG: Memory associated with the stellar, galaxy, and cosmic ray templates + is not freed in the tasks MKOBJECTS and MKNOISE. Repeated executions + (without flushing the process) eventually overflows the swap + space or causes out of memory errors. + +STATUS: The bug is caused by a simple typo and has been fixed. Large amounts + of memory are tied up only with a large number of repeated calls. + Normally all objects are created in one step rather than repeated + calls to add individual objects and so there is generally no + difficulty. The work around when using these tasks in a loop + is to add a "flprcache" call to flush the process after each + call or set of calls. + +NUMBER: 140 +MODULE: dataio.rfits +SYSTEM: V2.9 +DATE: Thu Dec 6 11:38:42 MST 1990 +FROM: davis + +BUG: A command of the form "rfits mta 1-8 "" oldirafname+" will generate + the message "ERROR: T_RFITS: Error reading output file name" because + the code was not dealing properly with an empty output file list. + +STATUS: Rfits has been modified in 2.10 so that a temporary output file + name is created if oldirafname is true or a clear error message + is generated if oldirafname is false, and the user has set the + output file name to "". The workaround is to avoid setting + the output file name to "". + +NUMBER: 141 +MODULE: identify +SYSTEM: V2.9 +DATE: Wed Dec 19 16:47:06 MST 1990 +FROM: valdes + +BUG: The automatic line identification algorithm fails to find some + lines in certain circumstances. + + The source of the problem is when multiple lines in the line + list end up being centered in the same place in the data. For + example if two lines in the list are 4888.1234 and 4889.1234, + the second one is intrinsically weak, and the data is low + resolution (say 3A per pixel) then as far as the data is + concerned there is just one line. This line will be marked + twice with the same position but different wavelengths. The + complication is that valid weaker lines will be removed based + on the maxfeatures criteria (for example only the 50 highest + peak values are kept of which say 10 are multiple assignments + to the same peaks in the data). Then after the lines are + found the minsep criteria is applied to winnow out the multiple + assignments to the same pixel leaving 40 lines found and 10 of + the weaker valid lines not found. This is a complex behavior + dependent on data resolution, the initial dispersion solution, + the line list (the problem occurs with dense line lists used + for high resolution such as the thorium list used with lower + resolution data), and the maxfeatures and match parameters. + +STATUS: The bug fix is to winnow out the multiple identifications to + the same pixel before selecting the maxfeatures strongest + lines. The workaround most likely to work is to reduce the + match parameter so that some of the multiple identifications + are thrown out based on wavelength differences with the + dispersion function estimates. Another thing is to increase + maxfeatures but this will result in many undesired weak lines. + + +NUMBER: 142 +MODULE: testphot.daophot.psf +SYSTEM: V2.9 +DATE: Tue Feb 5 16:39:13 MST 1991 +FROM: davis + +BUG: The task psf in testphot.daophot was writing incorrect values of the + zero point position of the psf "XPSF" and "YPSF" into the psf image + header. Although this was not a problem for the constant psf fitting + code, the variable psf fitting code was interpolating in the wrong + place in the look-up table, resulting in a very strange looking psf + fit. In effect the coordinate system of the look-up table was shifted + with respect to the image. + +STATUS: The bug has been fixed in the ftp archive version of testphot and on + all our local nodes (orion, gemini, ursa). Users can either get a + new version of testphot from the archive or contact the IRAF group + for a patch since only one file is affected. + +NUMBER: 143 +MODULE: images.imsurfit +SYSTEM: V2.9 +DATE: Mon Feb 25 10:03:39 MST 1991 +FROM: davis + +BUG: There is a bug in the bad pixel rejection code in the IMSURFIT task + which occurs when the parameter upper > 0.0 and lower = 0.0, or + if lower > 0.0 and upper = 0.0. In the former case all points with + negative residuals were rejected instead of none, and in the latter + case all points with positive residuals were rejected instead of + none. IMSURFIT was computing the rejection limits by multiplying + the computed standard deviation by upper and lower respectively + without checking for the zero case. + +STATUS: The big is fixed in IRAF 2.10. There is no workaround, except to + set upper or lower to very large values if you do not want to + reject pixels. + +NUMBER: 144 +MODULE: artdata +SYSTEM: V2.9.1 +DATE: Mon Mar 4 09:43:28 MST 1991 +FROM: valdes + +BUG: The tasks sometimes fail when the output image is in STF (.hhh) format. + This is due to a problem in how image header comments are put in + the image header affecting only the STF format. Note that the + original version released with V2.9 does not provide header + comments and so it does not have a problem. The newer version with + this STF header problem came as part of V2.9.1. + +STATUS: This problem has been fixed in the next version of the package. + The only workaround is to use OIF (.imh) format and then convert + to STF format with IMCOPY. + +NUMBER: 145 +MODULE: apextract +SYSTEM: V2.9 +DATE: Wed Mar 27 16:57:13 MST 1991 +FROM: valdes + +BUG: For some default background functions and sample regions a singular + solution error can occur. This is caused by defining the function + range to be the entire image dimension while the sample region is + only a small part of this range. It probably also depends on the + function type and order and the degree of curvature in the fitted + data. When apertures are read from the database or reset by the + 'b' mode in APEDIT the fitting limits are set to the limits of the + sample region. + +STATUS: The singular solution message should be harmless. Reading apertures + from a database does not have this problem. Entering the 'b' mode in + APEDIT (where the message might be seen) and exiting will fix the + fitting function properly. Of course if background subtraction + is not required this problem does not arise. The problem has + been fixed for V2.10. + +NUMBER: 146 +MODULE: images.geomap +SYSTEM: V2.9 +DATE: Tue Apr 9 14:08:45 MST 1991 +FROM: davis + +BUG: Geomap would not permit the user to fit cross-terms (terms containing + x*y) in the the x coordinate fit if xxorder=2 and xyorder=2, or in + the y coordinate fit if yxorder==2 and yyorder=2. For higher order + fits cross-term fitting was enabled. + +STATUS: This bug has been fixed in IRAF 2.10. There is no workaround. + +NUMBER: 147 +MODULE: ccdred.mkskycor ccdred.mkillumcor +SYSTEM: V2.9 +DATE: Tue Apr 16 16:42:36 MST 1991 +FROM: valdes + +BUG: The CCDMEAN parameter computed by the task MKSKYCOR and MKILLUMCOR + is computed incorrectly in the sense that it is smaller than the + correct value by a small amount. The last few lines of the image + were not accumulated before dividing by the number of pixels in + the output image. + +STATUS: This bug has been fixed for V2.10. One workaround is to use + yboxmin of 0. The other workaround is to use IMSTATISTICS and + HEDIT to compute and replace the correct value. Failing to do so + and then correcting images with CCDPROC will slightly change the + data level which may be acceptable. + +NUMBER: 148 +MODULE: ecdispcor, msdispcor +SYSTEM: V2.9 +DATE: Mon Apr 22 13:23:09 MST 1991 +FROM: valdes + +BUG: The combining options "sum", "average", "minmax" do not work correctly. + The cause is failing to clear an array between each spectrum so + that as subsequent spectra are added the preceding spectra are + multiply added. + +STATUS: The workaround is to dispcor each order to the same dispersion + with onedspec output format and then add or average the spectra + with imcombine. The problem is fixed for V2.10. + +NUMBER: 149 +MODULE: artdata.mkobjects +SYSTEM: V2.9 +DATE: Mon Jun 10 10:44:47 MST 1991 +FROM: valdes + +BUG: The PSF position angle (parameter pa) is intended to be input + as degrees and converted internally to radians. The conversion is + not being done with the effect that the input position angle is + being interpreted as radians. + +STATUS: The conversion has been added to the program; a simple use of + the DEGTORAD macro. The workaround is to specify the position + angle in radians. Note that the object position angles specified + in the object list are correctly interpreted as degrees. + +NUMBER: 150 +MODULE: dataio.wfits +SYSTEM: V2.9 +DATE: Tue Jun 11 13:04:44 MST 1991 +FROM: davis + +BUG: Wfits was setting the IRAFNAME image header keyword to a blank + string if the input image was a section. This was done originally + to avoid rfits trying to rename the output image (if parameter + oldirafname = yes) to an image section, but had the side effect + of making IRAFNAME useless for book-keeping purposes. + +STATUS: Wfits has been modified in 2.10 to write the full image specification + including the image section but minus the directory specification + in the IRAFNAME keyword. Rfits has been modified to check for and remove + any image section before renaming the output image to the orginal + iraf name. If the renaming fails for any reason, then the name + specified by the iraf_file parameter will be used as before. + +NUMBER: 151 +MODULE: noao.twodspec.longslit.fitcoords +SYSTEM: V2.6-V2.9 +DATE: Fri Jul 12 08:38:03 MST 1991 +FROM: valdes + +BUG: Fitting a single trace made along the x or horizontal axis + does not work correctly. + +STATUS: The workaround is to transpose the data and trace the feature + vertically. This is corrected in V2.10. + +NUMBER: 152 +MODULE: images.imshift +SYSTEM: V2.9 +DATE: Mon Jul 29 11:42:28 MST 1991 +FROM: davis + +BUG: Imshift was not correctly initializing the shifts file descriptor to + NULL, when the shifts_file parameter was set to "", sometimes causing + a later conditional test in the code to fail. + + This bug is triggered when a user sets shifts_file to a file name + and then sets it back to "" without flushing the process cache, + as may happen after repeated executions in a script. + +STATUS: The bug has been fixed in 2.10. There is no workaround except to + flush the process cache between executions. + +NUMBER: 153 +MODULE: digiphot.apphot.apselect +SYSTEM: V2.9 +DATE: Mon Aug 12 15:07:29 MST 1991 +FROM: davis + +BUG: Apselect can sometimes fail with a segmentation violation if the + input file has variable length records, (as can be the case for + example if the user changes the number of apertures interactively, + or if the user has defined polygons of various sizes) + if the first record is not the longest record in the file, + and if the size of the variable length record exceeds 20, the + initial guess for buffer allocation. + +STATUS: The bug has been fixed in 2.10. There is no workaround except to + ensure that the longest record comes first in the output file. + +NUMBER: 154 +MODULE: proto.fixpix +SYSTEM: V2.9 +DATE: Tue Aug 13 12:27:17 MST 1991 +FROM: valdes + +BUG: Interpolation across columns with type double images does not work. + +STATUS: Fixed in V2.10. There is no workaround other than to avoid this + rare combination of datatype and direction of interpolation. + +NUMBER: 155 +MODULE: apphot.radprof +SYSTEM: V2.9 +DATE: Mon Aug 26 11:25:36 MST 1991 +FROM: davis + +BUG: 1. Radprof was computing the total intensity of the fitted radial + profile by integrating (RP) instead of the physically meaningful + quantity 2 * PI * (r * RP). + + 2. The computed total intensity (TINORM) was too small by a factor + equal to the profile step size in pixels, although the shape of the + curve was correct. + +STATUS: Both bugs have been fixed in 2.10. Bug 1 was fixed some time ago + at the request of a user at ST, but was not previously logged. + There is no workaround. Bug 2 was only recently discovered. + The workaround is to multiply the quantity TINORM by the step size + in pixels, and compare it to the aperture photometry results. + The two numbers should be equal to within the expected errors. + +NUMBER: 156 +MODULE: images.imstatistics +SYSTEM: V2.9 +DATE: Tue Sep 24 09:17:16 MST 1991 +FROM: davis + +BUG: The mode statistic was not being computed correctly in imstatistics, + because the parabolic interpolation correction for computing the + histogram peak was being applied in the wrong direction. + +STATUS: The bug has been fixed in IRAF 2.10 and the help page which uses + dev$pix as an example has been modified appropriately. There is no + workaround. + +NUMBER: 157 +MODULE: XC compiler +SYSTEM: V2.9 Sun/IRAF, all versions +DATE: Wed Oct 9 14:22:11 MST 1991 +FROM: tody + +BUG: XC will not recognize the V1.4 Sun Fortran compiler. The bug is due + to XC looking for V1.3 and finding V1.4 instead. + +STATUS: The workaround is to do a "ln -s f77-1.4 f77-1.3" in /usr/lang, or + wherever the compiler is installed. + +NUMBER: 158 +MODULE: dataio.rfits +SYSTEM: V2.9 +DATE: Wed Oct 9 15:50:36 MST 1991 +FROM: davis + +BUG: IRAF 2.9 rfits was not reading fits files with short last logical + records correctly, i.e. records not correctly padded out to 2880 + bytes. For each output image line contained or partially contained + in the final short record, an error message was generated, + and incorrect data was written to the output image. + +STATUS: The bug has been fixed in 2.10 and was not a problem in IRAF 2.8 + and earlier. The workaround is to use Unix dd command or the IRAF + reblock task to reformat the file. + +NUMBER: 159 +MODULE: images.imstatistics +SYSTEM: V2.9 +DATE: Fri Oct 11 13:54:19 MST 1991 +FROM: davis + +BUG: The computed value of the kurtosis was 1.0 too small, i.e. a + Gaussian distribution would have a computed kurtosis of -1.0 + instead of 0.0. + +STATUS: The bug has been fixed in IRAF 2.10. The workaround is to add + 1.0 to the computed value of the kurtosis. + +NUMBER: 160 +MODULE: onedspec.standard +SYSTEM: V2.9 +DATE: Thu Oct 17 09:22:06 MST 1991 +FROM: valdes + +BUG: If the calibration bandpasses are less than a pixel wide the flux + summation is incorrectly done when both endpoints are within the + same pixel; the code assumed that the two endpoint pixels were + not the same. Generally the calibration data, in onedstds$, has + much larger bandpasses than typical spectra and so this bug has + not be seen except in one reported case where a private calibration + file with very small bandpasses was used. + +STATUS: Fixed in V2.10. The workarounds are to revise the calibration + file to larger bandpasses (if using a private version), resample + the spectra to smaller dispersion, or, the best choice, specify + the bandpass widths and separations in the task to override the + calibration file bandpasses and interpolate the calibration file + data. + +NUMBER: 161 +MODULE: apextract.apsum +SYSTEM: V2.9 +DATE: Wed Oct 30 11:02:38 MST 1991 +FROM: valdes + +BUG: If the background regions go off the image, due to tilts in the + spectrum such as with echelle data, while the object apertures + remains on the image a segmentation violation occurs. This will + only happen with one-sided background regions as otherwise this + condition could not occur. The error is caused by a failure to + check for an error condition from background fitting. + +STATUS: This error is fixed in V2.10. The workaround is to insure + at least part of the background regions are on the image while the + object aperture is on the image. This would be true if background + regions are defined on both sides of the aperture. Note that it is + ok for the object aperture and background regions to both be off + the the image. The source fix is simple and could be supplied if + absolutely necessary. + +NUMBER: 162 +MODULE: reidentify +SYSTEM: V2.9 +DATE: Mon Nov 18 10:27:25 MST 1991 +FROM: valdes + +BUG: If reference features are identified in user coordinates other than + pixels, usually Angstroms for arc lines, and the user forgets to + type 'f' to fit a dispersion function, then REIDENTIFY will + compute a very large coordinate shift and then fail to trace + any features. + +STATUS: The workaround is to recognize this behavior and then go back and + do a dispersion function fit for the reference. The logical bug + in the task is fixed in V2.10. + +NUMBER: 163 +MODULE: artdata.gallist +SYSTEM: V2.9 +DATE: Tue Nov 26 17:07:03 MST 1991 +FROM: valdes + +BUG: The randomization of the galaxy size distribution when using the + Schecter luminosity function is incorrect. Instead of a 20% range + about the scaled eradius/sradius for a given magnitude a range of + 100% is computed coupled with a reduction of the size by a factor + of 2.5. + +STATUS: There is no workaround for the increased dispersion but the factor + of 2.5 in the size can be compensated by adjusting the eradius + parameter. This has been fixed in V2.10 + +NUMBER: 164 +MODULE: artdata.gallist +SYSTEM: V2.9 +DATE: Tue Nov 26 17:11:37 MST 1991 +FROM: valdes + +BUG: The axial ratios for elliptical galaxies when a mixture of spiral + elliptical galaxies is computed are incorrect. In particular + there will be axial ratio values greater than 1 in the output + file. + +STATUS: The work around is to compute the elliptical and spiral galaxy + data separately. This has been fixed in V2.10. + +NUMBER: 165 +MODULE: plot.pvector, proto.imexamine +SYSTEM: V2.9 +DATE: Wed Dec 11 11:32:36 MST 1991 +FROM: davis + +BUG: Profiles computed and plotted using the pvector task or the 'v' + key in imexamine occasionally show glitches, where 1-3 pixels + have bad values. This bug was traced to any error in + the column limits computed by the code which reads the + image pixels. As a result the image interpolator was requesting + values off the ends of the pixel array producing bad output values. + +STATUS: The bug has been fixed in 2.10. There is no workaround. + +NUMBER: 166 +MODULE: apphot.polyphot +SYSTEM: V2.9 +DATE: Tue Feb 25 16:37:41 MST 1992 +FROM: davis + +BUG: The intersection points of an image line and a polygon could be + incorrectly translated into a list of line segments if the polygon + was concave and contained one or more sides exactly collinear with + the image line. The symptom of this problem is a larger than expected + difference (larger than can be accounted for by fractional pixel + effects) in the computed area of the polygon as it is shifted + to different positions in the image (shifting by floating point + numbers tends to remove the condition of exact collinearity); + or larger than expected differences in the area and flux + of the same object measured with the same polygonal aperture + at slightly different positions in different images (again + shifting the polygon tends to remove the condition of exact + collinearity). + +STATUS: The bug has been fixed in 2.10. There is no work around except to + alter the shape of the polygon slightly. + +NUMBER: 167 +MODULE: images.imstatistics +SYSTEM: V2.9 +DATE: Tue Mar 10 14:58:59 MST 1992 +FROM: davis + +BUG: Precision was being lost unnecessarily in the computation of the + standard deviation, skew, and kurtosis because two of the + intermediate variables in the computation were real instead of + double precision. + +STATUS: The bug is fixed in 2.10. There is no workaround. + +NUMBER: 168 +MODULE: noao.twodspec.longslit.fluxcalib +SYSTEM: V2.9 +DATE: Thu Mar 19 11:27:18 MST 1992 +FROM: valdes + +BUG: Flux calibrating a short pixel type image will produce a short + pixel type output image which is generall all zeros since the + typical flux values are of order 10e-14. + +STATUS: The workaround is to convert the images to real (with chpixtype for + instance) before flux calibrating. For V2.10 the output image + will be of type real pixels. + +NUMBER: 169 +MODULE: imred.irs.batchred, imred.iids.batchred +SYSTEM: V2.10 +DATE: Mon Jul 6 10:01:35 MST 1992 +FROM: valdes + +BUG: The PROCESS script generated by BATCHRED included parameters no + longer part of STANDARD and CALIBRATE. Running this task produces + the error + + ir> process + ERROR on line 9: parameter `recformat' not found + process () + process () + +STATUS: To be fixed in V2.10.0. The workaround is to edit the process.cl + script generated by BATCHRED and delete two cases of "recformat=yes," + and one case of "apertures='',". + +NUMBER: 170 +MODULE: apphot +SYSTEM: V2.9 +DATE: Wed Jul 8 17:43:45 MST 1992 +FROM: davis + +BUG: The apphot tasks were failing to close up the coordinate files + in the case that 1) the number of input images was greater + than one and 2) the input coords parameter was set to "default". + If the input image list was sufficiently long the task could run + out of file descriptors producing a system error. + +STATUS: The bug is fixed in 2.10.0. The workaround is to break the image + lists into smaller groups (<= ~ 60). + +NUMBER: 171 +MODULE: apextract.apfit, apextract.apflatten +SYSTEM: V2.10.0 +DATE: Thu Jul 9 16:17:01 MST 1992 +FROM: valdes + +BUG: In these tasks which output the difference, ratio, or fit + based on a profile model the profile model is low by a factor of + the gain. Thus if the gain is not one the results will not be + correct. For example APFLATTEN will produce flat field values + within the aperture which are multiplied by the gain except outside + the apertures. The workarounds are either to use a gain of 1 or + correct the output such as with IMARITH. The latter option may be + difficult to apply for APFLATTEN since special steps need to be + taken for the interaperture values. Note that using an gain of 1 + even though the true gain is higher will often be unimportant, + especially if cosmic ray cleaning is not done. + +STATUS: Fixed in V2.10.1. + +NUMBER: 172 +MODULE: onedspec +SYSTEM: V2.10.0 +DATE: Mon Jul 20 14:24:07 MST 1992 +FROM: valdes + +BUG: The ability to extract and operate on long slit images using the + dispaxis/nsum parameters does not work. There is no workaround; + which is particularly unfortunate since TOONEDSPEC is no longer + available. One must resort to APEXTRACT to extract 1D spectra + from long slit images. + +STATUS: Fixed in V2.10.1 + +NUMBER: 173 +MODULE: images.gauss +SYSTEM: V2.10 +DATE: Thu Jul 23 08:17:27 MST 1992 +FROM: davis + +BUG: An incorrect convolution kernel is computed in the case theta=90.0, + 0.0 < ratio < 1.0, and bilinear=yes. The long axis of the kernel is + aligned along the x axis instead of the y axis as intended. + + The workaround is to set bilinear=no. + +STATUS: Fixed in 2.10.1 + +NUMBER: 174 +MODULE: onedspec.dopcor +SYSTEM: V2.10.1 +DATE: Thu Jul 30 16:29:31 MST 1992 +FROM: valdes + +BUG: There is a sign error in the conversion from velocity to redshift. + Thus one has to change the sign of velocities to get the effect + described in the documentation. The documentation was also + misleading in how to add a redshift in that one needs to complement + the redshift (1/(1+z)-1) rather than reverse the sign of the + redshift. The example is therefore incorrect. + +STATUS: The task has been modified to correct the sign error and to add + consistency checks on the redshifts and velocities. The help + has been improved and the erroneous example corrected. + +NUMBER: 175 +MODULE: tv.imexamine +SYSTEM: V2.9-V2.10.1 +DATE: Fri Jul 31 12:06:34 MST 1992 +FROM: valdes + +BUG: Attempting to use a single column or line at the top or left edge + (high column/line numbers) of an image yields an out-of-bounds + message. For some reason (typo?) the simple test for out-of-bounds + had an greater than or equal to with the edge rather than a greater + than. There is no workaround. + +STATUS: Fixed for V2.10.2 + +NUMBER: 176 +MODULE: images.imsurfit +SYSTEM: V2.9.2 and later +DATE: Mon Aug 3 15:12:01 MST 1992 +FROM: davis + +BUG: There is a typo in the imsurfit code which reads the sections file, + which can result in some sections specified by the user being ignored + in the fitting process. Whether or not the code executes correctly + depends on section specifications themselves since the intended + test "if (y2 < y1)" was actually coded as "if (y2 < x1)". + +STATUS: The bug is fixed in 2.10.1. There is no workaround. + +NUMBER: 177 +MODULE: images.imcombine, ccdred.combine, onedspec.scombine +SYSTEM: V2.10-V2.10.1 +DATE: Wed Aug 12 10:30:19 MST 1992 +FROM: valdes + +BUG: The minmax rejection option when used with a final average and with + weights does not correct for the rejected pixels in the weights + normalization. For example with four images having identical + weights and rejecting the high and low the final output is the sum + of the middle pixels divided by 4 instead of 2. There is no + workaround. If the weights are equal the end result is just that + the mean intensity levels are low by a constant factor. However, + when the weights are not equal the final result will have pixel + position dependent effects. + +STATUS: Fixed for V2.10.2 + +NUMBER: 178 +MODULE: images.fmedian +SYSTEM: V2.9 +DATE: Tue Aug 18 11:31:49 MST 1992 +FROM: davis + +BUG: The fmedian task can crash with a segmentation violation or a + floating operand error if image pixel to integer mapping is turned + off (hmin = zmin and hmax = zmax) and the input image contains + data outside the range defined by zmin and zmax. The bug is not + seen often because for most ccd images the data is between -32768 + and 32767. + +STATUS: The bug is fixed in 2.10.1. The work-around is to either let zmin and + zmax default to the image minimum and maximum or set hmin and hmax + to numbers that are slightly different from hmin and hmax. + +NUMBER: 179 +MODULE: daophot.allstar +SYSTEM: V2.10 +DATE: Wed Sep 16 14:37:46 MST 1992 +FROM: davis + +BUG: If 1) cache=no, or cache=yes and memory preallocation fails for one or + more of the data, scratch or weight arrays, 2) one or more of the + groups has greater than maxgroup stars, 3) regrouping is + performed on the too large group and 4) the first star in the + next non-regrouped group has a y value less than the y value of + the first star in one of the regrouped groups, allstar can + fail with an "attempt to access the scratch, weight, or data pixels + randomly" error. + +STATUS: The bug is fixed in 2.10.2. Possible work arounds include: 1) setting + cache=yes instead of no if the machine has enough memory and swap + space 2) setting the maxgroup parameter to a larger value than the + default value of 60 3) decreasing the fitting radius somewhat since + this affects the grouping process. + +NUMBER: 180 +MODULE: identify/reidentify +SYSTEM: V2.10.1 +DATE: Wed Sep 16 16:24:05 MST 1992 +FROM: valdes + +BUG: If a spectrum is shifted using IMSHIFT with a positive shift + then the physical pixel coordinates are incorrectly computed. + The workaround is to reset the WCS with WCSRESET. + +STATUS: Fixed in V2.10.2. + +NUMBER: 181 +MODULE: ccdred.ccdproc +SYSTEM: V2.9(?) V2.10.1 +DATE: Tue Sep 22 08:40:14 MST 1992 +FROM: valdes + +BUG: When using STF images with a flat field that has been processed but + has lost the CCDMEAN keyword CCDPROC will produce an error of the + form: + + ERROR: OPEN: File does not exist (tmp4294ha.hhd) + + A flat field in this state would most likely be produced by + FLATCOMBINE with preprocessing before combining selected. The + combined flat field will lack the CCDMEAN keyword. + + The workarounds are to either use OIF images or add the CCDMEAN + keyword manually. This would be done by using IMSTAT to compute + the mean and adding the CCDMEAN keyword with that value using + HEDIT. + +STATUS: The error is ignored by CCDPROC in V2.10.2. The reason for the + error when calling imunmap with an image which has been created + but for which no pixel data has been written is under investigation. + +NUMBER: 182 +MODULE: apnormalize +SYSTEM: V2.10.1 +DATE: Tue Sep 22 13:40:26 MST 1992 +FROM: valdes + +BUG: The parameter t_nlost is missing from the parameter file apnorm1.par. + When attempting to run APNORMALIZE there will be an error message + concerning this parameter. It can be fixed if desired by adding + the following line after line 63 in the file + iraf$noao/twodspec/apextract/apnorm1.par: + + t_nlost,i,h,)aptrace.nlost,,,>aptrace.nlost + + After adding this parameter one must "unlearn apnorm1". There is + no workaround other than to add the parameter. + +STATUS: Fixed in V2.10.2 + +NUMBER: 183 +MODULE: doargus, dohydra, dofibers, skysub +SYSTEM: Newimred, V2.10.0, V2.10.1 +DATE: Wed Sep 23 15:57:40 MST 1992 +FROM: valdes + +BUG: When using the skyedit option to review and eliminate bad sky + apertures there is a limit to the number of sky apertures that + can be retained. Exceeding this limit can cause the CL to crash. + The limit is determined by how many aperture + numbers can be fit into 160 characters in a string of the form + 11,12,13,...; for 2 digit aperture numbers this would be a + little over 50 sky apertures. The workarounds are to use less + than about 50 sky apertures or to not use the sky edit option. + +STATUS: Planned to be fixed in V2.10.2. + +NUMBER: 184 +MODULE: splot +SYSTEM: V2.10.1 +DATE: Thu Sep 24 08:48:57 MST 1992 +FROM: valdes + +BUG: The '(' and ')' keys for scrolling through multiple spectra images + does not work properly in cases where the aperture numbers are + not the same as the line number. The only workaround is to use + the explicit '#' key to access particular apertures. + +STATUS: Fixed in V2.10.2 + +NUMBER: 185 +MODULE: imcombine, ccdred.combine, onedspec.scombine +SYSTEM: V2.9 +DATE: Thu Oct 1 17:06:23 MST 1992 +FROM: valdes + +BUG: When using the CCDCLIP or CRRJECT rejection option with mclip=yes + (which is the default) a minimum of 3 images/spectra is required. + This means that two image/spectrum cosmic ray rejection doesn't + work as intended. The workaround is to use mclip=no. This is + equivalent for two images/spectra since the median and average are + the same in this case. + +STATUS: Fixed in V2.10.2. + +NUMBER: 186 +MODULE: ccdred.ccdproc +SYSTEM: V2.9-V2.10.1 +DATE: Mon Oct 26 11:04:21 MST 1992 +FROM: valdes + +BUG: If an image is processed which has an unknown CCD type it will have + the minimum replace operation applied to it. This operation is + only supposed to apply to flat field types. The workarounds are + to setup/define a translation allowing the CCD types to be + determined or to set the minreplace parameter to a very large + negative value to avoid limiting the data. Note that this will + only apply to data which has low or negative values in the first + place. + +STATUS: Fixed for V2.10.2. + +NUMBER: 187 +MODULE: echelle.dofoe +SYSTEM: V2.9 +DATE: Thu Oct 29 10:32:12 MST 1992 +FROM: valdes + +BUG: When there is a second arc it is incorrectly extracted with a + .ms extension instead of a .ec extension causing downstream + processing to fail. The workaround is to rename the file + to .ec and then start again. + +STATUS: Fixed in V2.10.2. + +NUMBER: 188 +MODULE: longslit.fitcoords +SYSTEM: V2.6-2.10.1 +DATE: Wed Nov 11 10:43:43 MST 1992 +FROM: valdes + +BUG: FITCOORDS is supposed to ignore features which have an INDEF + for the line identification. This was not happening but instead + some random value was substituted for the INDEF. The workaround + is to avoid creating features with INDEF in IDENTIFY. + +STATUS: In V2.10.2 any features with INDEF line ids will be ignored. + +NUMBER: 189 +MODULE: onedspec.splot/specplot +SYSTEM: V2.10-V2.10.2 +DATE: Fri Dec 4 09:41:16 MST 1992 +FROM: valdes + +BUG: The units conversion to millimeters and centimeters is off by a + factor of 10 too large. The inverse function on these units + will be off by a corresponding amount. + +STATUS: Fixed for the next release. + +NUMBER: 190 +MODULE: longslit.fitcoords +SYSTEM: V2.10-V2.10.2 +DATE: Mon Dec 7 11:05:09 MST 1992 +FROM: valdes + +BUG: If "combine=yes" and the input images do not have the same fit axis + a segmentation error occurs. The task is supposed to ignore all + images which don't agree with the first image in the fit axis but + there is a bug where it attempts to clean up for a skipped image + using a NULL pointer. The workaround is to check that all the + images being combined have the same fit axis. Note that a likely + cause of this error is to inadvertently have combine=yes though + what is really desired is combine=no to fit all the inputs + separately in which case both fit axes can be done in one + execution. + +STATUS: It is fixed and a warning is now printed when mismatched fit axes + are encountered indicating which input image(s) are ignored. + Currently expected to be released with V2.10.3. + +NUMBER: 191 +MODULE: apextract.apscatter (and in related packages) +SYSTEM: V2.10-V2.10.2 +DATE: Tue Dec 8 17:24:34 MST 1992 +FROM: valdes + +BUG: If interactive=no then the smooth parameter is ignored and the + scattered light subtraction will not apply the smoothing along + the dispersion. There is no way around this. The only suggested + partial workaround is to leave interactive=yes, set fitsmooth=no + and fitscatter=no, and then answer NO for the queries. With + a list of images this will then process all further images with + no queries. + +STATUS: Fixed for the next release of the APEXTRACT package (expected to be + V2.10.3). + +NUMBER: 192 +MODULE: photcal.fitparams +SYSTEM: V2.10 +DATE: Thu Dec 17 17:22:04 MST 1992 +FROM: davis + +BUG: The fitparams task could produce incorrect weight, chi, and fitted + parameter error estimates in the case that weighting=photometric, + nreject > 1, and low_reject > 3.0 || high_reject > 3.0. + This problem was occuring because the weight array was not + being reinitialized correctly after each iteration of the rejection + cycle. The actual problem was in the inlfit package routine + inlfit$inreject.gx. + +STATUS: The bug is fixed for the next release of IRAF. The work around is + to use interactive bad point deletion with the graphics cursor instead + of the automatic iterative rejection algorithm. + +NUMBER: 193 +MODULE: sensfunc +SYSTEM: V2.9-2.10.2 +DATE: Mon Dec 21 13:01:36 MST 1992 +FROM: valdes + +BUG: SENSFUNC will not work when the standards file has a starting + wavelength greater than the ending wavelength. The workarounds + are to linearize the spectra with an increasing wavelength, + flip the spectra in STANDARD (i.e. standard spec[-*]), or + edit the standards file to reverse the starting and ending + wavelengths. In the latter two cases the sensitivity function will + then have a reversed sense from the data but the calibration will + still correctly match wavelengths. + +STATUS: It is the intention that no spectral task care which way the + wavelength runs relative to the pixels. SENSFUNC has been + modified to work in either case for the next release. + +NUMBER: 194 +MODULE: splot +SYSTEM: V2.10.2 +DATE: Thu Dec 31 10:34:52 MST 1992 +FROM: valdes + +BUG: The 'e' key in SPLOT either produces a floating operand error or + a nonsensical equivalent width when the data values are less than + about 1e-10 such as is the case with flux calibrated spectra. + This problem was introduced due to a change in a system routine. + The workaround is to scale the data, say with IMARITH or SARITH, + to yield pixel values near unity. The equivalent width and + wavelengths will be independent of the scaling and the other flux + quantities will simply have the same scale factor. + +STATUS: Fixed for the next release. + +NUMBER: 195 +MODULE: daophot.allstar +SYSTEM: V2.10 +DATE: Sun Jan 3 11:04:59 MST 1993 +FROM: davis + +BUG: In crowded regions allstar could occasionally refuse to 1) fit a + bright star or group of bright stars, or 2) fail to converge to + reasonable x,y, and magnitude values for a group of bright + stars by the time the number of iterations equaled maxiter, + resulting in a group of stars with very poor subtractions and + large chi values. + + The problem was caused by a bug in the code which steps through the + stellar groups, subtracting off the current best fit for all the + stars, to produce a residuals image. Due to this bug, on occasion + stars which should have been subtracted from the residuals image + were not being subtracted. Since the residuals image is used to + determine the relative errors and weights, which in turn are used + to control the bad data rejection algorithm, allstar sometimes + refused to fit stars because the residuals were too big or could + not converge to a reasonable value. This bug is data dependent + but is most likely to be a problem if, 1) the stellar detection + threshold is very low, 2) allstar has to do a lot of regrouping to + get the groups below maxgroup in size 3) the fitting radius is + large resulting in very large groups. + +STATUS: This bug is only a problem in 2.10 (not in the external testphot + package) and has been fixed for the next release of IRAF. There + is no reliable workaround for allstar, but the nstar task which fits + fixed groups does not have this problem. + +NUMBER: 196 +MODULE: splot +SYSTEM: V2.10.2 +DATE: Fri Jan 8 16:39:01 MST 1993 +FROM: valdes + +BUG: Use of "zero" in the option parameter (or ymin=0.) or the 'b' key + with flux calibrated data causes a plot with limits -0.01 and 0.01 + making the data appear all zero. The workaround is to set the + minimum value to a number much smaller than the data but not + exactly zero. For example setting ymin=1e-30 when the data + is around 1e-14. This plot limit behavior applies to all tasks + (GRAPH, IMPLOT) but is most likely to appear in SPLOT with flux + calibrated data. + +STATUS: A change to a system routine is required and has been requested. + +NUMBER: 197 +MODULE: images.imcombine, ccdred.combine (and related scripts) +SYSTEM: V2.10.2 +DATE: Wed Jan 20 15:54:28 MST 1993 +FROM: valdes + +BUG: When reject=[avsigclip|sigclip|ccdclip|crreject|pclip], combine=average, mclip=yes, and nkeep!=0 there is a rare possiblity of a segmentation + error. This is more likely the fewer pixels are allowed to be + rejected. This occurs in the step where the pixels with the lowest + residuals are added back after too many are rejected and the + pattern of rejections is such that only low pixels have been rejected. + The sure workaround is to change the combine option to a median + or mclip=no. However, changing other parameters such as nkeep, + the sigma thresholds, or the combining algorithm is likely to + avoid the problem. + +STATUS: Fixed for V2.10.3. + +NUMBER: 198 +MODULE: images.imcombine +SYSTEM: V2.10.2 +DATE: Wed Jan 20 16:30:10 MST 1993 +FROM: valdes + +BUG: The CCDCLIP and CRREJECT algorithms quietly fail to reject any pixels. + The basic source code is actually correct but due to a dependency + condition based on file dates the wrong derived code wes used + resulting in a mismatched argument list. This mismatch generally + results in the rejection algorithm seeing that there are zero + images to process and so no rejection is done. The workarounds + are to use a different rejection option or the CCDRED.COMBINE + version which is the same except for the ccdtype, keyword + mapping, and filter subset features. + +STATUS: Fixed in V2.10.3. + +NUMBER: 199 +MODULE: tv.wcslab +SYSTEM: V2.10 +DATE: Thu Jan 28 11:10:51 MST 1993 +FROM: davis + +BUG: Wcslab was failing with the error "error processing newline" for + images which were sections of a higher dimensioned parent images, + and whose coordinate system was "physical" or not recognized + recognized by wcslab, e.g. glon,glat. The actual error message + was coming from the cl and was due to a trailing \n in the + string passed to the error trapping routine. The actual problem was due + to an error in the wcslab axis mapping code which was failing + to take proper account of an existing axis map. + +STATUS: The bug is fixed in 2.10.3. A possible workaround is to temporarily set + the wcsdim parameter in the image header to be equal to the dimension + of the image. + +NUMBER: 200 +MODULE: astutil.rvcorrect +SYSTEM: V2.10-V2.10.2 +DATE: Mon Feb 1 10:31:22 MST 1993 +FROM: valdes + +BUG: When using RVCORRECT with a list of input images that don't have + the OBSERVAT keyword, the observatory name supplied by the user in + the parameter file is truncated to two characters. An error + message is printed and a prompt is issued for another name. + Replying to this prompt allows the task to complete; i.e. the reply + to the prompt is not truncated. This is caused by a typo in + RVCORRECT which reads only the first two characters from the + observatory parameter. The workarounds are to either enter the + proper observatory when prompted or set the observatory in the + image headers under the keyword OBSERVAT. + +STATUS: Fixed for the next release (currently expected to be V2.10.3). + +NUMBER: 201 +MODULE: identify +SYSTEM: V2.10-V2.10.2 +DATE: Wed Feb 3 16:49:36 MST 1993 +FROM: valdes + +BUG: The 'i' initialize key fails to initialize the wavelength scale. + +STATUS: Fixed in V2.10.3. + +NUMBER: 202 +MODULE: apscatter, doecslit +SYSTEM: V2.10-V2.10.2 +DATE: Fri Feb 5 15:25:52 MST 1993 +FROM: valdes + +BUG: When using the APSCATTER option (either directly or in the + DOECSLIT script) without specifying an output name instead + of a temporary image name being used for intermediate results + the name ".imh" is used. This is a hidden file and if the + task aborts or is aborted it will be left behind and prevent + any further use of this task. The workaround is to recognize + that this is why it fails to work and delete the image + ".imh". + +STATUS: Fixed in V2.10.3. + +NUMBER: 203 +MODULE: sarith, scombine, splot +SYSTEM: V2.10-V2.10.2 +DATE: Wed Feb 10 10:55:11 MST 1993 +FROM: valdes + +BUG: In certain circumstance (listed below) when the dispersion coordinates + are inverted to get pixel coordinates the wrong pixel coordinates + are obtained. In practice this is important only when resampling + spectra such as in arithmetic or combining between two spectra + as might occur with SARITH, SCOMBINE, or the function mode in + SPLOT. It also can cause a problem with the SPLOT equivalent width + options (giving a floating divide by zero). This problem does NOT + apply to DISPCOR! The conditions under which this problem occurs + are when all the following apply: + + 1. Multispec coordinate system images with more than one + spectrum. + 2. The spectra have different coordinate systems; i.e. + are not all at a common coordinate system. + 3. The spectrum aperture numbers differ from the line + numbers; for example line 1 is aperture 3 and line 3 + is aperture 1. Note that if an image section is + used this will change the line number so even if + the apertures are the same as the line numbers in + the original image this will not be true with an + image section. + + In many applications DISPCOR is used to linearize all spectra + to a common dispersion system. This problem does not apply + to such data. It is likely to affect echelle spectra and users + who use nonlinear dispersion coordinates. The workarounds are + to assign aperture numbers sequentially increasing with pixel + coordinate when extracting, renumber the apertures with the + renumber option in SCOPY, dispersion correct to a common system + with DISPCOR, separate the spectra into ONEDSPEC images before + doing the arithmetic/combining, or avoid arithmetic/combining + operations. + + What is happening is that the coordinate transformations + between pixel and world coordinates are (x,l) <-> (w, a) + where x is the pixel image coordinates along the dispersion, + l is the line number, w is the wavelength, and a is the aperture + number. Note that the image line maps to an aperture and vice-versa. + The bug is that instead of using the aperture number the inverse + transformation being used is (w,l) -> (x,?). So unless the + line number happens to be the same as the aperture number or + the dispersion functions are the same for all apertures the + dispersion function from the wrong spectrum is used for the + inversion. + +STATUS: This will be fixed in V2.10.3. + +NUMBER: 204 +MODULE: daophot +SYSTEM: V2.10 +DATE: Tue Feb 16 09:08:48 MST 1993 +FROM: davis + +BUG: The parameters psfrad, fitrad, and matchread were being written + to the daopars parameter set in pixel units instead of scale units + if the daophot task update parameter was on. + +STATUS: Fixed for the next release of iraf. There is no workaround except + to turn off the update parameter or always check the input + parameters using the verify parameter. + +NUMBER: 205 +MODULE: imslice +SYSTEM: V2.9 +DATE: Tue Feb 16 13:52:34 MST 1993 +FROM: davis + +BUG: Removed a check that was preventing imslice from being used to reduce + the dimensionality of images where the length of the slice_dimension + = 1. + +STATUS: Fixed for the next version of iraf. The work around is to use imcopy. + +NUMBER: 206 +MODULE: photcal.obsfile +SYSTEM: V2.10 +DATE: Mon Mar 1 15:18:47 MST 1993 +FROM: davis + +BUG: The obsfile task was not decoding the image names correctly from the + obsparams file, when obsfile was being called directly from the cl + rather than from the script tasks mknobsfile and mkobsfile. Since + obsfile could not match the names of the images in obsparams with + those in imsets it simply ignored the contents of the obsparams + file. + +STATUS: The bug is fixed for the next release of iraf. There is no workaround. + +NUMBER: 207 +MODULE: splot +SYSTEM: V2.10-V2.10.2 +DATE: Tue Mar 2 14:47:45 MST 1993 +FROM: valdes + +BUG: When doing arithmetic between two spectra and an invalid image + name is entered for the second spectrum , usually because of a + typo, the correct error message is returned. However, attempting + to repeat the operation, say with the correct image name, results + in a segmentation error and the task aborts. This will continue + to happen until the task is flushed from the process cache. The + workaround is simple to flush the processes cache with + the command "flpr splot". + +STATUS: Fixed for the next release (V2.10.3) + +NUMBER: 208 +MODULE: adccdrom.catalog +SYSTEM: adccdrom external package: archive prior to March 4, 1993 +DATE: Thu Mar 4 16:03:16 MST 1993 +FROM: valdes + +BUG: Use of the "evsptype" function results in a segmenation or bus + error. This was caused by using a wrong pointer datatype. + There is no workaround other than to not use this function. + However the external package archive was updated. + +STATUS: Fixed in the archive version of March 4, 1993. + +NUMBER: 209 +MODULE: doslit, doecslit +SYSTEM: V2.10-V2.10.2 +DATE: Wed Mar 17 11:10:30 MST 1993 +FROM: valdes + +BUG: The input list of arcs is sorted alphabetically and first sorted + arc is used as the arc reference rather than the first specified + by the user. The workaround is to rename the desired reference + arc to be first alphabetically. + +STATUS: Fixed in V2.10.3. + +NUMBER: 210 +MODULE: photcal.mknobsfile,photcal.mkobsfile,photcal.obsfile +SYSTEM: V2.10 +DATE: Fri Apr 2 11:45:11 MST 1993 +FROM: davis + +BUG: The mknobsfile,mkobsfile, and obsfile task were occasionally dropping + stars from the output observations file in the case that: 1) the + parameter allfilters=no, 2) there were multiple matches to a + given star in 1 or more filters, and 3) the closet matching star was + not the first candidate star found. + + This bug was occuring because the code was correctly matching to + the nearest of the possible candidate stars, but was not resetting + the matching index from the previous star, confusing the indexing + scheme, and causing the incorrectly matched star to be dropped + from the list. + +STATUS: The bug is fixed in 2.10.3. There is no fullproof workaround but + accurately determining the shifts between frames and using small + matching tolerances will minimize the problem. + + +NUMBER: 211 +MODULE: longslit.fitcoords +SYSTEM: V2.10 - V2.10.2 +DATE: Mon Apr 5 10:01:12 MST 1993 +FROM: valdes + +BUG: When there are many samples to be fit an 'Out of memory" error can + occur. This is caused by repeatedly opening an image section + for each sample and failing to close it. If there are enough + samples this can cause memory to run out. If this happens on + other than the first invocation of FITCOORDS then the workaround + is to flush the process cache between executions, "flpr fitcoords". + If it happens on the first execution then the only workaround is to + reduce the amount of data being fit by using a larger step size, + and avoiding multiple runs of REIDENTIFY (since redoing an + IDENTIFY appends to the database rather than replacing resulting + in multiple entries). For marginal cases it might be possible to + make sure the process has the maximum amount of memory + available by minimizing memory use by other processes. + +STATUS: This is a rather severe bug which is fixed in V2.10.3. + +NUMBER: 212 +MODULE: scombine +SYSTEM: V2.10-V2.10.2 +DATE: Thu Apr 22 09:54:07 MST 1993 +FROM: valdes + +BUG: When combining spectra which have log sampling (DC-FLAG=1) and + one chooses log=yes the dispersion per pixel parameter is incorrectly + computed in the output. The workaround is to use the + first=yes option. + +STATUS: Fixed in V2.10.3 + +NUMBER: 213 +MODULE: images.imcombine ccdred.combine +SYSTEM: V2.9-V2.10.2 +DATE: Mon May 10 14:57:05 MST 1993 +FROM: valdes + +BUG: When using a median combining operation, no rejection or with + mclip=no, and outputing a sigma image, the sigma image is incorrect. + This is due to the median computation destroying some of the + input data values before the sigma is computed. The workaround + when both output median and sigma images are desired is to used + one the rejection options with mclip=yes. By choosing the + rejection option sigclip with low and high sigma thresholds + of 1000 no pixels will be rejected and the results are the + same as not specifying a rejection algorithm. + +STATUS: Fixed in V2.10.3. + +NUMBER: 214 +MODULE: scopy, sarith +SYSTEM: V2.10-V2.10.2 +DATE: Thu May 20 17:07:53 MST 1993 +FROM: valdes + +BUG: When using SCOPY or SARITH with a specified wavelength range, + w1 and w2 not equal to INDEF, and rebin=yes the spectra are + correctly resampled to the requested wavelength interval but + the coordinate system in the header is updated incorrectly. + The coordinates may be off by a fraction of a pixel. For + example if w1=6400 and w2=6600 the output data will have + the first pixel at 6400 but the coordinate reported by + LISPIXEL or any other task might be 6400.25 (where the + dispersion is, say, 3 Angstroms per pixel). This error + is caused during the conversion from logical to physical + pixel coordinates when the physical coordinates are treated + as integer; i.e. a wavelength of 6400 for the first logical + pixel might be physical pixel 185.325 but it is then + truncated to 185 and the coordinate system is set so + that physical pixel 185 is 6400 and pixel 185.325 is + 6400.25. This is a subtle error which may be discovered + by looking at the coordinate of the first pixel with LISTPIX + and comparing it with the requested wavelength of the first pixel. + +STATUS: Fixed in V2.10.3. + +NUMBER: 215 +MODULE: imcombine, ccdred.combine +SYSTEM: V2.10-V2.10.2 +DATE: Wed May 26 14:06:15 MST 1993 +FROM: valdes + +BUG: The following combination of parameters give a floating divide + by zero due to an error in the code. Rejection is CRRJECT or + CCDCLIP, grow is greater than zero, and the images are offset. + The simplest workaround is to not use a growing factor (grow=0). + +STATUS: Fixed in V2.10.3 + +NUMBER: 216 +MODULE: noao.astutil.asttimes +SYSTEM: V2.9 +DATE: Thu May 27 15:01:18 MST 1993 +FROM: valdes + +BUG: The epoch printed is not clearly defined and the siderial time is + incorrect by a few seconds. There is also a gross error at the + new year for observatories with a negative time zone. The epoch + used is the day of the year, including the fraction of the day, + divided by a Julian year of 365.25 days. However the siderial + time calculation assumes a J2000 Julian epoch which is not the + same as the previous definition. The previous epoch definition + is also no smoothly continuous at the new year since some years + have 366 days and other 365 and no years have 365.25 days. + Other tasks in the ASTUTIL package also use the astronomical + time routines but it appears that generally the error cancels + out (because the date->epoch->julian date transformations use + the same epoch definition) or is insignificant (such as in + precession or air mass calculations). + +STATUS: For V2.10.3 the routines have been modified to consistently use + J2000 epochs. ASTTIMES will print these epochs and the + sideral times will not have the errors of a few seconds. + +NUMBER: 217 +MODULE: identify +SYSTEM: V2.9 +DATE: Fri Jun 4 10:00:06 MST 1993 +FROM: valdes + +BUG: The labels associated with marked features are not correctly + updated when a feature is deleted. The effect is that the + wrong labels get associated with the features after deletion. + There is no workaround though the labels are informational + so the main job of determining dispersion functions is unaffected. + +STATUS: Fixed in V2.10.3. + +NUMBER: 218 +MODULE: fitprofs +SYSTEM: V2.9 +DATE: Tue Jun 8 09:11:06 MST 1993 +FROM: valdes + +BUG: When the dispersion axis is 2 and the number of lines is greater + than the number of columns a floating operand error can occur. + This is caused by dimensioning an array by the number of columns + rather than the number of elements along the dispersion axis. + The workaround is to either use an image section to make the + number of lines equal to the number of columns or to transpose + the image. Transposing the image also requires reseting some + of the WCS keywords. + +STATUS: Fixed in V2.10.3. + +NUMBER: 219 +MODULE: images.geomap +SYSTEM: V2.9 +DATE: Wed Jul 7 11:04:31 MST 1993 +FROM: davis + +BUG: If the input coordinate file contains fewer than 3 stars geomap + dies with a segmentation violation. The problem was caused by + some missing errchk statements in the error handling code, with the + result that geomap tried to evaluate a non-existent solution. + +STATUS: The problem has been fixed in 2.10.3. + +NUMBER: 220 +MODULE: ptools.pconvert +SYSTEM: V2.9 +DATE: Wed Jul 28 08:34:39 MST 1993 +FROM: davis + +BUG: In append mode the pconvert task was refusing to append data to + columns derived from multi-valued quantities in the original + apphot/daophot text output, e.g. MAG[1]. + + The problem was due to an extraneous escape character "\" + infront of the "[" in the column specification (this is required + for column template expansion, but not for column definition). + +STATUS: Fixed in 2.10.3. There is no work-around. + +NUMBER: 221 +MODULE: images.imcombine, ccdred.combine +SYSTEM: V2.9-V2.10.2 +DATE: Wed Aug 4 15:48:03 MST 1993 +FROM: valdes + +BUG: When the number of input images + number of output images + + logfile (if used) is exactly 60 the task fails with error 757. For + example if there are 59 input images, an output image, and no + logfile this error occurs. The workaround is to add or eliminate + the logfile or else change the number of input or output images. + +STATUS: Fixed in V2.10.3. + +NUMBER: 222 +MODULE: images.fit1d, generic.background, longslit.background +SYSTEM: V2.10-V2.10.2 +DATE: Fri Aug 6 10:36:36 MST 1993 +FROM: valdes + +BUG: When the input and output images are the same the last part of + the image will not be modified. The workaround is to use + a different output image and then, if desired, delete the + original and rename the new image to the original image. + +STATUS: Fixed for V2.10.3. + +NUMBER: 223 +MODULE: photcal.fitparams +SYSTEM: V2.10 +DATE: Sun Aug 8 15:05:17 MST 1993 +FROM: davis + +BUG: Errors in the catalog and observations variables were not being + added to the total error computed for an observation by the fitparams + task if these variables were used in a set equation, the set equation + was then used in one or more of the transformation equations, and the + weighting parameter was set to photerrors. + +STATUS: The bug is fixed in iraf 2.10.3. Possible workarounds include use of + the weighting=equations option and avoiding the use of the set + equations in transformations equations. + +NUMBER: 224 +MODULE: apnormalize +SYSTEM: V2.10 - V2.10.2 +DATE: Fri Aug 27 18:40:27 MST 1993 +FROM: valdes + +BUG: When the dispersion axis is 1 and the "cenorm" option is selected + the result is not correct. One workaround would be to transpose + the image and the other is to not use the "cenorm" option. + +STATUS: Fixed in V2.10.3 + +NUMBER: 225 +MODULE: apfit, apnormalize +SYSTEM: V2.10 - V2.10.2 +DATE: Fri Aug 27 18:42:14 MST 1993 +FROM: valdes + +BUG: The results of the "fit" and "difference" in APFIT and of + APNORMALIZE are incorrect by a factor of the gain. This is + basically the same bug as 171 which was not correctly fixed. + The workarounds are to use a gain of 1. + +STATUS: Fixed in V2.10.3 + +NUMBER: 226 +MODULE: artdata.mkobjects +SYSTEM: V2.9-V2.10.2 +DATE: Fri Sep 17 14:13:24 MST 1993 +FROM: valdes + +BUG: The scales of the "expdisk" and "devauc" images are incorrect due + to an integer truncation error. The error is such that the actual + output radius for a given input radius is given by the formulas: + + expdisk: rout = rin * int(ln(D)/1.6783) / ln(D)/1.6783 + devauc: rout = rin * int(ln(D)/7.67)**4) / (ln(D)/7.67)**4 + + where D is the dynamic range parameter in the ARTDATA package + parameters, ln() is the natural logarithm, int() is the integer + truncation function, and ** is the exponentiation operator. + From this one can, fudge the input radii to give the + desired output radii, select a dynamic range where the correction + factor is 1, or account for this as needed when the artificial + image is analyzed. The simplest thing is to adjust the dynamic + range; for example, a dynamic range of 126514 for the "expdisk" + model is the closest to the default value of 10000 which will give + correct output scales. + +STATUS: Fixed in V2.10.3 + +NUMBER: 227 +MODULE: longslit.transform +SYSTEM: V2.8-V2.10.2 +DATE: Sun Sep 19 14:21:35 MST 1993 +FROM: valdes + +BUG: If the requested output coordinates extend outside of the input + data range, the interpolated output data very near the edge + may suffer a small stretch distortion. The error is confined + to the end 50th of the image and the magnitude of the stretch + depends on the specifics of the requested output sampling. + The workaround is to either creating an output image + which extends beyond the input data range. + +STATUS: Fixed in V2.10.3 + +NUMBER: 228 +MODULE: images.imsurfit +SYSTEM: V2.9 +DATE: Wed Sep 22 13:29:23 MST 1993 +FROM: davis + +BUG: Bugs in the bad pixel rejection code were causing the imsurfit task + to either 1) hang or crash with a segmentation violation or 2) + display oscillating behavior (sigmas which would decrease then + increase again after succesive iterations), if the number of + detected bad pixels was very large. The first problem was caused + by a failure of the code to allocate sufficient space for the bad + pixel list. The second problem was caused by a failure of the code + to correctly resolve overlapping regions in some circumstances, + causing the same pixels to be alternately rejected and included + in the fit. + +STATUS: Fixed in 2.10.3. + +NUMBER: 229 +MODULE: images.imcombine, ccdred.combine +SYSTEM: V2.9 +DATE: Fri Sep 24 10:40:31 MST 1993 +FROM: valdes + +BUG: If an offset file is specified as containing absolute offsets + but with all the offsets equal then the combining acted like + relative offsets except the output image size would be that + of the absolute offsets and garbage appears in the final + lines/columns. The workaround is to either not have + identical offsets or combine the images without offsets + and then paste the result into a bigger empty image at + the desired offset with IMCOPY. + +STATUS: Fixed in V2.10.3. + +NUMBER: 230 +MODULE: images.imcombine, ccdred.combine +SYSTEM: V2.9 +DATE: Fri Sep 24 10:45:00 MST 1993 +FROM: valdes + +BUG: The documentation says that scale and zero offset factors specified + by an @file of header keyword are multiplicative and additive. + However they are used as divisive and subtractive. The workaround + is to know the values should be input as divisive and + subtractive. + +STATUS: In V2.10.3 this has been fixed so the input is as defined in + the documentation. + +NUMBER: 231 +MODULE: imcombine, ccdred.combine +SYSTEM: V2.10.2 +DATE: Tue Nov 9 09:17:12 MST 1993 +FROM: valdes + +BUG: If there are fewer pixels at some point than that specified by nkeep + parameter, such as caused by offsetting, thresholding, or masking, + then the tasks try to add data from the nonexistent images resulting + either in garbage or a segmentation violation. The workaround + is to use nkeep or 1 or 0 rather a higher value unless there + are no offsets or other factors that will result in a smaller + number of points than the number of images at some points. + +STATUS: This has been fixed for V2.10.3. This also resulted in a change + in how a negative nkeep is used. In the new version, if one + specifies a maximum number to reject, that number applies to + the initial set of pixels rather than to the total number of + images. + +NUMBER: 232 +MODULE: images.geomap +SYSTEM: V2.9 +DATE: Wed Dec 29 16:39:24 MST 1993 +FROM: davis + +BUG: Geomap was computing an incorrect coordinate transformation if the + functional form of the coordinate transformation was "chebyshev" + or "legendre" x fit x or y order was > than 2 and the y fit was + linear (x and y order equal to 2), or if the y fit x or y order + was > 2 and the x fit was linear (x and y order equal to 2). + This was occurring because geomap was incorrectly redefining the + functional form of the linear fit to be "polynomial". + +STATUS: Fixed in 2.10.3. There is no direct workaround but setting the + cross terms parameter of the linear fit to "yes" will avoid + the problem at the expense of computing one extra term in the fit. + +NUMBER: 233 +MODULE: apphot package tasks +SYSTEM: V2.9 +DATE: Fri Dec 31 14:46:23 MST 1993 +FROM: davis + +BUG: If the number of input images is greater than one, the number of + output files is exactly equal to one, and the input coordinate + file(s) do not contain any decodable coordinates, the input coordinate + file rather than the empty output file is deleted. The problem + occurs because the output file name is not being correctly stored + as the tasks looped through the input image list. + +STATUS: The bug is fixed in 2.10.3. The workaround is to make sure at least + one of the coordinate files contains valid coordinates. + +NUMBER: 234 +MODULE: onedspec.standard +SYSTEM: V2.10-V2.10.2 +DATE: Fri Jan 7 09:38:51 MST 1994 +FROM: valdes + +BUG: When using STANDARD on a long slit spectrum with a dispersion axis + of 2 (where each column is treated as a spectrum) the task uses the + length of the second axis rather than the first axis to define the + number of spectra. If the second axis length is greater than the + first axis then the last column is processed repeatedly. One may + limit this by using the apertures parameter to specify just the + columns; i.e. 1-250 in a 250x800 images. If the number is smaller + then some of the columns will not be processed. On workaround is + to transpose the image but then some fudging of the WCS will be + necessary. Another workaround would be to use SCOPY to extract all + the spectra to a multispec format. + +STATUS: Fixed for the next release. + +NUMBER: 235 +MODULE: digiphot.apphot.fitpsf +SYSTEM: V2.9 +DATE: Mon Jan 17 14:18:33 MST 1994 +FROM: davis + +BUG: In cases where the fitting box was entirely off the image or there + were too few pixels in the fitting box to fit the psf model (e.g. + < 5 in the case of function=radgauss), the output fitted parameter + and parameter error arrays were not being initialized correctly. + Instead, although the fit was correctly tagged with the appropriate + error code, the results of the previous fit were written to the + output file. + +STATUS: Fixed in 2.10.3. There is no workaround except to make sure that + the fitting box contains enough pixels and/or to check the error + codes of the fitted objects. + +NUMBER: 236 +MODULE: digiphot.photcal.invertfit +SYSTEM: V2.10 +DATE: Wed Jan 19 08:03:42 MST 1994 +FROM: davis + +BUG: On VMS systems the invertfit task will crash with an adjustable + array dimension error if the user has no defined set equations + in his/her configuration file. In this case invertfit passes a + 2D array with a zero length first dimension to a subroutine, + triggering a run time error under VMS, even though the array is + never accessed. + +STATUS: Fixed in 2.10.3. The workaround is to include a dummy set equation + in the transformation section of the configuration file. + +NUMBER: 237 +MODULE: IEEE NaN support +SYSTEM: Sun/IRAF V2.10, V2.10.1, V2.10.2 +DATE: Fri Jan 21 15:55:46 MST 1994 +FROM: tody + +BUG: When converting native floating point to IEEE floating point (as + when writing FITS files), V2.10 IRAF has a feature which allows + pixels with a reserved floating point value to be replaced by IEEE + NaN on output. In V2.10 Sun/IRAF, the code which does this was + correct, but the wrong version of the affected object module was + present in the system library (libvops.a) and in the IRAF shared + image (S6.e). This would cause zero to be written as the output + IEEE value instead of NaN. + +STATUS: Fixed in V2.10.3 or later. So far as I know the core IRAF system + does not use this feature but it is used by some layered packages, + e.g., STWFITS. The bug only comes into play when mapping of NaNs on + output is enabled by the application being used. This is probably + not a serious bug in most cases, but if the zeros are a problem the + bug can be fixed by rebuilding the IRAF shared library S6.e. Contact + the IRAF group for advice on how to do this. + +NUMBER: 238 +MODULE: ccdred.combine +SYSTEM: V2.10 +DATE: Tue Feb 15 14:04:14 MST 1994 +FROM: valdes + +BUG: When combining images with separate exposure and dark times the + final dark time recorded in the header is actually the exposure + time; so the final dark time and exposure time will always be the + same. The correct dark time is computed but the wrong thing + is being written to the image. This is likely to be of relevance + for combining dark frames when the dark times of the individual + frames are not the same as the exposure times. The workaround + is to copy the dark time to the exposure time with HEDIT in + the dark frames before combining. Note that this bug + applies to the script DARKCOMBINE since it calls COMBINE. + +STATUS: This is a simple typo code fix which has been made for the V2.11 + release. + +NUMBER: 239 +MODULE: onedspec tasks +SYSTEM: V2.10 - V2.10.2 +DATE: Sat Mar 5 16:05:55 MST 1994 +FROM: valdes + +BUG: Applying IMSHIFT with a positive shift can cause errors in + the ONEDSPEC tasks. Negative shifts do not cause a problem. The + same problem has been noted previous in bug log number 180 for + IDENTIFY and REIDENTIFY. Errors occur when a wavelength is + transformed to a pixel coordinate. This happens in a number of + operations in SPLOT. There are various workarounds depending on + what is desired. A WCSRESET of the physical coordinate system can + be used though this will cause the dispersion coordinates to also + shift; i.e. then the shift will move the pixel relative to the + image data array and the wavelength coordinate system. As a + general rule use of IMSHIFT with spectra, particularly dispersion + calibrated spectra, should be avoided. + +STATUS: The problems have been fixed for V2.11. + +NUMBER: 240 +MODULE: ptools.pexamine +SYSTEM: V2.10 +DATE: Tue Mar 15 08:43:20 MST 1994 +FROM: davis + +BUG: If either or both of the columns specified by the pexamine task + parameters xcolumn or ycolumn is undefined in the input image data, + then pexamine will crash with a segmentation violation if the user + types the o keystroke command in image cursor input mode. The problem + occurs because the o keystroke command switches the task to graphics + cursor mode, and tries to move the graphics cursor to a point in the + default x-y plot which is undefined. + +STATUS: The bug is fixed in 2.11. The workaround is to set the xcolumn and + ycolumn parameters to a column that is defined in the input data. + +NUMBER: 241 +MODULE: sarith, scopy +SYSTEM: V2.10 +DATE: Tue Apr 12 13:56:49 MST 1994 +FROM: valdes + +BUG: If a spectrum is "multispec" with more than 127 APID keywords the + tasks will fail with a segmentation violation. This is due to + a limit in a keyword template expansion step. The work around + is to delete some of the keywords with: + + cl> hedit 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: 546 +MODULE: mscred.ccdproc, mscred.mscmerge +SYSTEM: -V4.8: May 11, 2004 +DATE: Fri Apr 15 16:55:02 MST 2005 +FROM: valdes + +BUG: CCDPROC produces a "Pixel subscript out of bounds" error when + applying calibrations produced from binned and merged data. + In other words, mosaic data with multiple amplifiers per + CCD, which are taken with binning, will produce this error + after running ZEROCOMBINE with merging enabled and applying + this calibration to flat fields or objects. This problem + is caused by CCDPROC incorrectly updating the physical WCS + for binned data. This causes the merging of multiple amplifiers + to produce incorrect section keywords. This is particularly + important for the CCDSEC keyword. Attempting to apply merged + calibrations with the invalid CCDSEC keyword causes the error. + There are two workarounds. One is to not merge the amplifiers + at all or until all calibrations have been applied. The other + is to edit the CCDSEC keywords for merged calibration images + produced by ZEROCOMBINE and FLATCOMBINE to reflect the true + CCD section. The error is normally that the first pixel in + CCDSEC is zero rather than one. + +STATUS: Fixed for the next release of MSCRED. + +NUMBER: 547 (see also 544) +MODULE: argus, ctioslit, hydra, iids, irs, kpnocoude, kpnoslit +SYSTEM: V2.12a-V2.12b +DATE: Mon Apr 25 10:59:24 MST 2005 +FROM: valdes + +BUG: Changes to SCOMBINE in V2.12.2a made it a separate executable. The + package definitions for the packages listed above (see also number + 544 concerning the ECHELLE package) failed to be updated so when + trying to run SCOMBINE (or a task that calls SCOMBINE such as + DOHYDRA) the following error message is produced. + + ERROR: task `scombine' has no param file + + The solution is editing the $.cl file, where + is one of the modules listed above, so that it reads as + shown below. A simpler workaround is to load the onedspec package + and run scombine from that package. + +STATUS: Fixed for the next release. + +Modifications to $.cl: + +... +task ..., + [scombine,] <-- Delete line + ..., + ... = onedspec$x_onedspec.e +task scombine = "onedspec$scombine/x_scombine.e" <-- Add line +... + +Note that scombine has to be removed from the first block of task +definitions and added as a separate task statement as shown. + + +NUMBER: 548 +MODULE: specplot +SYSTEM: -V2.12.2a +DATE: Mon May 2 11:03:20 MST 2005 +FROM: valdes + +BUG: When using a file for the cursor input the colon commands + must include the x, y, and system values even if the spectrum + is explicitly selected. For example: + + 0 0 1 :color[2] 2 + + If this is not done then a floating exception results. This is + because the search for the nearest spectrum to the cursor position + is always done even if the spectrum is specified explicitly. + +STATUS: In the next release the cursor position is optional. + +NUMBER: 549 +MODULE: spectool +SYSTEM: SPT V1.2: February 2003 +DATE: Tue Jun 21 11:35:40 MST 2005 +FROM: valdes + +BUG: When the arithmetic function needs to interpolate the spectrum it + needs a parameter "interp" which was left out. The workaround is + to type 'string interp="poly5"' after loading the SPT package and + before running SPECTOOL. + +STATUS: Fixed for a future release. + +NUMBER: 550 +MODULE: spectool +SYSTEM: SPT V1.2: February 2003 +DATE: Tue Jun 21 11:38:36 MST 2005 +FROM: valdes + +BUG: Use of spectra with the lookup world coordinate system, as produced + by RSPECTEXT with "non-linear", causes various failures such as + segmentation violations and memory corruption. the workarounds are + to use SPLOT and other equivalent tasks from the ONEDSPEC package. + +STATUS: The task is currently frozen. This will be studied further if + resources allow. + +NUMBER: 551 +MODULE: doecslit +SYSTEM: -V2.12.2 +DATE: Mon Nov 14 14:56:06 MST 2005 +FROM: valdes + +BUG: The sparams.refit parameter is not actually used during the arc + reidentification step. Instead doecslit will always attempt to + refit the dispersion function. There is no workaround other than + fixing the appropriate script task doecslit$sdoarcs.cl to change + the refit value from yes to sparams.refit. + +STATUS: Fixed for the next release. + +NUMBER: 552 +MODULE: imcombine +SYSTEM: V2.12.2 +DATE: Tue Feb 28 14:07:30 MST 2006 +FROM: valdes + +BUG: When the combine option is sum and weighting is selected an exception + occurs. The sum option was added as a later feature and a + flag needed for weighting was not set. There is no workaround to + combine weighting and summing directly. One can use "average" and + the scale the result to the equivalent of a sum. + +STATUS: Fixed for V2.12.3. + +NUMBER: 553 +MODULE: splot +SYSTEM: -V2.12.3 +DATE: Tue May 16 11:08:14 MST 2006 +FROM: valdes + +BUG: If SPLOT is run more than once without flushing the process (flpr) + then the default aperture will be that from the last execution. + The consequence is that use of an image section to select an + aperture in a multiaperture file may not display the intended + spectrum. The workaround is to use the command "flpr" before + using an image section. + +STATUS: Fixed for the next release. + +NUMBER: 554 +MODULE: dopcor +SYSTEM: V2.13 +DATE: Tue May 23 16:11:05 MST 2006 +FROM: valdes + +BUG: The verbose output only prints information based for the last + spectrum in a multispec file. When a single correction is being + applied to all apertures this is correct but when different + corrections are being generated for different apertures, say when + adding a correction to apertures which had different initial + corrections applied this can be concerning. The actual corrections + are being applied correctly for each aperture but the verbose output + may be misleading. There is no workaround though it is not a data + calibration error just a logging error. + +STATUS: To be fixed in a future release though no fix has yet been implemented. + +NUMBER: 555 +MODULE: longslit.fitcoords +SYSTEM: V2.13-Beta[12] +DATE: Wed Jun 14 10:41:50 MST 2006 +FROM: valdes + +BUG: If the fitting axis is 2 (the identify/reidentify features are defined + by cuts along the second axis) the y coordinate for the 2D fitting + will be wrong. You will notice this if data are plotted with one + axis being the y coordinate. The other way you would notice this + is that the transformation won't correctly remove the distortions + and make a correct wavelength solution. + + The only workaround is to transpose the data early before doing + the feature identification and tracing. Note that you must then + also reset the physical WCS after the transpose with the command + "wcsreset wcs=physical". + +STATUS: Fixed for the next V2.13 release. + +NUMBER: 556 +MODULE: splot, sarith, scombine, standard +SYSTEM: -V2.13Beta +DATE: Fri Oct 27 09:33:16 MST 2006 +FROM: valdes + +BUG: When matching one spectrum to another, the reference spectrum, + for some operation (e.g. arithmetic, combining, standard star + calibration) the first spectrum is converted to its natural + WCS units. If the reference spectrum is in different units + the result will be wrong. This is rare but a particular case + is when SPLOT displays a spectrum in some units, possibly set + by the display units in the header or by the task parameter, + and then a binary arithmetic operation is performed using a + second spectrum. Even if the second spectrum has the same + display units it may be resampled to match the reference + spectrum in the wrong units. The code solution is to always + resample in the current units of the reference spectrum. + + The workaround for the SPLOT example is to use the ":units" + command to put the initial spectrum into the natural units + of the second spectrum. After the arithmetic you can changes + the units back if desired. + +STATUS: Fixed for a future release. + +NUMBER: 557 +MODULE: splot +SYSTEM: -V2.13beta +DATE: Mon Dec 4 15:29:44 MST 2006 +FROM: valdes + +BUG: When the dispersion function for a spectrum is log sampled, + e.g. DC-FLAG=1, and there is also a logical/physical pixel offset, + i.e. LTV1 is not zero, then writing out a new spectrum with the + 'i' key the results in a wrong WCS. There is no workaround. + +STATUS: Fixed for a future release. + +NUMBER: 558 +MODULE: mscimage +SYSTEM: all release up to date +DATE: Fri Mar 30 11:04:18 MST 2007 +FROM: valdes + +BUG: MSCIMAGE defines the resampled output world coordinate system + (WCS) using a reference image WCS. If this reference image + has a ZPN projection an error will occur. This is because when + the output WCS is set the ZPN projection is inherited from the + reference image but MSCIMAGE does correctly setup the output ZPN + projection from the reference image. So one must use a reference + image with another projection such as TAN. + + What is confusing is that wcssource="parameters" implies that + the output WCS is entirely defined by the task parameters. + This is true for everything but the WCS projection type which is + taken from the input image. There is no parameter to set the + projection explicitly and the MSCIMAGE script would need to be + edited to access the projection parameter in the underlying call + to a hidden task MSCWTEMPLATE. MSCIMAGE automatically changes + input projections of "tnx" and "zpx" (distorted projections) to + "tan" since the point of MSCIMAGE is to resample to a simpler + undistorted WCS. A change will be made to also do this for "zpn". + + The workarounds when the input data uses ZPN are to use a reference + image that doesn't have a ZPN WCS or edit mscsrc$mscimage.cl + to change projection="" to projection="tan" in the call to + MSCWTEMPLATE. The code change to MSCWTEMPLATE could also be + made and the MSCRED package recompiled but this is a more complex + process and users should contact iraf.net for help. + + The recommendation for users with the most recent version of IRAF + is to use the task imcoords.mkcwcs to create a reference WCS. + This task creates a dataless image with the desired WCS. It is + basically like defining the WCS using the MSCIMAGE parameters + except you have control over the projection and the tangent + position. The only thing that is less obvious is that you must + set a reference pixel. When building a mosaic you might set this + to be roughly in the middle of the field. For instance if the + final image will be roughly 4Kx4K you might choose a reference + pixel at (2100,2100). + + If you don't have MKCWCS you can call MSCWTEMPLATE directly to do + the same thing. Leave the input and reference image parameters + empty, set wcssource="parameters" and fill in the parameters + including the projection as "tan". This will leave the reference + pixel at (0,0) so you would use HEDIT to set CRPIX1 and CRPIX2 + to the desired point. Alternatively, you could make a list of + all the extensions in the input and specify that as the input + in MSCWTEMPLATE. This then does exactly what mscimage would do + put give you access to the projection parameter. In other words + making the reference image manually this way is equivalent to + editing the mscimage.cl script. + + +STATUS: Future releases of MSCRED will convert input ZPN WCS to TAN WCS + automatically. + +NUMBER: 559 +MODULE: longslit.transform +SYSTEM: -V2.12.3 +DATE: Tue Aug 7 10:39:13 MST 2007 +FROM: valdes + +BUG: When using log resampling (xlog=yes or ylog=yes) it is possible to + get a segmentation error. This is caused by taking the log and + anti-log of coordinates and not getting back exactly the same value + due to real precision problems. This process caused an attempt to + go outside the valid range of the interpolator. This may be a + rare problem but if it does happen one may be able to use the + x1, x2, y1, y2 values to work around the problem. The workaround + for a future release is to use double precision and to impose + range limits on data passed to the interpolator. + +STATUS: Fixed for the next release. + + +NUMBER: 560 +MODULE: CCFIND +SYSTEM: V2.14 +DATE: Wed Jan 23 15:56:04 MST 2008 +FROM: fitz + +BUG: For an image with a ZPN projection, the transform code in mwcs tries + to reference the parent image to get the PV matrix keywords. This task + called sk_decwcs() to open the WCS, but this routine then unmaps + the image. When the task later uses the saved 'mw' pointer to + transform coords the ZPN reference to the parent image is invalid + and results in a segfault. Changed the code to call sk_decim() + directly and operate on the currently open image instead. + + There is no workaround other than to not set the 'usewcs' parameter + and to set the WCS using the other parameters. Contact iraf.net for + a new binary if needed. + +STATUS: Fixed for the next release. + + + +NUMBER: 561 +MODULE: imstatistics, mimstat +SYSTEM: V2.14 +DATE: Tue Jul 15 11:03:18 MST 2008 +FROM: valdes + +BUG: The user supplied upper and lower data limits may be exceeded if + clipping is used. For instance, if the limits exclude all pixels + the clipping with behave as if no pixels are excluded. If not + all pixels are excluded and the clipping thresholds computed + (number of sigma * standard deviation) exceed the limit then + the clipping threshold is used. The only workaround is to not + use clipping if the limit values are supplied or check first + with no clipping to see if all pixels are excluded. + +STATUS: Fixed for the next release. + +NUMBER: 562 +MODULE: mscred.ccdproc +SYSTEM: V4.8 +DATE: Tue Aug 12 12:19:30 MST 2008 +FROM: valdes + +BUG: The fix for bug number 546 was not fully correct. It works for + binned data but results in an error for data which is flipped + (e.g. when CCDSEC/DETSEC have a starting column greater than + the ending column as in '[2048:1025,1:2048]'. The error + is that the resulting CCDSEC in the processed image will + be off by one. This can result is losing a column when + merging multiple amps. + +STATUS: Fixed for mscred V4.9. + +NUMBER: 563 +MODULE: imexpr +SYSTEM: -V2.14 +DATE: Tue Aug 12 15:12:04 MST 2008 +FROM: valdes + +BUG: Literal (quoted) strings cannot be used in expressions stored in the + expression database. The quotes are stripped and then the error is + that an operand by that name is not found. As a warning, single + quotes in the database are not interchangable with double quotes as + they are on the command line. They are interpreted as character + constants and something like 'abc' will be expanded to 'a bc'. + +STATUS: Double quoted strings allowed in next release. + +NUMBER: 564 +MODULE: ccdmask +SYSTEM: -V2.14.1 +DATE: Fri Aug 22 09:27:06 MST 2008 +FROM: valdes + +BUG: The output mask from ccdmask is incorrect if the task has been run + previously without starting the executable fresh. The workaround + is to type "flpr ccdmask" before executing this task to force a + fresh executable. + +STATUS: Undiagnosed at present. Only the workaround has been defined. + + +NUMBER: 565 +MODULE: imextensions +SYSTEM: V2.13-V2.14 +DATE: Mon Aug 25 16:24:33 MST 2008 +FROM: valdes + +BUG: Specifying an extension version or range of versions results in an + integer divide by zero. This is a bug for which there is no + around. + +STATUS: Fixed for the next release. + +NUMBER: 566 +MODULE: display +SYSTEM: V2.12.4/V2.14 +DATE: Tue Aug 26 17:10:07 MST 2008 +FROM: valdes + +BUG: The "ocolors" parameter was being used in place of the "bpcolors" + parameter. There is no workaround. + +STATUS: Fixed for the next release. + +NUMBER: 567 +MODULE: apall, apedit +SYSTEM: V2.11-V2.14.1 +DATE: Tue Oct 7 10:53:14 MST 2008 +FROM: valdes + +BUG: The :parameters and :apertures commands cause the task to exit with + an error that parameter "apertures" isn't found. This problem has + existed for a long time due to a missing parameter in the hidden + parameter sets. + +STATUS: Fixed for the next release. + +NUMBER: 568 +MODULE: imcombine +SYSTEM: -V2.14.1 +DATE: Tue Oct 7 12:52:35 MST 2008 +FROM: valdes + +BUG: When using avsigclip, ccdclip, or sigclip rejection around the + median (mclip=yes) the resulting final median may be incorrect. + This will generally only occur if unusually small low sigma values, + such as lsigma=1, are used. This was due to using a wrong + variable. + +STATUS: This is fixed for the next release. + + +NUMBER: 569 +MODULE: cosmicrays +SYSTEM: -V2.14.1 +DATE: Mon Oct 13 10:33:15 MST 2008 +FROM: valdes + +BUG: The message + + ERROR: PLIO: reference out of bounds on mask + + occurs when the image is not 2D. This can be a conceptual problem + for data which define a higher dimensionality but with length of 1; + e.g. [2048,2048,1]. This is effectively a 2D image but some + IRAF tasks designed for 2D images can have problems with this. + + The workaround is simply to use a 2D image section: + + cosmicrays image[*,*,1] + + Of course one can also convert the image to 2D with imcopy or imslice. + +STATUS: No updates are currently planned and users should use the workarounds + noted above. + +NUMBER: 570 +MODULE: imexpr, mskexpr, or tasks other asks using the expression evaluator +SYSTEM: -V2.14.1 +DATE: Mon Nov 3 22:16:41 MST 2008 +FROM: valdes + +BUG: Use of the built-in functions mod, min, max, and median produce an + "incompatible types" error even though the types of the arguments are + correct. This is a due to a coding error. There is no workaround + other than using alternative ways to express the desired + expression. + +STATUS: Fixed for the next release. + +NUMBER: 571 +MODULE: IMAGES.IMUTIL.HSELECT +SYSTEM: V2.14 +DATE: Fri Jan 2 21:41:53 MST 2009 +FROM: fitz + +BUG: The use of a '$' in a field name was causing the 'missing' value + to always be printed even if the field exists in the image. This + was caused by a failure to check for the character and removing it + prior to getting the value from the header. There is no workaround, + the code change is trivial. + +STATUS: Fixed for the next release. + +NUMBER: 572 +MODULE: dotasks +SYSTEM: -V2.14 +DATE: Tue Apr 28 11:19:41 MST 2009 +FROM: valdes + +BUG: It is likely that the DO tasks (e.g. doslit) will not work correctly + if the input image names have a path. This is because + internal database filenames are derived from the image names. + The recommended action is to work in the data directory. + +STATUS: Work on these and related tasks is currently frozen and since + there is a basic workaround (working in the data directory) + nothing may be done for some time. + +NUMBER: 573 +MODULE: mscimage +SYSTEM: - V4.9 August, 2008 +DATE: Fri Sep 18 08:36:30 MST 2009 +FROM: valdes (discovered and diagosed by Thomas de Boer) + +BUG: The task ignores the parameters "boundary" and "blank" which are + fixed to be "constant" and "0." respectively. + +STATUS: This is fixed for the next release. + +NUMBER: 574 +MODULE: daophot.psf +SYSTEM: -V2.14 +DATE: Tue Apr 13 22:01:52 MST 2010 +FROM: fitz + +BUG: The ":function" command was not properly saving the new function + when refitting is done with the 'f' keystroke. This is because the + fitting function reinitializes the parameters to the startup + values without first saving the modified function. + +STATUS: Fixed for the next release + +NUMBER: 575 +MODULE: all tasks using the icfit tools +SYSTEM: - V2.14 +DATE: Mon Jun 28 14:08:48 MST 2010 +FROM: valdes + +BUG: The icfit tools are used in many tasks involving 1D function fitting. + These include onedspec tasks like continuum and identify. The + tools provide for a grow radius where any sigma rejected points + have neighbors also rejected. The logic was wrong + in two ways; one where if a neighbor was also a rejected point + it did not also reject neighbors of that point, and another where + the grow radius units were used both as in pixels and in user + coordinates. In reality the grow is supposed to be in user + coordinate units. In addition some tasks, like continuum, incorrectly + described the units adding to the confusion. + +STATUS: Fixed for the next IRAF release. + +NUMBER: 576 +MODULE: imcombine +SYSTEM: V2.14 +DATE: Wed Nov 17 15:20:16 MST 2010 +FROM: valdes + +BUG: The addition of the image names using imcmb="$I" does not work for + input images with a square bracket; e.g. foo[1], foo[im1], foo[*,*]. + The IMCMB value, in order to allow long filenames, is stripped of + any path. For an obscure reason related to VMS directories this + code failed to find a rootname. + +STATUS: This has been fixed for the next release. + +NUMBER: 577 +MODULE: dohydra, dofibers, doargus, do3fiber +SYSTEM: -V2.15.1 +DATE: Fri Feb 11 12:30:46 MST 2011 +FROM: valdes + +BUG: The tasks will shorten root input image names to six characters by + using the first five and last characters. Depending on the style + of image names this can result in name conflicts. The reason for + this shortening is no longer known so it is now considered a bug. + Workarounds are to be aware of this and rename image names to avoid + conflicts. + +STATUS: This is fixed in the next release. The fix is to modify the file + $iraf/noao/imred/src/fibers/proc.cl as shown (replace lines 125 to + 129 with "extn = extn // ".ms"). If you don't have permission + to make this change then copy the file to your iraf "home$" + directory, edit it, load the desired package, and then override + the definition of the file with "redefine proc = home$proc.cl". + + 125,129c125 + < i = strlen (extn) + < if (i < 7) + < extn = extn // ".ms" + < else + < extn = substr (extn, 1, 5) // substr (extn, i, i) // ".ms" + --- + > extn = extn // ".ms" + + +NUMBER: 578 +MODULE: splot, scombine, fxcor, identify tasks, dispcor, disptrans +SYSTEM: v2.15-V2.15.1a (64-bit platforms only) +DATE: Tue Mar 8 21:57:38 MST 2011 +FROM: fitz + +BUG: The 64-bit port changes to smw.h improperly added a P2R() macro to + the APLOW/APHIGH macro declarations. This was causing tasks with + 2-D data to make an out-of-bounds request for data and leading to + and error message such as + + ERROR: Pixel subscript out of bounds (spec.fits) + + Normal onedspec data or use on 32-bit platforms is not affected. + +STATUS: Fixed for the next release. A re-application of the v2.15.1a patch + file will replace the affected binaries on 'linux64' and 'macintel' + platforms. + + +NUMBER: 579 +MODULE: onedspec.specplot +SYSTEM: V2.15 +DATE: Thu Mar 31 10:41:56 MST 2011 +FROM: fitz + +BUG: SPECPLOT can sometimes throw a segmentation violation or not + recognize valid input spectra due to an incorrect macro definition + on 64-bit platforms (linux64 and macintel only). + +STATUS: This has been fixed for the next release. Patched x_onedspec.e + binaries can be installed from + + ftp://iraf.noao.edu/iraf/v215/support//x_onedspec.e + + where the is either 'linux64' or 'macintel'. + + +NUMBER: 580 +MODULE: imcombine and variants +SYSTEM: -V2.15.1 +DATE: Fri Apr 1 10:53:41 MST 2011 +FROM: valdes + +BUG: When the grow options is used with masks or partially overlapping + data a segmentation could occur. This is because when data is + absent (because of non-overlap) or excluded (because of mask) an + identifier value was not initialized. The only workaround is to + not use the grow options. + +STATUS: Fixed for future patches and releases. + +NUMBER: 581 +MODULE: splot +SYSTEM: V2.15- +DATE: Mon Jun 6 17:21:27 MST 2011 +FROM: valdes + +BUG: When using the deblending options a memory free error occurs with + 64-bit versions. This is caused by allocating an integer array and + freeing it as a real array. + +STATUS: Fixed in future patches and releases. +NUMBER: 582 +MODULE: utilities.curfit +SYSTEM: -V2.15.1 +DATE: Fri Jul 29 12:40:08 MST 2011 +FROM: valdes + +BUG: For input data with two or more values having the same x value + there is an arithmetic exception when setting the niterate parameter + greater than zero during interactive fitting. This occurs because + a check for the distance between two points for the purpose of the + grow option divides by the distance. This is done even if no growing + is requested (grow=0). The workaround is to edit the input so that + the values are not exactly the same. + +STATUS: This condition has been eliminated for the next release. + +NUMBER: 583 +MODULE: apall, +SYSTEM: V2.15 +DATE: Mon Mar 5 08:51:03 MST 2012 +FROM: valdes + +BUG: The optimal extraction for significantly tilted spectra, the Marsh + algorithm, has bug which manifests only under 64-bit architectures. + The symptom is a crash, usually a memory or segmentation panic. + The only workarounds are 1) go to an 32-bit system or 2) don't + use the optimal extraction option. + +STATUS: Fixed for V2.16. + + +NUMBER: 584 +MODULE: cosmicrays +SYSTEM: -V2.16 +DATE: Thu Aug 2 14:55:18 MST 2012 +FROM: iraf + +BUG: A pointer to a an array of pointers was used in one place as a real. + This is an error (e.g. segmentation error) when integer and real + arrays are not of the same size; i.e. on 64-bit architectures. + There is no workaround other than using a 32-bit architecture. + +STATUS: Fixed in future updated. + +NUMBER: 585 +MODULE: mscred.mscfinder.msctpeak, nfextern.msctools.mscfinder.msctpeak +SYSTEM: V2.16 +DATE: Wed Aug 8 19:26:21 MST 2012 +FROM: valdes + +BUG: The IRAF system core version of the tables library now used changed + in its default behavior when creating and reading tables without + an explicit extension. This results in the error: + + ERROR: Table `/tmp/iraf?????' does not exist or cannot be opened. + + This requires a change to the script to use an explicit extension. + A workaround is possible by editing the script but it is recommended + that you just update the appropriate external package. + +STATUS: Fixed in the latest version of the packages. + +NUMBER: 586 +MODULE: apsum/apall +SYSTEM: V2.16 +DATE: Tue Mar 12 12:55:34 MST 2013 +FROM: valdes + +BUG: When cleaning or weighting and an aperture runs off the edge of the + there was a bug that could allow referencing outside of the image + data array. The value would then be arbitrary which could produce + errors such as floating or arithmetic exceptions. The workaround + is to eliminate apertures that go off the edge. + +STATUS: Fixed for the next release. diff --git a/local/help.log b/local/help.log new file mode 100644 index 00000000..298455c6 --- /dev/null +++ b/local/help.log @@ -0,0 +1,1474 @@ + +NUMBER: 1 +KEYWORDS: splot, scopy, imslice, multispec +DATE: Mon Jan 3 14:22:09 MST 2005 +FROM: valdes + +Q: I have spectra that have been produced by 'apall', with 4 bands + and 2 apertures, with 3071 data points, thus have dimension + [3071,2,4]. I want to shift from band to band simply by + using the ')' and '(' within 'splot', I actually have to exit + 'splot' each time, and specify the band at the prompt or on the + command line. + + What I tried to do is separate the 2 apertures into 2 distinct + files, each one of them being [3071,1,4]. Naturally, I can + accomplish this more or less with 'imslice', in which case I end up + with 2 files, each [3071,4]. In principle, this is perfectly OK, + but the problem is that when I try to use 'splot' on these [3071,4] + files, I still cannot shift from band to band simply by using the + ')' and '(' within 'splot'. + +A: The '%' key in SPLOT can be used to go to a new band. You have to + enter the band so it is not quite as convenient as '(' and ')' + which is for apertures. The ')' and '(' keys do have a special + feature that if there is only one aperture then it steps through + the bands which is why you thought of splitting the apertures. + + For the approach of separating the apertures you cannot use + IMSLICE because it automatically changes the dimension of the + multispec image. There are ways to add the dimension back but they + are not easy. Instead use SCOPY to copy out each spectrum with its + extra bands. This task can split multispec formats to single + spectra but it doesn't naturally split things into multispec + organized by aperture. However, with a simple loop you can do what + you want. The solution is + + on> for (i=1; i<=2; i+=1) + scopy ("abc.ms", "abc"//i//".ms", aperture=i) + + Of course with just two spectra you could just do the command twice + without the loop and the generation of output names based on the + line number. + +NUMBER: 2 +KEYWORDS: tables, binary, fits, tprint, tdump +DATE: Tue Jan 4 02:44:51 MST 2005 +FROM: fpierfed + +Q: How do I convert a table in FITS binary format to ASCII using IRAF? + +A: Converting a table in FITS format to ASCII is pretty simple. All you need is the TABLES package, developed and distributed by STScI (http://www.stsci.edu/resources/software_hardware/tables). Within TABLES, the tasks that you might want to use are tdump and tprint. The first one is pretty simple to use. tprint on the other hand offers more control on the output. At the minimum, you can do something like this: + +tt> tdump combined_dr2_062404.fits > my_ascii_table.dat + +Please, keep in mind that any further support on the TABLES package is handled by STScI directly (help@stsci.edu). + + +- + +NUMBER: 3 +KEYWORDS: filesize largest 64bit +DATE: Wed Jan 5 10:47:47 MST 2005 +FROM: zarate + +Q: +I'm working with some large images (1-2 GB), and IRAF has a problem with +this. Any tool I try to run gives me the message: + +ERROR: Attempt to write out of bounds on file + +This is an example from an 'imarith' attempt, but it seems to happen with +all tools. It seems to me that IRAF isn't allocating enough memory in +some sort of buffer to be able to work with the images. Does this sound +correct? And if so, do you know how I can fix it? + +I'm running this on a UNIX system (Solaris 8) with 4 GB of RAM, running +IRAF version 2.12.2a. Let me know if you need any more info. + +A: + Iraf file size is limited to the 32 bit range which + is about 2GB. When an IRAF task like imarith opens an + input image and tries to creates another one near this + limit you migth get this kind of problems. The same + limitation applies to memory requirements of a task. + + To find out if this is your problem, you could you + can operate on a subsection of the big image and see if it + goes to completion. + + This will be addressed with the 64 bit extension of IRAF which is + still pending. + +NUMBER: 4 +KEYWORDS: vertical labels specplot txset +DATE: Wed Jan 5 15:12:05 MST 2005 +FROM: valdes + +Q: How do I write vertical labels in SPECPLOT? + +A: Unless the application, such as IGI or SPECTOOL, provide features for + adjusting the text attributes, or an application like IDENTIFY + automatically writes vertical text, the only control you have is + with the "cursor mode" capability. To learn about this type + "help cursors" in IRAF. Cursor mode is quite a nice feature since + it applies to all graphs but it has the drawback that any redraw of + the screen (by the application) will lose the changes and it is not + possible to put the cursor mode commands in a file to be executed + again. + + Before describing what to do with SPECPLOT I will point out that + you might investigate the tasks noted above. In particular, + SPECTOOL is a powerful alternative to the tasks in the standard + NOAO spectroscopy packages. It has features for stacking, like + SPECPLOT, and for marking and labeling things, like IDENTIFY, and + general interactions like SPLOT. There are GUI control panels to + do things like set the graphics attributes. + + Now for SPECTOOL start up the program. As described in the cursor + mode help page, to get the graphics on your screen to look like + they will look (approximately) in a postscript file you should type + ":.txq h". Then do a 'r' to redraw the SPECPLOT graph. This allows + the lettering to be drawn with strokes rather than hardware fonts. + + Next rotate the lettering path with ":.txset up=180". Then start + adding the labeling with the 'T' key available in cursor mode. You + can save intermediate states with ":.w " which you + restore with ".r ". Note that if you write to the same + file more than once it will append. When you read it back the + screen will flash with all of the past saves. Finally dump the + graph with something like ":.snap eps". Again, if you do a redraw + SPECPLOT will forget about the changes you made with 'T'. + +NUMBER: 5 +KEYWORDS: encapsulated postscript snap +DATE: Wed Jan 5 15:16:12 MST 2005 +FROM: valdes + +Q: How do I make a postscript file from the SPECPLOT? + +A: + When you have the graph you want type one of the following + + :.snap eps + :.snap epsl + :.snap psdump + + The first two produce a file sgiXXXXXX.eps in your working + directory and the last produces a file irafdmpXXXXX.ps in /tmp. + Because of buffering you might need to type ".gflush" from the + cursor mode or "gflush" from the CL command line. The two EPS + files are in portrait and landscape. You would probably want to + rename the files so you remember what they are. + + Note that postscript in IRAF is black and white only. To get color + postscript see + + http://iraf.noao.edu/iraf/web/faq/FAQsec08.html#8005 + + Another task to call your attention to is "igi" in the + tables.tbplot package. This is a Mongo-like graphics language + interpreter that understands IRAF files. While you need to learn + the language it is what I use if I really need complex graphics + with lots of labels and spectra. It is convenient because you can + keep the commands in a text file. If you are happy with SPECPLOT + for what you are doing then this would be overkill. + + +NUMBER: 6 +KEYWORDS: longslit fitcoords transform fceval +DATE: Thu Jan 6 12:44:12 MST 2005 +FROM: valdes + +Q: I would like to generate a mapping from (x,y) pixels of an image + to a wavelength and a spatial axis coordinate. I know this is + what TRANSFORM through the FITCOORDS database. Can I do the + evaluation directly from the CL? I found that the IRAF math + libraries include routines for evaluating the FITSCOORDS mappings + but I can't find a CL interface for them. Is there a way to use + the math routines to evaluate the FITCOORDS mappings? + +A: You are in luck because a task to do what you want was added to + V2.12.2 (and following patches). So if you have the latest IRAF + then the task you want is LONGSLIT.FCEVAL. + + As far as accessing the functions in the math package these are + purely for SPP programming. In future there will be language + bindings for access from other languages but it will still be + largely intended for software developers rather than users. While + it might be an interesting idea to wrap these functions into CL + callable tasks it might not be so useful depending on how the input + is defined. Anyway, this is a low priority at this time. We do + welcome suggestions such as the one that led to FCEVAL which was + basically similar to your request. + + +NUMBER: 7 +KEYWORDS: VMS Platform Support +DATE: Tue Jan 11 12:12:33 MST 2005 +FROM: fitz + +Q: Is IRAF still available for VMS? + +A: We haven't supported VMS in a few years so the most recent version + we have is IRAF V2.11.3 (Dec99) which was prepared under VMS 7.1. + You can still download this from the archive directory: + + ftp://iraf.noao.edu/iraf/v211/VMS7 + + If it works you're in luck, but if there are problems I'm afraid + there's not much we can do to help as all our VMS systems were + abandoned a while ago. + +NUMBER: 8 +KEYWORDS: xgterm, RedHat Enterprise WS3, ncurses, garbage on screen +DATE: Wed Jan 12 10:31:17 MST 2005 +FROM: valdes + +Q: We are running RedHat Enterprise WS3 (Taroon update 4) + and implot produces garbage on the screen. We are not using xgterm + because it requires curses 4 and we only have curses 5 + +A: Be sure that you aren't using konsole or gnome-terminal, as neither + of these implement the textronix tools. You must use xterm or + xgterm. Garbage on the screen is typically due to a mismatch in + the terminal setting. If you see the garbled text when usign an + xterm, then you probably have the terminal set to 'xgterm'. Edit + your login.cl file. + + To get xgterm working, there are two things you can try. There is + version of x11iraf that is linked against ncurses version 5. You can + get that from the following link: + + ftp://iraf.noao.edu/pub/fitz/x11iraf-v1.3.2-bin.redhat.tar.gz + + The alternative is to create a symbolic link as follows: + + cd /usr/lib + ln -s libncurses.so.5 libncurses.so.4 + + +NUMBER: 9 +KEYWORDS: DS9, color problem +DATE: Wed Jan 12 10:42:01 MST 2005 +FROM: valdes + +Q: We are using DS9 with RedHat Enterprise WS3 and when we use the + IRAF display task we only see a pink box though directly loading + by DS9 works fine. + +A: The user reported that upgrading from DS9 V3 to DS9 V3.03 fixed + the problem. + +NUMBER: 10 +KEYWORDS: DS9, display, WCS, coordinate display +DATE: Wed Jan 19 09:02:12 MST 2005 +FROM: valdes + +Q: When I load a fits image (say, a 2Mass image) from within DS9 (with + file->open), the cursor on the DS9 display provides the x,y and + RA,DEC position on the image. + + If instead I use the IRAF/display command to load the same image on + DS9, then I only get x,y from the cursor, no RA-DEC. Why can't DS9 + read the world coordinates of the image when displayed from IRAF cl? + + Is there a parameter I should update somewhere? + +A: When IRAF sends the image WCS to the display server it includes the + pathname to the image, however DS9 doesn't currently do anything + with this filename and so only displays the x,y coords and + approximate pixel value based on the z1/z2 scaling. When DS9 loads + the image standalone it's able to read the image pixels/wcs + directly and makes use of them. There is no parameter you can set, + this is a change that needs to be made in DS9 to have it access the + image when displayed from IRAF. + +NUMBER: 11 +KEYWORDS: Debian, LNUX, IRAF platforms +DATE: Wed Jan 19 09:07:38 MST 2005 +FROM: fitz + +Q: Is there any distribution of IRAF compatible with the Debian linux? + +A: The standard PC-IRAF system supports Debian using the LNUX + architecture. You'll need the as.pcix.gen source distribution, and + the ib.lnux.x86 (core IRAF) and nb.lnux.x86 (NOAO package) binaries + as well as the pciraf.ps installation guide (all files compressed so + note the .gz extensions). See also the README file. You can download + the files from our archive in ftp://iraf.noao.edu/iraf/v212/PCIX. + +NUMBER: 12 +KEYWORDS: cosmic rays, crutil +DATE: Fri Jan 21 11:38:07 MST 2005 +FROM: valdes + +Q: Last year, Wojtek Pych (Copernicus Center, Poland; also Dunlap Obs.) + published an interesting paper on a fast algorithm for CR removal + from single CCD images, suited especially for 2-D spectral images + (Pych, PASP 116, 148, 2004 Feb). His C code is available at + + http://www.camk.edu.pl/~pych/ + + Do you by any chance know whether anyone has written an IRAF task + that runs this code? (I have asked Pych directly, who does not + know of any such task.) + + If that hasn't been done yet, I'll try to have one written, since + Pych's code seems to be very efficient and good at CR removal from + single 2-D spectra. + +A: I am not aware of anyone that has implemented this in an IRAF task. + I just quickly read the paper and the method is simple enough that + it should not be hard, particularly with the code available. It + would be a interesting addition to the suite of tasks recently + collected together in a CRUTIL package. + +NUMBER: 13 +KEYWORDS: mosaic astrometry, WCS solutions for multiple amps/CCD +DATE: Fri Jan 21 11:51:46 MST 2005 +FROM: valdes + +Q: I am trying to derive a WCS for a new mosaic camera. + I have used CCMAP to derive a fair WCS using ten bright stars on + one amplifier of one ccd. To simplify the situation, I have cut + three of the CCD's out of the mosaic, so I have only two amplifiers + (and two extensions) to work with. My first question deals with + how to treat both amps at once. CCMAP seems to want only one + extension at a time, or a frame that has been put into a simple + fits format. I can create the simple format by copying the two + extensions into one simple fits file (but I lose the header info + from extension [0]), but I don't think this is what I should be + doing. I assume I derive a WCS for the mosiac and then make a + simple fits file which is corrected and shifted to a point common + with the other dithered images of the same object. Am I right? + How do I treat the two amps (extensions) with CCMAP? + +A: Your are right that you should derive a single WCS for a CCD since + multiple amplifiers are geometrically linked. This is what is done + with the CTIO mosaic that has 2 amplifiers per CCD and I do a + single WCS solution for each CCD which are then divided across the + amplifiers. The way this is done is to derive a database solution + for the merged single CCD using MSCTPEAK. In the database it + should say pixsystem is physical. + + Then the other thing is setting up the mapping between physical + coordinates (think of this as CCD coordinates) and the pixels in + the amplifier images correctly. This is done with the LTV1 + keyword. Normally you would have no LTV or LTM keywords in the raw + data but it might depend on the presence of any over/pre scans on + the left side of the image. + + LTV1 should be the offset from the first pixel of the real data, + i.e. the merged CCD image and the first pixel in the amplifier + image. An example is best here. Suppose you have two amplifier + image extensions called im1 and im2. In im1 there is nothing on + the left. This means pixel (1,1) is the first CCD pixel + corresponding to (1,1) in the image you used for MSCTPEAK. Then + the offset in x is 0 and you can either set LTV1=0 or leave it out + because the default for a missing LTV keyword is 0. Now the first + amplifer reads out the first 1024 pixels of the CCD. The second + amplifier reads out the second 1024 pixels. Again, if there is no + dummy data on the left of the image for im2 then the first image + pixel maps to pixel (1025,1) in the merged CCD image. Then the + offset is LTV1=1024. + + Once you have this setup to define this "physical" or CCD + coordinate system then MSCSETWCS will apply a database solution + appropriately. This only modifies the WCS keywords and will set + CRVAL1/CRVAL2 to some real point on the sky for the exposure based + on a keyword in the header. That is, the one solution for the CCD + will be set appropriately for each of the two amplifiers. Note + that what this really means is that the keywords will be the same + except that the CRPIX1 keywords will differ by some amount. As a + reminder CRPIX1 is the pixel relative to the image that corresponds + to the "tangent point" where the CRVAL1 keyword gives the RA (in + degrees). As noted in the astrometry write up the celestial point + on the sky needs to be the same for all the pieces of a mosaic and + then the CRPIX keywords define the different distances of a WCS to + that point on the sky in terms of the origin of the particular + image. + + To illustrate what I do for the CTIO mosaic I make 8 solutions for + the 8 CCDs. These are labeled im1, im3, im5, etc in the database. + I then copy the first 8 to the end of the file and change the + labels to im2, im4, etc. There is nothing else changed in terms of + the WCS. + + Once you have the database file then running MSCSETWCS to populate + the WCS in the mosaic data will preserve the headers and only + change the WCS keywords. + + References: + + http://iraf.noao.edu/projects/ccdmosaic/astrometry/astrom.html + http://iraf.noao.edu/projects/ccdmosaic/generic/generic.html + + +NUMBER: 14 +KEYWORDS: binary tables, spectra, splot, rspectext +DATE: Fri Jan 21 12:19:28 MST 2005 +FROM: valdes + +Q: I have at my disposal spectra in FITS format, but with a binary + table extension. The extension contains the following: + + WAVELENGTH R %10.3f ANGSTROMS + FUNNORM R %10.4e "" + FNORM R %10.4e "" + SNR R %10.1f "" + ORDER I %3d "" + + I am wondering how I can use IRAF NOAO tasks such as SPLOT (to + examine, e.g. 'fnorm' vs 'wavelength') or CONTINUUM (to continuum + normalize 'funnorm') on these data. + +A: We would like to eventually have SPLOT, and other ONEDSPEC tasks, + operate directly on this table format. A table format for spectra + is a reasonable thing but in the IRAF NOAO packages we use an image + format with a WCS in the header to handle the coordinates. + + The current solution is to extract the data you want into a two + column text file. The tasks in the TABLES package provide the + ability to convert a FITS table into text. The TABLES package must + be installed separately from the STSDAS distribution which is also + available at + + http://iraf.noao.edu/contrib.html + + You could also use TABLES tools for plotting and GRAPH for the text + files. But all of the analysis features in SPLOT require use of + image format. + + The columns would be wavelength and one of the flux columns. You + would then use the task ONEDSPEC.RSPECTEXT to convert the text file + into an image spectrum. In this task there are choices about how + to create the wavelength coordinate system. If the coordinates + vary smoothly a fit is a compact description. But you can also use + the non-linear mode to store each wavelength in a list in the + header. Note that this method has a limitation that the list, + which is stored as text, has to fit in less than 999 68 character + strings. So a very long spectrum could not be handled in this + way. + +NUMBER: 15 +KEYWORDS: spectra, continuum +DATE: Mon Jan 31 09:35:44 MST 2005 +FROM: valdes + +Q: I am having a strong continuum in my extracted blackbody corrected + spectra of which I want to get rid off ( I am looking for a faint + emission on this continuum). Can you suggest me a way to do it + effeciently, since I am having 100 such spectra. + +A: The task CONTINUUM in the ONEDSPEC package may be used. Defining + the continuum can be hard if there are many lines. Thie method in + CONTINUUM (which is also available with the '/' key in SPLOT) is to + fit a function with rejection of the high and low points. It + primarily works well with spectra that are either all absorption or + emission so that a one sided clipping can be used. For your + question about emission you should use something like a 1-sigma + threshold below and 4-sigma (or higher) above. This will then + approach the continuum from below removing the absorption lines + while not removing emission lines. + +NUMBER: 16 +KEYWORDS: spectra, smoothing, filtering, boxcar +DATE: Mon Jan 31 09:37:58 MST 2005 +FROM: valdes + +Q: Is there any way in IRAF by which I can take a 5 point running + average for a given specta (say spectra.imh). + +A: This can be done either with the SPLOT 's' key or with the task + BOXCAR. In both cases a moving average is also called "boxcar + smoothing". In SPLOT it is interactive for visual interaction. + The result can be saved from SPLOT if you want. Note that other + tasks in the IMFILT package (see help imfilt) can be applied to 1D + spectra as well as 2D. The most common alternative to boxcar + filtering is gaussian filtering. + +NUMBER: 17 +KEYWORDS: crosstalk, MiniMosaic +DATE: Thu Feb 3 16:32:20 MST 2005 +FROM: valdes + +Q: Where can I find the latest MiniMosaic crosstalk files? + +A: As far as we know, there are no crosstalk files for MiMo. Users + generally are more concerned if a bright star is present for issues + of saturation bleeding and ghosting (ghosting is described in the + MiMo manula). As to crosstalk, it is assumed to be low (an old + measurement is "a few adu in multiple 10,000 adu". + + +NUMBER: 18 +KEYWORDS: photometry, DAOFIND, CENTERPARS +DATE: Thu Feb 3 16:43:14 MST 2005 +FROM: valdes + +Q: We are doing variability photometry and occasionally get about + 700 CCD images per night. I do the reductions in IRAF, and mostly + it goes pretty quickly, except dealing with coordinate files. Is + there any way to specify the positions of the stars to do + photometry on, so you don't have to edit 700 coodrdinate files that + come out of DAOFIND? The drift of the objects during the night is + fairly small, but not zero, but the fields are not crowded, so if + there is so me way to define a coordinate box where DAOFIND looks, + that would save alot of editing and messing around with S/N + cutoffs, and max brightness levels to try and reduce the number of + stars DAO finds to a manageable level. + + +A: There is no need to use DAOFIND before every exposure when the + images have only small shifts. Once you have a list of pixel + positions of the stars, say from DAOFIND, in one exposure all you + should have to do is recenter the pixel coordinates for each + exposure rather than "find" them again? The DAO package photometry + tools have options to center on the sources provided by the input + coordinates. The centering option would be controled by the + CENTERPARS parameter set. So consult the CENTERPARS help file. + + Centering works when the shifts are fairly small and the field is + not too crowed. The CENTERPARS options work within a box around + the starting coordinate. So the box should be big enough for the + shift but not so big as to include another star within a couple of + magnitudes fainter (very faint stars should not affect the + centroid). + +NUMBER: 19 +KEYWORDS: spectra, convolution, multispec, 3D +DATE: Fri Feb 4 13:02:22 MST 2005 +FROM: valdes + +Q: I have a set of multispec FITS that I need to convolve (gauss, + boxcar, ...). Each multispec FITS has 3 spectrum with the same + dispersion and all of them need to be convolved. The gauss or + boxcar tasks complain about the higher dimensions. Is there a way + to convolve the multispec without having to extract each aperture, + convolve, and them combining them again? + +A: The BOXCAR, GAUSS, ..., tasks will work on 1D and 2D data. If you + have multiple apertures in the multipec format, that is more than + one line, then you would set the convolution size in y to 1. Now + if you have the third dimension, the "extras" information from + APALL, then you do have to do something because the tasks are not + designed for 3D data. You can do things fairly easily as follows. + + Let me assume you have multispec data which is [*,3,4]. There are + some number of wavelength points along the first dimension which + you want to convolve, there are 3 spectra, and each spectrum has + the primary spectrum and 3 associated spectra. Note whether it + makes sense to convolve the sigma spectrum I won't address. For + this example suppose you want to do a boxcar convolution of 5 + pixels. + + cl> boxcar spec.ms[*,*,1] band1 5 1 + cl> boxcar spec.ms[*,*,2] band2 5 1 + ... + cl> imstack band1.band2,band3,band4 newspec.ms + + You could also do this with a loop: + + cl> for (i=1; i<=4; i+=1) + >>> boxcar ("spec.ms[*,*,"//i//"]", "band"//i, 5, 1) + cl> imstack band1.band2,band3,band4 newspec.ms + + In summary, you want to use image sections to select bands of the + 3D multispec file and use IMSTACK to rebuild the 3D multispec + format. + + +NUMBER: 20 +KEYWORDS: apall, long slit, dispaxis +DATE: Fri Feb 4 13:15:40 MST 2005 +FROM: valdes + +Q: I am attempting to run apall to extract spectra from images that + have the dispersion axis running horizontally (along x-direction) + and the spatial axis running vertically (y-direction). However, it + seems that this IRAF task is hard-wired to interpret data with the + oppsite orientation, and I am having a difficult time finding the + parameter which can be changed so that the program recognizes the + orientation of my dispersion axis. Currently, it chooses a + dispersion line which runs parallel to my dispersion axis...i.e. it + chooses a line that misses my object spectrum all together! I think + that the program should be choosing a line that runs perpendicular + to my dispersion axis (and consequently my object specrum) so that + eventually the dispersion line will run across my object, from + which I can define an aperture window from there. + + +A: I think you are asking about defining the dispersion axis. This is + done either by a header keyword DISPAXIS or the parameter + "dispaxis" in the parent package parameters. For example, if you + load APEXTRACT then use "epar apextract". If you use KPNOSLIT then + do "epar kpnoslit". The values of dispaxis are 1 for dispersion + increasing/decreasing with the column (first image axis), which is + horizontal when viewed in an image display, and 2 for the opposite + orientation. From what you describe you want dispaxis=1. + + +NUMBER: 21 +KEYWORDS: Gemini, SALT, crosstalk, xtalkcor +DATE: Mon Feb 7 08:47:35 MST 2005 +FROM: valdes + +Q: I am using the GEMINI package convention of using EXTNAME and + EXTVER, so that the image extensions are named [SCI,1], [SCI,2], + etc. This would have worked with the old xtalkcor.cl, but with the + new one I am getting an error message: + + Warning: FXF: extname and/or extver value already exists + in extension ('SCI') + + +A: I did manage to use xtalkcor on Gemini-convention data. I thought + you might be interested in how in case anyone else asks. By the + way, the reason I am doing this is that I am adapting the Gemini + package (with their approval) to use on the Southern African Large + Telescope (SALT); I am PI on the first major instrument, Prime + Focus Imaging Spectrograph (PFIS), which has a similar CCD layout + and mode set to GMOS. I wanted to graft your xtalkclcor into it, + since they say their crosstalk is too small to bother with a + correction, and ours is not. + + The only incompatibility arises from the Gemini extension names, + which are [SCI,1], [SCI,2], etc. Xtalkcor appears to slice the MEF + into individual fits files named xxx_SCI,1.fits, xxx_SCI,2.fits, + etc. The comma in the fits name confuses those tasks that + interpret image lists, where "," denotes a new image. The + crosstalk correction is correctly applied, it just trips up trying + to glue the fits files back into an MEF. So I used your "split" + option and glued them back together myself, begin careful to not + use routines that use image lists, or by escaping the "'" with a + "\". It works fine, and is nice and fast, even for unbinned data: + + ---------------- + # do crosstalk correction using mscred.xtalkcor + # ignore bpm for now + # get around xtalkcor bug by splitting extensions + # and re-assembling them with fxcopy + + if (canxtalk) { + mscred.verbose=l_verbose; mscred.logfile=l_logfile + xtalkcor(output[ii],output[ii],output[ii], + xtalkfiles=tmpxfile,bpmthreshold=-10.,split+, + fextn="fits",noproc-) + + tmpfile=mktemp("tmpfile")//".fits" + fxcopy(output[ii],tmpfile,groups="0",new_file+,verbose-) + imdelete(output[ii]//".fits",verify-) + imrename(tmpfile,output[ii]//".fits",verbose-) + + for (jj=1;jj<=n_ext[ii];jj+=1) { + fxcopy(output[ii]//"_"//l_sci_ext//"\,"//jj//".fits", + output[ii]//".fits", groups="", new_file-, verbose-) + salhedit(output[ii]//"["//jj//"]","EXTNAME",l_sci_ext, + "Extension name") + salhedit(output[ii]//"["//jj//"]","EXTVER",jj, + "Extension version") + } + + salhedit(output[ii]//"[0]","XTALKCOR ","yes", + "Corrected for amplifier crosstalk") + print (output[ii]//"_"//l_sci_ext//"*.fits") + delete (output[ii]//"_"//l_sci_ext//"*.fits", verify-) + delete (output[ii]//"*.pl", verify-) + delete ("pfisxtalk_*", verify-) + } + ----------------------------------- + + +NUMBER: 22 +KEYWORDS: graphics, windowing, zooming, gtools, identify +DATE: Mon Feb 7 09:01:45 MST 2005 +FROM: valdes + +Q: I've been able to get to the wavelength calibration part of + my spectral reduction, and am currently assigning wavelengths to my + arc..however there was a bad column in the chip, and thus there is + one segment of my plot that has a horrendous spike...now I have + tried to find a way to remove that spike and re-plot my arc + spectrum (after extraction, naturally), but haven't found a way...I + also tried to find a way to change the y-axis (i.e. :y 300 500) but + that doesn't seem to work when I am executing the task IDENTIFY. + +A: There are two questions here. One is editing the data in an + applicatation graph, what you called "remove that spike". There is + no generic way to edit data in a graph though some applications + such as SPLOT and SPECPLOT let you do that. + + The second question about replotting the data is very common. This + is how one "expands" the plot to see finer detail. In many of the + science applications, though not all and not in the core PLOT or + IMAGES package, there is an interface called GTOOLS. If you type + "help gtools" you can read about it. These are commands to tell + the application how to redraw the graph. So in IDENTIFY you would + do something like 'w' 'e' 'e' to expand the graph. Also 'w' 't' to + put an upper limit in order to chop off the spike. It is important + to know that 'w' 'a' will return you to autoscale which is what the + applications usually do by default. So there are lots of + keystrokes available. Note also that the 'z' and 'p' keystrokes in + IDENTIFY let you zoom around the marked features and then cancel + the zoom. But what I most often use with IDENTIFY are the e and a + window commands. + + +NUMBER: 23 +KEYWORDS: apall, upper/lower, aperture widths +DATE: Mon Feb 7 09:12:06 MST 2005 +FROM: valdes + +Q: One thing I did want to clarify under the APALL parameters, + numerous as they be...the actual extraction aperture is defined by + the "upper" and "lower" parameters, true? The profile centering + width, nsum, etc are simply for centering purposes, as far as I can + discern...though this is my first time reducing spectra. + +A: In APALL when you first type 'm' or use the automatic find the + application needs to have a default aperture width. You are + correct that upper and lower define the default. If you edit an + aperture in the edit mode and then mark a new aperture it will use + the last defined aperture. But for most purposes you need only to + be concerned with "upper" and "lower". You are also right that the + widths used for centering on a feature for setting an aperture and + tracing are not the same as the aperture width. + +NUMBER: 24 +KEYWORDS: implot, splot, graphics, windowing +DATE: Tue Mar 29 10:19:29 MST 2005 +FROM: valdes + +Q: When I inspect a reduced spectrum (an image file) of DN vs. + wavelength with IMPLOT I can use 'e' and 'e' to mark the lower + left and upper right corners of a window. But with SPLOT that + doesn't work at all: nothing happens. + + I can use 'a' and 'a' to define the left and right sides of a + window in SPLOT, but then the lower and upper edges are set by the + bottom and top DN values in that window. This is very limiting. + Can you suggest a solution? + + +A: For various reasons a distinction is made between "core" image + processing tasks and astronomical applications tasks concerning + features and standards for windowing graphics. Many of the + applications tasks, such as SPLOT, use a layer called "gtools". If + you type "help gtools" you can get info about the many functions. + The help for the application, such as typing '?', should tell you + that the commands are extended with the gtools commands. The + extensions are done using a precusor which is 'w' for cursor + windowing and '/' for colon commands. The equivalent of the 'e' + key in IMPLOT is 'w'+'e'. + + SPLOT not only has the gtools functions but it has a few of its own + windowing commands such as 'a' and 'b'. The 'a' key, along with + the keys that slide the window, are actually pretty useful since + they "autoscale" with the data in the window. But since you don't + want this behavior what you are looking for is 'w'+'e'+'e'. + + There is no equivalent standard for the core tasks such as IMPLOT. + So the 'e' is simply a part of IMPLOT. What is standard in all + graphics, both core and application, are the cursor mode functions + (see "help cursors"). Note that this applies to the rendering of + the graph so you lose the axes with something like 'E'. The + distinction is whether the application redraws the graph of the + rendering layer simply replays the graphics stream with zooming or + whatever. + + In windowing graphics there is usually the ability to use colon + commands to explicitly set limits rather than just using the + cursor. In IMPLOT this is the :x and :y commands. In the gtools + functions these are the :/xwind and :/ywind commands. It may be + that you want these to, for instance, force the bottom to be zero + for spectra. The 'b' key in SPLOT does this for you. + + So it is possible to do exactly the same thing in SPLOT as in + IMPLOT but the keystrokes are not the same and the set of windowing + options are much greater in SPLOT. + + +NUMBER: 25 +KEYWORDS: doslit, doecslit, dofiber, dohydra, doargus, dofoe, imtype +DATE: Fri Apr 15 10:56:47 MST 2005 +FROM: valdes + +Q: I'm getting the error message: + + cc> doslit + List of object spectra (a0134): + Edit apertures for a0134? (yes): + ERROR on line 58: Arc reference spectrum not found - a0135 + doslit () + + However, the file a0135.fits does exist. What's wrong? + +A: This error is usually caused by a mismatch between the image extension + you have set as the default and the type of your data. Because + the installation default is "imh" but now it is more common to use + FITS files this mostly occurs when imtype="imh". You can change the + default imtype value by editing your login.cl, uncommenting the line + for imtype and changing the value to "fits" (or whatever + extension you use). + + This dependence on imtype is a "gotcha". The task needs to + manipulate the image names and uses the imtype variable to do + this. This is described in + + http://iraf.noao.edu/irafnews/apr98/irafnews.1d.html + + The reason this is not more general is that this program preceded + the changes which allowed people to use different image types and + the quick way to modify this complex task was to use the imtype + variable to tell the script what extensions to look for. + + I have made a changes to various related task to help with this + occasional "gotcha". The new behavior will be to show the full + name the task is looking for and to add a hint to check the imtype + variable. + + kp> doslit + ... + ERROR on line 58: Arc reference spectrum not found - demoarc1.imh + Check setting of imtype + kp> dir demoarc1* + demoarc1.fits + + +NUMBER: 26 +KEYWORDS: echelle, multispec, crpix, cdelt, slist, scopy +DATE: Fri Apr 15 12:53:32 MST 2005 +FROM: valdes + +Q: I have reduced, extracted, linear dispersion echelle data with + headers similar to that in Figure 3 of section 5.1 of phelp + onedspec.specwcs + + I want to extract the "specN" data for each aperture. + Specifically, I am interested in getting w1 and dw for each order + for use in an alternate application which requires specification of + CRVAL and CDELT. + +A: What you want is the task SLIST: + + on> slist test.ec + test.ec 1 1 108 0 5174.281 0.07307974 512 Artificial Echelle Spectrum + test.ec 2 2 109 0 5126.81 0.07240991 512 Artificial Echelle Spectrum + test.ec 3 3 110 0 5080.203 0.07175154 512 Artificial Echelle Spectrum + test.ec 4 4 111 0 5034.435 0.07110465 512 Artificial Echelle Spectrum + test.ec 5 5 112 0 4989.485 0.07047016 512 Artificial Echelle Spectrum + test.ec 6 6 113 0 4945.33 0.0698462 512 Artificial Echelle Spectrum + test.ec 7 7 114 0 4901.95 0.06923369 512 Artificial Echelle Spectrum + test.ec 8 8 115 0 4859.324 0.0686317 512 Artificial Echelle Spectrum + test.ec 9 9 116 0 4817.434 0.06804022 512 Artificial Echelle Spectrum + test.ec 10 10 117 0 4776.259 0.0674583 512 Artificial Echelle Spectrum + + The sixth and seventh columns give the starting wavelength and + reciprocal dispersion. + + Note that you could also copy the + orders to separate 1D images that will have the simple FITS keywords + you want: + + on> scopy test.ec test format=onedspec verb+ + test.ec[*,1](1) --> test.0001(1) + test.ec[*,2](2) --> test.0002(2) + test.ec[*,3](3) --> test.0003(3) + test.ec[*,4](4) --> test.0004(4) + test.ec[*,5](5) --> test.0005(5) + test.ec[*,6](6) --> test.0006(6) + test.ec[*,7](7) --> test.0007(7) + test.ec[*,8](8) --> test.0008(8) + test.ec[*,9](9) --> test.0009(9) + test.ec[*,10](10) --> test.0010(10) + on> imhead test.0001 l+ + test.0001[512][real]: Artificial Echelle Spectrum + [...] + CTYPE1 = 'LINEAR ' + CDELT1 = 0.0730799958109856 + CD1_1 = 0.0730799958109856 + CRVAL1 = 5174.2807617188 + CRPIX1 = 1. + [...] + + +NUMBER: 27 +KEYWORDS: long slit, transform, fceval, S-distortion +DATE: Tue Apr 26 09:01:38 MST 2005 +FROM: valdes + +Q: I have just installed the latest version of IRAF in order to use + your recently introduced fceval package. It is a very useful + addition. Thank you! + + Anyway, I have a question regarding its use. + + In the first example you give: + cl> fceval STDIN STDOUT arcfit,std + + where, I assume, "arcfit" and "std" are the database fits produced + by "fitcoords", such that you have two separate, distinct fits for + each axis (dispersion (arcfit) and spatial (std)). + + I can understand how you came by the dispersion fit (ie. via + "identify" --> "reidentify" --> "fitcoords"), but I am unclear + about what you did to obtain the spatial fit. + + Any help you can give me would be very welcome. + + +A: The spatial distortion function is sometimes called the + "S-distortion". It is meassured either by tracing a bright star, + tracing a calibration obtained by moving the star to different points + on the slit in one exposure, or with a special comb slit. The tracing + is done with IDENTIFY/REIDENTIFY/FITCOORDS just as for the dispersion. + + Note that during the spatial IDENTIFY one can either specify a pixel + position or use some system like arcsec. The effect of all this is to + make the spatial coordinate be that put in during the initial IDENITFY + at some point along the dispersion be the same at all dispersion points + (i.e. straighten the traced features to be exactly aligned with the + rows or columns. + + Note also that one can specify more than one fit along the same axis. + This would normally be a before and after calibration. This averages + the flexture. + + The reason TRANSFORM and FCEVAL allow multiple functions at once is to + allow a single transformation rather than multiple transformation to + minimize interpolation degradation. + + +NUMBER: 28 +KEYWORDS: sarith, ignoreaps +DATE: Mon May 2 10:01:18 MST 2005 +FROM: valdes + +Q: I am using iraf version 2.12.2a . I am trying to use 'sarith' to + sum two spectra. They are both wavelength calibrated. It doesn't + add the two spectra together, but just copies input1 to the output + spectrum. Do you have any idea what may be going wrong? I am + trying to effectively sum two rows of a multi-object 2d frame (or + actually, subtract them as one will be negative) + +A: I thing the problem you are having is that you must set + ignoreaps=yes. When your input consists of columns from 2D images, + SARITH assigns the "extracted" 1D spectra to have aperture numbers + corresponding to the central column. (Note that the "nsum" + parameter in the package parameters may be summing neighboring + columns in this extraction.) By default SARITH only wants to + operate on 1D spectra with the same aperture numbers. To change + this you use the ignoreaps parameter mentioned previously. Other + tasks such as SCOMBINE also generally have an "ignoreaps" parameter + that you should be aware of. + + +NUMBER: 29 +KEYWORDS: spectra, overplotting, splot, specplot, spectool, bplot +DATE: Mon May 2 11:43:50 MST 2005 +FROM: valdes + +Q: I am producing many plots of 5 or more superposed spectra over a + small wavelength range using: + + on> splot spn1c001_01_133 xmin=3900 xmax=4100 ymin=0 ymax=2.5e-16 \ + >>> opt="wr" + + and then interactively typing: o g spn1c001_01_134 + o g spn1c001_01_141 + o g spn1c001_01_143 + o g spn1c001_01_144 + The five plotted spectra are uniquely defined by + "spn1c001_01_1??.fits". + + To save myself all this interactive typing, I would like to simply + type: + + on> splot spn1c001_01_1??.fits xmin=3900 xmax=4100 ymin=0\ + >>> ymax=2.5e-16 opt="wr,o" + + and then four times interactively type "q". As I understand the + help file for `splot', this should produce the same graph ("o" in + options for overplot). + + However, when I do this, each new spectrum appears by itself, and I + have been unable to achieve overplotting in this mode? How do I + prevent the erasing of the previously plotted spectra? Is there a + way to achieve it? Will be grateful for any help or pointer you + may provide, since I am producing dozens of such superposition + plots in the first, inefficient way. + +A: The cycling through images which are specified as the input list + and using 'q' to go to the next spectrum does not work the way you + want. It is equivalent to doing SPLOT separately on each input. + The option setting you tried with the 'o' specification is to avoid + having to type 'o' before every 'g'. It does not apply to a 'q' as + you found. + + The answer to what you want to do is to use the task SPECPLOT. + This task was specifically designed for overplotting types of work + which is common with spectra. It has a number of options, + including scaling and color coding. It may take you a short while + to learn how to use this and the cursor and colon commands but it + is worth learning. + + To do a batch type of graphics with colors and plotting types use a + cursor input file in place of the interactive cursor. For + example: + + on> type cursor.dat + 0 0 1 :ptype[1] 1 + 0 0 1 :ptype[2] 2 + 0 0 1 :ptype[3] 3 + 0 0 1 :color[1] 1 + 0 0 1 :color[2] 2 + 0 0 1 :color[3] 3 + r + q + on> specplot test* xmin=6000 xmax=6250 cursor=cursor.dat + + Note that you must put the "0 0 1" on the colon command lines to + workaround a bug which will be fixed in the next release. You also + need the 'r' to get the plot to redraw. + + You can redirect the graphics to a printer or metacode file if you + want. See BPLOT for some help on how to use cursor input + redirection in IRAF tasks. + + Another reference is that the SPECTOOL graphical tool has many + sophisticated options for stacking, etc. It is a separate add-on + package. You may or may not want to investigate this new tool as + alternatives to SPLOT, SPECPLOT, and other ONEDSPEC tasks. + + + PS You might think BPLOT could do what you want. But because the + spectrum name specified for the 'g' option comes from a parameter + rather than the cursor input you can't use cursor input redirection + for this purpose. + +NUMBER: 30 +KEYWORDS: splot, signal-to-noise, S/N, batch +DATE: Thu Jun 16 16:33:27 MST 2005 +FROM: valdes + +Q: I need to find the signal to noise of a great deal of HST/NICMOS3 + spectra. I know I can use splot and the 'm' key to get signal to noise + interactively. However, I need to make sure that I am using the same + region for signal to noise in each spectra. If I do it interactively, + I can't tell if I am getting the same wavelength range each time. + + Is there another command similar to splot that I can use to get the + signal to noise of a region of a spectra over the same region like in a + batch mode? Or is there some hidden epar file for m in splot that I + can define the wavelength range it uses to calculate signal to noise. + +A: If you like what SPLOT does then the batch version is BPLOT. To give + an example, suppose the wavelength region is 5000A to 5500A (with + the spectra dispersion calibrated in Angstroms). Create a file, + for example cursor.dat, that contains the one line "5000 5500 1 + m". The use BPLOT: + + on> bplot spec* cursor=cursor.dat >G dev$null + m again:avg: 94.28 rms: 16.73 snr: 5.63 + m again:avg: 94.86 rms: 17.83 snr: 5.32 + m again:avg: 94.28 rms: 16.73 snr: 5.63 + on> type splot.log + + Jun 16 16:25 [spec1.fits]: Artificial Spectrum + avg: 94.28 rms: 16.73 snr: 5.63 + + Jun 16 16:25 [spec2.fits]: Artificial Spectrum + avg: 94.86 rms: 17.83 snr: 5.32 + + Jun 16 16:25 [spec3.fits]: Artificial Spectrum + avg: 94.28 rms: 16.73 snr: 5.63 + + The ">G" redirects the graphs to a file (the null file in the + example). If you don't want the "m again:..." output also add "> + dev$null" to send this to the null file. + + Note that the example used the same spectrum with three different + names which is why the answers are the same. + + +NUMBER: 31 +KEYWORDS: mknoise, synthetic spectra, S/N, SNR, artdata +DATE: Tue Jun 28 15:09:11 MST 2005 +FROM: valdes + +Q: I have a question about the task MKNOISE in artdata package. + I would like to inject some noise in synthetic spectra. What I + wonder is how I can relate the read noise and gain in the + parameters in the task to the signal to noise (S/N)? And what are + the reasonable values for background, gain, and readnoise? + + I will use the synthetic spectra for estimating stellar atmospheric + parameters(Metallicity, surface gravity, and temperature ) for SDSS + spectra. + +A: If you are adding noise to existing synthetic spectra then you + probably do not want to add a background. The gain parameter is + used to convert your data numbers to photons for the purpose of + including a Poisson noise. The read noise parameter, on the other + hand, is used to define a constant noise which is independent of + the number of photons. + + The easiest thing is to set "poisson=no" and use a constant + noise. In this case the "gain" parameter is ignored and the + "rdnoise" parameter specifies the constant noise sigma. If you + want to simulate a particular signal-to-noise ratio, SNR, then + determine the average continuum level, , in the synthetic + spectrum. Then the "rdnoise" value you want is /SNR. + + If instead you want to use Poisson statistics set the read noise to + zero, set "poisson" to yes, and set the gain to (SNR)^2/ (the + desired S/N at the continuum squared divided by the mean continuum + value). + + This all assumes your synthetic spectrum is purely positive (i.e. + it is not continuum or sky subtracted). If instead you have just + the source spectrum and you want to simulate an observation with a + non-zero sky you would use the background to add a background or + continuum. It would be simplest if you first add the background + without noise and then follow the suggestions I gave earlier about + setting rdnoise or gain. Then you could subtract the same + noise-less background to return the simulated spectrum to source + only. + + Note that to compare to SDSS spectra you really need to understand + all the details of the SDSS spectra though if you are just matching + a S/N then adding noise as described above may be a reasonable + thing to do. + + +NUMBER: 32 +KEYWORDS: uncertainties, errors, sarith +DATE: Mon Aug 1 09:06:52 MST 2005 +FROM: valdes + +Q: I have a question about the behavior of sarith in noao.onedspec + package. I have a so-called 3D multispec format fits files, + with basically the standard contents: optimally-extracted, + no-weighting, sky, and sigma vectors. When I tried to do an + arithmetic globally on this fits file, this is what I get: + + cl> sarith f1672.oii / 2.38e-18 f1672.oii clobber+ format="multispec" + f1672.oii.fits[*,1,1](1) / 2.38E-18 --> f1672.oii.fits[*,1,1](1) + f1672.oii.fits[*,1,2](1) / 2.38E-18 --> f1672.oii.fits[*,1,2](1) + f1672.oii.fits[*,1,3](1) / 2.38E-18 --> f1672.oii.fits[*,1,3](1) + f1672.oii.fits[*,1,4](1) --> f1672.oii.fits[*,1,4](1) + + I'm wondering why sarith does not do the intended computation on + the 4th vector. I've tried explicitly specifying the band 4 within + the task option, but for some reason operation on that band does + not yield intended results (which is dividing by 2.38e-18 here). + + Is this a bug, or the behavior is intended? + + Also, to make sure I'm interpreting the multispec format. The 4th + vector is an error vector, which means the error/uncertainty + associated with the particular pixel for the optimally-extracted + spectrum (1st vector). So basically if x1, x2, ... , xN are the + optimally extracted pixel values, then the 4th vector contains dx1, + dx2, ..., dxN, such that + + x1 +/- dx1 + x2 +/- dx2 + .. + xN +/- dxN + + are the array of pair (best estimates, uncertainty). I hope + I'm interpreting the format correctly here, but if I'm not, + I'd appreciate if you could let me know. + +A: The behavior with the error or uncertainty vectors is intended though + it raises a common question. The reason for the behavior is + that since SARITH can be doing arbitrary operations, as well + as possibly resampling the spectra, it was decided that rather + than do the incorrect thing to uncertainty it was better to + do nothing. SARITH is not sophisticated enough to due correct + error propagation. + + Your understanding of the meaning of the error array is correct. + In the more constrained situation of extraction from a 2D CCD image + with specified noise model (the readout noise and gain with Poisson + statistics) the uncertainty is the formal 1 sigma error estimation. + + Correct and, more important, meaningful error propagation in a + general image and spectral processing environment is hard and + IRAF task have generally avoided this for some indefinite future. + + +NUMBER: 33 +KEYWORDS: quadformat, quadred, quadproc, gain and readout noise +DATE: Mon Aug 15 09:24:13 MST 2005 +FROM: valdes + +Q: Settings for the read noise and gain appear in the parameter sets + for zerocombine, flatcombine, qzerocombine and qflatcombine + [maybe elsewhere, too??] + + I've got data with one chip from Tololo, but each quadrant is + read out separately. So, there are four gain readings and four + read noise readings in the header. I've been averaging these four + gain and four noise reading values, and entering the average read + noise and gain in the qzerocombine nad qflatcombine parameter sets. + + Is that correct, or does quadproc automatically pick the four + noise readings and four gain readings from the header, and enter + them into quadproc? + + Do I have my parameter files etc., straight? + +A: The gain and read noise parameters are used by the underlying + combine task to try and identify cosmic rays or other transient + noise. While this could be potentially useful in the tasks + you mention, there are other rejection methods, I recommend + "avsigclip", that work just as well and don't require the gain or + read noise. The reason I say this is that the current software + doesn't know about the keywords in the quadformat (see "help + quadformat") which define the gains of the individual amplifiers; + though they should be present as GTGAINij and GTRONij in your data. + So I suggest you not worry about this since CCDPROC doesn't need + this and there are other rejection methods in the combining tasks + that should be fine. After flat fielding the issue of the gain + and readout noise is put off to applications such as photometry + which don't understand the quadformat anyway. + + If you want to do more than I suggest there are two approaches + you could try. One is the task QUADSCALE which can scale the data + to a common gain. The other is to split the data with QUADSPLIT + and treat each quadrant (or half) as separate data sets. + + I need to qualify my response by saying that I have never reduced + CTIO quadformat data and some of the tools were written by others + at CTIO. If you want more guidance on reducing this data you + might contact the instrument scientists at CTIO that support the + instrument you used. + + +NUMBER: 34 +KEYWORDS: mscred, msccmatch, mef, single images +DATE: Fri Aug 26 11:47:31 MST 2005 +FROM: valdes + +Q: I've been using mscred for a long time and have grown used to + the efficiency of msccmatch for WCS fitting and installation. + Is there anything like it for single CCD images? I'm aware of + the imcoords package, but it seems like it would be a lot of work + compared to msccmatch, which just runs by itself. + +A: Msccmatch will work with single images. So you need to have an + initial WCS. Note that msccmatch is not a general matching method + so the assumption is that the WCS is off by a zero point shift, + possibly a small (~1deg) rotation and have some linear distortion. + + In general many of the useful mscred tasks will work on single + images (mscdisplay, msczero, msccmatch, mscfinder, and mscimage + are examples). + + You are right that a general solution would involve imcoords + package. The task ccxymatch is one of the tasks for finding + WCS from scratch but it is sensitive to parameters settings. + + +NUMBER: 35 +KEYWORDS: identify, scripts +DATE: Fri Nov 4 12:35:45 MST 2005 +FROM: valdes + +Q: I am writing some IRAF scripts involving the use of the task + "identify". I would like to use the task interactively, as + when it is launched from the command line. Everything works + fine at the beginning: the task is launched and the graphical + window pops up, waiting for the interactive commands. The + problem is that whenever I try to mark some features using the + "m" key the task does not allow me to type in the wavelength, + just as if the enter key is automatically hit, so that + the feature wavelength remains INDEF. Trying to hit "u" + to enter the wavelength is of no help. The keystrokes and + colon commands work fine, but there is no way of typing in + the wavelength for marked features. I also tried to launch + identify through a simple script with just a line: "identify", + and I noticed that at the end (being the "autowrite" parameter + set to "no") the script does not stop waiting for my answer, + but it gets the last entry and directly exits; also this + behaviour suggests that it is just like an enter command + is automatically sent to the task. Could you give me any + suggestion on how to solve this problem? Thank you for all + the help you may provide. + +A: This is a common "gotcha" (FAQ) with using IDENTIFY. The + IDENTIFY task reads input from the cursor, from parameters, + and from the standard input of the task. It is this last part, + where it asks for such things as the wavelength, that causes + problems with the simplest way to invoke a script. I suspect + you are doing something like: + + cl> cl < myscript.cl + + In this case you are redirecting the standard input of the CL + from the terminal to the script file which then causes the problem + you have. There is an easy solution. You must declare the script + as a task as follows: + + cl> task $myscript = myscript.cl + cl> myscript # This runs the script + + The script must use the .cl extension. The path, such as + home$, is optional but if you don't specify a path then the + script will only run in the directory where the script file + is located. The first $ in the task statement says that the + script does not have parameters. Note there are other ways to + write scripts, which also use the task statement to define them, + that include parameters and is more like a programing language + (see http://iraf.noao.edu/iraf/ftp/iraf/docs/script.pdf). + + To repeat, IDENTIFY cannot be used in a script that is executed + by redirection to the cl but can be used in other forms script + invocations. + + +NUMBER: 36 +KEYWORDS: psfmeasure, ellipticities, position angles, imexamine +DATE: Mon Nov 14 12:53:53 MST 2005 +FROM: valdes + +Q: I have a (long) list of x and y positions of stars in an image. I + would like to measure the ellipticities and position angles of + the images non-interactively. How should I do this? + +A: IMEXAM I suggest you look at the task PSFMEASURE. In the current + version of IRAF it is part of the OBSUTIL package. To do the + non-interactive job you want you would make a text file of x/y + for all your stars. + + ob> psfmeasure starfield imagecur=mystars.dat >G dev$null + ** Select stars to measure with 'm' and finish with 'q'. + ** Additional options are '?', 'g', and :show. + NOAO/IRAF V2.12.2a-EXPORT valdes Mon 12:47:40 14-Nov-2005 + + Image Column Line Mag FWHM Ellip PA SAT + starfield 164.79 184.59 0.00 2.206 0.06 -23 + + Full width at half maximum (FWHM) of 2.2061 + + This is with the default parameters. Note the redirection of + the graphics to null file. You could redirect the graphics to a + metacode file viewable with (e.g.) GKIMOSAIC. However for 30,000 + stars I don't think you want that. + + The algorithms in PSFMEASURE are largely the same as in IMEXAM. + +NUMBER: 37 +KEYWORDS: colbias, ccdproc, fit1d, prescan, overscan +DATE: Mon Nov 14 14:13:04 MST 2005 +FROM: valdes + +Q: I have a question concerning the colbias command in the noao.bias + package of IRAF. I am working with a telescope which uses columns + 1-48 and 2096-2158 as overscan regions. The bias is found by the + colbias command. I was wondering if it is poissible to set up the + parameters in such a way that both sections (so 1-48 and 2096-2158) + are used for this purpose. Could you help me with this question? + +A: It is not common to use both the prescan and overscan columns at + the same time. The standard IRAF tasks for handling bias (colbias + and ccdproc) do not allow use of more than one contiguous region + for bias. However, if you wish to do so you can use FIT1D to do + what you want. The parameters I recommend are: + + + I R A F + Image Reduction and Analysis Facility + PACKAGE = imfit + TASK = fit1d + + input = Images to be fit + output = Output images + (axis = 1) Axis to be fit + type = difference Type of output (fit, difference, ratio) + (interac= no) Set fitting parameters interactively? + (sample = 1-48,2096-2158) Sample points to use in fit + (naverag= -100) Number of points in sample averaging + (functio= chebyshev) Fitting function + (order = 2) Order of fitting function + (low_rej= 0.) Low rejection in sigma of fit + (high_re= 0.) High rejection in sigma of fit + (niterat= 1) Number of rejection iterations + (grow = 0.) Rejection growing radius in pixels + (graphic= stdgraph) Graphics output device + (cursor = ) Graphics cursor input + (mode = ql) + + The type of "difference" subtracts the bias, the "sample" + parameter defines the data to use for the bias. The value of + -100 says to take the median of each bias region (a median is + good to avoid bad pixels and cosmic rays), and the function and + order fit a line between the two regions. The value of the fit + is subtracted from each pixel in the image. Read the help page + for this task for the various options. + + To later trim away the bias regions you would use imcopy with image + sections. + + cl> imcopy [49:2095,*] + + +NUMBER: 38 +KEYWORDS: zscale, display, autoscaling +DATE: Mon Dec 5 15:37:00 MST 2005 +FROM: valdes + +Q: I can't find a description of the 'zscale' scaling algorithm anywhere. + Do you have a reference for how it determines the proper scaling of + the pixels? + + +A: The algorithm is described in the IRAF help for the DISPLAY task + in a section on the algorithm. I include the section below for your + convenience. In summary, the algorithm consists of selecting a subset + of pixels (using masks if defined to exclude data), sorting the values, + chopping off the ends, and fitting a linear function. + + +From the DISPLAY help page: + +ZSCALE ALGORITHM + The zscale algorithm is designed to display the image values near + the median image value without the time consuming process of + computing a full image histogram. This is particularly useful for + astronomical images which generally have a very peaked histogram + corresponding to the background sky in direct imaging or the + continuum in a two dimensional spectrum. + + The sample of pixels, specified by values greater than zero in the + sample mask zmask or by an image section, is selected up to a + maximum of nsample pixels. If a bad pixel mask is specified by the + bpmask parameter then any pixels with mask values which are greater + than zero are not counted in the sample. Only the first pixels up + to the limit are selected where the order is by line beginning from + the first line. If no mask is specified then a grid of pixels with + even spacing along lines and columns that make up a number less + than or equal to the maximum sample size is used. + + If a contrast of zero is specified (or the zrange flag is used and + the image does not have a valid minimum/maximum value) then the + minimum and maximum of the sample is used for the intensity mapping + range. + + If the contrast is not zero the sample pixels are ranked in + brightness to form the function I(i) where i is the rank of the + pixel and I is its value. Generally the midpoint of this function + (the median) is very near the peak of the image histogram and there + is a well defined slope about the midpoint which is related to the + width of the histogram. At the ends of the I(i) function there are + a few very bright and dark pixels due to objects and defects in the + field. To determine the slope a linear function is fit with + iterative rejection; + + I(i) = intercept + slope * (i - midpoint) + + If more than half of the points are rejected then there is no well + defined slope and the full range of the sample defines z1 and z2. + Otherwise the endpoints of the linear function are used (provided + they are within the original range of the sample): + + z1 = I(midpoint) + (slope / contrast) * (1 - midpoint) + z2 = I(midpoint) + (slope / contrast) * (npoints - midpoint) + + As can be seen, the parameter contrast may be used to adjust the + contrast produced by this algorithm. + + diff --git a/local/iraf_test.tar.gz b/local/iraf_test.tar.gz new file mode 100644 index 00000000..fb6445f2 Binary files /dev/null and b/local/iraf_test.tar.gz differ diff --git a/local/lib/helpdb.mip b/local/lib/helpdb.mip new file mode 100644 index 00000000..55e9bfb0 Binary files /dev/null and b/local/lib/helpdb.mip differ diff --git a/local/lib/mkpkg.inc b/local/lib/mkpkg.inc new file mode 100644 index 00000000..a13524ab --- /dev/null +++ b/local/lib/mkpkg.inc @@ -0,0 +1,14 @@ +# Global MKPKG definitions for the LOCAL package. + +$set XFLAGS = "$(XFLAGS) -p local" +$set XVFLAGS = "$(XVFLAGS) -p local" +$set LFLAGS = "$(LFLAGS) -p local" + +# Uncomment and modify the following to add special file list entries for +# various machine architectures and Fortran compilers. + +# $ifeq (MACH, sparc) then +# $include "local$lib/mkpkg.sf.sun4" +# $else $ifeq (MACH, vms) then +# $include "local$lib/mkpkg.sf.vms" +# $end diff --git a/local/lib/root.hd b/local/lib/root.hd new file mode 100644 index 00000000..34a8f88b --- /dev/null +++ b/local/lib/root.hd @@ -0,0 +1,5 @@ +# Root help directory for the LOCAL packages. This dummy package is necessary +# in order to have `local' appear as a module in some package, so that the user +# can type "help local" (with the `local' given as a task). + +_local pkg = local$lib/rootlocal.hd diff --git a/local/lib/rootlocal.hd b/local/lib/rootlocal.hd new file mode 100644 index 00000000..7fbbed03 --- /dev/null +++ b/local/lib/rootlocal.hd @@ -0,0 +1,8 @@ +# Root task entry for the LOCAL package help tree. Defines `local' as both a +# task and a package in the local help database. + +local men = local$src/local.men, + hlp = local$src/local.men, + sys = local$src/local.hlp, + pkg = local$src/local.hd, + src = local$src/local.cl diff --git a/local/lib/strip.local b/local/lib/strip.local new file mode 100644 index 00000000..93550862 --- /dev/null +++ b/local/lib/strip.local @@ -0,0 +1,4 @@ +# STRIP.LOCAL -- Rmfiles command script, used to strip the LOCAL directories +# of all files not required for ordinary runtime use of the system. + +src -allbut .hlp .hd .men .cl .par .key .dat .mip diff --git a/local/lib/zzsetenv.def b/local/lib/zzsetenv.def new file mode 100644 index 00000000..07645dfa --- /dev/null +++ b/local/lib/zzsetenv.def @@ -0,0 +1,8 @@ +# Global environment definitions for the LOCAL packages. + +#set localbin = "local$bin(arch)/" +set localbin = "local$bin/" +set pkgbin = localbin$ +set pkglibs = local$lib/ + +keep diff --git a/local/login.cl b/local/login.cl new file mode 100644 index 00000000..00425b6a --- /dev/null +++ b/local/login.cl @@ -0,0 +1,132 @@ +# LOGIN.CL -- User login file for the IRAF command language. + +# Identify login.cl version (checked in images.cl). +if (defpar ("logver")) + logver = "IRAF V2.16 March 2012" + +set home = "iraf$local/" +set imdir = "HDR$/" +set uparm = "home$uparm/" +set cache = "home$cache/" +set userid = "fitz" + +# Set the terminal type. We assume the user has defined this correctly +# when issuing the MKIRAF and no longer key off the unix TERM to set a +# default. +if (access (".hushiraf") == no) + print "setting terminal type to xgterm..." +stty xgterm + + +# Uncomment and edit to change the defaults. +#set editor = vi +#set printer = lp +#set pspage = "letter" +#set stdimage = imt800 +#set stdimcur = stdimage +#set stdplot = lw +#set clobber = no +#set imclobber = no +#set filewait = yes +#set cmbuflen = 512000 +#set min_lenuserarea = 64000 +#set imtype = "imh" +set imextn = "oif:imh fxf:fits,fit fxb:fxb plf:pl qpf:qp stf:hhh,??h" + + +# XIMTOOL/DISPLAY stuff. Set node to the name of your workstation to +# enable remote image display. The trailing "!" is required. +#set node = "my_workstation!" + +# CL parameters you mighth want to change. +#ehinit = "nostandout eol noverify" +#epinit = "standout showall" +showtype = yes + + +# Default USER package; extend or modify as you wish. Note that this can +# be used to call FORTRAN programs from IRAF. + +package user + +task $adb $bc $cal $cat $comm $cp $csh $date $dbx $df $diff = "$foreign" +task $du $find $finger $ftp $grep $lpq $lprm $ls $mail $make = "$foreign" +task $man $mon $mv $nm $od $ps $rcp $rlogin $rsh $ruptime = "$foreign" +task $rwho $sh $spell $sps $strings $su $telnet $tip $top = "$foreign" +task $awk $vi $emacs $w $wc $less $rusers $sync $pwd $gdb = "$foreign" + +task $xc $mkpkg $generic $rtar $wtar $buglog = "$foreign" +#task $fc = "$xc -h $* -limfort -lsys -lvops -los" +task $fc = ("$" // envget("iraf") // "unix/hlib/fc.csh" // + " -h $* -limfort -lsys -lvops -los") +task $nbugs = ("$(setenv EDITOR 'buglog -e';" // + "less -Cqm +G " // envget ("iraf") // "local/bugs.*)") +task $cls = "$clear;ls" +task $clw = "$clear;w" +task $pg = ("$(less -Cqm $*)") + +if (access ("home$loginuser.cl")) + cl < "home$loginuser.cl" +; +keep + +# Load the default CL package. Doing so here allows us to override package +# paths and load personalized packages from our loginuser.cl. +clpackage + + +# List any packages you want loaded at login time, ONE PER LINE. +images # general image operators +plot # graphics tasks +dataio # data conversions, import export +lists # list processing + +# The if(deftask...) is needed for V2.9 compatibility. +if (deftask ("proto")) + proto # prototype or ad hoc tasks + +tv # image display +utilities # miscellaneous utilities +noao # optical astronomy packages +vo # Virtual Observatory tools + +prcache directory +cache directory page type help + +# Print the message of the day. +if (access (".hushiraf")) + menus = no +else { + clear; type hlib$motd +} + + +# Uncomment to initialize the SAMP interface on startup. +if (deftask ("samp") == yes) { + printf ("Initializing SAMP .... ") + if (sampHubAccess() == yes) { + samp quiet + + # Enable SAMP messaaging. + samp ("on", >& "dev$null") + + # Set default handlers that don't require VO capabilities. +# samp ("handler", "table.load.votable", "tinfo $url", >& "dev$null") +# samp ("handler", "image.load.fits", "imstat $url", >& "dev$null") + + samp noquiet + print ("on") + } else + print ("No Hub Available\n") +} + + + +# Delete any old MTIO lock (magtape position) files. +if (deftask ("mtclean")) + mtclean +else + delete uparm$mt?.lok,uparm$*.wcs verify- + +keep + diff --git a/local/mkpkg b/local/mkpkg new file mode 100644 index 00000000..47cd3a8f --- /dev/null +++ b/local/mkpkg @@ -0,0 +1,61 @@ +# Make the LOCAL package. + +$call update@src +$exit + +update: + $call update@src + ; + +# STRIP -- Strip the LOCAL package directories of all sources and other files +# not required to run the system, or for user programming. + +strip: + !rmfiles -f lib/strip.local + ; + +# SUMMARY -- [UNIX] mkpkg summary: output a summary of the spooled mkpkg +# output, omitting most of the mundane chatter. Used to scan large spool +# files for errors. + +summary: + $ifeq (HOSTID, unix) + ! grep -v ':$$' spool | grep -v '^xc' | grep -v '^ar'\ + | grep -v '^check file' + $else + $echo "mkpkg summary only available on a UNIX system" + $endif + ; + +# SUN/IRAF multiple architecture support. +# ---------------------------------------- + +showfloat: # show current float option + $verbose off + !$(hlib)/mkfloat.csh + ; +f68881: # install f68881 binaries + $verbose off + $set DIRS = "lib src" + !$(hlib)/mkfloat.csh f68881 -d $(DIRS) + ; +ffpa: # install ffpa binaries + $verbose off + $set DIRS = "lib src" + !$(hlib)/mkfloat.csh ffpa -d $(DIRS) + ; +fswitch: # install fswitch binaries + $verbose off + $set DIRS = "lib src" + !$(hlib)/mkfloat.csh fswitch -d $(DIRS) + ; +fsoft: # install fsoft binaries + $verbose off + $set DIRS = "lib src" + !$(hlib)/mkfloat.csh fsoft -d $(DIRS) + ; +sparc: # install sparc binaries + $verbose off + $set DIRS = "lib src" + !$(hlib)/mkfloat.csh sparc -d $(DIRS) + ; diff --git a/local/notes.64-bit b/local/notes.64-bit new file mode 100644 index 00000000..0b32d162 --- /dev/null +++ b/local/notes.64-bit @@ -0,0 +1,565 @@ + +mkpkg +noao/mkpkg +local/.login +bin.linux64 + +bin.linux64/IB.LNUX.X86_64 + +noao/bin.linux64 + +noao/bin.linux64/NB.LNUX.X86_64 + +unix/as.linux64 + +unix/bin.linux64 + +unix/hlib/cl.csh +unix/hlib/fc.csh +unix/hlib/install +unix/hlib/irafuser.csh +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.LNUX64 + +unix/hlib/strip.iraf +unix/hlib/sysinfo +unix/os/irafpath.c + Set up 'linux64' architecture dirs/paths for port, added a '-DLINUX64' + to HSI_CF. (4/20/09, MJF)) + + +bin.redhat -> bin.linux +noao/bin.redhat -> bin.linux +unix/as.redhat -> as.linux +unix/bin.redhat -> bin.linux +unix/hlib/irafuser.csh + Removed the 'redhat' directories and consolidated into a single 'linux' + architecture. In order to maintain compatability with external packages + we retain the 'redhat' architecture in paths, the idea being that an + extpkg can still use redhat, but in the core system the links resolve to + the linux directory to saisfy the path. (4/20/09, MJF) + +sys/libc/scanf.c +sys/libc/printf.c +sys/libc/eprintf.c +sys/libc/sprintf.c +pkg/cl/errs.c +pkg/cl/clprintf.c +pkg/ecl/errs.c +pkg/ecl/clprintf.c +unix/hlib/libc/stdarg.h + Removed the ifdef'd USE_STDARG code. The is no longer + routinely used and support it problematic. (7/13/09, MJF) + +unix/hlib/libc/libc.h + Declared XERPSH/XERPOP for use in all procedures. (7/13/09, MJF) + +unix/hlib/libc/ctype.h + Cast the subscripts to (int) to avoid -Wall warnings. (7/13/09, MJF) + +sys/libc + Major changes to make ANSI C and clean compile. (7/13/09, MJF) + +unix/hlib/libc.h + Added prototype declarations for libc procedure. (7/13/09, MJF) + +pkg/cl/clprintf.c +pkg/ecl/clprintf.c + Declared eprintf() void to match libc prototype. (7/13/09, MJF) + +pkg/libc/stgio.c + Added a maxch arg to c_stggetline(). This is only used in cl$modes.c + (and ecl$modes.c) and a 3rd arg is supplied. (7/13/09, MJF) + +unix/hlib/libc/kernel.h + Added , , and definition to + get system prototypes (e.g. for the glibc strcmp()) (8/14/09, MJF) + +unix/hlib/libc/iraf.h +unix/hlib/libc/varargs.h - +unix/hlib/libc/varargs-bsd.h - +unix/hlib/libc/varargs-linuxppc.h - + Removed use of from the system. (8/14/09, MJF) + +unix/bin.redhat/f2c.h +unix/hlib/libc/kproto.h +unix/hlib/libc/vosproto.h + System prototypes ....... (8/24/09, MJF) + +unix/hlib/f77.sh + Added a '-P' flag to allow F2C to produce function prototypes in + files with '.P' extensions. We'll use this in building the system + library prototype files which have changed since the last time they + were generated and are in need of automation (8/24/09, MJF) + +unix/os/zgtime.c + Modified to use more modern CLOCKS_PER_SEC vs CLK_TCK (9/23/09, MJF) + +sys/nmemio + + New version of MEMIO interface supporting pointer bounds checking. + +lib/syserr.h +lib/syserrmsg + Added new codes for pointer under and overflow. () + +unix/boot/xyacc/debug/ytab.x +noao/obsutil/src/sptime/tabinterp.x +noao/obsutil/src/sptime/grating.x +noao/imred/vtel/destreak.x +noao/artdata/t_mk2dspec.x +noao/artdata/mktemplates.x +noao/onedspec/t_sapertures.x +noao/onedspec/t_tweak.x +noao/onedspec/dispcor/dcio.x +pkg/lists/lintran.x +pkg/images/imutil/src/imexpr.x +pkg/images/tv/display/imdwcs.x +pkg/images/tv/wcslab/wlutil.x +pkg/images/tv/wcslab/wllabel.x +pkg/images/tv/wcslab/wlwcslab.x +pkg/images/immatch/src/listmatch/t_imctroid.x +pkg/xtools/rmmed.x +pkg/xtools/rmturlach.x +pkg/xtools/rngranges.x +pkg/bench/xctest/lintran.x +sys/nmemio/zzfoo.x +sys/qpoe/zzdebug.x +sys/qpoe/gen/qpexcoder.x +sys/qpoe/gen/qpexparser.x +sys/qpoe/qpmacro.x +math/curfit/cverrorsr.x +math/nlfit/nlerrorsr.x +math/iminterp/asifit.x +math/gsurfit/gserrorsr.x + Modified to add P2R/P2P macros on Memr as neded. + +tables/lib/stxtools/xtwcs.x +tables/lib/stxtools/sp_util/sprote.x +tables/lib/stxtools/wcslab/wllabel.x +tables/lib/stxtools/wcslab/wlwcslab.x +tables/pkg/tbplot/igi/igi.h +tables/pkg/fitsio/stwfits/wfits.h +tables/pkg/fitsio/strfits/rfits.h +tables/pkg/tobsolete/r49fits/rfits.h +tables/lib/stxtools/wcslab/wcs_desc.h +tables/lib/gilib/gi.h + Modified to add P2R/P2P macros on Memr as neded. + +./noao/mtlocal/cyber/rrcopy/rrcopy.h +./noao/mtlocal/cyber/cyber.h +./noao/obsutil/src/starfocus/starfocus.h +./noao/obsutil/src/sptime/sptime.h +./noao/obsutil/src/specfocus/specfocus.h +./noao/imred/ccdred/src/ccdred.h +./noao/imred/ccdred/src/generic/ccdred.h +./noao/imred/quadred/src/ccdproc/ccdred.h +./noao/imred/quadred/src/ccdproc/generic/ccdred.h +./noao/imred/vtel/numeric.h +./noao/imred/dtoi/hdicfit/hdicfit.h +./noao/artdata/lists/starlist.h +./noao/digiphot/photcal/lib/obsfile.h +./noao/digiphot/photcal/lib/prstruct.h +./noao/digiphot/photcal/lib/lexer.h +./noao/digiphot/photcal/lib/apfile.h +./noao/digiphot/daophot/lib/psfdef.h +./noao/digiphot/daophot/lib/daophotdef.h +./noao/digiphot/apphot/lib/radprofdef.h +./noao/digiphot/apphot/lib/fitpsfdef.h +./noao/digiphot/apphot/lib/finddef.h +./noao/digiphot/apphot/lib/polyphotdef.h +./noao/digiphot/apphot/lib/noisedef.h +./noao/digiphot/apphot/lib/centerdef.h +./noao/digiphot/apphot/lib/photdef.h +./noao/digiphot/apphot/lib/fitskydef.h +./noao/digiphot/apphot/lib/apphotdef.h +./noao/rv/rvplots.h +./noao/rv/rvidlines/identify.h +./noao/rv/rvsample.h +./noao/rv/rvpackage.h +./noao/rv/rvcont.h +./noao/astcat/lib/aimparsdef.h +./noao/astutil/pdm/pdm.h +./noao/nproto/ace/acesky.h +./noao/nproto/ace/cat.h +./noao/nproto/ace/gwindow.h +./noao/nproto/ace/ace.h +./noao/nproto/ace/skyfit.h +./noao/nproto/ace/grow.h +./noao/nproto/ace/split.h +./noao/nproto/ace/detect.h +./noao/nproto/ace/objs.h +./noao/nproto/ace/skyblock.h +./noao/nproto/ir/iralign.h +./noao/onedspec/specplot.h +./noao/onedspec/irsiids/idsmtn.h +./noao/onedspec/ecidentify/ecidentify.h +./noao/onedspec/identify/autoid/autoid.h +./noao/onedspec/identify/identify.h +./noao/onedspec/sensfunc/sensfunc.h +./noao/onedspec/dispcor/dispcor.h +./noao/lib/smw.h +./noao/lib/units.h +./noao/lib/funits.h +./noao/twodspec/multispec/ms.h +./noao/twodspec/apextract/apertures.h +./pkg/obsolete/oimstat.h +./pkg/obsolete/fits/wfits.h +./pkg/images/imutil/src/imtile.h +./pkg/images/imutil/src/imstat.h +./pkg/images/imfit/src/imsurfit.h +./pkg/images/imcoords/src/starfind.h +./pkg/images/tv/tvmark/tvmark.h +./pkg/images/tv/imexamine/imexam.h +./pkg/images/tv/imexamine/starfocus.h +./pkg/images/tv/iis/src/gwindow.h +./pkg/images/tv/iis/lib/ids.h +./pkg/images/tv/imedit/epix.h +./pkg/images/tv/display/gwindow.h +./pkg/images/tv/wcslab/wcs_desc.h +./pkg/images/imfilter/src/median.h +./pkg/images/imfilter/src/fmedian.h +./pkg/images/imfilter/src/frmode.h +./pkg/images/imfilter/src/fmode.h +./pkg/images/imfilter/src/frmedian.h +./pkg/images/imfilter/src/mode.h +./pkg/images/imfilter/src/rmode.h +./pkg/images/imfilter/src/rmedian.h +./pkg/images/immatch/src/xregister/xregister.h +./pkg/images/immatch/src/psfmatch/psfmatch.h +./pkg/images/immatch/src/geometry/geotran.h +./pkg/images/immatch/src/linmatch/linmatch.h +./pkg/xtools/icfit/icfit.h +./pkg/xtools/inlfit/inlfitdef.h +./pkg/xtools/gtools/gtools.h +./pkg/plot/crtpict/wdes.h +./pkg/plot/crtpict/crtpict.h +./pkg/proto/maskexpr/peregfuncs.h +./pkg/proto/masks/mimstat.h +./pkg/proto/masks/rskysub.h +./pkg/dataio/fits/wfits.h +./pkg/dataio/export/export.h +./sys/psio/psio.h +./sys/mwcs/imwcs.h +./sys/imio/iki/oif/imhv1.h +./sys/imio/iki/oif/imhv2.h +./sys/imio/iki/fxf/fxf.h +./sys/imio/iki/qpf/qpf.h +./sys/plio/plcircle.h +./sys/imfort/imhv1.h +./sys/imfort/imhv2.h +./sys/gio/sgikern/sgi.h +./sys/gio/imdkern/imd.h +./sys/gio/calcomp/ccp.h +./sys/gio/stdgraph/stdgraph.h +./sys/gio/glabax/glabax.h +./sys/gio/nsppkern/gkt.h +./sys/qpoe/qpoe.h +./sys/qpoe/qpex.h +./sys/qpoe/qpio.h +./math/surfit/surfitdef.h +./math/curfit/curfitdef.h +./math/nlfit/nlfitdefr.h +./math/iminterp/im1interpdef.h +./math/iminterp/im2interpdef.h +./math/gsurfit/gsurfitdef.h +./lib/imio.h +./lib/evexpr.h +./lib/imhdr.h +./lib/gio.h +./lib/evvexpr.h +./lib/pkg/rmsorted.h + Modified to add P2R/P2P macros on Memr as neded. + +unix/boot/xyacc/debug/ytab.x +noao/obsutil/src/sptime/tabinterp.x +noao/obsutil/src/sptime/grating.x +noao/artdata/t_mk2dspec.x +noao/artdata/mktemplates.x +noao/onedspec/t_sapertures.x +noao/onedspec/t_tweak.x +noao/onedspec/dispcor/dcio.x +pkg/lists/lintran.x +pkg/images/imutil/src/imexpr.x +pkg/images/tv/display/imdwcs.x +pkg/images/tv/wcslab/wlwcslab.x +pkg/images/immatch/src/listmatch/t_imctroid.x +pkg/bench/xctest/lintran.x +sys/qpoe/qpmacro.x +math/curfit/cverrorsr.gx +math/nlfit/nlerrorsr.gx +math/iminterp/asifit.x +math/gsurfit/gserrorsr.gx + Added P2R macros where needed (11/23/09) + +lib/gio.h +lib/imio.h +lib/imhdr.h + Added P2R macros where needed (11/23/09) + +unix/gdev/sgidev/mkpkg.sh +unix/gdev/sgidev/sgi2svg.c + Added SVG translator. + +sys/plio/plload.x +sys/plio/plsave.x +sys/imfort/imioff.x +sys/imfort/imopnx.x +sys/imfort/imrdhdr.x +sys/imfort/imwrhdr.x +sys/imio/iki/oif/oifopen.x +sys/imio/iki/oif/oifopix.x +sys/imio/iki/oif/oifrdhdr.x +sys/imio/iki/oif/oifwrhdr.x +sys/imio/iki/stf/stfrdhdr.x +sys/imio/iki/stf/stfreblk.x +sys/imio/iki/fxf/fxf.h +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfrfits.x + Uses of SZ_STRUCT in computing sizes were converted to SZ_MII_INT + +sys/libc/fgets.c + Modified to ignore '\r' used in DOS-style text files. Also now handles a + missing '\n' at the EOF as can sometimes happen with emacs-edited files. + + +noao/onedspec/odcombine/src/xtimmap.gx +noao/onedspec/odcombine/srcwt/xtimmap.gx +noao/twodspec/longslit/lscombine/src/xtimmap.gx +pkg/images/immatch/src/imcombine/src/xtimmap.gx + A pointer (Memi[ims+index-1]) wasn't being reset to NULL when + freed, leading to a segfault when run a second time from the cache. + +osb/bitfields.c + Added masks to accomodate 64-bit int sizes. Fixed a FDV problem + seen in NCAR tasks (e.g. contour) + +pkg/plot/t_implot.x + The impcom common block was being confused in the linker with the + impcom.o object (imio$dbc) in libex.a. Fixed implot bus error. + +lib/gio.h + Modified GP_WCSPTR to be properly aligned. + +lib/szpixtype.inc + + Added an equivalent to szdtype.inc for use with pixel-based applications. + The idea is that pixels will continue to be 32-bit ints regardless of + the platform. + +imcssz.x +imflsh.x +imggsc.x +imgnln.x +imgobf.x +imnote.x +impnln.x +imrbpx.x +imrdpx.x +imwbpx.x +imwrpx.x + Changed use of ty_size[] to pix_size[] + +imioff.x +imsetbuf.x +iki/fxf/fxfopix.x +iki/fxf/fxfpak.x +iki/fxf/fxfupk.x +iki/fxf/zfiofxf.x +iki/qpf/zfioqp.x +iki/stf/stfnewim.x +iki/stf/stfopix.x +iki/stf/stfrdhdr.x + Changed use of sizeof(IM_PIXTYPE(im)) to pix_size[IM_PIXTYPE(im)] + +lib/nmi.h +sys/etc/nmiread.gx +sys/etc/nmireadb.x +sys/etc/nmireadc.x +sys/etc/nmiwrite.gx +sys/etc/nmiwriteb.x +sys/etc/nmiwritec.x + Added a new Native Machine Integer (NMI) interface. This is similar to + the MII interface but is meant for use with external binary files that + don't require a (possible) byte-swap. The main point of this is to + provide a means to write native 32-bit ints distinguished from 64-bit + long. + +sys/osb/nmilen.x +sys/osb/nminelem.x +sys/osb/nmipak.x +sys/osb/nmipak16.x +sys/osb/nmipak32.x +sys/osb/nmipak8.x +sys/osb/nmipakd.x +sys/osb/nmipakr.x +sys/osb/nmipksize.x +sys/osb/nmiupk.x +sys/osb/nmiupk16.x +sys/osb/nmiupk32.x +sys/osb/nmiupk8.x +sys/osb/nmiupkd.x +sys/osb/nmiupkr.x + Support routines for the NMI interface. + +sys/fmtio/evexpr.gy +sys/fmtio/evvexpr.gy +sys/fmtio/xevgettok.x +sys/fmtio/xvvgettok.x + Broke out the xev_gettok() procedure into a new file. Newer GCC + compilers were complainint about the data type. + +sys/imio/dbc/imdcom.x - +sys/imio/dbc/imdrmcom.x + + Renamed the file containing the imdrmcom() procedure. This was causing + confusion with the 'imdcom' common block in the linker. + +unix/os/mkproto + Added utility script to generate IRAF kernel prototypes. + +unix/gdev/sgidev/sgi2svg.x + + Added new SGI driver for SVG graphics. + +unix/boot/spp/rpp/test.r + + Added new test file for RPP driver. + +unix/boot/spp/xpp/xpp.l +unix/boot/spp/xpp/xppcode.c + Attempt to try to manage new use of Memr[] macros, but one known to + break backward compatibility. A use such as "Memr[$1+N]" is obviously + part of a structure definition, so we automatically add a P2R() macro + so it reads "Memr[P2R($1+N)]" when being passed to RPP. This properly + aligns the struct on 64-bit platforms and is a no-op on 32-bit. + The complication is a simple case of "Memr[$1]" which may be either + the first element of a structure or a utility macro for a TY_REAL array. + In this case, we output an error indicating that a P2P or P2R macro is + required to resolve any ambiguity. + There are similar examples for 2-D arrays that aren't as easily parsed, + but since we can't trap them generally we can't do much to automatically + 'fix' the macro. + The overall utility of this change is questionable and may be pulled + from a later release. + +sys/osb/abs.c + Added an abs() function to avoid type conflicts between int/long. + +sys/osb/i32to64.c +sys/osb/i64to32.c + Imported int 32/64 pack/unpack from IRAF64 code. Note these are + MACHDEP on Intel byte order! + +sys/osb/urand.c +sys/osb/imul32.c + The urand() algorithm relies on 32-bit overflow to work properly. Needed + to add an 'imul32' function to do the multiplication with overflow. + +sys/osb/ipak32.c +sys/osb/iupk32.c + Added pak/unpak for 32-bit integers. + +pkg/images/imutil/src/t_chpix.x + Added an imflush() to the output image. + +pkg/plot/t_implot.x + Renamed the 'impcom' to 'implcom' to avoid a symbol name clash in the + linker. + +lib/gio.h +sys/gio/cursor/gtr.h + Increased the size of the WCS buffer. The size was previously calculated + as being 17 structure elements by assuming the SZ_INT was 2. Increased + to accomodate 64-bit sizes and will live with the wasted space. + +local/iraf_test.tar.gz + Added the "images test scripts" to the main distribution. These require + stty playback and so require the old CL to run. To use these, unpack + in a clean directory and begin with "stty playback=test.images", + successive tests will be run automatically. + +pkg/system/bench.cl + Added benchmark script to core distribution. + +pkg/cl/proto.h +pkg/ecl/proto.h + Function prototypes for the CL code. + +unix/hlib/libc/kproto32.h +unix/hlib/libc/kproto64.h +unix/hlib/libc/vosproto.h + Kernel prototype files. These are somewhat massaged by hand to remove + duplicate symbol names that cause errors but provide 98% coverage until + this can be addressed. + +unix/hlib/iraf.h -> +unix/hlib/mach.h -> +unix/hlib/iraf32.h +unix/hlib/mach32.h +unix/hlib/iraf64.h +unix/hlib/mach64.h + Added 32 and 64-bit definitions of the files defining primary data types. + Compilation is actually done using symlinks to the appropriate version in + hbin$ directory. The hlib$ versions are likewise a symlink that points to + the correct version when the architecture is set. + +/util + +/Makefile + + Top-level makefle and utility scripts for building the system. Makefile + targets are + + all alias for 'update' + sysgen do a complete sysgen + update update system since last sysgen + updatex update with debugging flags enabled + src clean system of current binaries + clean clean system of current binaries + pristine clean system of all binaries + tables compile the TABLES package + noao compile the NOAO package + summary print core/noao/tables spool file summaries + showarch show currently configure arch + reconfigure for named architecture + +unix/hlib/mkpkg.sf.LNUX64 + Special files list for new arch. + +unix/hlib/irafarch.csh + Utility script to determine proper platform architecture name. + +sys/osb/bitfieds.c + Added extra masks to accomodate 64-bit integers. + +pkg/xtools/ranges/rgfree.x + Added a check for a null pointer around the mfree. There were cases in + the ICFIT code that this was being called with a NULL pointer and would + trigger an error on newer libc, it seemed safest to allow the previous + behavior but just protect against it. + +sys/pmio/zzinterp.x + pm_create() was being called with too many arguments. + +unix/hlib/libc/libc.h + Added libc prototype definitions for automatic checking. This is also + where we look at the vosproto.h + + + +------------------------------------------------------ +V2.15-ALPHA release (3/2/10) +------------------------------------------------------ + +math/nlfit.gh + A leftover definition of P2R was causing problems. + +sys/nmemio/minit.x + Calls to fmkbfs() to create initialize the I/O buffers were not taking + into account that subsequent calls to the task in the prcache would + already have an i/o buffer. This was causing leading nulls to appear + in the stdout stream (e.g. redirection or scan-from-pipe) as well as + just output to appear in the CL stdout. Commented out the code until + it is better understood. The intent was to ensure that when reporting + memory usage we wouldn't see some arbitrary base value but could ensure + that memory allocated by an app was accounted for completely. + +noao/imred/ccdred/src/cosmic/crsurface.x +noao/imred/crutil/src/crsurface.x +pkg/images/tv/imedit/epsurface.x +pkg/images/tv/imexamine/iesimexam.x +pkg/plot/t_surface.x + There is apparenty a bug in the NCAR ezsrfc() routine that reaches beyond + the defined 'work' area (said to be twice the size of the data raster). + This was originally increased to be 4*data in the SURFACE task, but the + routine is called elsewhere and was failing in e.g. IMEXAM. Increased + the size for all instances but will need to track this down. + Pragmatically this can be ignored on modern systems as a minor waste of + space, it is much harder to debug the login of the NCAR code. diff --git a/local/notes.v216 b/local/notes.v216 new file mode 100644 index 00000000..46306a15 --- /dev/null +++ b/local/notes.v216 @@ -0,0 +1,528 @@ +System Notes File for IRAF Version 2.16. +Begun with V2.16 code freeze 22 March 2012. +------------------------------------------- + +sys/imio/imt/imxftype.x + Use of MEF names without an explicit '.fits' weren't being interpreted + correctly by the expansion code, e.g. "imcopy mef[0]". The problem was + that the code determining the type was trying to open the file to read + it, but of course without the extension would fail, but wasn't being + caught. (3/24/12) + +sys/imio/imt/imxexpand.x + A string buffer for expanding @files was not being properly increased + in size when using many files/extensions. This showed up as a + truncation of the expanded extension string for DECam images when + used by MSCRED tasks (3/27/12) + +pkg/tbtables/tbtyb.x + Bypassed error message checking for variable length arrays to allow + tasks to open a .fits.fz file to access the headers. (4/3/12) + +sys/fio/frmdir.x + Clean up some comments (4/5/12) + + +pkg/system/mkpkg +pkg/system/isdir.x - +sys/fio/mkpkg +sys/fio/isdir.x + +sys/fio/fcache.x + Moved the isdirectory() function from pkg$system to a general FIO + procedure. This was essentially duplicated in the fcache.x file and + is useful elsewhere as well. (4/9/12) + +sys/imio/imt/imx.x +sys/imio/imt/imxftype.x +sys/imio/imt/imxexpand.x +sys/imio/imt/imxpreproc.x + Modified to allow directories to be lists, e.g. "@/path/dir" would + expand to all images in the directory, "@@/path/dir" would expand + the MEF files in the directory. Expression selection works and + use of logical directories is also permitted. (4/10/12) + +sys/imio/imt/imxbreakout.x + The new template code wasn't properly detecting e.g. "[-*,*]" as + an image section. (4/11/12) + +pkg/images/imutil/src/imexpr.gx + Increased the default auto dimension line length to 32K from 8K to + avoid an implicit limit in the use of auto="dims" (4/13/12) + +unix/hlib/install + Fixed some problems with mixed use of quotes. (4/16/12) + +sys/imio/imt/imx.x + Fixed a problem with @files containing sections not expanding properly. + The contents of the file become a comma-delimited list, however it + was preceeded by a 'CH_DELIM//' sequence that prevents further expansion + in the fntgfn code. (4/18/12) + +math/gsurfit/gsurfitdef.h +math/gsurfit/dgsurfitdef.h + Fixed a problem with structure alignment in the dgsurfit.h file in an + attempt to find a bug introduced with the recent 'tweak' change. In + both files, increased the LEN_GSSTRUCT to a common value of 64 to + provide some cargo-cult padding. (5/9/12) + +pkg/cl/unop.c +pkg/ecl/unop.c +pkg/vocl/unop.c + Fixed a problem where the "INDEF" string operand was not being correctly + recognized in the isindef() function (5/24/12) + +sys/imio/imt/imt.x +sys/imio/imt/imx.x +sys/imio/imt/imx.h +sys/imio/imt/imxexpr.x +sys/imio/imt/imxparse.x +sys/imio/imt/imxftype.x +sys/imio/imt/imxescape.x +sys/imio/imt/imxbreakout.x + Fixed multiple problems in correctly distinguishing sections from index + ranges, escaping string, etc. Also added ability to use @ and @@ in + front of directories. (5/24/12) + +pkg/vocl/bkg.c + Background jobs were broken because they were calling the ECL to execute + instead of the VOCL, so the dictionary address differed. (7/5/12) + +unix/hlib/install - +$iraf/install + + Moved the install script to the toplevel directory where it logically + belongs. Also added code so that if no $iraf is defined, the toplevel + directory is assumed (7/5/12) + +sys/imio/imt/imxparse.x + The parsing of extension names (e.g. "foo.fits[im1]") was failing and + being mistaken as an index range. (7/14/12) + +sys/fmtio/evvexpr.y + The min/max/mod/median functions were incorrectly passing the operand + pointer to the xvv_newtype() function rather than the type code (7/24/12) + +sys/etc/votable.x + Moved the VOClient SPP support code for VOTable to the iraf system. This + is mostly to remove the SPP dependency from the voclient source tree but + this code only makes sense in IRAF anyway. (8/12/12) + +unix/as.macosx/ieee.gx +unix/as.macosx/ieeed.x +unix/as.macosx/ieeer.x + An earlier change to the IEEE code for macintel was not carried over to + the macosx architecture, meaning the same bug (all BITPIX=-64 pixels are + zero) was present for 32-bit Mac systems (9/4/12) + +sys/imio/imwrpx.x + Writing sections that are reversed what not working properly for INT + images. (10/02/12) + +pkg/cl/history.c +pkg/ecl/history.c +pkg/vocl/history.c + The history character '^' was being improperly expanded in literal + strings on the commandline. (10/28/12) + +math/slalib +math/slalib/README +math/slalib/sedscript +math/slalib/SED1 +math/slalib/SED3 - + Replaced the SLALIB with the GPL'd version from Starlink per a request + by Pat Wallace. This updates the library to v2.5-2 and includes updates + to the leap-second table to 2012. The IRAF copyright was not edited into + the files, instead each file contains the GPL copyright (full text of + which is in SLA_CONDITIONS. (11/2/12) + +local/LICENSES/GPL + +local/LICENSES/README + Added the GPL license for math$slalib and ecl$readline. (11/2/12) + +pkg/cl/grammar.y +pkg/ecl/grammar.y +pkg/vocl/grammar.y + Removed extra commas from %token declarations (11/30/12) + +install + Remove 'redhat' architecture name (2/1/13) + +sys/imio/imrbpx.x + The 'ncp' variable wasn't being properly initialized (2/10/13) + +unix/hlib/login.cl + Added 'sed' to the list of foreign tasks (2/14/13) + +pkg/cl/config.h +pkg/ecl/config.h +pkg/vocl/config.h + Increased the max number of background jobs from 4 to 32 (2/20/13) + +sys/libc/fgets.c + The newline that was being added was corrupting the parameter buffers + read from the uparm files when parameter strings were longer than + PF_MAXLIN chars (3/11/13) + +sys/imio/imt/imx.h +sys/imio/imt/imx.x +sys/imio/imt/imt.x +sys/imio/imt/imxexpand.x +sys/imio/imt/imxescape.x +sys/imio/imt/imxpreproc.x + Various fixes to all the know image template bugs (3/14/13) + +noao/lib/obsdb.dat + Added entries for the 'saoras' and 'terskol' observatories (4/11/13) + +pkg/ecl/eparam.c +pkg/vocl/samp.c +pkg/vocl/sampFuncs.c +pkg/vocl/eparam.c +unix/boot/spp/xpp/xpp.l +unix/boot/spp/xpp/decl.c +unix/boot/spp/xpp/xppcode.c +unix/boot/spp/rpp/ratlibc/putch.c +unix/boot/rtar/rtar.c +unix/boot/wtar/wtar.c +unix/boot/generic/generic.c +unix/boot/mkpkg/host.c +unix/boot/mkpkg/pkg.c +unix/boot/mkpkg/tok.c +unix/boot/rmbin/rmbin.c +unix/boot/rmfiles/rmfiles.c + Misc changes to fix compiler errors for gcc 4.2 (4/17/13) + +sys/fio/poll.x +sys/libc/cpoll.c +unix/hlib/libc/libc.h +pkg/vocl/history.c + The polling structure was being used as an 'int' instead of 'XINT' (4/25/13) + +sys/pmio/pmglr.gz + The 'rl_out' pointer was being explicitly allocated as TY_SHORT but used + as 'Mem$t', changed to TY_PIXEL declaration. (5/4/13) + +install + The install script wasn't properly allowing the arch to be overwritten + by an IRAFARCH setting (5/28/13) + +unix/boot/bootProto.h + +unix/bootlib/kproto32.h - +unix/bootlib/kproto64.h - + Added a new 'bootProto.h' include to enable prototype declaration + checking in the code. Removed earlier (unused) kprotoNN.h files (7/2/13) + +unix/boot/bootlib/bootlib.h +unix/boot/bootlib/osaccess.c +unix/boot/bootlib/oschdir.c +unix/boot/bootlib/osclose.c +unix/boot/bootlib/osdelete.c +unix/boot/bootlib/osdir.c +unix/boot/bootlib/osfcopy.c +unix/boot/bootlib/osfpathname.c +unix/boot/bootlib/osproto.h +unix/boot/bootlib/tape.c +unix/boot/generic/chario.c +unix/boot/generic/generic.c +unix/boot/generic/lexyy.c +unix/boot/generic/tok.l +unix/boot/generic/yywrap.c +unix/boot/mkpkg/char.c +unix/boot/mkpkg/fdcache.c +unix/boot/mkpkg/fncache.c +unix/boot/mkpkg/host.c +unix/boot/mkpkg/main.c +unix/boot/mkpkg/mkpkg.h +unix/boot/mkpkg/pkg.c +unix/boot/mkpkg/scanlib.c +unix/boot/mkpkg/sflist.c +unix/boot/mkpkg/tok.c +unix/boot/rmbin/rmbin.c +unix/boot/rmfiles/rmfiles.c +unix/boot/rtar/rtar.c +unix/boot/spp/rpp/ratlibc/cant.c +unix/boot/spp/rpp/ratlibc/close.c +unix/boot/spp/rpp/ratlibc/endst.c +unix/boot/spp/rpp/ratlibc/getarg.c +unix/boot/spp/rpp/ratlibc/getlin.c +unix/boot/spp/rpp/ratlibc/initst.c +unix/boot/spp/rpp/ratlibc/open.c +unix/boot/spp/rpp/ratlibc/putch.c +unix/boot/spp/rpp/ratlibc/putlin.c +unix/boot/spp/rpp/ratlibc/r4tocstr.c +unix/boot/spp/rpp/ratlibc/remark.c +unix/boot/spp/rpp/rpp.c +unix/boot/spp/xc.c +unix/boot/spp/xpp/decl.c +unix/boot/spp/xpp/lex.sed +unix/boot/spp/xpp/lexyy.c +unix/boot/spp/xpp/xpp.l +unix/boot/spp/xpp/xppcode.c +unix/boot/spp/xpp/xppmain.c +unix/boot/spp/xpp/xppProto.h +unix/boot/wtar/wtar.c +unix/boot/xyacc/dextern.h +unix/boot/xyacc/y1.c +unix/boot/xyacc/y2.c +unix/boot/xyacc/y3.c +unix/boot/xyacc/y4.c + General changes necessary to clean up any "gcc -Wall" warnings and + errors. This cleaned up several actual errors that might have been + caused by NULL pointers and generally added prototypes and ANSI-fied + declaratations (7/2/13) + +unix/gdev/sgidev/sgi2gif.c +unix/gdev/sgidev/sgi2svg.c +unix/gdev/sgidev/sgi2uapl.c +unix/gdev/sgidev/sgi2ueps.c +unix/gdev/sgidev/sgi2uhpgl.c +unix/gdev/sgidev/sgi2uhplj.c +unix/gdev/sgidev/sgi2uimp.c +unix/gdev/sgidev/sgi2uptx.c +unix/gdev/sgidev/sgi2uqms.c +unix/gdev/sgidev/sgi2xbm.c +unix/gdev/sgidev/sgidispatch.c +unix/gdev/sgidev/sgiUtil.c + +unix/gdev/sgidev/sgiUtil.h + + Cleaned up all warning messages and made code ANSI. In the process + extracted the common procedures such as bswap2() to a new common + sgiUtil.[ch] file. (7/11/13) + +unix/os/irafpath.c + Removed unused string buffer declaration (7/11/13) + +unix/os/prwait.c + Fixed pointer size warnings (7/11/13) + +unix/os/alloc.c +unix/os/zalloc.c + Modified to use and /var/run/utmp interface instead of the + older deprecated utmp API (7/11/13) + +unix/os/zawset.c + Fixed printf() type warnings (7/11/13) + +unix/os/zflink.c + Fixed type warnings of PKCHAR on (char *) values (7/11/13) + +unix/os/zzepro.c + Added declaration for ex_handler() function (7/11/13) + +unix/os/zzdbg.c + Various format type changes to print statements (7/11/13) + +unix/os/zoscmd.c +unix/os/zopdpr.c + Added declarations for prwait.c functions (7/11/13) + +unix/os/zgcmdl.c + Removed unused variable declarations (7/11/13) + +unix/os/zfiopr.c + Various format type changes to print statements (7/11/13) + +unix/os/zfiond.c + Various type changes to accept()/select() calls (7/11/13) + +unix/os/zfiomt.c + The #ifndef that disabled the code for MACOSX didn't cover the + declarations for the interface (7/11/13) + +unix/os/zfioks.c + Type casting and format conversion fixes (7/12/13) + +unix/os/zzstrt.c + Declarations for other ZAWSET/ZOPNTY/ZZSETK procedures (7/12/13) + +unix/os/zxwhen.c + Fixed macro definitions for MACOSX being redefined (7/12/13) + +unix/boot/bootlib/osfn2vfn.c +unix/boot/bootlib/vfn2osfn.c + Type casting fixes (7/12/13) + +unix/f2c +unix/f2c/mkpkg.sh + +unix/f2c/src/mkpkg.sh + +unix/f2c/libf2c/mkpkg.sh + + Updated to latest version of F2C sources to get a working 64-bit version. + (7/13/13) + +unix/mkpkg.sh + Added F2C to build as part of bootstrap. (7/13/13) + +unix/f2c/src/makefile.u +unix/f2c/libf2c/makefile.u + Removed the 'xsum' targets (7/13/13) + +unix/hlib/zzsetenv.def + Added 'fts' to the list of valid FITS extensions (7/14/13) + +pkg/vocl/vocl.x + Renamed the 't_ecl' task. (7/21/13) + +pkg/system/touch.x + Fixed a segvio when trying to touch a non-existent file where some + element of the path doesn't exist or isn't writeable. (7/30/13) + +extern/configure + Replaced with a Bourne-shell version of the script (7/30/13) + +math/slalib/_mkdiff - + Removed development file. (7/30/13) + +lib/imio.h.ORIG +noao/astcat/lib/catdb.dat.old +noao/astcat/src/agetcat/atfcat.x.old +noao/astcat/src/attools/atinpars.x.old +noao/digiphot/daophot/allstar/dpalinit.x.OLD +noao/digiphot/photcal/evaluate/phminv.f.old +noao/digiphot/photcal/fitparams/ftweights.x.old +noao/digiphot/photcal/lib/obsfile.h.old +noao/digiphot/photcal/mkobsfile/phimtable.x.old +noao/digiphot/photcal/mkobsfile/phsort.x.old +noao/digiphot/photcal/mkobsfile/t_obsfile.x.old +noao/imred/hydra/demos/xgdohydra.bak +noao/imred/src/dofoe/proc.bak +noao/onedspec/scombine/t_iscombine.bak +noao/twodspec/apextract/apmw1.bak +noao/twodspec/apextract/apmw2.bak +pkg/dataio/reblock/reblock_file.x.old +pkg/images/imcoords/src/t_ccmap.x.old +pkg/images/immatch/doc/imcentroid.hlp.old +pkg/images/imutil/src/t_minmax.x.old +pkg/images/tv/tvmark/mkoutname.x.old +pkg/system/help/helpdb.x.bak +pkg/xtools/catquery/cqgfields.x.old +pkg/xtools/inlfit/infit.gx.old +pkg/xtools/inlfit/inrefit.gx.old +unix/boot/spp/rpp/rppfor/endcod.f.OLD + Removed old, unused, source files. (7/31/13) + +unix/hlib/buglog.sh +unix/hlib/cl.sh +unix/hlib/ecl.sh +unix/hlib/f77.sh +unix/hlib/fc.sh +unix/hlib/helplog.sh +unix/hlib/irafarch.sh +unix/hlib/irafuser.sh +unix/hlib/mkfloat.sh +unix/hlib/mkiraf.sh +unix/hlib/mkmlist.sh +unix/hlib/util.sh +unix/hlib/vocl.sh + Added Bourne shell equivalents of all scripts (7/31/13) + +unix/reboot +unix/os/mkproto + Converted to Bourne shell script (7/31/13) + +unix/os/zmfree.c +unix/hlib/libc/knames.h + Added a new ZFREE procedure to free pointers allocated from host malloc() + calls. Needed to free the readline() return value. (7/31/13) + +sys/libc/freadline.c +unix/hlib/libc/libc.h + Added a new freadline() wrapper on a host readline() call. This allows + libc to get the command buffer and then free the value in the interface. + (7/31/13) + +pkg/ecl/mkpkg +pkg/ecl/history.c +pkg/ecl/readline - +pkg/vocl/mkpkg +pkg/vocl/history.c +pkg/vocl/readline - + Modified to use libc readline interface to avoid having multiple copies + of the library for each version of the CL. (7/31/13) + +unix/hlib/libc/stdarg-linux.h + Added typedef change to __builtin_stdarg_start to work w/ GCC 4.4 (10/8/13) + +pkg/vocl/samp.c +pkg/vocl/sampCmd.c +pkg/vocl/sampFuncs.c +pkg/vocl/sampHandlers.c + Changed declaration of rl_event_hoot to fix compiler warning. Modified + to use the readline include files however readline itself is no longer + compiled as part of the binary, instead we rely on the system lib. (10/9/13) + +unix/boot/spp/xc.c + Added "-lrt" to the link line for Linux systems to satisfy GCC 4.4. and + later compilers (10/8/13) + +pkg/cl/main.c +pkg/ecl/main.c +pkg/vocl/main.c +unix/hlib/login.cl + Modified to allow login using the global $HOME/.iraf startup when there is + no login.cl in the current directory. The user is notified when this file + in used in the banner message. Note that that use of logout.cl is + unaffected since the hlib$cllogout.cl script refers to home$logout.cl and + in a global login home$ is $HOME/.iraf + (10/10/13) + +unix/hlib/mkiraf.sh + Modifications to allow global login (10/10/13) + +unix/hlib/setup.sh +unix/hlib/setup.csh + Changed the IRAFARCH to user 'irafarch.sh' (10/10/13) + +system/system.hd +system/system.men +system/system.par +system/chkupdate.x + +system/chkupdate.par + +system/doc/chkupdate.hlp + +unix/hlib/login.cl + Added a new CHKUPDATE task to check iraf.noao.edu for a newer release + of IRAF than the one currently installed. By default, the file + '.release_date' defines the current release date, a similar timestamp + file is kept on the server. The check is only done ever 'interval' + days to minimize the impact and may be disabled entirely. (10/12/13) + +unix/hlib/login.cl + Modified to allow a 'loginuser.cl' and/or 'uparm' directory in the + current working dir to override a global version in the $HOME/.iraf + directory. (10/13/13) + +vo/java/Aladin.jar +vo/java/topcat-full.jar + Updated to latest version (10/14/13) + +unix/hlib/libc/fpoll.h + undefined POLLIN etc to avoid compiler warnings (10/14/13) + +unix/hlib/irafuser.csh + Added an XC_CFLAGS to add a '-I$HOME/.iraf' to the opts to allow + compilation of C files in a sysgen. (10/14/13) + +.version +pkg/cl/cl.par +pkg/ecl/cl.par +pkg/vocl/cl.par +unix/hlib/motd +unix/hlib/install +unix/hlib/login.cl +unix/hlib/irafarch.csh +unix/hlib/zzsetenv.def + Updated version strings to final export (10/14/13) + +unix/hlib/irafuser.sh +unix/hlib/irafuser.csh +unix/hlib/irafarch.sh +unix/hlib/irafarch.csh + Removed 'ppc' architecture references. Also fixed a 'too many arguments' + error when sourcing these files with an invalid IRAFARCH set (10/15/13) + +install + Modified to create cmdlink targets for source-only system. (10/18/13) + +pkg/vocl/mkpkg +pkg/vocl/readline/ - + Modified to use the iraf$vendor readline includes (10/18/13) + +============================================================================== + diff --git a/local/src/README b/local/src/README new file mode 100644 index 00000000..7ca0cb0f --- /dev/null +++ b/local/src/README @@ -0,0 +1,75 @@ +LOCAL -- Locally added tasks and packages. + + The LOCAL package is a place to put locally added tasks and packages +without modifying the standard IRAF system (and thereby complicating future +updates and so on). The LOCAL provided with the distributed system is a +template package provided to make it as easy as possible for user sites to +set up their own custom LOCAL packages. + +To create a custom LOCAL package: + + [1] Copy the template package directory tree (iraf$local) to a new + directory somewhere outside the iraf directories. DO NOT MODIFY + THE TEMPLATE LOCAL, CREATE AN EXTERNAL COPY AND MODIFY THAT INSTEAD. + This is necessary to ensure that your custom local is unaffected by + updates to the core IRAF system. + + [2] Edit the pathame of local in the "reset local = ..." statement in the + IRAF file hlib$extern.pkg, replacing the "iraf$local/" by the host + pathname of the root directory of your custom LOCAL. Be sure to + include the trailing / on UNIX systems, or escape $ and [ on VMS + systems. All references to LOCAL will now refer to your custom + version of LOCAL, rather than to the template version provided with + the distributed system. + +To add a new task to LOCAL: + + [1] Add the source and parameter file if any to this directory, e.g., + mytask.x, mytask.par. + + [2] Add the name of the new task to x_local.x. Any number of tasks may + be added to the package in this way. + + task pavg = t_pavg, + mytask = t_mytask + + [3] Add the manual page for the task to the `doc' subdirectory, e.g., + file doc/mytask.hlp. Add entries for the new task to local.hd + (so that HELP can find the new manual page) and local.men (so that + the task will be listed when `help local' is entered). Load the + softools package and run `mkhelpdb' to recompile the help database + else HELP will not know about the new manual page. + + cl> mkhelpdb local$lib/root.hd local$lib/helpdb.mip + + [4] Add an entry for all source files to the library member list in + the mkpkg file in this directory. List any include files referenced + in the source file to the right of the source file name. + + libpkg.a: + pavg.x + mytask.x + ; + + [5] Add an entry for the new task in local.cl, so that the CL will + know about the new task when the LOCAL package is loaded. Prefix + the task name with a dollar sign ($mytask) if the new task does + not have an associated parameter (.par) file. + + task pavg, + mytask = "local$src/x_local.e" + + [6] Enter the command `mkpkg -p local' to compile and link the new package + executable `x_local.e'. After testing the new task, install the new + package executable in bin$ with the command `mkpkg -p local install'. + +You should now be able to load the LOCAL package in the CL, and run the new +task, or get help for any of the LOCAL package tasks. + +Any number of tasks may be added to your custom LOCAL package in this fashion. +Host programs and IMFORT programs may also be added, modifying the task +statements and mkpkg compile/link instructions appropriately (if used). +Subpackages should be used to group like tasks if the LOCAL grows large +enough. For more information on program development in IRAF, refer to the +SOFTOOLS package help pages for xc, mkpkg, etc., the SPP/VOS technical +documentation, the IMFORT manual, and so on. diff --git a/local/src/bswap.par b/local/src/bswap.par new file mode 100644 index 00000000..815d00dd --- /dev/null +++ b/local/src/bswap.par @@ -0,0 +1,3 @@ +input,f,a,,,,"input file" +output,f,a,,,,"output file" +wordswap,b,h,no,,,"swap every 4 bytes rather than every 2 bytes" diff --git a/local/src/bswap.x b/local/src/bswap.x new file mode 100644 index 00000000..d9fad447 --- /dev/null +++ b/local/src/bswap.x @@ -0,0 +1,42 @@ +include + +define SZ_IOBUF 2048 + + +# BSWAP -- Copy a file, swapping the bytes. + +procedure t_bswap() + +bool wordswap +int in, out, nchars +pointer sp, input, output, bp +int open(), read() +bool clgetb() + +begin + call smark (sp) + call salloc (input, SZ_FNAME, TY_CHAR) + call salloc (output, SZ_FNAME, TY_CHAR) + call salloc (bp, SZ_IOBUF, TY_CHAR) + + call clgstr ("input", Memc[input], SZ_FNAME) + call clgstr ("output", Memc[output], SZ_FNAME) + wordswap = clgetb ("wordswap") + + in = open (Memc[input], READ_ONLY, BINARY_FILE) + out = open (Memc[output], NEW_FILE, BINARY_FILE) + + repeat { + nchars = read (in, Memc[bp], SZ_IOBUF) + if (nchars > 0) { + if (wordswap) + call bswap4 (Memc[bp], 1, Memc[bp], 1, nchars * SZB_CHAR) + else + call bswap2 (Memc[bp], 1, Memc[bp], 1, nchars * SZB_CHAR) + call write (out, Memc[bp], nchars) + } + } until (nchars == EOF) + + call close (in) + call close (out) +end diff --git a/local/src/doc/bswap.hlp b/local/src/doc/bswap.hlp new file mode 100755 index 00000000..779105de --- /dev/null +++ b/local/src/doc/bswap.hlp @@ -0,0 +1,36 @@ +.help bswap Mar89 local +.ih +NAME +bswap - swap the bytes in a file +.ih +USAGE +bswap input output +.ih +PARAMETERS +.ls input +The file to be swapped. +.le +.ls output +The name of the output swapped file. +.le +.ls wordswap = no +Swap four-byte longwords rather than pairs of bytes. +.le +.ih +DESCRIPTION +The \fIbswap\fR task reads the input file as a binary file, +writing the result to the output file. +Successive byte pairs are interchanged if \fIwordswap\fR=no, +otherwise the four bytes within each successive longword are swapped. +.ih +EXAMPLES +1. Byte swap file A, writing the result to file B. + + cl> bswap a b +.ih +BUGS +The input and output files cannot be the same. +.ih +SEE ALSO +dataio.reblock +.endhelp diff --git a/local/src/doc/pavg.hlp b/local/src/doc/pavg.hlp new file mode 100644 index 00000000..d0c29185 --- /dev/null +++ b/local/src/doc/pavg.hlp @@ -0,0 +1,29 @@ +.help pavg Apr86 local +.ih +NAME +pavg - plot the average of the lines of an image or image section +.ih +USAGE +pavg image +.ih +PARAMETERS +.ls image +The image or image section to be averaged and plotted. +.le +.ih +DESCRIPTION +The \fIpavg\fR task averages the lines of the given image or image section +and plots the result on the standard graphics output. +.ih +EXAMPLES +1. Plot line 125 of the standard test image "dev$pix". + + cl> pavg dev$pix[*,125] + +2. Plot the average of lines 100 through 200 of the same image. + + cl> pavg dev$pix[*,100:200] +.ih +SEE ALSO +plot.* +.endhelp diff --git a/local/src/local.cl b/local/src/local.cl new file mode 100644 index 00000000..41e2b092 --- /dev/null +++ b/local/src/local.cl @@ -0,0 +1,10 @@ +#{ Package script task for the LOCAL package. Add task declarations here +# for any locally added tasks or subpackages. + +cl < "local$lib/zzsetenv.def" +package local, bin=localbin$ + +task bswap, + pavg = "local$src/x_local.e" + +clbye() diff --git a/local/src/local.hd b/local/src/local.hd new file mode 100644 index 00000000..04117f92 --- /dev/null +++ b/local/src/local.hd @@ -0,0 +1,7 @@ +# Help directory for the LOCAL package. + +$defdir = "local$src/" +$doc = "local$src/doc/" + +bswap hlp=doc$bswap.hlp, src=bswap.x +pavg hlp=doc$pavg.hlp, src=pavg.x diff --git a/local/src/local.men b/local/src/local.men new file mode 100644 index 00000000..bb82ed45 --- /dev/null +++ b/local/src/local.men @@ -0,0 +1,2 @@ + bswap - Swap the bytes in a file + pavg - Plot the average of the lines of an image or image section diff --git a/local/src/local.par b/local/src/local.par new file mode 100644 index 00000000..66d02acc --- /dev/null +++ b/local/src/local.par @@ -0,0 +1,3 @@ +# Dummy LOCAL package parameter file. + +version,s,h,"Mar89" diff --git a/local/src/mkpkg b/local/src/mkpkg new file mode 100644 index 00000000..5b86e2fe --- /dev/null +++ b/local/src/mkpkg @@ -0,0 +1,27 @@ +# Make the LOCAL package. + +$call relink +$exit + +update: + $call relink + $call install + ; + +relink: + $set LIBS = "-lxtools" + + $update libpkg.a + $omake x_local.x + $link x_local.o libpkg.a $(LIBS) -o xx_local.e + ; + +install: + $move xx_local.e pkgbin$x_local.e + $purge pkgbin$ + ; + +libpkg.a: + bswap.x + pavg.x + ; diff --git a/local/src/pavg.par b/local/src/pavg.par new file mode 100644 index 00000000..61e9e430 --- /dev/null +++ b/local/src/pavg.par @@ -0,0 +1 @@ +image,s,a,,,,Image from which to plot average of lines diff --git a/local/src/pavg.x b/local/src/pavg.x new file mode 100644 index 00000000..7124c4d0 --- /dev/null +++ b/local/src/pavg.x @@ -0,0 +1,45 @@ +include + +# PAVG -- CL callable task to plot the average of the lines of an image or +# image section on the standard graphics output. This example is taken from +# the IRAF paper. + +procedure t_pavg() + +char image[SZ_FNAME] # name of image to be plotted +char title[SZ_LINE] +int npix, nlines +long v[IM_MAXDIM] +pointer im, lineptr, sumv +pointer immap(), imgnlr() + +begin + # Fetch image name from CL and open the image. The IMMAP + # function returns a pointer to the image descriptor structure. + + call clgstr ("image", image, SZ_FNAME) + im = immap (image, READ_ONLY, 0) + + # Allocate a zeroed buffer of length NPIX for the sum-vector, + # and set V to point to first image line, i.e., v=[1,1,1,...]. + + npix = IM_LEN(im,1) + call calloc (sumv, npix, TY_REAL) + call amovkl (long(1), v, IM_MAXDIM) + + # Sum the lines of the image. + for (nlines=0; imgnlr(im,lineptr,v) != EOF; nlines=nlines+1) + call aaddr (Memr[lineptr], Memr[sumv], Memr[sumv], npix) + + # Normalize the sum-vector to get the average. + call adivkr (Memr[sumv], real(nlines), Memr[sumv], npix) + + # Format plot title and plot the sum-vector on STDGRAPH. + call sprintf (title, SZ_LINE, "Line Average of %s") + call pargstr (image) + call gplotv (Memr[sumv], npix, 1., real(npix), title) + + # Free storage for sum-vector and close image. + call mfree (sumv, TY_REAL) + call imunmap (im) +end diff --git a/local/src/x_local.x b/local/src/x_local.x new file mode 100644 index 00000000..02b52027 --- /dev/null +++ b/local/src/x_local.x @@ -0,0 +1,6 @@ +# Task declaration for the LOCAL package. To add new task entries, add a +# comma to the last line and a new line "mytask = t_mytask". In the task +# sourcefile the main procedure should be named "procedure t_mytask". + +task bswap = t_bswap, + pavg = t_pavg -- cgit