Some experiments with LINMOS have revealed some hard requirements in both the header and file naming. These are required for LINMOS to perform leakage correction appropriately.
Here STOKES must be lower case i.e. .i., .q., .u. or .v., and the beam number must presented in zero-padded format e.g. .beam00 (note that preceding .)
Also, in the header there must be a dummy Stokes axis in NAXIS3 - this is the 2nd (index 1) in numpy. So ordering must be (FREQ, STOKES, Y, X) in numpy or (X, Y, STOKES, FREQ in FITS). Without this ordering leakage subtraction will fail. Right now I've stacked the FREQ into NAXIS3 (it needs to be NAXIS4).
Also, interestingly, LINMOS will default to looking for
when correcting e.g. image.blahblah.q.blahblah.beam{BEAMNUMBER}.blahblah.fits. This can be overridden using the linmos. stokesinames parameter to point to any other FITS file. We may want to consider keeping the model files around for a more robust subtraction method.
Some experiments with LINMOS have revealed some hard requirements in both the header and file naming. These are required for LINMOS to perform leakage correction appropriately.
LINMOS expects a filename with like:
Here
STOKES
must be lower case i.e..i.
,.q.
,.u.
or.v.
, and the beam number must presented in zero-padded format e.g..beam00
(note that preceding.
)Also, in the header there must be a dummy Stokes axis in NAXIS3 - this is the 2nd (index 1) in numpy. So ordering must be (FREQ, STOKES, Y, X) in numpy or (X, Y, STOKES, FREQ in FITS). Without this ordering leakage subtraction will fail. Right now I've stacked the FREQ into NAXIS3 (it needs to be NAXIS4).
Also, interestingly, LINMOS will default to looking for
when correcting e.g.
image.blahblah.q.blahblah.beam{BEAMNUMBER}.blahblah.fits
. This can be overridden using thelinmos. stokesinames
parameter to point to any other FITS file. We may want to consider keeping the model files around for a more robust subtraction method.Ping @tjgalvin for thoughts