iraf.net

Applications :: RE: problem in psf (in daophot)

nakisa — Thu, 11 Mar 2010 12:56:31 GMT

Author: nakisa
Posted: Thu Mar 11, 2010 12:56 pm (GMT 0)

hello
I check ds9 's version is 6.0 . so the problem is not the version!

best,nakisa

Applications :: RE: problem in psf (in daophot)

fitz — Wed, 10 Mar 2010 15:30:11 GMT

Author: fitz
Posted: Wed Mar 10, 2010 3:30 pm (GMT 0)

It looks like the DS9 died, did the window disappear? If so then this is a problem in DS9 and not the task. Various versions have been known to have problems with image display, try getting the latest version from SAO or checking the DS9 web pages for known problems.

Applications :: RE: problem in psf (in daophot)

nakisa — Wed, 10 Mar 2010 12:19:56 GMT

Author: nakisa
Posted: Wed Mar 10, 2010 12:19 pm (GMT 0)

Hi

I think the connection between ds9 and pyraf is lost :
===================================================
omputing PSF for image: new.fits
29 stars read from new.fits.mag.1

Star 9 has been added to the PSF star list
X: 34.10 Y: 25.96 Mag: 24.276 Dmin: -0.01702284 Dmax: 0.426677
Star 28 has been added to the PSF star list
X: 32.24 Y: 56.45 Mag: 24.500 Dmin: -0.007852103 Dmax: 0.2966193
Star 8 has been added to the PSF star list
X: 57.44 Y: 23.87 Mag: 24.769 Dmin: -0.01296441 Dmax: 0.2620879
Star 27 has been added to the PSF star list
X: 14.14 Y: 54.79 Mag: 25.241 Dmin: -0.01097132 Dmax: 0.2041787

4 PSF stars read from new.fits.pst.1

Killing IRAF task `psf'

PANIC in `/iraf/iraf/noao/bin.linux/x_daophot.e': Write to IPC with no reader
Exception in Tkinter callback
Traceback (most recent call last):
File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1417, in __call__
return self.func(*args)
File "/usr/lib/python2.5/site-packages/pytools/editpar.py", line 1058, in execute
self.runTask()
File "/usr/lib/python2.5/site-packages/pytools/editpar.py", line 1423, in runTask
self._taskParsObj.run(mode='h', _save=1)
File "/usr/lib/python2.5/site-packages/pyraf/iraftask.py", line 277, in run
self._run(redirKW, specialKW)
File "/usr/lib/python2.5/site-packages/pyraf/iraftask.py", line 716, in _run
(self, iraf.getVarDict()), redirKW)
File "/usr/lib/python2.5/site-packages/pyraf/irafexecute.py", line 357, in IrafExecute
raise exc
IrafError: Cannot open image display

What is your suggestion ?
Best,Nakisa

Applications :: RE: Keck LRIS data reduction - 2006

ash — Tue, 09 Mar 2010 20:53:11 GMT

Author: ash
Posted: Tue Mar 09, 2010 8:53 pm (GMT 0)

Thanks for all of your help! Sorry for the delay, but I hit midterms and didn't get back to work. I was told that NMISC is not needed for the WMKOLRIS function I'm using, so I bypassed it and things seem to running. Thank you for your help!

-Alec

Applications :: RE: help for the installation

fitz — Tue, 09 Mar 2010 14:57:45 GMT

Author: fitz
Posted: Tue Mar 09, 2010 2:57 pm (GMT 0)

The README files are generally based on an old template, for ".gz" extensions use the 'gunzip' command or unpack with "tar zxf gmisc.tar.gz"

Applications :: help for the installation

Anonymous — Tue, 09 Mar 2010 13:10:51 GMT

Author: Guest
Subject: help for the installation
Posted: Tue Mar 09, 2010 1:10 pm (GMT 0)

Hello
I need some help about the instalation to the package gmisc.
I download the readme, but the instalation its not good because its not work.
I'm working with Ubuntu 8.10 and the IRAF 2.14.
My problem is in the point 3)
after the ftp, in the uncompression

cl> !uncompress gmisc.-bin.redhat.tar.gz

the package is not uncompress, I probe with other comand and uncompress, but..
the next steps is not completed.

I hope yours answers
Many thanks

Natalia Nuñez

*******************************************************************
Instituto de Ciencias Astronómicas de la Tierra y el Espacio
Av. España 1512 sur - J5402DSP
San Juan - Argentina

Post generated using Mail2Forum (http://www.mail2forum.com)

General IRAF :: improving the calibration accruacy....

amalmirando — Tue, 09 Mar 2010 07:16:29 GMT

Author: amalmirando
Subject: improving the calibration accruacy....
Posted: Tue Mar 09, 2010 7:16 am (GMT 0)

What methods can be used to increase the accuracy of the calibrated spectrum?
_________________
-Amal Mirando

Systems :: RE: mscstack ERROR: FXF: EOF encountered while reading FITS file

sarah.easton — Tue, 09 Mar 2010 00:54:00 GMT

Author: sarah.easton
Posted: Tue Mar 09, 2010 12:54 am (GMT 0)

Thanks for that fitz, I returned to mscimage to recreate the mosaiced files and the mscstack task now is working on those. It appears the input files in question didn't mosaic properly so that the header information wasn't transferred properly from im1. (In case it is helpful to others, mscstack was terminating before creating the output file that caused the error, so there was no output file to test or add EXTVER to.)

Thanks for your help!

General IRAF :: RE: 2.15a : able to run old binaries?

fitz — Mon, 08 Mar 2010 23:27:21 GMT

Author: fitz
Posted: Mon Mar 08, 2010 11:27 pm (GMT 0)

I dont' think this has anything to do with v2.15, using the STScI-supplied binary on a 64-bit machine fails with an "Out of memory" error for me. This basically just means the libc malloc() call either failed or more likely returned a 64-bit pointer value that was seen as a failed request. This is one of the known issues with 32-bit binaries on 64-bit systems so unless you trace it to something else I'm not sure there's much to debug here.

As for the core dump: Normally we'd set the 'debug_sig' in a debugger or else simply set a break in 'zpanic_' and get the stack trace then. It's easy enough to add a method to dump a core file, the reason we don't do it by default is that error recovery allows tasks to continue to run so more manual methods are better to trap the error. Thanks for the suggestion.

-Mike

General IRAF :: RE: 2.15a : able to run old binaries?

Mark S. — Mon, 08 Mar 2010 20:22:16 GMT

Author: Mark S.
Posted: Mon Mar 08, 2010 8:22 pm (GMT 0)

That helped. Now it says

Code:

stsdas> iminfo dev$pix

PANIC in `/usr/stsci/iraf-2.15a/stsdas/bin.linux64/x_headers.e': Memory has been corrupted
stsdas>

I'm going to try to debug that, but already it leads to my first suggested patch:

In unix/os/zpanic.c in the function ZPANIC, it says:

Code:

/* Terminate process with a core dump if the debug_sig flag is set.
*/
if (debug_sig) {
#ifdef LINUX
signal (SIGABRT, SIG_DFL);
kill (getpid(), SIGABRT);

The definition of debug_sig is in unix/os/zxwhen.c, but it is just

Code:

int debug_sig = 0;

There are no other assignments anywhere. If I were making the change, I would change ZPANIC to say

Code:

if (debug_sig || getenv("IRAF_ALLOW_CORE_DUMP") ) {

so that I could flip between normal operation and allowing the core dump without compiling the entire IRAF kernel.

I suspect there is a better place to put it (like maybe in some initialization code somwehere), but I am not familiar enough with IRAF internals to know where it should go.

I realize the implications, of course: My old executable compiled with the old iraf would not have that capability. Still, I think this is a useful feature going forward.

Mark S.