iraf.net

GREETINGS.

I am also having the same problem as ste_atreb is having in this thread:

https://iraf.net/forum/viewtopic.php?forum=4&showtopic=1467707&highlight=No%20write%20permission%20on%20file%20(String_File)

I am trying to process images (taken from DECam in 2014) using IRAF.

But if I use tasks like display or imhe I get the following error message:

"ERROR: No write permission on file (String_File)"

but other FITS images (e.g. from the NVO DataScope portal) work fine.

I have IRAF 64-bit installed both on a Mac and a linux box and IRAF exhibits the same behavior/error message on both machines.

What's going on?



Also, I just tried posting this thread and then didn't see it in my "Find all postings" link in my profile and thought that I saved the URL. So I'm not sure if this thread is a duplicate or not since I thought that I already posted it.

Also, I just tried posting this thread and then didn't see it in my "Find all postings" link in my profile and thought that I saved the URL. So I'm not sure if this thread is a duplicate or not since I thought that I already posted it.


Also, I did not see a way to edit my first post, so I have to create a reply in my own thread. Can someone merge these together so I'm not double posting?

Why do you keep taking the Edit button away from me? I was still fixing my post and then I got an error saying "You cannot edit this post anymore" or something like that I don't remember the error that I just saw.

ANYWAY... what I MEANT to say in the second post is:



Also, I saw that others were posting that this is an old Y2K bug (really? This is 2014...), and that if I am still having this error message, I was told to contact NOAO directly. Should I proceed?

The String_File error has been linked to a number of things: your /tmp (or current) directory is full, a malformed header (inc. a DATE-OBS that isn't Y2K compliant), a FITS file that isn't an integer multiple of 2880 bytes, etc. There were also several FITS kernel bugs in the initial IRAF v2.15 64-bit systems that might explain it, what version of IRAF are you running (use "cl\$this->_split2($m[0]) head hlib$motd nl=2" to find out)??

Since it's unlikely both your machines have filled their /tmp, and since we would've seen DATE-OBS issues in DECam data by now my guess is that the filesize is incorrect or the image is otherwise corrupted somehow. Could you upload a sample bad file to the anon ftp at ftp://iraf.noao.edu/pub so we can have a look?

I am running "NOAO/IRAF PC-IRAF Revision 2.16.1 EXPORT Mon Oct 14 21:40:13 MST 2013"

Alright I have uploaded the file, and named it: "FaTestDECamNoAccess.fits.fz"

This is one of the "calibrated by NOAO" images.

There are two issues here:

For compressed images like this (i.e. with a ".fits.fz" extension) you need to be sure that the FITS kernel is used by adding the "fz" to the list of filename extensions given in the 'imextn' variable. This can be set in your login.cl file, the systemwide hlib$zzsetenv.def, or on the commandline with:



where the 'fz' is added to the 'fxf' kernel type.

Secondly, IRAF doesn't operate directly on FITS compressed data so you can't e.g. run DISPLAY on a specific extension or MSCDISPLAY on the entire file, you need to run the FUNPACK task (either from the FITSUTIL external package, or the unix binary available as part of CFITSIO) first. It is however possible to run IMHEADER on the primary header, and THEADER on the other extensions (because as compressed imaged they're stored as binary tables) so long as you specify the extension explicitly, e.g.

Well running the "reset imextn" helped with recognizing the extension. I haven't yet taken a look at FUNPACK so more on this later...

Update: FUNPACK doesn't work. I get an error message:

fitsutil\$this->_split2($m[0]) funpack FaTestDECamNoAccess.fits.fz

/bin/bash: /iraf/iraf/extern/fitsutil/bin.macintel/funpack: cannot execute binary file

Thu 12:40:14 18-Sep-2014
/bin/bash: /iraf/iraf/extern/fitsutil/bin.macintel/funpack: cannot execute binary file
Thu 12:40:14 18-Sep-2014

1 images, 0.00 seconds per image, 0:00:00.0 elapsed

input: 300.726 MB
fitsutil\$this->_split2($m[0])

Greetings again.

I have not yet received a response to my question about why FUNPACK isn't working.

Can someone help me out?

Sorry for not following up. Apparently there was a binary incompatibility in the FITSUTIL binaries for macintel preventing the task (which comes from CFITSIO) from running. I've rebuilt the package and updated the repository, to get the update simply



If you still have problems, post back.

In xgterm, when I type

"cd $iraf/extern"

I get the following error message:


"ERROR: Cannot change directory to `$iraf/extern'
called as: `cd ($iraf/extern)'"

In Terminal, when I type

"cd $iraf/extern"

I get the following error message:


"-bash: cd: /extern: No such file or directory"


So now what do I do?

You need to either define an 'iraf' environment variable so $iraf is defined, or else use the explicit path to your iraf installation and the extern subdirectory (normally /iraf/iraf/extern)

Alright, so I was able to get to /iraf/iraf/extern

but then in xgterm when I typed

"make fitsutil"

I received the following error message:


"Setting architecture: 'macintel' ....
Installing package 'fitsutil' .... [Error]"


and that was it, no further message.

I got the same error when I tried using Terminal.

Do you have write permission on the iraf directory tree? If not, try "sudo make fitsutil" to execute as root or else login as the owner of the iraf tree (note an 'iraf' user is no longer required but you may have one from an earlier installation).

Excellent, that worked. And funpack also works.

Looks like we're set. I may probably ask for help again as I go through the analysis.

Follow-up question: How do I get the mosaic of all 60-CCDs from the DECam image to display in SAOimage ds9?
I tried importing the .fits.fz file directly and that gave me the option to look at data cubes, but the frames are not presented in ds9 in the correct XY space.
So, I exported each frame as a fits file and then made a single mosaic file using imcombine, but that made the resulting file size ( 3.17 GB ) too large for SAOimage to handle.
How would I go about displaying the whole thing?

From the 'File' menu choose 'Open as' submenu and then either "Mosaic IRAF" to use the DETSEC keywords to layout the image by ccd pixels, or "Mosaic WCS" to use the WCS in the extension headers. You can likewise do "ds9 -mosaicimage iraf foo.fits.fz" or "ds9 -mosaicimage wcs foo.fits.fz" from the commandline.

Alright but then I can't do imexamine on any of the frames of the mosaic because I get the following error message:


Warning: Cannot open image ([...file name...])
Warning: Pixels out of bounds


I tried changing stdimage to larger sizes so that I could do imexamine and imstat on a larger section of the image, but then I got other errors, which is why I have been using FUNPACK. So, what do I do?

If you're running ds9 v7.2 then there is a know bug in it when reading cursor position, however I think it might also be an issue with the way the 'mosaicimage' flag loads the display but doesn't define a display WCS compatible with IMEXAM. If you're using a 32-bit system (e.g. 'linux' or 'macosx' IRAF architecture) the large image might also be a problem, but I suspect the 'cannot open image' refers to the fact that the base image is still compressed and IRAF cannot map it.

Frank has done more work with DECam images than I have and might also have suggestions. I think the best route may be to FUNPACK the images and then use the MSCRED package to display/imexam it (e.g. MSCDISP/MSCIMEXAM).

Alright that's interesting. I was considering the large file size, since loading the manually-reconstructed mosaic weighing 3.17 GB (a few posts earlier) wouldn't work; however, I found that I could make mosaics of a smaller number of frames (I went up to 10 I think and that displayed fine and I could do imexam).

Everything that I'm doing is with the latest version of IRAF on a 64-bit Macintel (and also 64-bit kernel of Linux on a separate computer as a quality check) so I'll see what I can do.

Hi, I have some additional questions about funpack.

1. First, consider a .fits.fz file, in some working directory. When I use funpack, it deletes the corresponding .fits.fz file, after unpacking it. The default behavior, according to the following webpage:

http://portal-nvo.noao.edu/tutorials/fpack

is for funpack to **retain** the original files in that working directory. Instead, funpack deletes it. Why is funpack deleting the originals when it is not supposed to?



2. Second, consider the set of .fits.fz files that are posted to the NVO portal, for each exposure that I took at DECam. Briefly, there is the raw image, a set of instant calibrated images specifically for DECam, and a set of resampled images. I cannot seem to use funpack on three particular .fits.fz files:

instant calibrated, wtmap
resampled, image
resampled, wtmap

I receive the following error messages:

FITSIO status = 415: unknown error status

I searched online for what this means, and I saw on the following webpage that I may have an older version of funpack:

http://portal-nvo.noao.edu/tutorials/fpack

"Older versions of FUNPACK may show an error when processing, reporting "FITSIO status = 415; unknown error status". If this happens, please try upgrading to the latest version from the HEASARC distribution."

So, I ran the command that you suggested in your post dated "09/25/2014 10:45AM" in this thread, but that didn't remedy the problem. Why is funpack not able to unpack these particular files?



3. Also, I cannot get FTP upload to work. I tried uploading the file using FTP, and I have no idea how I was able to get it to work the last time, but I can't figure out why it isn't working this time. I've tried searching all over the internet for directions on how to do this and I found these:

http://iraf.noao.edu/iraf/web/iraf/ftp/WHEREIS

so, I logged in, but I didn't see an example on how to upload a file, so I've been guessing how to use Terminal commands to do this. Before I upload the file, I check to make sure that I am at the correct directory:

Remote directory: /pub

Local directory: /Users/[myusername]/Downloads

but then when I use the put command, I receive the following error message:

553 Could not create file

I tried searching online for what this means, and it said something about write permissions. How do I fix this?


4. Also, some of the DECam images contain egg-shaped stars, due to some Y-coordinate blur in some of my images:



I am not sure why this is happening. I have emailed CTIO staff repeatedly to ask them about this, but they have not answered my emails and it is very frustrating. (1) Why are they not responding, and who else can I contact for help? (2) Why are the images distorted? The individual exposures are only 2 minutes long.

The page you mention refers to the FPACK/FUNPACK binaries distributed as part of CFITSIO. If instead you are using the FPACK/FUNPACK tasks in the FITSUTIL package, then these are script wrappers around those host binaries. In particular, the FUNPACK task has a 'keep' parameter that is off by default and is causing the unpacked file to be deleted -- just turn on this parameter to keep the file.




From your DS9 image it appears you are running OSX, if this is the 32-bit 'macosx' architecture then the package update on 9/25 didn't also update the macosx binary for some reason. This has been fixed and if you do a "make fitsutil" now you should get the updated binaries that will hopefully fix the problem. If not, let me know.




If you're referring to the FTP pub area then this was locked down recently due to spam. I've opened the directory again in case you still need to upload the image.




I don't know who you've contacted at CTIO or why they're not responding, you might open Help Desk ticket with sdmhelp@noao.edu in case there was a problem with the pipeline reductions.

Hi, well with regard to the fitsutil package not being updated, I am pretty sure that I am running all 64-bit architecture, not 32-bit. Nonetheless, I tried doing make fitsutil. That did not remedy the problem, I still get the same error message. I have uploaded the following file to FTP for testing:

AquariusD06S5InstCalwtmap.fits.fz


Also, I am using imcombine to create a mosaic of repeated exposures on cleaned images using IRAF (e.g., 2 minutes, followed by another 2 minutes, for a total of 5 exposures). The offsets are very slight, which I can fix using offset="wcs." But then the output of imcombine has rows and columns along the edges that I want to trim. How do I trim the edges using the imcombine routine? I have tried searching all over the iraf help menu and the internet for help on this, but I couldn't find any information. Is there a routine that I can use?


Also, I noticed that the time stamps on the forums are off by 1 hour and about 57 or so minutes. How can we fix this?

I was able to reproduce the problem and verified that updating the FITSUTIL package to use the latest version of CFITSIO works. I've updated the package binaries and so a "make fitsutil" to install the package should fix the problem.




I don't believe imcombine will trim the image automatically, however you can always use IMCOPY to extract an image section to a new file that trims the edges.



This site is hosted at commercial service provider and I've verified the server has the correct time. The site itself it configured to use UTC as the timezone, otherwise I can't explain why you would see such an odd offset.

So, regarding:

cd /iraf/iraf/extern
sudo make fitsutil

Installing package 'fitsutil' .... [OK]


Glad it works for me this time as well with the new update.

Regarding post timestamps, sometimes they're like 2 hours off for my posts and 3 hours off for your posts, I'm perplexed.

I appreciate the feedback on imcombine. It would be nice to see imcombine with that added functionality for a future release.


Also, I just posted this exact message (above) at 2:35pm edt, to IRAF.net, and it never showed up. What happened?