The pol2map tool for reducing POL-2 data was released to the science community for the start of 17B observing. As with all newly commissioned instrumentation the “ideal” reduction has yet to be finalised. This advanced section of the POL-2 data reduction documentation aims to provide you with tools for expanding and examining the POL-2 reduction process further and in more detail.
This section describes the six-step process of combining data for one or more new POL-2 observations into existing I, Q and U maps and vector catalogue created by an earlier run of pol2map.
MAPDIR, and then add in the raw data files for the new observations. The auto-masked I maps have names that end in
MASKOUT2parameters (see Step 3 in Section 3). To create the new masks that would be generated from the new auto-masked map, use this command.
Ensure the new auto-masked co-add is used in place of the old one to define any new masks needed in future.
Currently, as with unpolarised SCUBA-2 reductions, the default reduction pixel size is 4′′. The pixel size is
controlled by the
PIXSIZE parameter in the Smurf pol2map command:
The following four-step example shows how to investigate the impact of changing pixel size. In this example, we compare 12′′ pixels and 7′′ pixels.
maskparameter value is enclosed in single and double quotes).
Using larger pixels can sometimes encourage smooth blobs and other artificial features to appear in
the map. The
iauto12.sdf file should be examined to check that it does not have such artificial
Check the masks (
pcamask12.sdf) to make sure they look reasonable.
The error on the IP is reported to be of the order of 0.5%. It is possible to investigate the effects of the systematic error in IP by creating maps using the upper and lower limits on the IP value. The makemap configuration parameter called ipoffset can be used to do such an investigation. To use it, run pol2map twice as follows:
to produce maps using the upper and lower IP limits (a range of 0.5%). If pol2map has already been run
on POL-2 data then a file will already exist that was created using the mean IP (the mean IP is
ipoffset is omitted from the configuration value, or the configuration parameter itself is
Vector catalogues produced by pol2map contain information about World Coordinate Systems (WCS) in two different forms:
Starlink software such as Polpack, Kappa and Gaia rely on the WCS FrameSet for all WCS-related operations (drawing annotated axes, aligning data sets, etc). Thus problems are likely if the WCS FrameSet is removed from the vector catalogue. This could happen for instance if you use inappropriate software to process an existing catalogue, creating a new output catalogue – the WCS FrameSet may not be copied to the output catalogue, causing subsequent WCS-related operations to fail. It is safe to use Polpack, Kappa, Gaia and Cursa) as all these packages copy the WCS FrameSet to any new output catalogues. Unfortunately, the popular Topcat catalogue browser (see http://www.starlink.ac.uk/topcat/) and the STILTS package (http://www.starlink.ac.uk/stilts/) upon which it is based, do not copy the WCS FrameSet to any output catalogues.
For this reason, Polpack contains a command that can be used to copy the WCS FrameSet from one catalogue to
another. Say for instance you create catalogue
mycat.FIT using pol2map, and then use Topcat to remove low
signal-to-noise vectors, saving the results to a new catalogue called
selcat.FIT. The WCS FrameSet will be
selcat.FIT, and so we need to copy it back again from the original catalogue
mycat.FIT. To do
this we use the “polwcscopy” command:
This creates a third catalogue
selcat2.FIT, which is a copy of
selcat.FIT but with WCS inherited from