iraf.net

Hi,I was helping a user who was using mscred.ccdproc to process some multiextension fits files produced by a new instrument at the GTC (mscred v4.9 under Iraf v2.14.1 on a Fedora 8 PC).
The problem showed up when he tried to subtract out an averaged bias from a flat field image.
The same error message though is displayed when using ccdlist.[code:1:9ec34da33a]mscred> ccdlist flat_i.fits
ERROR: FXF: syntax error in kernel section
"ccdproc="")"
line 18: mscsrc$ccdlist.cl
called as: `ccdlist (images=flat_i.fits)'
[/code:1:9ec34da33a]After inspecting the header of all extensions looking for obviously malformed keywords, and checking the source code of the ccdlist task, I found that the problem was caused by the dashes in the string value of the EXTNAME keyword.[code:1:9ec34da33a]mscred> hedit flat_i.fits[1] EXTNAME .
flat_i.fits[1],EXTNAME = CCD-1-L1[/code:1:9ec34da33a]The solution was simply to use hedit to replace the dashes with underscores (CCD-1-L1 --> CCD_1_L1, etc.) .Is this a (very understandable and reasonable) limitation of mscred in handling ETXNAME values, or does using dashes in the EXTNAME value violate the FITS standards?And should I tell the instrument team about this, so that they can correct the software that writes the FITS header? Thanks very much
Nicola

Hi Nicola,Thanks for identifying the problem so clearly. The '-' isn't explicitly forbidden by the FITS standard for values as far as I know, nor is it explicitly excluded by the FITS kernel in IRAF. However, the way the kernel section is being parsed by the FITS kernel, the '-' is being confused with the use of a hyphen to mean turn off a parameter (e.g. "inherit-" instead of "inherit=no"). Because the hyphen is in the value, I think it's actually a bug in the fits kernel parser code. Fixing this would require some investigation and then a completely new set of binaries, or at least a new library you have to install and then relink external packages in order to have effect. For now, the simplest fix of editing the value may be the best. The instrument team might well be willing to change the field, assuming of course doing so wouldn't break any other software.-Mike

I might also add that using quotes or \ escapes would allow extension names with characters also used by the FITS kernel syntax. But for something like ccdproc or other mscred-type scripts the script code would probably need a fair amount of massaging and not worth the effort.I would also mention another drawback of the FITS kernel syntax. An extension name cannot be a number because something like[code:1:b671bc6df9] abc.fits[4][/code:1:b671bc6df9]Assumes the number is the position in the file. In other words, in order to allow both an order number and an extension name in the syntax (filename[order][extname,...]) the parser has to make some assumptions.So, while the extension names are allowed to be anything, there are some limitations for making data work efficiently in reductions. It's like saying your could have a 68 character extension name but a user reducing data would not want to have to type out such a thing.My thoughts,
Frank Valdes

Dashes in EXTNAME keyword in the FITS header caused a bit different error from FXF in my case, see https://iraf.net/phpBB2/viewtopic.php?t=88899