Smurf has the capability to produce simulated data from SCUBA-2 with the sc2sim task. The simulator samples an input astronomical image in the presence of a model atmosphere and other sources of noise. Output files are written in the same format as real data from SCUBA-2 with complete flatfield, WVM, WCS and JCMT state structure information. These files can be processed with other Smurf tasks. Model atmospheres may be generated with the skynoise task.
The simulator supports the primary observing modes: DREAM, STARE and SCAN along with FLATFIELD, POINTING and FOCUS observations. Rudimentary support exists for the SCUBA-2 polarimeter though this is untested. Instrument apertures may be set (offsets which adjust the tracking position to a specific sub-array), and microsteps (small offsets from the tracking position) are fully supported. Simulating the motion of the major Solar System bodies (Venus, the Moon, Mars, Jupiter, Saturn, Uranus and Neptune) is supported.
For SCAN observations, the simulator has two modes controlled by the SIMTYPE parameter. A FULL
simulation generates simulated complete astronomical data including the effect of the atmosphere. A
WEIGHTS simulation generates data which may be used to assess areal coverage and ‘hit’ density
(i.e. the number of times a point on the sky is observed) for different mapping strategies or
the impact of non-working bolometers. Several different scanning models are supported:
boustrophedon (conventional back-and-forth raster scan), two variations of ‘pong’ (or box-scan)
with either sharp or gentle turnarounds and a lissajous pattern. [REF TO ANA SCAN
DOC]
The simulator requires some preparatory work before data can be simulated. The basic procedure is outlined below:
It is not necessary to recalculate a model atmosphere or flatfield solution for every simulation, even for different input sky images.
Example files are installed as part of Smurf and may be found in the $STARLINK_DIR/share/smurf
directory. An explanation may be found in the README file in that directory.
The astronomical image may be any suitable image, provided it has WCS information. It should be as large as the size of the map to be made. The WCS is used unless the source is a moving object (listed above). The image must be an NDF. It is recommended that the image pixel scale be set to be much less than the likely output map pixel spacing (typically 3 arcsec at 850 m, 1 arcsec at 450 m) to avoid imaging and sampling artefacts.
The model atmosphere is calculated with the skynoise task. The atmosphere is modelled as a Kolmogorov turbulent thin-screen [11] with a characteristic turnover frequency and scaling law. Different models may be generated for the same parameters using a random number seed (specified or calculated internally using the system clock). The parameters may be modified though the user should be familiar with the details of this model of the atmosphere before exploring the parameter space too widely.
The model atmosphere calculated is generic and may be used for simulations at both 850 m and 450 m. The model is scaled at the time of simulation according to the particular wavelength.
Before a data simulation can take place, the flatfield solution for each sub-array must be calculated.
This is achieved by specifying a special observing mode called heatrun and running a
simulation.
The flatfield solution is written to a file using a naming scheme which follows that for raw data. The convention is s[4|8][a-d]heatYYYYMMDD_NNNNN.sdf where s[4|8][a-d] is the sub-array name (e.g. s8a), heat indicates a flatfield observation, YYYYMMDD is the date of observation and NNNNN is a zero-padded, 5-digit observation number.
The simulator relies on this naming scheme for reading the flatfield information, and the files must be present in the current directory.
The simulator has a large number of parameters which may be freely adjusted. The list of parameters
is divided between two groups: simulation parameters (usually telescope- and instrument-specific);
and observation parameters (properties of the observation in question). These are specified using the
SIMPAR and OBSPAR ADAM parameters to sc2sim. For convenience, the parameters are stored in plain
text files and are passed in using the ^ scheme mentioned above in Section 1.2.5. Example
input files for all major observing modes may be found in the $STARLINK_DIR/share/smurf
directory.
The main observation parameters (OBSPAR) of interest are the RA/Dec of the source, wavelength,
observing mode (obsmode), observation date and duration of observation (which in the case of SCAN
observations, is determined by the size of the area to map). Planets may be specified by name.
The RA/Dec must match that in the astronomical image. If the source is not above the
horizon, the simulator will exit with an error message. The date must be specified as a UT
modified Julian day number. As a point of reference, 20090701T00:00:00 corresponds to MJD
55013.
The main simulation parameters (SIMPAR) are the sub-arrays to simulate data for, the names of the
atmosphere model and astronomical source files and the zenith opacity (at 225 GHz). The
zenith opacty is converted to a value at the appropriate wavelength using the empirical
relations derived for SCUBA by Archibald et al. (2002). Similar relations for SCUBA-2 will be
derived.
Data for all sub-arrays (at the specified wavelength) may be generated in a single run. The size of the
output files is governed by the MAXWRITE parameter for sc2sim which specifies the number of samples
to write per file. Multiple observations may be simulated by setting the OVERWRITE parameter to FALSE
(the default behaviour is to overwrite existing files).
A word of caution. Since the data output from the simulator mimics the real instrument, it is possible
to generate many GB of data which may take many minutes to hours of CPU time. The
sc2sim parameter SIMSTATS tells the simulator to estimate the properties of the simulation including
the duration of the simulation, quantity of data, memory requirements and CPU time. The
results are printed to the screen, allowing the user to modify the simulation parameters if
necessary.
For STARE simulations, the images are calculated at 1-second intervals at the time the simulator is run and written to the output files. For DREAM the images must be reconstructed after the simulation has run. This means that the DREAM weights file must be calculated using dreamweights as desribed in Section F.0.7. Likewise, the images are calculated using dreamsolve.
The processing of simulated data proceeds exactly as for real SCUBA-2 data and depends on the observing mode. See the respective workflows in Sections F and 3.3 above. Note that dark frames are not produced by the simulator and do not need to be included in any processing (there is no drift in the model bolometer response).
FOCUS observations are designed to be processed by the Orac-dr pipeline rather than Smurf, as their analysis involves multiple steps. POINTING observations are equivalent to short science observations and should be processed in the same way.