Errors while trying to load some Parkes rpf files as scantables

[slbreen@…]

Some rpf files from Parkes cannot be loaded into ASAP with the command data = scantable('file.rpf')

The error that it returns of a couple of files is

Traceback (most recent call last): File "<ipython console>", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/asap/scantable.py", line 70, in __init__

  self._fill([filename], unit, average)
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/asap/scantable.py", line 1743, in _fill

  r._read() RuntimeError: ArrayBase::Array(const IPosition&) - Negative shape

We have also tried loading the files in with commands r = reader('2008-06-20_0425-P625.rpf') data = r.read()

and get a similar error, as follows

Traceback (most recent call last):

  File "<ipython console>", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/asap/asapreader.py", line 57, in read
    stfiller._read(self) RuntimeError: ArrayBase::Array(const IPosition&) - Negative shape

if we then enter data = r.read() again it does it without error.

We have also loaded the data into SPC without error. I can email one of the data files if you like?

[Malte Marquarding]

Hi,

please let me know where I can access the data file. What kind of observation is it?

Cheers, Malte

[Malte Marquarding]

rpfits file causing the trouble

[Malte Marquarding]

It is not readable by the PKSreader, e.g.

rp2sdfits 2008-06-20_0425-P625-ticket139.rpf t.sdf
SDFITSwriter::write: Invalid IF number 0 (maximum 1).

[Malte Marquarding]

The problem is with the data itself. The file contains two scans, the first with 6 integrations and the second with 1. The UTC timestamps recorded for these are

 15975.0
 16005.0
 16035.0
 16065.0
 16095.0
  2685.4  <- time goes backwards

  5548.3

The UTC normally increases during a scan, even past 86400, so this is abnormal. DATE-OBS for the second scan is the same as the first which also can't be right. I've added a check to MBFITSreader for such behaviour, it will issue a warning, add 86400 to the UTC, and carry on.

The position interpolation for the last two integrations in the first scan, and the one in the second scan are unreliable but the positions could be fixed manually if the data is worth preserving.

Cheers, Mark