Open IanHeywood opened 3 years ago
Actually hanningsmooth
might not be the culprit. The parent MS has a mixture of X-band and P-band in the SPW table (X-band being a pointing scan I guess). The X-band SPWs (0-15) all have 64 channels, the P-band SPWs have 128...
Ah! Now that's an open problem in shadeMS. I was lazy -- there's some shortcuts in there that make assumptions about SPW/DDID. Need to go in and clean that up.
How were you so unfortunate as to end up with an MS like that? Why not keep them separate?
It arrived like this from the archive. There are 16 X-band SPWs that are not referenced by any rows in the main table, which is what made me think it was a pointing scan (I didn't make the SBs).
My first attempt to process this involved using mstransform
to split out SPWs 16-31 containing just the P-band data. I then ran split-ms-spw.py
to get a MS per SPW. This preserves the full SPECTRAL_WINDOW table, even though the main table only references one row in it, which is what seems to be causing the tricolour issue.
My second attempt I skipped the mstransform
step and went straight for split-ms-spw.py
. This took the X-band SPWs with it, and the varying number of channels between the two halves of the SPW table are (I guess) what's causing this trouble.
So I do want to keep it all separate, firstly because this is going to be a very hands-on reduction and it's more manageable this way, and secondly because having multiple SPWs seems to be a complete pain in the ass for all my favourite software.
I think this might be a CASA bug rather than a shadems bug, as I don't think the former updates the SPW table after Hanning smoothing has been applied, but:
wsclean also crashed with a very similar message: