Welcome to iraf.net Wednesday, May 01 2024 @ 07:32 PM GMT
jeanm12 |
11/21/2013 11:24PM (Read 998 times)
|
|
|
Status: offline
Registered: 10/28/2013
Posts: 2
|
Hello,
To start with, my computer is a 64-bit machine running CentOS 6. I have been doing some echelle data reduction and ran across a few things that might be bugs or errors.
Running IRAF 2.16 with IRAFARCH=linux:
- I found that ecreidentify did not produce correct database files, they appeared to be wrong by just a little bit. When I switched to IRAFARCH=linux64, they worked. It appears that this may have been fixed in the 2.16.1 patch. Just want to confirm that this was looked at.
Running IRAF 2.16 with IRAFARCH=linux64:
-cosmicrays occasionally gives a segmentation violation. I have not figured out how to reproduce it exactly, but it only occurs with some nights of my data, and not others. Appears to be fixed in 2.16.1, but since I can't figure out how to reproduce it exactly, I'm just checking to see if it was fixed.
Running IRAF 2.16.1 with IRAFARCH=linux64:
-creating a pixel mask with text2mask, and then using fixpix to correct images for bad columns and pixels: When using IRAFARCH=linux64, the mask that gets output does nothing to the images when ran through fixpix. With IRAFARCH=linux, the mask that gets output actually does remove the bad pixels when ran through fixpix (in both 32-bit and 64-bit).
Running IRAF 2.16.1 with IRAFARCH=linux64:
-ccdproc and zerocombine both failed with an error about no 'instrument' translation file. I went back and used setinstrument and they functioned, however it didn't do this in 2.16 for me.
Please let me know if any of these have already been looked at.
Jean
|
|
|
|
fitz |
11/22/2013 02:13AM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
COSMISCRAYS is the only one on your list where there was a clear change made to the task, but I can't say specifically that it fixed what you were seeing. Task behavior can change because a bug in the underlying image/mask interface was fixed, or the combination of compiling all the new code now hides a memory error that may or may not still exist.
In general you can look at the 'Revisions' file in the source directory for the task/package to see what has changed, but without data, parameters and a specific way to reproduce the problem I can't say for sure your specific reports were addressed (they don't sound familiar).
|
|
|
|
| |
|
Content generated in: 0.07 seconds |
|