iraf.net

I'm getting an error when running the DAOPhot 'group' command that I don't know how to resolve.Warning: Image header parameter not found (FUNCTION)I've been experimenting with the autoalign.cl script and I'm sure it must be changing something in my header, but I'm not sure how to fix/update my header. I haven't been able to find out what is being modified in my headers yet, because whatever it is isn't displayed in the regular "full" header.DAOPhot works fine on my un-aligned frames, so there's nothing wrong with the headers until after the align script is run.Any ideas would be appreciated.Thank you.

From an earlier reply to a similar problem:[quote:305d664454]
As you already know, allstar needs the header parameter FUNCTION, from
the psf image, to fit the psf for all other stars. This parameter is
written when you run the psf task, which gets the FUNCTION parameter
from 'daopars'.If you take a look at the psf header, you should find parameters such
as PSFX, PSFY, PSFHEIGHT, and PSFMAG. These are accompanied by the
FUNCTION parameter.If the FUNCTION parameter is missing, you should check that you have the
function type set in 'daopars' (see 'phelp daopars' for a list of
available functions). Also be sure that 'update' is set to 'yes' in the
daophot parameters (epar daophot).
[/quote:305d664454]Write back if you still have problems.-Mike

Setting update to yes fixed my problem. Thank you very much.

I'm having the same problem, and setting Update to Yes didn't seem to fix it. I've used imheader on the psf .imh and it seems to report that there's no PIXEL file.Any ideas?
Thanks.;.

If you mean the long IMHEADER output contains a line such as:[code:1:0c62c9a8a0] Pixel file "/tmp/foo.pix" [NO PIXEL FILE][/code:1:0c62c9a8a0]then it means the pixel file associated with the .imh can't be found. This can happen when you move imh images between machines and forget to copy the .pix files, have an invalid 'imdir' so it couldn't be created, or the directory doesn't exist. You can HEDIT the 'i_pixfile' header parameter to reset this pathname and reconnect to the .pix file, otherwise check that your 'imdir' directory exists and you can write to it (the value is set in login.cl).Updating/reading of headers should still be allowed, but sometimes errors cascade from some underlying reason like this and so may be bogus. Try fixing the pixel file problem first.Cheers,
-Mike

Hmm, well I'm simply working in a single directory -- all of my other daofind, phot, pstselect (etc) output is being created fine. I don't know why there would be a problem with the .pix file.
I have both image.imh and image.pix in the directory, shouldn't it automatically detect it there?If not, perhaps the problem is with my login.cl. Is there something that tells me what login.cl file IRAF is currently using (I have about 6 on my machine in various places...).Thanks again for the help -- haven't used IRAF in a long time!

update -- imh is seeing the pix nowstill getting the Function error however

[quote:39268003c8]I have both image.imh and image.pix in the directory, shouldn't it automatically detect it there? [/quote[Only if the i_pixfile and your 'imdir' use "HDR$" to tell it to look in the same directory as the .imh file, otherwise it's an explicit path (with a node! prefix usually.[/quote:39268003c8]f not, perhaps the problem is with my login.cl. Is there something that tells me what login.cl file IRAF is currently using (I have about 6 on my machine in various places...). [/quote]Do a "cl> show home". Note that certain paths are created by MKIRAF when writing the login.cl that may become invalid if what you do is simply copy the login.cl file to a new location rather than do a separate MKIRAF.-Mike

Should the psf have its own pix file? apart from the pix that corresponds to the original image file?
if so, that's probably the problem here, because a psf pix file is not being generated, only a psf.imh.

Then do a "cl> show imdir" to see where it's trying to put the .pix file and make sure it's valid. You can do[code:1:b31893c3d7]
cl> reset imdir = HDR$
cl> flpr 0 # zero not oh
[/code:1:b31893c3d7]To reset it so the .pix is in the same dir as the .imh, and edit the login.cl to make the change for the next time.-Mike

I've set the path to HDR$, and still no .pix file. I've done a system search and it doesn't look like it's putting it anywhere.Really appreciate your help here Mike...

Try a simple test first like[code:1:15723c41ab]cl> imcopy dev$pix foo[/code:1:15723c41ab]Do you get both a foo.imh and foo.pix file in the current directory or some error message? Did you do the 'flpr' so tasks would reset with the new value? Is you 'imtype' variable set to 'imh' or are you putting that explicitly as an extension to the image name?-Mike

The test works fine -- imcopy gives me both a .imh and .pix.
I have been specifying image.imh (including the extension) at the prompts.

...and if I remove the .imh extension, it reports an ambiguous image name, even though imtype is indeed set to imh.

The 'ambiguous' name means you've got e.g. an image.fits and an image.imh in the same directory. The message comes when referring only to 'image', which some tasks may do internally. Note you can work on the FITS file directly (e.g. set 'imtype' to be 'fits' so new images are created as 'FITS'), otherwise it's best to move the files with the problematic extensions.-Mike

Ok, that's fine now, it will read the files without putting .imh. Unfortunately I still have absolutely no idea why this silly thing isn't producing a .pix.Any remaining ideas greatly appreciated....

Let's backup a bit then: Is there indeed a FUNCTION keyword in your psf.imh header in the first place? If so, the lack of a .pix may be the masked cascading problem I mentioned earlier; If not, then the question is 'How are you creating the psf.imh image"?The imcopy test indicates your 'imdir' is fine. A missing .pix can also occur if an image was mapped (created) but then an error occurred when writing it. Sometimes obscure things like a /tmp directory at 100% capacity can cause it, other times its a more obvious error message from the system.
-Mike

Here's my imheader output on my psf .imh:[code:1:822284cc91]imutil> imheader mosaic_fixed2.psf.imh longheader=yes
mosaic_fixed2.psf.imh[0][real]:
No bad pixels, min=unknown, max=unknown
Line storage mode, physdim [0], length of user area 1 s.u.
Created Wed 18:34:03 15-Aug-2007, Last modified Wed 18:34:03 15-Aug-2007
Pixel file "" [NO PIXEL FILE][/code:1:822284cc91]

That says you've got no header keywords, the image dimension is zero, and there is no pixel file specified.What was the command that created the image? Is it an IRAF task or something locally written?-Mike

The main image was originally a .fits file, converted to imh/pix using imcopy,>imcopy mosaic.fits mosaic.imhThat successfully created the original .imh and .pix, both of which seem valid.As for the PSF image, I'm simply using the psf command to generate that as output, which yields only that .imh file with the seemingly bad header.

So what happens if you create it from the original mosaic.fits image? Is imtype still set to FITS? What are the parameters to the PSF task you used.I'm thinking having a mosaic.fits and mosaic.imh in the same directory may be confusing things, Using imh isn't required but if you want to do it try using a different name so the images are unique.-Mike

I've (a) tried removing the .fits from the directory, and (b) just using the .fits off the bat for the psf input. They both yield the same result. Hope it's not over-kill, but here's my whole psf process. The .mag and .pst files I'm using seem fine, so I don't think they're the issue.

I'm about at the end of what I know about DAOPHOT. The second output of PSF looks normal but what's up with the 'cannot open image' message in the first call? Did you do something to fix it in another window or just run the task twice? Does putting the .fits extension on the output psf image name likewise create an empty image with no keywords? What about setting the 'imtype' to be 'fits'?-Mike

I've got our sysadmin to through iraf on another machine, and things seem to be working now. There must be some kind of conflict in the configuration on my machine hidden somewhere. Sorry to whoever is reading this post in the future for help -- not the triumphant ending you were looking for.Just wanted to say thanks for all your help though, much appreciated!

If the error is due to long path, you can use Long Path Tool, it handles such issues..