B Notes on Shared Risk Observing

B.1 S2SRO FCFs

Calibration observations were undertaken on a series of secondary calibrators, which are listed with their SCUBA fluxes in Table 1. The data for the FCF calculations were taken between the 23rd of February and the 14th of March, 2010.

The observations were reduced with the mapmaker using the config dimmconfig_bright_compact.lis and post-processed with the Picard recipe SCUBA2_FCFNEFD. Figure 29 shows the 850 $\mu$m and 450 $\mu$m $\mathrm{FC<msub><mrow>F</mrow><mrow>beamequiv</mrow></msub>}$ values for all calibrator observations taken during the S2SRO period. The resulting mean FCF’s in each waveband are as follows:

Figure 29: Histograms of the 450 $\mu$m (left) and 850 $\mu$m (right) $\mathrm{FC<msub><mrow>F</mrow><mrow>beamequiv</mrow></msub>}$ values calculated for the secondary calibrators observed during the S2SRO period.

The first note regarding the FCF’s produced by the current reduction is in regard to the picowatt (pW) scale produced by the mapmaker. The pW scale is dependent on the accuracy of the heater resistance and the fraction of the heater power which is transferred to the bolometer. At the time of data release, the effective resistance was not well described, which induces an uncertainty in the pW scale of the resultant maps. This resistor value, and therefore the absolute pW scale, will be determined accurately when the instrument is returned to operation, and when this is known the new values will be added to the reduction code. This will affect the pW values of all observations, and the corresponding FCFs. However, the flux scaling will be preserved. The FCF values above have been calculated with the original pW scale.

Secondly, it is obvious that there is a large scatter in the FCFs in Figure 29. It is possible that the variation in the FCFs is produced by instrument performance changes or inconsistencies in the way the map-maker reduces the observations. At the time of release, the source of the scatter was not well understood and investigation continues. However, it is worth noting that the scatter between calibrations in an individual night of observations was sometimes observed to be as high as the scatter over the entire dataset. No trends were observed as a function of atmospheric transmission, or time during the night, or over the entire observing period. It is for this reason that it is advised that the average FCF values above are used, as opposed to selecting individual calibrations and using that FCF to calibrate your data.

B.2 Method for calibrating your data

It is the recommendation to use the mean $\mathrm{FC<msub><mrow>F</mrow><mrow>beamequiv</mrow></msub>}$ values presented in the previous section to calibrate your data. However, if it is desired to produce an individual FCF from the night of a particular set of science observations, then the method is described here.

(1)

Reduce the selected calibration observation using the dimmconfig_bright_compact.lis config file.

(2)

Use Picard’s recipe SCUBA2_FCFNEFD on your reduced calibration observation. This will produce information to the screen and a logfile log.fcfnefd with the FCFs as mentioned above, and an NEFD for the observation. Picard by default uses fixed FCF’s to calculate the NEFD. (450 $\mu$m: 400 Jy/beam/pW and 850 $\mu$m: 500 Jy/beam/pW). If you wish to get an NEFD using the FCF calculated for the individual calibrator you are reducing, add USEFCF=1 to your parameter file.

(3)

Take your selected FCF and multiply your map by it using Kappa cmult.

B.3 Significant Events

Part of the risk in S2SRO was that the instrument was being commissioned in parallel to being used for science observations. During February and March 2010 a number of events occurred that will possibly affect the data quality in a good or a bad way. This section documents these changes to aid in interpreting unexpected results that may come out of the data reduction process.

Note: all dates listed below are UT and are inclusive, and although setup changes should not affect the calibration they will affect the number and quality of functioning bolometers.

B.3.1 Data Files

Up to 20100219 the first and last file in a scan are dark frames for science, pointing⁹ and focus observations. From 20100220 to 20100302 the first and last file are fast flatfield ramps. From 20100303 the first file is a dark frame and the second and last file are fast ramps. Note noise and discrete flat fields are different.

B.3.2 Flatfields

Beginning of S2SRO – 20100211

Until scan #17 on 20100211 discrete flatfields were reduced using the TABLE method.

20100211 – End of S2SRO

From scan #18 on 20100211 discrete flatfields were reduced using the POLYNOMIAL meth. Note: the stand alone flatfield observations are not used after the fast ramp flatfield was implemented 20100223. The fast flatfields are done as part of the observations.

20100213 – 20100215

Until scan #45 the heater step in the discrete flatfield was smaller leading to failure of the flatfield on the sky, particular at 450. Hence a lot of the flatfields on these dates were in the dark. This means less accurate flatfields.

20100220 – 20100222

Fast ramp flatfield used implemented but done in the dark. Smurf uses the discrete flatfields for these dates.

20100223 – 20100302

Fast ramp flatfield on the sky. Note: on 20100223 the data header claims the ramp was in the dark but from notes and the heater value it was on the sky i.e. the dark shutter header was wrong this night. Smurf knows about this and uses the fast ramp flatfield.

20100303 – end of S2SRO

Fast ramp flatfield used with an initial dark in the observations. This dark was used as a sanity check and is not used by the map-maker.

Explanatory Notes:

• Discrete flatfields step through a number of heater values rather slowly. The slow speed make the flatfield accuracy and quality susceptible to thermal drifts, 1/f noise and weather changes. Discrete flatfields were used for flatfielding until 20100223. Thereafter fast flatfield ramps are done at the start and end of every science observation.
• Fast ramp flatfield uses a fast heater ramp repeated several times - this improves the flatfield accuracy and quality.
• TABLE and POLYNOMIAL are two reduction methods used for discrete flatfields (fast ramp always uses a polynomial method). Due to the lack of dark frame subtraction the TABLE flatfield only used 2 points of the $\sim$10 heater settings in a discrete flatfield. Further, the slope from these two points were extrapolated far away. Obviously this affects the flatfield accuracy and quality. The flat field calculation should be redone using the POLYNOMIAL method for data taken before 20100211¹⁰.

B.3.3 Setup

20100216 – 20100218

s4a detector bias set to 40000 - during the S2SRO the normal s4a value was 65000.

20100304 – end of S2SRO

The heater tracking was changed such that the heater is returned to the default value each time the shutter was closed. This was done to prevents drifts in the heater setting. Such drift affect the setup. However, noise observations also reset the heater. Thus the heater drift before this adjustment were small and is not believed to have affected the data.

B.3.4 Electronics

Beginning of S2SRO – 20100217

A large number of spikes are present in the s4a array data.

20100218 – end of S2SRO

The MCE was changed on the s4a array significantly decreasing the number of spikes in the s4a data.

B.3.5 Weather

20100310

Very bad seeing: data severely affected

20100311 early evening

Bad seeing: data affected

B.3.6 Telescope

early commissioning – 20091202

For early commissioning data it was found that one of the mirrors was installed upside down leading to a slightly distorted beam shape. This was fixed from 20091203 so care should be taken when analysing very early commissioning data found in the archive before that date.

Beginning of S2SRO – 20100225

A two component pointing model (utilising only the CA and IE terms) was used, leading to large pointing shifts when doing large slews. On 20100226 the full eight component model was implemented and all-sky pointing improved. This should not affect data quality significantly since local pointing would still be adequate even with the earlier model.