iraf.net

Does anyone here use Astro::IRAF::CL? I tried using the CPAN forum for that Perl module without any replies. Here's what I posted on that forum:[quote:b1429b1c65]
Any ideas on why I can't create a .coo file from daofind or a .mag file from phot? I've copied over a uparm file and the proper login.cl. I've tried various ways of doing it, like straight from the Perl script and also by creating a task. It freezes so I have to hit Ctrl+c. When I do this the program is killed, but it creates the desired file as it logs out of IRAF. Here is my code:
[code:1:b1429b1c65]$iraf->exec(command => "daofind $imagename output=\"$imagename.coo\" fwhmpsf=$fwhm sigma=$sigma threshold=5");
[/code:1:b1429b1c65]
or
[code:1:b1429b1c65]$iraf->load_task(name => "findstars",
task => "daofind $imagename output=\"$imagename.coo\" fwhmpsf=$fwhm sigma=$sigma threshold=5",
file =>; "findstars.cl",
parfile => 1);
$iraf->exec(command =>; "findstars");[/code:1:b1429b1c65]
Yes, I've tried using the timeout option for the first one, but it still doesn't create the desired file. When using phot, the format is similar and the results (or lack of them) are the same. Any help would be appreciated. Thanks.
[/quote:b1429b1c65]So, does anyone have any suggestions? If not here then where? And again, any help would be appreciated.

[quote:5799c53674]
Any ideas on why I can't create a .coo file from daofind or a .mag file from phot? I've copied over a uparm file and the proper login.cl. ..... [/quote:5799c53674]I'm not sure what you mean by "proper login.cl", but one explanation would be that you're using .imh images and your login.cl defines an 'imdir' or 'uparm' directory that isn't valid for the runtime environment. Does it work if you first do a 'mkiraf' from the directory where you're trying to run the script?-Mike

Well, I've changed the login.cl file so I don't have to mess with the cumbersome .imh extensions. I've changed 3 lines on the login.cl file altogether:[code:1:29882062cc]
set stdimage = imt1024
set imtype = "fits,noinherit"
set imextn = "oif:imh fxf:fits,fit,fts plf:pl qpf:qp stf:hhh,??h"
[/code:1:29882062cc]The first one so I can see the whole image in SAOImage, the second so I won't have to deal with the .imh extensions, and the third so that it will read the images I receive with the extension .fts.I tried "mkiraf" in the directory where IRAF is launched again. It reinstated the login.cl defaults which I changed back to my preferences listed above. Could this have anything to do with my problem? Should I try changing my code to deal with the .imh extensions? What possible advantage does using .imh have over simply changing what IRAF reads?

There's actually a speed advantage to using imh, but for this question the point is that .imh images use the imdir to store the pixel file, and if that isn't valid you can't create temp or output images properly. A MKIRAF will create a new uparm directory and so you'll use the default parameters the first time you run a task, this is normal.One thing to try is to run your command directly in the CL and see if you get the expected results (with your parameter settings). This will separate whether its an Astro::CL thing or something in how you're calling the task.-Mike

Speed? Hmm, well that's the whole reason for doing what I'm doing. I'll give that a shot. Maybe it's some crazy quirk in the Astro::IRAF:CL module. I have tried inputting the command directly into the CL with the expected results (i.e. nothing freezes, a .coo file is made for daofind and a .mag file is made for phot).

Nope, changing it back to .imh did make it go faster up until the daofind task where it froze again.

Any chance the 'interactive' parameter is set and it's just waiting for input?

I don't think so. I checked the default for daofind and its interactive setting is turned off. For phot the default is such that the interactive is turned on, at least in the apphot package, so I turn it off in the command line. And every setting should not have to be explicitly stated if the default settings suffice. What I really don't understand is why it actually makes the desired file [i:df3611d5ca]after[/i:df3611d5ca] I hit Ctrl-c and [i:df3611d5ca]after[/i:df3611d5ca] it exits out of the apphot, digiphot, and noao packages and just [i:df3611d5ca]before[/i:df3611d5ca] it exits out of IRAF altogether. I want it to create the file, use the file, and continue on with the rest of the program without human intervention.When I enter the commands on the CL it does ask for a confirmation on the fwhmpsf and other already entered parameters. Then it asks about the minimum and maximum settings which are already set to INDEF. If the parameters are already set and the defaults in place, why should they be entered in the Perl script? And how does it create the file later when it hangs up before I hit Ctrl-c?I'm sorry if I appear upset. This problem is a little exasperating. Where's the frustrated smiley on the left?

Try turning off the DAOPHOT 'verify' parameter, I think this is what's causing the prompt for the confirmations and if you're being prompted at all then probably why the script hangs. I assume Astro::CL knows how to deal with package params but I've never used it, resetting the parameter in the CL should update the uparm file for the daophot package and it'll get picked up from there.-Mike

OMG IT WORKED!!! :shock: I've been dealing with this problem since forever! Thank you thank you thank you.

[quote:943e44b0a3="fitz"]There's actually a speed advantage to using imh, but for this question the point is that .imh images use the imdir to store the pixel file, and if that isn't valid you can't create temp or output images properly. A MKIRAF will create a new uparm directory and so you'll use the default parameters the first time you run a task, this is normal.[/quote:943e44b0a3]Is there any chance that IRAF in 2.14 will be changing the default extension (the one in the hlib$login.cl) to "fits" instead of "imh"? I don't know anybody that still uses imh files as their preferred format.

[quote:9ff4c3cbd7]Is there any chance that IRAF in 2.14 will be changing the default extension (the one in the hlib$login.cl) to "fits" instead of "imh"? I don't know anybody that still uses imh files as their preferred format.[/quote:9ff4c3cbd7]It's already been done. Additionally, ECL is the default command interpreter.-Mike