OBSERVING WITH UFTI

Contents

• Run-up and Run-down
• Preparing an Observing Programme - the UKIRT OT
• Available Template Observations (separate page)
• Loading and running a Sequence - the UKIRT QT
• On-line data reduction - the ORAC DR
  • Available DR Recipes (separate page)
• Data Format and Location at UKIRT

Run-up and Run-down

Login to KAUWA and OHI as observer.

You will use KAUWA to prepare or modify your observing programme with the UKIRT Observing Tool (ukirtot) and OHI to sort, load and run "Minimum Schedulable Blocks" (MSBs - see below) from your programme via the ORAC Query Tool (ukirtqt). The data will be reduced with the pipeline software ORAC-DR (oracdr).

Back to page contents

Preparing an Observing Programme: the UKIRT OT

	Alternatively, on KAUWA at UKIRT just click on this icon.

A small window will appear (containing a photo of UKIRT) in addition to the copyright notice window; you may use the former to open existing programmes, create new programmes or access the database. If you're new to the OT, close the copyright box and read on...

Flexible Scheduling and Minimum Schedulable Blocks:

Since semester 03A, UKIRT observing (except for Japanese and UH runs) has been flexibly-scheduled. Consequently, observations must be grouped within "Minimum Schedulable Blocks", or MSBs. An MSB represents the minimum amount of data that needs to be obtained for an observation to be useful, e.g. observations of a sky flat, a standard star and the science target. You or indeed any other observer will then be equipped to properly observe one or more of your targets, simply by executing everything in the MSB.

The UFTI Template Library

All users should work from a "Template MSB" (available Template MSBs are described on a separate page - a table of DR recipes is also available). The "Template Library" contains MSBs comprising observations that can be modified to suit your specific needs. It is unwise to try and write an observation completely from scratch. Open the Template Library by selecting this option from the menu under "File" (top-left corner of the small "UKIRT" window). At the same time, create a new programme by selecting this option from the same (File) menu. After a few moments, two Programme windows - like those shown in Fig.1 - will appear.

From the list of template MSBs (see Fig.1), examine those that may be of use to you by clicking on the small button to the left of the MSB icon; the observations (usually only one) within the MSB will be displayed. The elements of each observation can then be displayed as a flow chart by again clicking on the buttom to the left of the observation icon (the blue square); see Fig.2 for an example. Click on any element within the observation for further details.

Fig.1 Available MSBs in the Template Library (subject to change!)
(Click above for a larger image)

Once you've selected an MSB, e.g. for a 9-point jitter map of your target, click (and hold - left mouse button) on the icon and drag-and-drop this observation into your new programme (or use the Copy and Paste buttons).

Understanding the Elements of an Observation

To understand how to use the OT, lets consider a specific example... The programme shown in Fig.2 contains just one MSB (you'll probably need one MSB for each of your targets); the MSB contains two separate observations, one for the target and one for a sky flat. A standard star observation might be a third observation within the MSB. The second (opened) observation in Fig.2 aims at obtaining a 9-point jitter pattern on the target HH7, in three separate filters. Note that the "HH7 9-point jitter" observation and the "Sky Flat" observation will be loaded and run separately at the telescope; both observations need not necessarily be taken, though because they are inside the MSB, its likely that both are needed for a full reduction/calibration of the data. However, the order of the observations in the OT doesn't matter. The observer can decide the order in which to observe each target.

The HH7 observation opened in Fig.2 begins with three components (broken blue boxes), which specify the Target information (target and guide star coordinates), the UFTI instrument configuration and the Data Reduction (DR) Recipe . The UFTI instrument configuration has been highlighted (clicked upon) so that the selected parameters are displayed on the right half of the window: in this case, the 2.122 filter, a 60-sec exposure time and a "HiGain+NDSTARE" readout mode will be used. Some of the parameters will be changed later in the observation using an UFTI iterator (see below).

Fig.2 A Typical MSB involving observations needed for one target.
(Click above for a larger image)

The target information is used to enter the source coordinates AND to specify a guide star. This component may also be used to display a Digitised Sky Survey image of the target field, the instrument aperture size, and various guide-star catalogues (see the the observing guide for a description of this tool). The DRRecipe component also needs careful consideration; this component allows you to select the recipe appropriate to your mode of observation, so that the DR can reduce your data on-line. An MSB copied from the template library should already have the DR recipe set correctly. In the case of HH7 here, because a 9-point jitter pattern is being repeated in three separate filters, the JITTER_SELF_FLAT_NCOLOUR recipe is the most appropriate. All object files obtained as part of this observation will be flagged with this recipe.

Below the DRRecipe component in Fig.2 there is a "running man" icon, labelled Sequence. Embedded "within" this sequence icon are the actual exposures (the "eye" symbol) and three nested iterators (more running-man symbols). The observation in Fig.2 first takes two dark exposures; click on the "eye" icons to set the dark exposure times. Two darks are needed because different exposure times will be used with the different filters. Below the darks there are three iterators that are stacked much like "embedded do-loops" in a computer programme. The idea here is to obtain a 9-point jitter map (the offset iterator) in three different narrow-band filters (the UFTI iterator). However, to build up signal-to-noise, each 9-point mosaic is repeated 3-times before switching to the next filter. The offsets in the 9-point jitter pattern can be changed by clicking on the Offset iterator; similarly, different filters and exposure times can be chosen by clicking on the UFTI iterator (see Fig.3). N.B. the UFTI iterator is used to override whatever is set in the UFTI component (the blue broken square); everything not in the UFTI iterator is unchanged. And of course, if you only want one cycle of 9-point jitters per filter, the repeat iterator can also be changed.

Fig.3 The UFTI Iterator, used here to update the filter and exposure time.
(Click above for a larger image)

The last step in the observation (below the note) simply makes sure that the telescope is back to the 0,0 offset position. DO NOT delete this last step - some DR recipes need this to help them decide when an observation is finished.

Finally, if you want to view the whole observation of observations (telescope moves and filter changes) written as a simple text list, click on the Sequence "running-man" icon and hit "show".

The Flat Field observation...

As noted above, the example MSB in Figs.2 and 3 contains two observations, the jitter map on HH7 and a separate flat-field. For accurate photometry a good flat-field is of course a necessity. Using a "self-flat" observation from the Template Library, i.e. one in which the median average of source frames is used to construct a flat, may NOT be adequate for bright sources where the integration time is short. Suffient background signal for flat-fielding at broad-band J and K is obtained only after about 30 and 10 seconds integration on-sky respectively. Thus, if your on-source integration time is going to be much less than this, you should consider obtaining separate flat-fields using one of the "Make_Skyflat" observations available in the OT. Related discussion on Background-Limited Exposures is given in the previous section.

Saving and Storing your handy-work...

When preparing MSBs, keep saving the file to disk: click on File - Save As - at the top-left corner of the programme window. Once the programme is complete, save it to disk one last time. If you are at UKIRT or the JAC, you may then store it to the telescope site (Database - store to telescope site), using your project ID (e.g. u/03a/99). The programme can then be retrieved from the database at the summit and your observation executed.

Back to page contents

Loading and Running Observations in an MSB - the UKIRT QT

To take data at the telescope, use the Query Tool, or ukirtqt, from OHI. Login to OHI as observer and type ocs_up to run up the Observatory Control System.

Those visiting the telescope will be shown how to use the QT by their support scientist, though a guide is also given here.

TIP: To avoid image latency affects (discussed here) a "set dark" command appears at the end of all observations. If you stop a sequence before it has run through to the end, you should move the highlight to this command and "continue from highlight" so that the blank is inserted before the telescope is slewed to another target.

Back to page contents

On-line data reduction - the ORAC DR

A sizable number of reduction recipes are now provided with ORAC. The template observations discussed above contain recipes appropriate to the associated observing mode. Please take care when changing DR recipes; many have specific requirements in terms of darks and flat fields, which must be acquired before a target observation is obtained and reduced on-line. Tables of available DR recipes - and links to detailed descriptions of them - are available. If a special reduction recipe would be useful to you, please contact your support scientist - we may be able to produce something specific to your needs, though we do need to be notified well in advance of your run at UKIRT.

To run ORAC-DR on KAUWA type

  oracdr_ufti

The above command should be followed by

  oracdr -loop flag 

Fig.3 The results of typing "oracdr -loop flag";
the oracdr text display (left) and gaia display (right) give the results of the pipeline reduction as you observe...

  oracdr -loop flag -from 199 

  oracdr -loop flag -list 199:210 

 oracdr -list 31:40 -calib flat=flat_Z_7 

Help on this and other ORAC-DR topics is available by typing

  oracdr -help 

Photometry with Gaia

Gaia is an extremely versatile image display and analysis tool. In addition to measuring the seeing, taking slices across features, and calculating statistics in a movable box, Gaia may be used to astrometrically callibrate your images, and calculate the magnitude of a source in your data. Here's a Guide to Photometry with Gaia for those wishing to do the latter.

A note about co-adds and averaging in ORAC-DR: If more than one co-add is used, then users should note that the "co-added" frames are in fact averaged. In other words, the data values, or counts, in each raw frame correspond to the exposure time of one co-add. Similarly, the frames that comprise a jitter pattern are also averaged by ORAC-DR. However, please note that if a jitter sequence is repeated the mosaics that result from each jitter pattern are added to give the final, "master" mosaic.

As an example; if you expose with 10secs x 2 coadds, and you repeat a nine-point jitter pattern three times, the integration time equivalent to the counts in each of the three mosaics will be 10 seconds. The integration time in the final, master mosaic (the sum of the three seperate mosaics) will then be 30 seconds.

Note that in all cases the integration time written to the fits header always reflects the averaging or addition of frames described above. Division by the integration time given in the header will always give data calibrated in counts/second.

Mean versus Median averaging: The DR recipes currently take the "mean" when creating the final mosaic in a reduced group, rather than the "median". Observer's have noted that this method does not deal with cosmic rays or hot pixels. However, it is argued that taking the median will underestimate the flux. If the registration is not quite perfect, when combining pixel values near a source centre (peak pixel in a star, say), there is a tendancy to underestimate the flux, because the peak pixel in one frame is regarded as an outlier compared to the corresponding pixels in the other frames where the registered pixel is in the profile wings of the source. So the median is biased below the true peak. This is thought to affect photometry by up to 3.5%, but is typically in the 1% region. The better the seeing, the worse the bias. Taking the mean, on the other hand, will conserve flux. And note that most bad pixels will be removed by subtraction of the bad-pixel mask and/or during flat-fielding.

If, however, you still want to take the median average when using ORAC to produce your mosaics, this is simple enough to set up. Make a copy of the recipe JITTER_SELF_FLAT in your ORAC_DATA_OUT directory (the unix command "locate JITTER_SELF_FLAT" will show you where the recipe is on your system). Now change the METHOD argument of the _MAKE_MOSAIC_ primitive to "median",e.g.

   _MAKE_MOSAIC_ TRIM=0 RESAMPLE=1 INT_METHOD=linint FILLBAD=1 METHOD=median

If the registration is good, i.e. the pipeline uses the stars themselves rather than the telescope offsets (which are only good to about 0.5" or 5 pixels) then the median is the best choice. You can check what the DR used by examining the .oracdr_*.log file. Likewise if you take the flat-fielded files and create your own mosaic with, say, the CCDPACK tasks PAIRNDF, REGISTER, TRANNDF (or KAPPA's SETORIGIN), and MAKEMOS, you will do better than the telescope offsets, and again in that case taking the median is a good option. For best results in a sparse field where the DR uses the telescope offsets we recommend the manual matching of sources and registration with PAIRNDF.

Back to page contents

Data Format and Location at UKIRT

At the summit, raw and reduced data files are currently saved to directories /ukirtdata/raw/ufti/UTdate/ and /ukirtdata/reduced/ufti/UTdate/ on Kauwa. The RAW data files are saved as "hierarchical data structures" (HDS) containing two NDFs. The REDUCED data output by ORAC-DR are NDF files (with the same .sdf extension), which can be displayed with any Starlink software or easily converted to FITS by typing:

 convert 

 ndf2fits "*.sdf" "*" comp=d

 ls -1 *.sdf | sed s/.sdf// > ndf.lis 

 ndf2fits "^ndf.lis" "*" comp=d

UKIRT staff will back-up your data onto tape after your run in your chosen format. Note that only a limited selection (the gf*.sdf mosaics) of the reduced data is transferred down to Hilo for backup (all of the raw data is backed-up and archived). If you want other reduced files, you will need to make your own tape or ftp these files to your home institute. Although the current versions of major Starlink software packages can process these HDS container files, including conversion to FITS, most observers prefer simple NDFs (or fits files).

If you only have the HDS container files you may convert these to NDF files by simply running the QUICK_LOOK ORAC-DR recipe on all of the files. For example:

 oracdr -list 5:250 QUICK_LOOK -nodisplay 

Back to page contents

Previous : UFTI Parameters | Up : UFTI homepage