ULTRACAM calibration information page

The purpose of this page is to to provide information upon extinction, zeropoints and conditions on the various ULTRACAM nights and other calibration information. I also provide tips on 'best practice'. Ultimately I hope to add stuff about colour transformations. If anyone has computed such information please send it to me.

ULTRACAM zero-points and extinction

The zeropoints are calculated as magnitudes at zero airmass unless otherwise stated. Extinction is in mags/airmass.

DateZeropointsExtinctionGainDate addedWhoComments
21 May 2003 i'=26.25, g'=27.03, u'=25.18 (PG1047+003A)
i'=26.13, g'=26.90, u'=24.79 (SA 113-339)
i'=0.22, g'=0.32, u'=0.64 Unknown 16 June 2004 TRM Extinction coefficients determined from NN Ser data from this night. The data range in airmass from 1.1 to 1.5 but there are clear changes in the extinction above just increasing airmass. In particular I suspect that the extinction may have increased fairly early in the night so that SA113-339 is better overall than PG1047+003A although possibly rather low in u'.
23 May 2003 i'=0.17, g'=0.28, u'=0.72 Unknown 15 June 2004 TRM Extinction coefficients determined from V407 Vul data from this night. However the night was not very photometric so these should be not be taken too seriously.
10 November 2003 r'=26.44, g'=26.87, u'=24.99 r'=0.091, g'=0.169, u'=0.480 Unknown 05 May 2004 TRM Standard star SA100-280, run026 at the end of the night. Star observed at airmass 1.148. Mags from Smith et al (2002) r'=11.689, g'=11.997, u'=13.140. Conditions of night were good apart from rather erratic seeing. The extinction coefficients here are assumed, not measured from this night, so these values may need updating. The counts on the standard were measured through an aperture size of 17 pixels with sky radii of 18 and 28.
02 March 2006 r'=26.410, g'=26.895, u'=25.051 r'=0.069, g'=0.161, u'=0.485 24 Jan 2007 TRM Average of standard stars Ru 152 and BD+33 at start and end of night. Weather was clear. Extinction coefficients determined from long runs on SDSS0926, using the main comparison star. Zero-points referenced to 0 airmass. Two stars differed by 0.016, 0.009 and 0.008 mags in r,g,u. I have been quite careful with this.

Bias frames

Bias frames should be computed by using the 'combine' program with the bias option. You need a large number to ensure that you do not add significant amounts of noise. For large numbers, the clipped mean combination is a good choice. The median should be avoided as it digitises to an integral number which is effectively noise that can more than offset the advantage of using a large number of frames.

There are now many pre-computed bias frames available so you may not have to make them up yourself. I recommend looking at these which have been calculated taking some care to avoid problem data.

Dark frames

Dark frames seem to be difficult. The general background dark current is quite low and no problem, but there are sometimes a number of fairly hot pixel and one very hot pixel at (423,902) on the UV CCD. However, the key word here is 'sometimes' as this does not seem to be repeatable. It should be said that one can only get decent dark frames at night with a dark dome, which requires poor weather.

I expect to compile best darks here.

Flat fields

The key thing to watch for in the flat fields (and normal observations) is the peppering effect which appears at high count levels, especially in the centre of the chips. This effect is much more significant for the green and UV CCDs than it is for the red one. The program 'makeflat' allows for this with the specification of a maximum mean level in bias subtraction frames. I suggest the following values for this maximum (before bias subtraction) for the red, green and UV chips respectively: 50,000, 31,000, 27,000. However, you should note that these values may depend upon the readout speed used. These ones were determined from the May 2004 run.

Another problem to watch for in flats is the very last frame of a run. Depending upon just when the exposures were terminated, this may end up with a mean level that is OK and yet be complete rubbish. Therefore I would advise that you always discard the last exposure of flat field runs.

'makeflat' works by first combining small groups of similar mean level and then adding all the results. The initial combination is supposed to remove cosmic rays and stars. I average in groups of a few, e.g. 7. For small numbers like these, 'median' combination is to be preferred. This is because a large deviation increases the estimated RMS so much that it is not then registered as being a large deviation.

You should subtract both the bias and a correctly scaled dark frame from all of the flat fields before combining them with makeflat. It may not always be safe to assume that the dark current can be ignored since you may end up using many fairly faint flats. So assuming that one had a 16 second dark and a set of 1 second flats, then the following sequence of commands would be what is wanted:

cdiv dark 16 junk
add junk bias junk
msub flat.lis junk no
makeflat flat.lis
You would be prompted for more inputs for 'makeflat'.

Noise parameters

You can investigate the readout and gain of the chips using 'ncal'. You basically form lists of bias subtracted and flat-fielded frames (not dark subtracted hence they are best if they are quite short exposures), a set of windows to define the region, and off you go. These may vary with time, and the readout mode, but here are example plots and values that I have derived. Note that ncal performs a local analysis and is rather insensitive to pickup noise which could nevertheless effectively add noise when integrated over apertures. Not that much can be done about this I'm afraid.

CCDDateComments
Left half of red CCD 19 May 2004 Noise estimated from many runs. Model, readout noise = 3.15, gain=1.17. At high counts the noise is less than it should be which is probably because these frames contributed significantly to the flat field.
Right half of red CCD 19 May 2004 Noise estimated from many runs. Model, readout noise = 3.10, gain=1.20. At high counts the noise is less than it should be which is probably because these frames contributed significantly to the flat field.
Left half of green CCD 19 May 2004 Noise estimated from many runs. Model, readout noise = 3.20, gain=1.10. Note the effect of peppering which switches on at 30,000 counts (after bias subtraction).
Right half of green CCD 19 May 2004 Noise estimated from many runs. Model, readout noise = 3.40, gain=1.13. Note the effect of peppering which switches on at 30,000 counts (after bias subtraction). This plot was made specifically avoiding a very bad pixel at (868,327), see below.
Left half of UV CCD 19 May 2004 Noise estimated from many runs. Model, readout noise = 3.35, gain=1.17. Note the peppering switching on at a rather lower count level than the green CCD.
Right half of UV CCD 19 May 2004 Noise estimated from many runs. Model, readout noise = 3.35, gain=1.15. Have lost the plot of the results unfortunately.

The gain values above are probably only good to +/- 0.02 or so, so effectively they can be considered the same for each CCD, but with definite variations between the CCDs. If you want to account for the variations, as opposed to using single numbers, I have made readout and gain frames.

Rogue pixels gallery

Some pixels are really, really bad news. Here is a list of some #1 public enemies and why. Lower-left corner = (1,1). If you find others, let me know. A future upgrade I plan for 'reduce' is to flag when the star aperture covers bad pixels.

CCDPositionComments
Green (868,327) Appears to have no sensitivity at all. Steer well clear of this as it affects 2 or 3 pixels above it and to its left. Avoid including it in noise analysis. It does not flat field. Looks like a charge trap.
UV (423,902) As mentioned above, this is a gushing fountain of a hot pixel, stacking up counts at 500 per second.

Coping with bad pixels

There are two parts to bad pixels. The first is avoiding them in the first place during setup. 'rtplot' has an option to plot defects which I have now upgraded this to plot all defects of CCDs onto any one CCD using a simple coordinate transformation that can be derived from the positions of any two stars visible on all frames. I intend to build up files of bad pixels suitable for plotting from 'rtplot'. The second element is warning you during reduction when you failed to avoid bad pixelsand your results may be affected. Since version 4.0.0 'reduce' can optionally load a special bad pixel mask (not the same as the rtplot one however). I intend to create files of these as well.


Tom Marsh, Warwick