Skip to main content Skip to navigation

Physics Astronomy and Astrophysics Group

ULTRACAM form instructions

These are the instructions for filling in the ULTRACAM phase II forms of which there are 2, one for general information that needs to be filled out once and the other for target data that needs to be filled out once per target. The forms are crude, and do no significant checking of inputs, so please think carefully about what you enter. Please try to fill in the entries as if your observations were to be carried out in service mode even if you expect to observe because it will make it easier for us to pick up the reins if need be. With classically scheduled runs, the need for this has lessened, but it may still allow us to work out some sort of optimisation, especially if the weather is poor.

First some general advice, followed by a blow-by-blow account of the meaning off the form entries.

Backup targets

Now is the time to think about backup targets. We are now largely operating in classical scheduled mode, so for ESO runs you should think about whether you want to get backup target approval from ESO for all the usual reasons, e.g. wind is in the wrong direction to observe your one target. For WHT runs, you can add backups in case your prime targets are not observable or the conditions are not right.

Target information and finding charts

Please be accurate with the target information, especially with coordinates, and make sure that your finding charts are as legible as possible. Finding charts should minimally include:

  • the name of the target,
  • an indication of which object is the target,
  • the coordinates of the field centre,
  • the width of the field,
  • the orientation.

It would be nice if they also contained an indication of your preferred comparison star or stars. We have developed an ULTRACAM-specific finding chart tool that does all of this, based on Aladdin. This tool shows timing and signal-to-noise information to allow you to optimise your observations. Some useful tips for defining your setups are: (1) try to avoid putting targets or comparisons right in the corners of the chip since these are somewhat vignetted, especially on the VLT, (2) avoid having a bright star on the same column as your target as the frame transfer may smear its flux out to an extent which can affect your photometry.

Scheduling

In the past we have tried to micro-schedule but have decided that largely this is not worth the huge effort since very often it is best for a program to use entire nights. On the other hand there are good reasons sometimes to switch between programs (i.e. a program that covers transits or eclipses may not make full use of a night). This is a major reason for wanting the phase II information.

u-band co-adds

While the red and green CCDs are strictly synchronous, the blue CCD exposures (u'-band) can be an integer multiple of the other two arms (e.g. 1, 2, 3, 4 etc). This is very often useful because in the past the u-band has tended to limit the time resolution on the other two arms. i..e in order to avoid being readout-noise limited in u, we have had to expose for longer than necessary in green and red. There is a cost in terms of losing exact simultaneity, although the blue chip exposures are still synchronised on a longer period. This is often a desirable option to use, especially on reddened targets, or targets with red comparison stars. You should specify whether you want to use the u-band co-add option at all and if so, what is the maximum permissible u-band exposure time. Put 'any' if the u-band is not important to you.

Observing condition constraints (mainly, but not entirely, for service mode)

We will use these to judge whether we should be observing a given target or not. Don't automatically assume that you should enter slack tolerances since you may then just end up with rubbish data. We don't use these rigidly, i.e. if a run starts OK and then gets worse, we often stay on target because of the cost of moving and the possibility of things getting better, so these parameters are really used to decide whether we should get on to a target in the first place. Also since we now operate mostly in classical mode, we tend to stick to the program for the night if at all possible, nevertheless, it can be frustrating to be observing when conditions are such that one knows the data will be no good, so try to be noble and think of this. It might even save you the bother of looking through 50GB of rubbish. Also, if you have a good program as a backup, then give us the targets and info needed to observe them.

Bright targets at high S-to-N

In our experience it is often a mistake to assume that you can get away with poor conditions on bright targets. These are often precisely the ones for which one wants to go fastest or achieve the highest signal-to-noise (otherwise why observe them on a large telescope?). Fast photometry in particular is quite sensitive to non-photometric conditions because the effects of the clouds do not cancel as well as they do for long exposures because one resolves the structure in the clouds. The light curves when going fast can be disappointing even through only thin cirrus which you would not notice in standard CCD photometry. Therefore please think carefully before you set loose constraints even on bright objects because we don't want to accumulate gigabytes of inadequate data. I think that the simplest way to look at it is to consider how much your object varies intrisically. If it flickers like crazy, then it will be this rather than the conditions which might set the threshold, so one could perhaps allow for a bit of cloud, whereas exoplanet transits for example suffer with even a little bit of cloud. We will stick with things if we think conditions will improve of course.

Filter changes during the night

On the NTT we observe in the New Observatory Building (NOB) which is down the mountain from the NTT. Since filter changes are by hand, there is a disincentive to changing filters during the night (better in any case for reliability of flats not to change filters). So please do not specify different filters unless you think it is absolutely essential. However do specify alternatives if you are not bothered e.g. r or i, because this increases flexibility and may even allow your program to get a bit of extra time. The cost in time of a filter change is not as bad as one might think because we communicate by radio, so around 5 minutes is feasible; still the fewer the better because it involves someone going on a night time drive.

On the WHT, filter changes are much easier (just need to go to the dome), but typically requires the telescope to be parked at zenith, and so cost 2 or 3 minutes.

Explanation of specific fields in the forms

Fields in the general information form

  • Programme ID: A unique identifier for your proposal, e.g. 074.D-1234. You will need to enter this for each of your targets, so make a note of it.
  • Number of nights: The number of nights awarded by the TAC (for ESO see the user portal if you have lost your record of this.)
  • Your proposal: Please attach a copy of the proposal as it may reduce the need for us to contact you.

Fields in the target information form

  • Programme ID: this must be identical to whatever you used for the general information form.
  • Priority: to allow us to decide between targets if weather conditions don't allow full coverage
  • RA, Dec: should be accurate to about 1 arcsec; ICRS/J2000 only please! If your target has significant proper motion, let us know its magnitude and direction in the comments in case it makes identification tricky. Please try to use a a standard HH MM SS.SS format. e.g. "12 31 45.34"; anything non-standard may fail to parse.
  • Magnitude: you can enter a single number or a range. If unqualified we will assume it to be g', otherwise add the filter as in B=16.5 or what have you; feel free to add a colour if it is very red, e.g. B=16.5, B-V=2.0. If it is variable over a large range (e.g. outbursts) then in the comments tell us roughly how long it spends in different states and whether your aims can be achieved in different states. If not, then we need to know how to identify the state that you want to observe.
  • Filters:it is most important that we know these so that we know whether we can switch between programmes in a night. Our default set of filters are u', g', r' (on the blue, green and red arms of ULTRACAM respectively; i' is probably the next most commonly used on the red arm). You must specify a filter for each arm in the order blue, green, red. If possible please use u'g'r' to minimise filter changes, but also let us know if you can tolerate alternative filters on any arm since the more flexibility we have, the fewer filter changes will be needed. See above for a note about not changing filters on the NTT if at all possible. The other filters are as follows:
    1. i' and z' SDSS filters for the red arm.
    2. CIII/NIII+HeII (central wavelength 4662A, FWHM 108A), green arm. Call this 'HeII' for short.
    3. NaI (central wavelength 5912A, FWHM 312A), red arm
    4. Halpha (central wavelength 6560A, FWHM 100A), red arm
    5. Red continuum (central wavelength 6010A, FWHM 118A, red arm. Call this 'RC' for short.
    6. Blue continuum (central wavelength 5150A, FWHM 200A), green arm. Call this 'BC' for short.
    For more information, see the ULTRACAM filter database.
  • Desired exposure time: This is the sampling time in seconds that you would like us to aim for.
  • Maximum exposure time: We might find that owing to the state of your target or the weather conditions that your desired sampling gives too much read noise. We will then need to know whether it is worth continuing or whether we should be looking at a brighter target if possible. First of all however, we will seek to lengthen the exposures. Therefore please tell us the maximum sampling time your programme can tolerate.
  • OK to use u-band coadds: Is your programme OK with the u-band co-add option? (see above for more info).
  • Maximum u-band exposure time (sec) If you answered yes to the previous question, then please specify the maximum u-band exposure that you can tolerate. You can write 'any' if you don't mind what we use.
  • Total time on target (mins): the sum of this over all targets should match the time you were awarded. Please assume 430 minutes per night for short summer nights, 600 for winter nights. This time should include overheads. Without a filter change, assume 10 minutes for a new target. If you really need a filter change you should add another 10 minutes for the NTT, 5 for the WHT. This time is not so important for classically scheduled runs, but may help keep track of whether you have used your allotted time. In this case you could over-allocate and we will observe as much as we can.
  • Minimum unbroken time on target: it may be that we have a gap in the schedule and are looking for something to fill it. This number tells us in a glance whether a given target is worth looking at. Again add 10 mns for overheads. This should simply be a number.
  • Must be photometric: if no, then we will assume that you can still get useful science when there is thin cirrus around. Please be aware that high-speeds tend to make things worse in this case: see the note about bright targets.
  • Seeing: worst case, FWHM arcsec. Especially important for faint objects of course, in combination with the sky brightness constraint. Remember to consider what you will get if all conditions are at their worst. You can always submit backup targets, so be realistic here.
  • Time critical: put yes if there is anything which might constrain the timing of the observation beyond observing conditions. Obvious ones are simultaneous satellite observations, eclipses and transits. ToO observations are not part of this, just flag them in the comments. Rather than try to anticipate everyone's requirements with other fields, the specification of time constraints is left to the comments.
  • Finding chart: please try to use Stu Littlefair's finding chart tool as it gives a good idea of the constraints that ULTRACAM sets on the choice of window etc. See the target information section above for more on this.

Useful links

Here are some links that may be useful: