#421 Converting to psrfits produces unreadable files

[Mike Keith]

Converting a timer format archive from dspsr to psrfits using either

pam -e rf -a PSRFITS in.ar

or

psrconv in.ar

Seems to produce a psrfits file that cannot be read by psrchive, producing errors similar to the below when read. Issue affects psrchive from repo on 2018-09-24, but not psrchive from repo on 2018-07-17, so it is a recent issue.

The error occurs when writing the psrfits file, as files written with eariler code are readable in both versions, but files written with new code are unreadable in both versions.

I will try to update this with more info when I get chance (I am teaching today).

psredit: error while processing 20180512_135406_B0531+21.zz:
Error::stack
    Pulsar::FITSArchive::load_Integration
    MJD::settle
Error::InvalidState
Error::message
    |fracsec=9327818134.000725| > 1.0 -- secs=0 days=0

[Mike Keith]

The problem is that the STT parameters are set to zero in the bad file.

STT_IMJD=                    0 / Start MJD (UTC days) (J - long integer)
STT_SMJD=                    0 / [s] Start time (sec past UTC 00h) (J)
STT_OFFS=                   0. / [s] Start time offset (D)
STT_LST =                   0. / [s] Start LST (D)
END

c.f. good file:

STT_IMJD=                58250 / Start MJD (UTC days) (J - long integer)
STT_SMJD=                50838 / [s] Start time (sec past UTC 00h) (J)
STT_OFFS= 0.000725930702174082 / [s] Start time offset (D)
STT_LST = '*       '           / [s] Start LST (D)
END

[Mike Keith]

I believe that this bug is caused from the fix to bug #420. In particular, in FITSArchive.C hdr_ext is now always created with dummy values, but later on in the code (around line 1008) it assumes that if a hdr_ext exists then the reference epoch can be read from that header so it never calls the routines that set the reference epoch when the header is blank. I think this could be fixed by setting the start time in the temporary hdr_ext object when it is created.

[Mike Keith]

Fixed in 61641d.

I merged the logic of how to get the reference epoch with the decision to make a temporary hdr_ext object. This seems to have fixed it the main issue, and the files are now readable.

I note that there are other parameters that are left undefined in the FITS header when converting from timer archives that might confuse other software later on, but I suspect this is largely unavoidable.