sub-scantables in scantable

[kuiper@…]

Reading a 50 row SDFITS extension into asap resulted in 45 'scans' but three of them are mini-scantables. However, all the get_[something]() methods return 50 values consistent with the SDFITS original. Only getscannos() gives a list of scans that can be fetched with get_scan() and that summary() will show.

Also something funny happens with the scan numbers, which go from 0 to 51 (instead of 49) with gaps not related to the scan grouping into miniscans.

I will attach a more detailed discussion and the SDFITS file.

[kuiper@…]

more detailed description with asap outputs

[anonymous]

SDFITS file showing sub-scantabling behaviour

[kuiper@…]

This is a managable problem if one knows two things:

scantable() does not reject bad scans (e.g. all data values the same) but makes them invisible to get_scan(), summary() and getscannos(). The bad scans will show up, for example, in get_sourcename() as "" and get_direction() as (0.0,0.0). This is also the situation in which I got scans lumped together. Keeping bad scans out of the SDFITS files fixed that.

I don't know what scantable() does with the original scan numbers but you can't count on the new scans numbers, starting from zero, to be contiguous. There may be missing numbers. To select a scan by index, you need to do get_scan(list(getscannos())[index]). Alternately, to get information about RVSYS for 'scan' from the pyfits bintable, you would do hdu[1].data(list(getscannos()).index(scan)).field('RVSYS').

Don't count on the python examples being 100% correct but you get the idea. It works for me.