### H SCUBA-2 Simulator

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]

#### H.1 Simulator workflow

The simulator requires some preparatory work before data can be simulated. The basic procedure is outlined below:

• Obtain an astronomical sky image;
• Calculate a model atmosphere;
• Calculate a flatfield solution;
• Decide on simulation parameters;
• Run simulation.

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. ##### H.1.1 Astronomical image 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 $\mu$m, 1 arcsec at 450 $\mu$m) to avoid imaging and sampling artefacts. ##### H.1.2 Model atmosphere 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 $\mu$m and 450 $\mu$m. The model is scaled at the time of simulation according to the particular wavelength. ##### H.1.3 Flatfield simulation 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. ##### H.1.4 Running the simulator 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.

##### H.1.5 A note on DREAM simulations

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.

#### H.2 Processing simulated data

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.