iraf.net

I am trying to combine some spectra, and I am getting unpredictable results, sometimes with "segmentation violations," sometimes not. For instance, the first of the following commands works, but not the second:ecl> scombine 1xtrno04,1xtrno05,1xtrno09 test1 aper=1
Nov 30 15:56: SCOMBINE
combine = average, scale = none, zero = none, weight = none
blank = 0.
Images
1xtrno04[ 1]
1xtrno05[ 1]
1xtrno09[ 1] Output image = test1, ncombine = 3
w1 = 18606.61, w2 = 25873.36, dw = 7.103371, nw = 1024., dtype = 0ecl> scombine 1xtrno04,1xtrno05,1xtrno09,1xtrno13 test1 aper=1
ERROR: segmentation violationHelp! I have reproduced this error in both IRAF 2.14.1 and 2.15. I am running an iMac with Snow Leopard (64-bit kernel enabled with 2.15).The fits files I was working with can be found at the following URL:http://dl.dropbox.com/u/9601016/scombine.iraf.net.tgz

Please try unlearning the task and/or recreating your uparm directory (or create a dummy login dir in /tmp for testing), if you still have problems please post the parameters you are using.Sorry, but it works fine for me on a v2.15 macintel system.

Yes, I'm sorry too.I have tried re-installing login.cl and uparm with "mkiraf," and even getting rid of my own custom login.cl file. Still the same errors as above, in exactly the same way.For reference anyway, here's an "lpar scombine":onedspec> lpar scombine
input = "" List of input spectra
output = "" List of output spectra
(noutput = "") List of output number combined spectra
(logfile = "STDOUT") Log file\n
(apertures = "") Apertures to combine
(group = "apertures") Grouping option
(combine = "average") Type of combine operation
(reject = "none") Type of rejection\n
(first = no) Use first spectrum for dispersion?
(w1 = INDEF) Starting wavelength of output spectra
(w2 = INDEF) Ending wavelength of output spectra
(dw = INDEF) Wavelength increment of output spectra
(nw = INDEF) Length of output spectra
(log = no) Logarithmic increments?\n
(scale = "none") Image scaling
(zero = "none") Image zero point offset
(weight = "none") Image weights
(sample = "") Wavelength sample regions for statistics\n
(lthreshold = INDEF) Lower threshold
(hthreshold = INDEF) Upper threshold
(nlow = 1) minmax: Number of low pixels to reject
(nhigh = 1) minmax: Number of high pixels to reject
(nkeep = 1) Minimum to keep (pos) or maximum to reject (neg
(mclip = yes) Use median in sigma clipping algorithms?
(lsigma = 3.) Lower sigma clipping factor
(hsigma = 3.) Upper sigma clipping factor
(rdnoise = "0.") ccdclip: CCD readout noise (electrons)
(gain = "1.") ccdclip: CCD gain (electrons/DN)
(snoise = "0.") ccdclip: Sensitivity noise (fraction)
(sigscale = 0.1) Tolerance for sigma clipping scaling correction
(pclip = -0.5) pclip: Percentile clipping parameter
(grow = 0) Radius (pixels) for 1D neighbor rejection
(blank = 0.) Value if there are no pixels
(mode = "ql")

I was hoping it was something easy.I looked around and found a machine that did, in fact, reproduce the problem. However, this was a machine running a 32-bit kernel and the problem is only reproducible using the 64-bit 'macintel' binaries. Running the native 'macosx' binaries works fine.Check whether you define an IRAFARCH environment variable in your .cshrc/.login file, if you do then try setting the value to be 'macosx'.Next, at the unix prompt, issue the command "uname -m". If the value is x86_64 then you are running a 64-bit kernel, if it's 'i386' then you may have a 64-bit capable machine, but it's booted to the 32-bit kernel. Another way to check is with the command[code:1:a3b5db293d]/usr/bin/system_profiler | grep 64-bit[/code:1:a3b5db293d]The value should be 'yes' if you're using the 64-bit kernel. Further
info on booting your system to 64-bit mode can be found at http://www.hackaapl.com/forcing-snow-leopard-os-x-to-boot-64-bit-kernel/and elsewhere via a Google search.

OK, maybe this qualifies as bizarro bug of the day:I was indeed using the 64-bit kernel on a 64-bit-capable machine, and the macintel binaries.I've been doing this inside an xgterm running tcsh. I just tried switched to xterm, or xgterm running bash, and the segmentation violation goes away. I can't remember why I tried this, but it worked.???

Sorry, scratch that last post -- not sure what I was doing yesterday, but I can't duplicate the success I had. I now get the "Segmentation violation" in all shells, in xterm or xgterm. (I suspect I was just carelessly typing in the 3-image combine, rather than the 4-image.)Anyway, I've now tried booting into the 32-bit kernel and installing IRAF with the "macosx" binaries. Still the same problem.I'm going to just try installing from source now, to see if I can get it working.

Installing from source won't do much I expect. At the unix prompt, what does "uname -m" say on your system? At the CL prompt, what does a "show arch" say?I ran a loop over your test 1000 times last night, worked fine.