Rather than cleaning the data by hand and then re-gridding it all at the end, we can instead do everything at once using the Smurf Dynamic Iterative Map-Maker (DIMM).
The DIMM is enabled using the
method=iterate switch to the makemap task. In the following
example we will produce a map of Uranus using the test data supplied with this Starlink distribution.
All of the settings for the DIMM are stored in configuration files. In this example we will use one of
the examples that are installed in the Starlink tree, ‘
dimmconfig.lis’. For an overview of the different
default configuration files available see Section 4.1. The parameters are also fully described in the
or the config files themselves. A local copy can be made and altered if desired. The following
command invokes the DIMM to produce the image shown in Fig. 9 with 2 arcsec pixels:
This excerpt shows the initial output of the DIMM. Note that the basic dimensions of the
data being processed are listed near the start of the first iteration, as well as the QUALITY
flagging statistics. This report is similar to that produced by the Kappa task showqual in
Section 3.7. At the beginning, the main purpose is to indicate how many bolometers are being
used: 368 bolometers were turned off during data acquisition (
BADDA); and 40 bolometers
exceeded the acceptable noise threshold (
NOISE). There were also small numbers of samples
flagged as containing spikes and jumps. The total number of bad bolometers (
413. Accounting for these, and the small numbers of additionally flagged samples,
effective bolometers are available at the start of the first iteration.
After each subsequent iteration a new QUALITY report is produced, indicating how the flags have
changed. An important flag that appears in the QUALITY report following the first iteration is
the DIMM rejects bolometers (or portions of their time series) if they differ significantly from the
common-mode (average) of the remaining bolometers. Another useful quantity reported is
CHISQUARED – the RMS of the residual (time series with the various model components
removed) for all of the samples with good QUALITY, normalized by the measured white noise
This particular configuration executes a maximum of 5 iterations, but stops sooner if the
CHISQUARED is less then 0.001. In this case, it reaches this stopping criterion after 5
Note that compared to the initial report, the total number of samples with good QUALITY (
samples available for map) has dropped from 10402995 to 10010475 (about a 4 per cent decrease) as
additional samples were flagged in each iteration.
The iterative map-maker estimates several components of the bolometer signal in addition to the
astronomical signal that goes into the map. The particular sequence of components that it fits is
modelorder in the configuration file. All of the examples provided with Smurf are
$STARLINK_DIR/share/smurf/dimmconfig.lis, and we show the relevant excerpt
By default, the final values of these fitted models are not written to files. However, this can be
modified by setting
exportndf in the configuration file to the list of models that you wish to
If we make a local copy of
dimmconfig.lis, add the above
exportndf line, and re-run the iterative
map-maker with this modified configuration, it now produces several new files at the
Note that the quality and variance for the data are stored as the VARIANCE and QUALITY components within the residual file NDF.
As with the input data, these are all standard Starlink NDF files which can be examined using all of
the existing tools, and can be used by other Smurf routines such as sc2clean, sc2fft, and makemap.
The base of the filenames is the first input file that went into the maps for each subarray, and the ‘
suffix indicates that several data files may have been concatenated together. The new files
*ast.sdf’, the time-domain projection of the astronomical signal as estimated in the
final map (same dimensions as the input bolometer data); ‘
*com.sdf’, an estimate of the
common-mode signal (predominantly sky emission and fridge temperature variations); ‘
additional noise (low-frequency noise in this particular case) that was filtered out of each
bolometer (same dimensions as the input bolometer data); and finally ‘
*res.sdf’, the residual
bolometer signal once the other components have been subtracted from the original data, which
should look predominantly like white noise (again, same dimensions as the input bolometer
Time traces for a single bolometer are compared for all of these model components in Fig. 10. Uranus is clearly seen as a positive spike in the astronomical signal component. The common-mode signal is the next largest, clearly exhibiting the 30 s fridge variations that are apparent in the raw data. The residual noise removed by the high-pass filter is significant, but much smaller than the common-mode component. Finally, the residual signal is quite flat, indicating that most of the signal has been accounted for in the other model components.
Since the DIMM has a large number of parameters, several configuration files are supplied with
Smurf for reducing common types of data. All of these files can be found in
$STARLINK_DIR/share/smurf/ with filenames of the form
dimmconfig*.lis. The default
dimmconfig.lis should give reasonable results for most observations. Note that this file also contains
the full set of parameters with extensive documentation. For clarity, all of the other configuration files
for specific observations types are derived from
dimmconfig.lis and simply override the relevant
While we have tested a wide variety of data sets with these files, it is certainly worth trying at least the default, and the specific configuration that sounds like it would be appropriate for your project:
noiseclipparameter), and the mean levels are subtracted. This default configuration solves for the following models:
NOI. The components
GAIwork together to calculate the average signal template of all the bolometers, and then fit/remove the templates from each bolometer. They also identify outlier bolometers that do not resemble the template and remove them from the final solution. The component
EXTapplies the extinction correction (derived from the water-vapour radiometer by default), and then
FLTapplies a high-pass filter to the data, above frequencies that correspond to angular scales of 600 arcsec and 300 arcsec at 450 m and 850 m, respectively (as established automatically from the mean slew speed of the scan). These cutoff frequencies were chosen through trial and error, but appear to give good results under a wide variety of situations. Finally,
ASTestimates the astronomical signal contribution to the bolometer signals from the current map estimate, and
NOImeasures the noise in the residual signals for each bolometer to establish weights for the data as they are placed into the map in subsequent iterations.
FLT), which can result in convergence problems when there is little signal in the map, a single, harsher high-pass filter is applied as a pre-processing step (corresponding to 200 arcsec scales at both 450 m and 850 m). There are also more conservative cuts to remove noisy/problematic bolometers. Finally, the parameters
ast.zero_notlastare set to constrain much of the map to precisely zero for all but the last of 5 iterations. This helps with map convergence, and is a reasonable prior for a blank-field. Normally the map would then be processed using a matched filter (see Section 6.1).
dimmconfig_bright.lis. The addition of
ast.zero_notlastparameters are used to constrain the map to zero beyond a radius of 1 arcmin for all but the final iteration. This strategy helps with map convergence significantly, and can provide good maps of bright sources, even in cases where scan patterns failed and the telescope degenerated into scanning back-and-forth along a single position angle on the sky.
ast.zero_snris used to constrain the map to zero wherever the S/N is lower than 5-. We recommend setting the parameter
itermap=1, and then visually inspecting the maps produced after each iteration (e.g.,
gaia map.more.smurf.itermaps) to help determine an appropriate number of iterations.
If you want to modify parameters for a particular config file the best approach is to create a new file
and first include a directive to load the file you want to modify and then supply your own parameters.
You can see this technique is used in the installed configuration files to reference them all to