Better fonts in postscript output from KAPPA

Until now, the fonts available for the annotation of axes within KAPPA, etc, were very limited (basically those supplied by PGPLOT). As of 6th February, anyone using a Starlink installation that has been rsynced from Hilo or built from a git checkout will have access to several higher quality postscript fonts when producing postscript output.

The environment variable PGPLOT_PS_FONT can be set to one of the following four values:

1. "Times"
2. "Helvetica"
3. "Courier"
4. "NewCentury"
5. "Zapf"

to produce axis annotations in the corresponding font family. In addition, the usualt PGPLOT font number can be set to control whether the font is italic and/or bold., using the following font numbers:

• "font=1": Normal
• "font=2": Italic
• "font=3": Bold
• "font=4": Bold and Italic

For example, here is a postscript image created using the default PGPLOT font with the following command:

% display $KAPPA_DIR/m31 mode=perc \

        percentiles=\[2,98\] style=^sty

If you first define the PGPLOT_PS_FONT environment variable to "Times" you get the following:

% setenv PGPLOT_PS_FONT Times

% display $KAPPA_DIR/m31 mode=perc \

        percentiles=\[2,98\] style=^sty

In the above command the text file sty  contains

# Set the default line width and colour for all graphical elements.

width=3

colour=black

#  Override the above defaults for specific graphical elements.

colour(border)=green

colour(ticks)=green

width(border)=3

width(ticks)=3

If, in addition, the Font attribute is set to 4 (bold and italic), you get the following:

% display $KAPPA_DIR/m31 mode=perc \

        percentiles=\[2,98\] style="'^sty,font=4'"

And dont forget, you no longer need to use psmerge to combine postscript plots! See this previous blog post. 

Converting HEALPix Maps to Tangent Plane Projection

Most astronomers are used to dealing with images that use the tangent-plane projection to map the spherical sky onto the flat image plane. However, the Advanced Data Products (ADPs) within the JCMT Science Archive (JSA) use a HEALPix projection instead, to facilitate the stitching together of adjacent tiles on the sky. The HEALPix projection differs from the tangent-plane projection in several ways:

1. The pixels are not quite square, with aspect ratios roughly in the range 1.0 to 1.4 depending on where on the sky the pixel is located (although all pixels are of equal area).
2. In the north and south polar regions (absolute Declination above 41.8 degrees) the RA and Dec axes are not orthogonal - the angle between east and north is about 60 degrees.
3. Maps that straddle the boundary between the polar and equatorial regions suffer from a discontinuous distortion as shown in the following image, a tile taken from a SCUBA-2 observation of M31.

In addition, JSA ADP maps are rotated so that north (in the equatorial region) is at 45 degrees to the image X axis.

If you would prefer to see your maps in the usual tangent-plane projection with square pixels and north upwards, you can use the JSAJOIN command within the Starlink SMURF package. This command pastes together one or more input maps in HEALPix projection, and then resamples the result onto a tangent-plane projection (the JSASPLIT command does the opposite).  For instance if the original HEALPix maps are listed in text file "tiles", then running the following command:

    % jsajoin ^tiles tan_map.sdf

will paste all the HEALPix maps into a new tan-projected map in file "tan_map.sdf". By default the output projection is centred on the centre of the available input data, and the pixels are square with size equal to the nominal size of the input pixels. However, the details of the output projection can be specified explicitly, or a template map can be provided that defines the require output projection. See the documentation for further details.

The JSAJOIN command is actually a script that uses various other SMURF and KAPPA commands to do the work. In particularly, it uses the SMURF JSAPASTER command to paste together the individual HEALPix maps into a single HEALPix map, and then uses the KAPPA WCSALIGN command to resample the combined HEALPix map onto a tangent-plane projection. It is of course possible to use these commands directly from the command line yourself if you want more control than is provided by the JSAJOIN script  - for instance if you want to use different values for the resampling parameters. If you want to see how how JSAJOIN chooses it's resampling parameters, search for string "wcsalign" within file $SMURF_DIR/jsajoin.py.

Recovering the number of chunks used by makemap - take 2.

The way in which the chunking behaviour of MAKEMAP is recorded,  described in previous post ("Recovering the number of chunks used by makemap" ), has been changed.  The SMURF extension of the output map created by MAKEMAP no longer contains an NCHUNK item. Instead, the FITS extension of the map contains a pair of headers as follows:

• NCONTIG: An integer giving the number of contiguous chunks of data within the supplied input time-stream data files. This number does not include any chunking performed because of low memory and will usually be 1 if a single observation is supplied as input.
• MEMLOW: A boolean value which is TRUE if the data was split into chunks due to the computer having insufficient memory.

Recovering the number of chunks used by makemap

This post has been superceded - see the new post "Recovering the number of chunks used by makemap - take 2".

As of today, the number of chunks of continuous time-series data used by makemap is recorded in the output map. It is stored in the NCHUNK item within the SMURF extension of the output map. So for instance, it can be viewed by doing:

   % kappa
   % setext mymap.sdf smurf get nchunk loop=no

If NCHUNK has a value of 1, then all the input time-stream data was processed as a single chunk. If NCHUNK is larger than 1, then either the computer had insufficient memory to process the data as a single chunk, or the data was not taken as a single continuous observation.

An rsync of the Hilo stardev system is required to use this new feature.

A new Starlink release contains notable updates to the SCUBA-2 configuration files.

The latest Starlink release - 2014A - has been made public. For details please read the release notes provided at: http://starlink.jach.hawaii.edu/starlink/2014A

As part of this new release we want to highlight one significant update and a couple of new additions to the SCUBA-2 reduction arsenal of config files.

Updates to bright_extended config file

This config file 'dimmconfig_bright_extended.lis' has always been intended for reducing data containing bright extended sources. It has remained untouched for a couple of years now despite advances in our understanding of SCUBA-2 reduction of bright regions. The config file now contains the following parameters/links:

   ^$STARLINK_DIR/share/smurf/dimmconfig.lis

   numiter=-40
   flt.filt_edge_largescale=480
   ast.zero_snr = 3
   ast.zero_snrlo = 2

   ast.skip = 5
   flt.zero_snr = 5
   flt.zero_snrlo = 3

In previous Starlink releases i.e. Hikianalia, the bright_extended configuration file only contained the following:

   numiter = -40
   ast.zero_snr = 5

   flt.filt_edge_largescale = 600

New 'FIX' config file

Two new config parameter files have been added These are intended to be used with one of the existing dimmconfig files. They provide new values for selected parameters aimed at solving a particular problem ("blobs" in the final map, or very slow convergence).

• dimmconfig_fix_blobs.lis 
• These parameters attempt to prevent smooth bright blobs of emission appearing in the final map. It does this by 1) identifying and flagging samples that appear to suffer from ringing a soft-edged Butterworth filter in place of the normal hard-edged filter, and 3) rejecting samples for which the separate sub-arrays see a markedly different common-mode signal.

• dimmconfig_fix_convergence.lis
• The parameters defined by this file attempt to aid the convergence process, and should be used for maps that will not converge within a reasonable number of iterations.

Spotting chunking caused by insufficient memory

It has been shown that better maps are created if all available time stream data are processed in a single chunk to create a single map. If the available memory is too small to allow this to happen, the data will be split into multiple chunks and a separate map made from each chunk, which are all co-added at the end to make the final map.

Thus it can be important to spot whether or not your map was "chunked" or not. Until recently the only option was to trawl through the makemap screen output looking for the warning about insufficient memory. Now, however, you also have an option to tell makemap to abort immediately with an informative error message if the data would be chunked due to insufficient memory (no output map is created in this case). To do this, add "memcheck=1" to your config.

Note, this only affects what happens if the data is processed in chunks due to lack of memory - if chunking is caused by the time-series data being intrinsically discontiguous then a map is still created even if memcheck is set to 1.

It will be necessary to rsync the stardev system from Hilo to use this feature. See starlink.jach.hawaii.edu/starlink/rsyncStarlink

Calibrating SCUBA-2 data in surface brightness units

In most cases the default calibration for SCUBA-2 data processed by the ORAC-DR pipeline is mJy beam^-1. The exception is the recipe for extended sources, REDUCE_SCAN_EXTENDED_SOURCES, which calibrates data in mJy arcsec^-2.

Unfortunately there was an error in an earlier version of this recipe which meant that the FCF was applied incorrectly. The corrected method is available now with an update of ORAC-DR (either from github or via rsync from JAC). If you have data processed with this recipe (either by running it yourself, or downloading processed products from CADC) then re-calibrating the data is easy: simply divide by the pixel area using KAPPA cdiv.

There is a new PICARD recipe for easy calibration of maps produced by running makemap by hand. CALIBRATE_SCUBA2_DATA allows data to be calibrated in in per-beam and surface brightness units. With no parameters, this recipe will calibrate data in mJy beam^-1. For surface brightness calibration, set the recipe parameter USEFCF to 1 and FCF_CALTYPE to ARCSEC, and the recipe will then use the default ARCSEC FCF for the wavelength of the given data.

The recipe can also convert the calibration from one type to another. If your data are already calibrated in mJy beam^-1, they can be given to CALIBRATE_SCUBA2_DATA with the FCF_CALTYPE recipe parameter above, and the recipe will create a new file (with suffix _cal) with units of mJy arcsec^-2. The value and units of the FCF are written into the FITS header of the calibrated file.

The companion recipe, UNCALIBRATE_SCUBA2_DATA, will undo the current calibration, reverting the units to pW in the output file (which has a suffix of _uncal).

Using ORAC-DR or PICARD to perform the (un)calibration is preferred to simply multiplying your data by the FCF as they also set the units correctly for the output files(s), and write the value of the FCF used into the FITS header of the file.

However, there is one note to highlight: the recommended way to calibrate data (either from raw or when changing from per beam to per square-arcsec) is to calibrate the individual observations first, and then coadd those (re)calibrated files. Calibrating or re-calibrating coadds will fail because the coadding step was recently updated to remove FITS header entries that differ between the input files. These usually include the UTDATE which is used by the ORAC-DR calibration system. A future upgrade will provide a workaround though the recommendation to calibrate individual observations stands.