MOPEX Online Manual

Which Modules Should I Choose?

When running MOPEX, each data reduction step should be tailored to the dataset. The user does this by selecting certain modules to run, and setting the input parameters for those modules. The number of modules and parameters in MOPEX can be a little daunting, so here we give a short introduction to the most-used modules. Detailed descriptions of the modules can be found later in the manual.

First-time users should with the example namelists found in the directory <mopex_dir>/cdf/, also available from the main MOPEX webpage, rather than trying to build up the flow in an empty namelist. These examples are intended only as guides. With experience, you will be able to turn on/off modules as needed and tune the input parameters for specific purposes. MOPEX typically saves the results from each module in <output-dir>. These intermediate results can be examined to evaluate the performance at each step.

For data reduction walk-throughs, including more advice on options to use with different data sets, see the Data Reduction Cookbooks. We stress that these are not exhaustive, and are continually being developed.

Background Matching (overlap.pl)

The Overlap script performs background matching on the input images. It does not set the background level to zero, rather it adds (or subtracts) a constant to bring it to an average level. This process is recommended for Spitzer data, as there can be variation in the sky level which will lead to a patchy-looking final mosaic if not corrected. The process may not be necessary if the BCDs downloaded from the Spitzer archive have been background-subtracted by the user (with, for example, a median sky) before using MOPEX.

The modules required for Overlap are:

Fiducial Image Frame (unless the file FIF.tbl already exists)

Mosaic Interpolate

Compute Overlap Correction

If there are bright objects in the field that could affect the estimate of the background level, MedFilter and Detect should be added. The namelist flag 'mask_bright = 1' should be set. Together, these will detect and ignore bright objects when calculating background levels.

Make sure to set the "apply_overlap_correction" option in the Overlap namelist to apply the correction to your input images. Overlap-corrected images can be used as the input to the mosaicker.

Mosaic (mosaic.pl)

The Mosaic flow has the largest number of modules to choose from, due to the many outlier detection options. While some outliers are flagged during the Spitzer pipeline processing (run by the SSC to produce the BCDs that you download from the archive), further rejection is recommended.

The basic mosaicking modules that you need, not including outlier rejection, are:

Fiducial Image Frame

Mosaic Interpolate

Mosaic CoAdder

Mosaic Combiner

Mosaic Coverage

Mosaic RMask

Mosaic Reinterpolate

Choosing the right kind of outlier rejection also requires some care. Rejection schemes utilize either temporal information (rejecting sources that don't appear at the same coordinates in every frame) or spatial information (rejecting outliers based on their shape or size), or both. In the case of good coverage per pixel (about 10 or more BCDs per pixel on the sky), temporal outlier rejection can be a good choice. To add temporal outlier rejection, use the Mosaic Outlier module. When using temporal outlier rejection, be careful when setting the rejection thresholds. A three sigma rejection is often too low if the coverage is very high (50 or more). If only shallow coverage is available, then either the box outlier rejection (include module Mosaic Box Outlier) or dual spatial-temporal outlier rejection are preferred. Dual outlier rejection requires the following modules:

MedFilter

Detect

Mosaic projection

Mosaic Dual Outlier

Level

Multiple outlier rejection methods can be employed, and all can be set to contribute to the RMask by setting the RMask Fatal Bit Pattern. The RMask module can also use the dual outlier rejection results as a check on the temporal outlier identifications (set the "refine_outlier" flag in the Mosaic namelist). This combination can be useful to prevent the false identification of temporal outliers inside bright sources.

The Mosaic pipeline can produce a number of final outputs. The most basic output files that you will need are the mosaic and its coverage map and uncertainty file (mosaic.fits, mosaic_cov.fits, and mosaic_unc.fits). For more options, see the Mosaic Pipeline pages.

APEX One Frame (apex_1frame.pl)

Source extraction can be performed on the mosaic image using APEX single frame mode. This takes a single image (together with an optional coverage map and optional unertainty file) as input. It can be used independently or as a follow-on to the Mosaic pipeline.

APEX peforms background subtraction (Detect MedFilter and Extract MedFilter), noise estimation (Gaussnoise), non-linear filtering (Point Source Probability), point source detection (Detect), point source fitting and flux estimation (Source Estimate) and aperture photometry (Aperture). If an uncertainty mosaic is available, Fit Radius can be run to define the fitting area based on source brightness above the noise. Setting Fitting_Area_X,Y in the Sourcestimate block is the other method of defining a fitting area (and this will override the use of Fit Radius results). Compared to the Mosaic pipeline, there are fewer module choices in APEX One Frame, so it is a little easier to use.

The output of APEX is the table of extracted sources (extract.tbl), which gives the position and flux for each object.

APEX MultiFrame (apex.pl)

Source extraction can also be performed in multiframe mode. In this case, sources are detected in the mosaic but PRF-fitting is performed simultaneously on the individual BCDs (after geometric distortion correction); aperture photometry is still performed on the mosaic.The major advantage over apex_1frame is seen in data with intra-pixel variability (e.g. IRAC data). APEX multiframe uses all of the same modules as the single frame mode, but can also optionally create the mosaic as well, with the following:

Fiducial Image Frame

Mosaic Interpolate

Mosaic CoAdder

Mosaic Combiner

The downside to having APEX create the mosaic is that it cannot do outlier rejection. Most users prefer to make their own mosaic beforehand with mosaic.pl, or the GUI. In command-line, set the output directory to be the same for the Mosaic and APEX flows so that APEX picks up the mosaics. Turn off the above modules in APEX - apex.pl will automatically get the files it needs. In the GUI, just append the APEX flow to the Mosaic flow, using "Insert Apex MultiFrame", and remove the above modules.

Residual Image Creation (apex_qa.pl)

The APEX QA flow takes in the list of detected point sources from APEX and subtracts them from the original input image(s) to create the residual image. This is invaluable for testing how well the PRF-fitting is performing. The input and output files depend on whether the flow is being run on a stack of images (when using it with apex.pl) or on a single mosaic image (when working with apex_1frame.pl). The APEX introduction page lists the input requirements.

There is basically only one module available in APEX QA, called Point Source Image, which is used here for point source subtraction. However, to make mosaics of the source-subtracted frames in the multi-frame case, you must turn on the namelist triggers mosaic_residual_images, run_mosaic_interp, run_mosaic_coadder and run_mosaic_combiner. The Mosaic Interpolate and Mosaic Coadd modules require parameter blocks in the namelist, but these can be empty if the default parameters are acceptable.

PRF Estimate (prf_estimate.pl)

For most users, the PRFs that are distributed with MOPEX will be suitable for their needs. Some users, however, may wish to generate custom PRFs from their data using the PRF Estimate flow. Note that this flow is not for use with IRAC data, or any other undersampled data. There are four modules, and all are required except Split By Array Position.