asap0000 ======== Hi Jim Lovell has discovered a strange corruption bug in asap. When we run: scans = scantable('2005-03-09_172811_t002.rpf') scans.summary(verbose=True) repeatably the source position become corrupted (generally it seems to be after the third "scantable" construction. The above data is in /DATA/VULCAN_1/cphillip/vulcan/data/asap, but I think any data will do. Cheers Chris --------------------------------------------------------- **OK ASAP> scans.summary(verbose=True) -------------------------------------------------------------------------------- Scan Table Summary -------------------------------------------------------------------------------- Beams: 1 IFs: 2 Polarisations: 1 Channels: 4096 Observer: Auto_Spec Obs Date: 2005/03/09/17:29:22 Project: NGC6334Fw Obs. Type: Antenna Name: DSS-43 Flux Unit: K Rest Freqs: [2.39639e+10] [Hz] Abcissa: Channel Cursor: Beam[0] IF[0] Pol[0] Scan Source Position (J2000) Time Integration FreqIDs -------------------------------------------------------------------------------- 0 NGC6334Fw 17:18:23.4 -35.47.01.3 17:30:37 1 x 02:31.0 [0, 1] [0] 1 NGC6334F 17:20:53.4 -35.47.01.3 17:33:43 1 x 02:33.9 [0, 1] [0] 2 NGC6334F 17:20:53.4 -35.47.01.3 17:36:34 1 x 02:33.9 [2, 3] [0] 3 NGC6334Fe 17:23:23.4 -35.47.01.3 17:39:40 1 x 02:33.9 [2, 3] [0] 4 NGC6334Fw 17:18:23.4 -35.47.01.3 17:42:11 1 x 01:22.9 [4, 5] [0] Table contains 5 integration(s) in 5 scan(s). FreqID Frame RefFreq(Hz) RefPix Increment(Hz) -------------------------------------------------------------------------------- 0 TOPO 2.396822e+10 2048 3906.25 1 TOPO 2.4143763e+10 2048 3906.25 2 TOPO 2.3968219e+10 2048 3906.25 3 TOPO 2.4143763e+10 2048 3906.25 4 TOPO 2.3968219e+10 2048 3906.25 5 TOPO 2.4143762e+10 2048 3906.25 -------------------------------------------------------------------------------- **BAD ASAP> scans = scantable('2005-03-09_172811_t002.rpf') Importing data... Auto averaging integrations... Weighting type selected : None ASAP> scans.summary(verbose=True) -------------------------------------------------------------------------------- Scan Table Summary -------------------------------------------------------------------------------- Beams: 1 IFs: 2 Polarisations: 1 Channels: 4096 Observer: Auto_Spec Obs Date: 2005/03/09/17:29:22 Project: NGC6334Fw Obs. Type: Antenna Name: DSS-43 Flux Unit: K Rest Freqs: [2.39639e+10] [Hz] Abcissa: Channel Cursor: Beam[0] IF[0] Pol[0] Scan Source Position (J2000) Time Integration FreqIDs -------------------------------------------------------------------------------- 0 NGC6334Fw 17:47:49.9 +16.00.27.6 17:30:37 1 x 02:31.0 [0, 1] [0] 1 NGC6334F 17:03:08.2 -44.33.03.4 17:33:43 1 x 02:33.9 [0, 1] [0] 2 NGC6334F 03:46:52.4 +56.43.05.6 17:36:34 1 x 02:33.9 [2, 3] [0] 3 NGC6334Fe 17:47:49.9 +16.00.27.6 17:39:40 1 x 02:33.9 [2, 3] [0] 4 NGC6334Fw 17:03:08.2 -44.33.03.4 17:42:11 1 x 01:22.9 [4, 5] [0] Table contains 5 integration(s) in 5 scan(s). FreqID Frame RefFreq(Hz) RefPix Increment(Hz) -------------------------------------------------------------------------------- 0 TOPO 2.396822e+10 2048 3906.25 1 TOPO 2.4143763e+10 2048 3906.25 2 TOPO 2.3968219e+10 2048 3906.25 3 TOPO 2.4143763e+10 2048 3906.25 4 TOPO 2.3968219e+10 2048 3906.25 5 TOPO 2.4143762e+10 2048 3906.25 -------------------------------------------------------------------------------- Seems to be a good old rpfits (fortran) memory problem. repeatedly opening an rpfits file with the read buggers up the refbeam field. as the summary function looks at the refbeam to determine the positions it fails as the reader returns a "random" value. I have a chat to Mark. Malte. Mark, The attached data has only one beam. This only occurs on this data set. If I convert it to sdfits the problem is solved as you don't write this column out unless it is MX data. For now I have put a kludge in, which checks nBeam >1 and only then gets the refbeam from the data.