Welcome to iraf.net Friday, May 03 2024 @ 08:14 PM GMT


 Forum Index > Help Desk > General IRAF New Topic Post Reply
 Possible critical regression in 2.15.1 patch
   
Jason Quinn
 02/21/2011 03:05PM (Read 2830 times)  
+++++
Active Member

Status: offline


Registered: 04/07/2006
Posts: 175
I hate to give an incomplete bug report where I haven't identified the culprit but I thought this might be worth a heads up.I have noticed that images produced with lacos_spec (Peter van Dokkum's cosmic ray cleaning task) under 2.15.1 differ significantly from the same images produced under 2.15 and 2.14.1. The latter two agree and look like what I'd expect but the 2.15.1 results are unusual. (64-bit system)Lacos_spec is a cl script that only uses the following IRAF tasks:imcopy, imreplace, fit1d, imarith, median, blkrep, convolve, blkavg, imcalcAs these are "fundamental" tasks and affect science results, I deem this a serious bug. Have any of these NOT changed since 2.15? That would help me locate the culprit. I can also upload a tarball with some images and steps that produce the problem. I think I have eliminated all things that would make it a local issue.JasonPS This weekend I was learning to use git. I'm curious what version control system in used for IRAF and what kind of unit testing framework there is.

 
Profile Email
 Quote
fitz
 02/21/2011 03:05PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
Hi Jason, One explanation might be a bug discovered last week that is related to an earlier fix in the v2.15.1 patch: The effect is that for single-precision images zero pixel values are interpreted as 128, since this is in the low-level code it affects all tasks and might explain the different results. A new binary release is in preparation, otherwise if you want to upload the images and steps I can verify whether this fixes the problem here before releasing the binaries.[quote:edbafc1984]
PS This weekend I was learning to use git. I'm curious what version control system in used for IRAF and what kind of unit testing framework there is.[/quote:edbafc1984]Our version control is historically of a "manual" nature however I'll be setting up an SVN system as part of planned iraf.noao.edu updates. I looked at GIT which has an all-repositories-are-equal philosophy but decided the there-exists-a-master-version zen of SVN fit better. We have some automated scripts to test general image tasks developed for testing ports, but there isn't really a comprehensive set of test scripts for the science apps (thus the long test period for v2.15).

 
Profile Email
 Quote
rjvo
 02/21/2011 03:05PM  
+++++
Active Member

Status: offline


Registered: 04/21/2007
Posts: 134
Does it mean that the IRAF 2.15.2 is in preparation? Or there will be a patch to a patch?

 
Profile Email
 Quote
fitz
 02/21/2011 03:05PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
More of a patch to a patch, but I'm just calling it v2.15.1a because it is such a small change (and is available now). A v2.15.2 patch is planned for later this summer.

 
Profile Email
 Quote
Jason Quinn
 02/21/2011 03:05PM  
+++++
Active Member

Status: offline


Registered: 04/07/2006
Posts: 175
I am happy to report that this is fixed by the 2.15.1a patch.Thanks for all the hard work as usual, devs!

 
Profile Email
 Quote
rjvo
 02/21/2011 03:05PM  
+++++
Active Member

Status: offline


Registered: 04/21/2007
Posts: 134
I installed IRAF 2.15.1a from scratch and extern packages "mscred" and "stsdas". In "fitsutil" folder, in the subfolder "lib" there are two unresolved links "libcfitsio.a" and "libmef.a", because the "bin" points to "bin.generic" and not to "bin.linux" (where the targets are). In "mscred" folder the "bin" point to "bin.generic" as well, not to "bin.linux" (the same for "stsdas" and "tables").
For "/iraf/iraf/unix" there is also void link "bin" to "bin.generic" which does not exist. The same to void link "as". The effect of this is that in "hlib" we have unresolved links "libboot.a, libboot_p.a, libos.a, libos_p.a" ("libboot.a" is in both "bin.linux, ...64" and the same "libos.a" but there are no "*_p.a" there).
Back to the "extern" packages. There is no "bin.linux" link to "bin.redhat" in "stsdas" and "tables". Because the "bin" link in both cases point to "bin.generic" we have many unresolved "lib*" links; there is also unresolved link "tables_v313".
Now in "/iraf/iraf/" I do "make check" and I can see the installed packages "is current" message. "make update" gives for all packages: "is not installed" and there is no data in the folders "fitsutil, mscred, stsdas, tables" - all contents removed.

 
Profile Email
 Quote
rjvo
 02/21/2011 03:05PM  
+++++
Active Member

Status: offline


Registered: 04/21/2007
Posts: 134
Similar situation with 2.15.1a and the same "externs" exists on the iMac.

 
Profile Email
 Quote
Jason Quinn
 02/21/2011 03:05PM  
+++++
Active Member

Status: offline


Registered: 04/07/2006
Posts: 175
[quote:bbf2a4641c="rj"]Similar situation with 2.15.1a and the same "externs" exists on the iMac.[/quote:bbf2a4641c]Hi, rj. I moved your topic to a new thread "Broken symbolic links (moved topic)" so that it can be more easily found in the future.Jason

 
Profile Email
 Quote
   
Content generated in: 0.20 seconds
New Topic Post Reply

Normal Topic Normal Topic
Sticky Topic Sticky Topic
Locked Topic Locked Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Anonymous users can post 
Filtered HTML Allowed 
Censored Content 
dog allergies remedies cialis 20 mg chilblain remedies


Privacy Policy
Terms of Use

User Functions

Login