Practically all
IMAGER commands cannot handle more than 1 polarization state.
So far, only two commands fully support polarized data:
UV_TIME and
STOKES.
-
STOKES is the primary command that allows to derive or extract
a UV data with only one Stokes parameter from a UV data set with
several polarization states.
IMAGER can then process the
individual Stokes parameters separately.
- For convenience (because polarized data is obviously in general
bigger), the
UV_TIME command can be used for time averaging
prior to use of the
STOKES command.
- Most other commands will flatly refuse to handle data with more than
1 polarization state (e.g.
UV_FILTER,
UV_RESAMPLE, etc...).
- For debugging purpose, some commands like
UV_PREVIEW,
UV_MAP
or
UV_STAT will operate with more than 1 polarization state,
but will not produce meaningful results (only a subset of the data
may be treated).
Specific treatment is thus required when handling data with partial or complete
polarization information.
- From UVFITS format by
fits_to_uvt script
When importing data, the
fits_to_uvt script assumes by default
the data is unpolarized and produces the pseudo-polarisation
state "None" from the UVFITS file, by a properly weighted combination
of the two parallel hand states if more than one state is present. The
weighting is based on the relative noise in both polarization states.
Full polarization information can be preserved by adding the
/STOKES option to the
@ fits_to_uvt command.
- By command
READ UV
READ UV command will read data with any
polarization state(s). The handling depends on whether 4 states are present
(in which case they are preserved), or only 2 (HH+VV or XX+YY, or RR+LL),
in which case the 2 polarization data are merged into one state representing
unpolarized emission, unless they are preserved by explicitely adding keyword
STOKES. See
HELP READ UV for details.
The resulting multi-polarization UV Tables should be split into tables
with one polarization for further processing. This is done by command
STOKES.
To simplify data handling, we strongly recommend following strict naming
conventions, as defined in the next section.