A variety of simple Picard recipes (see SUN/265) exist to perform post-processing analysis.
SCUBA-2 specific Picard recipes begin with or contain the word SCUBA2; recipes specific to processing
JCMT data contain JCMT. Documentation for each recipe is given in SUN/265, and on the
Picard home page, http://www.oracdr.org/oracdr/PICARD where each recipe is fully
documented.
Running Picard is simple. For example:
where <recipe_param_file> is a text file containing the relevant recipe parameters, RECIPE is the name of the recipe to run and <list_of_files> is the list of NDF files to process, which must exist in the current directory. The output files are written to the current directory, or the directory defined by ORAC_DATA_OUT.
Most recipes have one or more recipe parameters which can be specified using the -recpars option.
Recipe parameters are given in a text file with the following format:
The available recipe parameters are listed in the documentation on the Picard home page above and in SUN/265.
The recommended approach for a few common tasks is detailed below.
Although the pipeline will mosaic observations of the same target from the same night, it is clearly desirable to combine data from multiple nights. Alternatively, the user may wish to exert some additional control over the mosaicking parameters.
The MOSAIC_JCMT_IMAGES recipe deals with processed JCMT data (including ACSIS data cubes) and takes into account the instrument-specific NDF components such as the exposure time (EXP_TIME). The choice of coadding task is left to the user and may be either Ccdpack makemos or Kappa wcsmosaic (the default). If using makemos, images are first aligned using Kappa wcsalign. By default, the images (and additional NDF components) are combined using a nearest-neighbour scheme but this may be overridden by specifying the relevant parameter for wcsmosaic or wcsalign.
The output mosaic takes its name from the last input file in the list and has the suffix _mos. The user should take care to ensure this file does not already exist otherwise it will be overwritten.
Random pointing offsets and drifts between observations on a given night (and over different nights) mean that the final mosaic of a point source will not be optimal, and any faint surrounding structure may be masked entirely.
The recipe SCUBA2_REGISTER_IMAGES is specific to SCUBA-2 data. The approach is to find the position of a given source in each image and apply a shift to the WCS so that the peak fitted positions are coincident for each image. If a suitable source exists in each image, this recipe should be used before mosaicking (above).
Several recipe parameters are required, namely the coordinates of the reference position. Currently only equatorial coordinates are supported and must be written in sexagesimal format. The registered images have the suffix _reg.
As with the mosaicking recipe, this recipe knows about and takes care of applying the same shift to the EXP_TIME and WEIGHTS (and NEFD if it exists) components, so the combined results are accurate.
A Picard recipe called SCUBA2_CHECK_RMS exists for making the same assessments as the Orac-dr recipe REDUCE_SCAN_CHECKRMS. However it should be noted that this recipe should be run only on maps created from individual observations: it will not give the correct answer for coadds. This is because the coadds do not preserve the elapsed time, which makes it impossible to use the SCUBA-2 integration time calculator (ITC).
A minor difference is that, with the exception of running at EAO, it is not possible to determine NEP-based results. However, these are generally less useful for comparing with the ITC.
The recipe produces the same output log file, log.checkrms with the identical format. In order to
calculate the NEFD, this recipe will also create an NEFD image within the given map unless one exists
already.