Welcome to iraf.net Friday, March 29 2024 @ 12:00 AM GMT


 Forum Index > Help Desk > General IRAF New Topic Post Reply
 error "cannot close image"
   
kkwitter
 10/11/2007 05:35AM (Read 8708 times)  
+++--
Chatty

Status: offline


Registered: 01/19/2006
Posts: 42
While ccdproc'ing a list of files, my students (on Macs) are getting this:ERROR: cannot close file (filename)If tried again, that file is fine, but another might fail in the same way. Sometimes it happens when working on a single file - after the task should complete, the error occurs. There's no apparent permanent harm, just that any multiple file processing is interrupted and has to be restarted. Suggestions?

 
Profile Email Website
 Quote
fitz
 10/11/2007 05:35AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
Hi Karen,There's not really enough information to draw a conclusion, but is there any chance you're using .imh or .fits images but have your 'imtype' set to something else? See for example https://iraf.net/phpBB2/viewtopic.php?t=86571&highlight=imtype as to why this could be causing problems.That's just a quick guess, Frank may have other suggestions as well.Cheers,
-Mike

 
Profile Email
 Quote
kkwitter
 10/11/2007 05:35AM  
+++--
Chatty

Status: offline


Registered: 01/19/2006
Posts: 42
Hi Mike-No, the imtypes are all set to "fits" and that's what the data is. I did a mkiraf agin jus tin case. But no luck. When my student tries to ccdproc, she still gets the same kind of error, but now there's a number appended to the image:for the file named object1054.fits the error iswarning: cannot close file (object1054.fits_635)and each the next file's error has a higher number appended, i.e., the next one is 636, etc.Any other odeas?Thanks!
Karen

 
Profile Email Website
 Quote
valdes
 10/11/2007 05:35AM  
+++++
Active Member

Status: offline


Registered: 11/11/2005
Posts: 728
Hi Karen,When you see the appended number on a FITS file this is the result of the underlying "FITS kernel" having to make a temporary copy. One reason I have seen for this is when the raw data is 16-bit integer with BSCALE and BZERO not set to the special numbers defining unsigned integer. If you post a sample header listing we can check this. The effect I've seen with this is that things take a long time for large files. There may be other reasons the FITS kernel needs to make a temporary copy and we might need to ask the person responsible for this piece of software. One simple fix might be to imcopy all the raw data once:[code:1:029abb93d4]
cl> imcopy *.fits NEW/
cl> imdel *.fits # After verifying things of course.
[/code:1:029abb93d4]In any case, this error should not occur and I don't know what specifically is causing it. If you do the "imcopy" thing and you don't encounter the error we can conclude it is the FITS format and the FITS kernel. If the problem persists then my guess is wrong.Yours,
Frank

 
Profile Email
 Quote
kkwitter
 10/11/2007 05:35AM  
+++--
Chatty

Status: offline


Registered: 01/19/2006
Posts: 42
Hi Frank,Here's the entire image header for one of the raw files (from the 4m RC spectrograph at CTIO):. Thanks!KarenSIMPLE = T / Fits standard
BITPIX = 16 / Bits per pixel
NAXIS = 2 / Number of axes
NAXIS1 = 3132 / Axis length
NAXIS2 = 734 / Axis length
EXTEND = F / File may contain extensions
BSCALE = 1.000000E0 / REAL = TAPE*BSCALE + BZERO
BZERO = 3.276800E4 /
ORIGIN = 'NOAO-IRAF FITS Image Kernel July 1999' / FITS file originator
DATE = '2007-09-06T19:24:49' / Date FITS file was generated
IRAF-TLM= '16:24:45 (06/09/2007)' / Time of last modification
OBJECT = 'Dome flat, 1.5`` slit, 360 fil' / Name of the object observed
OPICNUM = 4201 / Original picture number
HDR_REV = '2.000 13Feb96 (add mode and group to hdrs)' /
IMAGETYP= 'DOME FLAT' / Type of picture (object, dark, etc.)
DETECTOR= 'Loral3K_1' / Detector (CCD type, photon counter, etc.)
PREFLASH= 0.000000 / Preflash time in secs
CCDSUM = '1 1 ' / On chip summation (X,Y)
DATE-OBS= '2007-09-05T20:59:07.8' / Date of observation start
UTSHUT = '20:59:07.8' / UT of shutter open
OBSERVAT= 'CTIO ' / Origin of data
TELESCOP= 'CTIO 4.0 meter telescope' / Specific system
NAMPSYX = '1 1 ' / Num amps in y & x (eg. '2 2'=quad)
AMPLIST = '12 ' / Readout order in y,x
BIASSEC = '[1:40,1:734]' / Bias section definition
BSEC12 = '[1:40,1:734]' / Bias section definition for Amp12
CCDSEC = '[1:3072,140:873]' / Section in full CCD for DATASEC
DATASEC = '[61:3132,1:734]' / Image area in raw frame
TRIMSEC = '[61:3132,1:734]' / Trim section definition
ASEC12 = '[1:3132,1:734]' / Section read with Amp12
CSEC12 = '[1:3072,140:873]' / Section in full CCD for DSEC12
DSEC12 = '[61:3132,1:734]' / Image area in raw frame for Amp12
TSEC12 = '[61:3132,1:734]' / Trim section definition for Amp12
WAVEFILE= 'Obs Wed Sep 5 11:25:14 2007' /
WAVEMODE= 'none ' / Waveform mode switches on
GTRON12 = 7.500 / (e-) predicted read noise, lower right
GTGAIN12= 1.940 / (e-/ADU) predicted gain, lower right
GTINDEX = 4 / Gain selection (index into Gain Table)
PIXELT = 57280 / (ns) unbinned pixel read time
DCS_TIME= 20000 / (ns) Double Correlated Sample time
EXPTIME = 150.000 / Exposure time in secs
DARKTIME= 151.275 / Total elapsed time in secs
OBSERVER= 'Winkler/Jaskot' / Observers
PROPID = '0257/0482' / Proposal Id
TELID = 'ct4m' / CTIO 4.0-m Telescope
ARCONVER= '17Oct97ver7_22' / Arcon software version
COMMENT METEOROLOGICAL INFORMATION
WEATDATE= 'Sep 05 20:56:05 2007' / Date and time of last update
WINDSPD = '7.5' / Wind speed (mph)
WINDDIR = '27' / Wind direction (degrees)
AMBTEMP = '18.8' / Ambient temperature (degrees C)
HUMIDITY= '14' / Ambient relative humidity (percent)
PRESSURE= '784' / Barometric pressure (millibars)
SEEING = 'mysql_query():Unknown Error seeing=column' / Tololo
DIMM seeing
COMMENT
INSTRUMENT
PARAMETERS
CLAMP = 'off' / Old lamp in use
DECKER = 'open' / decker position
COLLIMAT= 'blue' / Collimator identification
CAMERA = 'blueAirSchmidt' / Spectrograph camera identification
CAMFOCUS= 0 / Camera focus
UFILTER = '4' / Upper filter position
UFNAME = '4' / Full name of filter in ufbolt
LFILTER = '1' / Lower filter position
LFNAME = '1' / Full name of filter in lfbolt
SKYSUPPR= 'open' / Sky suppressor position
RSVIEWER= 'out' / Rear slit viewer
UT = '20:59:07.3' / UT of TCS coordinates
ST = '15:14:14.6' / siderial time
RA = '15:13:52.83' / right ascension (telescope)
DEC = '20:41:39.5' / declination (telescope)
EQUINOX = '2000.0' / epoch of RA & DEC
HA = '00:00:00.1' / hour angle (H:M:S)
ZD = '50.8' / zenith distance (degrees)
AIRMASS = '1.581' / airmass
TELFOCUS= '186347' / Telescope focus
POSANG = '90.1' / slit positioning angle
ADCSTAT = '0' / adc status
GUIDERX = '11.67' / x guider position (mm)
GUIDERY = '92.09' / y guider position (mm)
GUIDERA = '15:13:58.57' / ra guider position
GUIDEDEC= '20:51:02.62' / dec guider position
INSTRUME= 'R-C Spec' / CTIO R-C Spectrograph.
SLITWIDT= '225' / Slit width (microns)
GRATING = 'KPGL2-1' / Grating identification
TILT = '60.298248' / Grating tilt (degrees)
COLFOCUS= '515.000000' / Collimator focus
UFILTER = '0' / Upper filter position
LFILTER = '0' / Lower filter position
COMPLENS= 'out' / Comparison lens
MASK = 'open' / Newall mask / slow shutter
COMPLAMP= 'park' / Comparison lamp
ICSSEQ = 80 / ICSINFO-sequence
ICSDATE = 'Sep 5 16:59:08' / ICSINFO-timestamp
RECID = 'ct4m.070905.210351' / NOAO Archive record ID

 
Profile Email Website
 Quote
valdes
 10/11/2007 05:35AM  
+++++
Active Member

Status: offline


Registered: 11/11/2005
Posts: 728
Hi Karen,I don't see anything wrong. The BSCALE and BZERO are what they should be.Please send any log output from CCDPROC. In particular, near the point the cannot close image error occurs. It would help to know what step it was trying to do and any dependent calibration files it wants to use.Frank

 
Profile Email
 Quote
kkwitter
 10/11/2007 05:35AM  
+++--
Chatty

Status: offline


Registered: 01/19/2006
Posts: 42
Hi Frank-
The logfile doesn't include any of the errors, which come on the command line. The error says "cannot close file" etc. I did discover that what actually can't be closed is the temp file created in the reduction process (right now we're just OTZ-ing raw image files). The temp files for the problem images remain in the directory but when I try to open or list them, I get FXF EOF ENCOUNTERED, and now also SEEK ERROR. Again, some files work fine and others don't; and it's not always the same file that gives us trouble...

 
Profile Email Website
 Quote
fitz
 10/11/2007 05:35AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
Hi Karen,It's a longshot guess, but any chance these data are on NFS-mounted disks? If so, does the system message log (the /sbin/dmesg command on Macs) show there are any NFS errors happening at about the same time? If not, there might be other messages that could help (e.g. disk filling up could also be a problem).-Mike

 
Profile Email
 Quote
kkwitter
 10/11/2007 05:35AM  
+++--
Chatty

Status: offline


Registered: 01/19/2006
Posts: 42
Hi Mike,These are on an afp-mounted disk (all Mac), and there's plenty of room...We'll try working on a single local disk to see if the problem is with the network...

 
Profile Email Website
 Quote
kkwitter
 10/11/2007 05:35AM  
+++--
Chatty

Status: offline


Registered: 01/19/2006
Posts: 42
Hi guys,This is looking like a network timing issue - when we work on a local disk, there are no problems. But when we work on a networked disk, we get these "cannot close" errors, which seem as if the system is trying to access the new temp file before it's been closed. Most of the time the error is of no consequence that we can see, especially operating on a single file. But when there is a batch to be done, say in ccdproc, the process halts when one of these errors is encountered. Is there some way to introduce a delay between task read/writes? Or do you have other suggestions?Thanks!Karen

 
Profile Email Website
 Quote
fitz
 10/11/2007 05:35AM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
Hi Karen,I can't find any similar reports about problems using AFP shares, even outside of IRAF. CCDPROC writes its temp file to the current directory and there's no logical directory you could use to redefine it automatically.If copying the images to a local disk isn't an effective option, how about trying to use IRAF networking to access the images remotely? IRAF could be on a mounted shared disk and all you would need is to edit the dev$hosts file with the various machine names to enable it. Then, simply address the images as "ursa!/path/foo.fits". You'll need to run this from a local disk directory so the temp file isn't being written to an afp mount, but this then uses iraf I/O to handle the image rather than relying on the
underlying OS. You might also try manually mounting the remote disks with the /sbin/mount command so it uses NFS instead of AFP. See the mount(8) or mount_nfs(8) man pages for details.Cheers,
-Mike

 
Profile Email
 Quote
   
Content generated in: 0.29 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