Bad CDELT1 in FITS output?

[allegroLeiden]

When trying to view the FITS output of LIME in the CASA viewer (CASA-4.3.1), the viewer issues the following 'info':

FITS card 18: CDELT1 = -2.77777778110544E-06
Numeric value does not conform to FITS fixed format.

I'll have a look at the FITS specifications - possibly the number occupies more space than allowed. This keyword value looks 1 space longer than all the other numeric fields if I look at the header. Although since this write is done via a cfitsio call, it is arguably their bug, not ours.

[smaret]

fitsverify does not complain:

File name:  image0.fits
                                           Run Number 18195

              fitsverify 4.16 (CFITSIO V3.320)              
              --------------------------------              

1 Header-Data Units in this file.

=================== HDU 1: Primary Array ===================

*** Warning: Keyword #11, EPOCH is deprecated. Use EQUINOX instead.

   1 | SIMPLE  =                    T / file does conform to FITS standard
   2 | BITPIX  =                  -32 / number of bits per data pixel
   3 | NAXIS   =                    3 / number of data axes
   4 | NAXIS1  =                  100 / length of data axis 1
   5 | NAXIS2  =                  100 / length of data axis 2
   6 | NAXIS3  =                   61 / length of data axis 3
   7 | EXTEND  =                    T / FITS dataset may contain extensions
   8 | COMMENT   FITS (Flexible Image Transport System) format is defined in 'Astronomy
   9 | COMMENT   and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
  10 | OBJECT  = 'LIMEMDL '
  11 | EPOCH   =                2000.
  12 | LONPOLE =                 180.
  13 | EQUINOX =                2000.
  14 | SPECSYS = 'LSRK    '
  15 | RESTFREQ=        356734288000.
  16 | VELREF  =                  257
  17 | CTYPE1  = 'RA---SIN'
  18 | CDELT1  = -2.77777778110544E-05
  19 | CRPIX1  =                 50.5
  20 | CRVAL1  =                   0.
  21 | CUNIT1  = 'DEG     '
  22 | CTYPE2  = 'DEC--SIN'
  23 | CDELT2  = 2.77777778110544E-05
  24 | CRPIX2  =                 50.5
  25 | CRVAL2  =                   0.
  26 | CUNIT2  = 'DEG     '
  27 | CTYPE3  = 'VELO-LSR'
  28 | CDELT3  =                 500.
  29 | CRPIX3  =                  31.
  30 | CRVAL3  =                   0.
  31 | CUNIT3  = 'M/S     '
  32 | BSCALE  =                   1.
  33 | BZERO   =                   0.
  34 | BUNIT   = 'K       '
  35 | END     

 35 header keywords

 32-bit floating point pixels,  3 axes (100 x 100 x 61), 

++++++++++++++++++++++ Error Summary  ++++++++++++++++++++++

 HDU#  Name (version)       Type             Warnings  Errors
 1                          Primary Array    1         0     

**** Verification found 1 warning(s) and 0 error(s). ****

Perhaps a CASA bug rather than a CFITSIO bug?

[imckstewart]

Maybe... it is only a warning after all, so not too important. I'll still put it on the TODO to check the standard. I have the paper somewhere.

Are you concerned about releasing with open issues? These matters can all wait until post-release (and post-holiday) nirvana, surely.

[smaret]

Are you concerned about releasing with open issues?

No, unless there are serious / blocker bugs left. But I don't think this is the case.

[tlunttil]

Returning this timely issue: the problem is that value of CDELT1 doesn't conform to FITS fixed format; it's one character too long (do I smell traces of Fortran...). It's fine for free format, which allows much longer values, but the standard does say that the fixed format is recommended for all values.

The problem is that double precision floating point number can't always fit into FITS fixed format field without losing precision. Anyway, apparently cfitsio function fits_write_key_fixdbl should be able to round/truncate doubles so that they fit within the field.