...

Diagnostic Tools

Astropy / FitsHeader

One of the simplest ways to extract detailed diagnostic information from the metafits and raw gpubox file formats of the legacy correlator is to use the fitsheader  command line tool provided by Astropy. This Python library is also useful for correcting erroneous header values so that the files can be correctly processed. To load Astropy on Garrawarla:

module use /pawsey/mwa/software/python3/modulefiles
module load python astropy

Issue Details

NAXIS2 Mismatch

Symptoms

• number of frequency channels that we would expect based on the value of the FINECHAN header does not match the dimensions of the raw files.
  • metafits number of frequency channels is 1280/FINECHAN
  • raw file hdus should have dimensions (number of baselines, nubmer of fine channels).

Example

> fitsheader 1107478352.metafits --keyword FINECHAN --extension 0
# HDU 0 in 1107478352.metafits:
FINECHAN=                 40.0 / [kHz] Fine channel width - correlator freq_res 


# ^ we would expect there to be 32 fine channels.

> fitsheader 1107478352_20150209005219_gpubox01_00.fits --keyword NAXIS* --extension 0
# HDU 1 in 1107478352_20150209005219_gpubox01_00.fits:
NAXIS   =                    2 / number of data axes                            
NAXIS1  =                66048 / length of data axis 1                          
NAXIS2  =                  256 / length of data axis 2  

# ^ but there are actually 256 fine channels.

Potential fixes

update the metafits

export obsid=...
python - <<EoF
from astropy.io import fits
hdus=fits.open('${obsid}.metafits')
hdus[0].header['FINECHAN']=10
hdus.writeto('${obsid}.fixed.metafits')
EoF

Historical info

For the old correlator, the NAXIS values represent the actual, working correlator mode when the data was collected, while the metafits file represents what mode the user wanted the correlator to be in. Back in those days, the correlator never saw or knew anything about metafits files - the mode was changed using magic 'mode change' observations, so if one of those mode change observations was accidentally deleted, it would keep taking data in the previous mode. That happened quite often. If there's a discrepancy, you should use those, and fix (or ignore) the metafits file.

MILLITIM header fixed to zero gives duplicate HDU timestamps

Symptoms

• Groups of adjacent HDUs in the same gpubox file have the timestamp, according to the combination of the TIME  and MILLITIME headers of each HDU
• Only visible with with non-integer INTTIME  (e.g. 0.5s)

Example

> fitsheader 1059505936_20130802191158_gpubox01_00.fits --keyword '*TIM*'
# HDU 0 in 1059505936_20130802191158_gpubox01_00.fits:
TIME    =           1375470717 / Unix time (seconds)
MILLITIM=                    0 / Milliseconds since TIME 

# HDU 1 in 1059505936_20130802191158_gpubox01_00.fits:
TIME    =           1375470717 / Unix time (seconds)
MILLITIM=                    0 / Milliseconds since TIME 

Potential fixes

• Use a script to update the incorrect MILLITIM  headers

HDU timestamps out of sync between gpubox files

Symptoms

• One or more gpubox files have timestamps that fall in between the timestamps of the other gpuboxes
• Only visible with INTTIME > 1s

Example

# TODO 1092080416

Potential fixes

• Process groups of gpuboxes with common timesteps separately

Data ends ahead of schedule

Symptoms

• some or all gpubox files have less timesteps than specified in the metafits
• in severe cases, the data can run out before GOODTIME, meaning all data is considered contaminated.

Example

# TODO 1088203096

...