CGS4 is a 1-5um multi-purpose 2D grating spectrometer containing a 256x256 InSb array, installed in a cryostat which is cooled by liquid nitrogen and closed cycle coolers. Four gratings are available, two of which are installed in the cryostat at any one time. They are a 40 l/mm grating which provides resolving powers of 500-2200, a 75 l/mm grating, a 150 l/mm grating which provides resolving powers of roughly 3000-8500, and a 31 l/mm echelle which provides a resolving power of about 37,000 (8 km/s). The 75 l/mm grating is rarely used thesedays. These resolving powers are achieved with the 300 mm focal length camera optics and a one-pixel-wide slit, which provide a scale of 0.6 arcsec/pixel for the two moderate resolution gratings and roughly 0.41x0.90 arcsec/pixel for the echelle (0.41 arcsec/pixel in the direction of the dispersion).

General Description of the Instrument

CGS4 is a 1-5um multi-purpose 2D grating spectrometer containing a 256x256 InSb array, installed in a cryostat which is cooled by liquid nitrogen and closed cycle coolers. Four gratings are available, two of which are installed in the cryostat at any one time. They are a  40 l/mm grating which provides resolving powers of 300-2000, a 75 l/mm grating which provides resolving powers of about 600-2000, a 150 l/mm grating which provides resolving powers of roughly 2000-6000, and a 31 l/mm echelle which provides a resolving power of about 20,000 (15 km/sec).  The 75 l/mm grating is rarely used thesedays. These resolving powers are achieved with the 150 mm focal length camera optics and a one-pixel-wide slit, which provide a scale of 1.22 arcsec/pixel for the two moderate resolution gratings and roughly 1.0x1.5 arcsec/pixel for the echelle (1.0 arcsec/pixel in the direction of the dispersion). A 300 mm focal length camera mirror sometimes is installed in place of the standard camera; with it pixel scales and wavelength coverages are halved and resolving powers are doubled (in principle).

CGS4 slit lengths are about 80-90 arcseconds. It is possible to orient a slit at any angle on the sky. Slit widths of one pixel (~1.23 arcsec with the standard camera, 0.61 arcsec with the long focal length camera), two, and four pixels are available. Since the resolution is matched to one pixel on the array, with the one-pixel wide slit fully- (or over-) sampled spectra must be obtained by mechanically shifting the array in the dispersion direction, while holding the grating fixed. The array may be "shifted" over two pixel widths; so that isolated bad pixels do not result in gaps in the spectrum.

For optimum noise performance and efficiency in short exposures either multiple non-destructive readout of the array (NDSTARE) or a single read mode (STARE) can be used. The array can also be read in synch with the chopper. Chopping often is employed when observing at medium resolution at thermal wavelengths (beyond the K window).

The instrument has a calibration unit, containing a black-body source for flat-fielding and argon, krypton, and xenon arc lamps for wavelength calibration. Five broad band filters continuously cover the wavelength band 0.95-5.4um. Longward of 1.3um, CVFs serve as order-blockers for the echelle. Shortward of 1.3um, narrow band filters (1.083um, 1.233um, 1.257um, 1.282um), allow echelle observations at important wavelengths. Spectropolarimetry is available with CGS4 at all wavelengths.

Software

The spectrometer is completely under computer control. The low-level (VAX) side of the control system is run-up and looked after by the telescope operator, the observer's interaction with the system is through the ORAC software as with the other UKIRT instruments. Instrument configurations and observing sequences are specified using ORAC-OT.

Further Information

• Your support scientist should be the first point of contact.
• Tom Kerr, the CGS4 instrument scientist

CGS4 Optical Parameters

CGS4 optics layout

CGS4 Sensitivity

Sensitivity: Some Very Important Notes - Please Read.

• The values listed below are surface brightness sensitivities.
• The sensitivities are calculated for the best part of the band (near 100% atmospheric transmission). They cannot always be used to interpolate sensitivites at other wavelengths within the band.
• Sensitivities for point sources can be estimated from the following tables. Assuming 0.6" seeing and that the spectrum falls onto three rows of the array, the signal-to-noise will be approximately a factor 2.5 lower than quoted in the tables (about one magnitude).
• CGS4 is less efficient when very bright sources are observed and it is difficult to obtain signal-to-noise greater than a few hundred. The sensitivities on very bright sources also do not scale with brightness.
• In order to achieve the quoted sensitivities, you need to use long exposures. Typically > 30 seconds in H and K, and >75 seconds at J. Shorter exposures will result in a lower sensitivity. Please see CGS4 Exposure Times.

CGS4 sensitivity per pixel with the 40 l/mm grating and the long camera

The 3-sigma 30-minute sensitivities per 0.6"x0.6" pixel for the case of nodding up and down the 1-pixel wide slit are as given in the following table. Sensitivities for very extended objects which require nodding to blank sky will be 0.4 mag poorer. The line flux assumes that the line is unresolved. Please remember to reduce the sensitivity by one magnitude for point sources.

Predicted CGS4 sensitivity per pixel for the 150l/mm grating and the long camera.

The 3-sigma 30-minute sensitivities per 0.6"x0.6" pixel for the case of nodding up and down the 1-pixel wide slit are as given in the following table. Sensitivities for very extended objects which require nodding to blank sky will be 0.4 mag poorer. The line flux assumes that the line is unresolved. In the J-K windows the predicted sensitivity is based on a model for the dark time inter-OH sky background and the throughput of CGS4. There will be variation in this background depending on lunar phase. If you observe an astronomical line which is not resolved from an OH line, then the limiting magnitide will be less, depending on the strength and variability of the line. The limiting magnitude is approximately one magnitude brighter on a typical OH line. Please remember to reduce the sensitivity by one magnitude for point sources.

CGS4 sensitivity per pixel with the echelle grating and the long camera

The 3-sigma 30-minute sensitivities per 0.6"x0.6" pixel for the case of nodding up and down the 1-pixel wide slit are as given in the following table. Sensitivities for very extended objects which require nodding to blank sky will be 0.4 mag poorer. The line flux assumes that the line is unresolved.  The values assume that the observations are read noise limited with sufficiently long exposure times for the multiple NDR to provide a read noise of about 25e-. The sensitivity will be less if an exposure time less than 100sec is used to avoid saturating a strong OH line close to a faint astronomical line. Please remember to reduce the sensitivity by one magnitude for point sources.

CGS4 Exposure Times

Since the installation of the long focal length camera in August 1997, many observers have requested that optimum exposure times be placed in the CGS4 web pages and in the manual. This is not a trivial task, as the optimum exposure time is dependent on many factors such as resolution, wavelength, object brightness and weather conditions. In this article, we provide a guide on how to select appropriate exposure times given the above factors.

NB. Generally, the maximum possible exposure time is the optimum exposure time, as overheads are reduced to a minimum. However, you should discuss this with your support scientist before and during your run.

150 l/mm Grating

Approximate maximum exposure times (sec) for the 150 l/mm grating (J, H, K)

Assume a 1-pixel wide slit and that the light falls on one row of the array. Typically light falls over three rows and these exposure times can be increased by about 30%. Half these times when using the 2-pixel wide slit.

Approximate maximum exposure times (sec) for the 150 l/mm grating (L, M)

This table is for 1-pixel wide slit and the long camera. Half exposures for 2-pixel wide slit.

		FULL ARRAY, NORMAL WELL		SUBARRAY, DEEP WELL*
Wavelength (µm)	Notes;	Sky + tel emission; Max exposure (sec)	0.12s exposure Brightest observable star	Sky + tel emission Max. exposure (sec)	0.016s exposure. Brightest observable star
3.0		20		40
3.31	CH4 Q;	3		6
3.2-3.5	CH4 v-r lines	6	L ~ 1.5	12	L ~ -1.5
3.8		4	L' ~ 1.0	8	L' ~ -2.0
4.1		2		4
4.7		0.2	M ~ 0.5	0.4	M ~ -2.5
5.2		0.12		0.25

* These figures refer to the 256 x 32 subarray. There is also a slightly larger 256 x 48 subarray with a minimum exposure time of 0.023 sec. Therefore the brightest observable magnitude is 0.4m fainter when using this array.

150 l/mm grating and background limited exposures.

This medium-to-high resolution grating enables one to work in between OH lines in many regions in the 1.1 to 2.3 micron spectrum (OH line emission is not a factor beyond 2.3 microns).

In simple terms, in order to be background limited in the non-thermal regime (<2.3 microns), the sky noise must be greater than the array read noise. For multiple non-destructive reads (NDR), the read noise is approximately 23 electrons. A typical value for the continuum background (from the telescope, sky and long wavelength leaks) using the 1-pixel wide slit in J, H and K is 30 counts in 100 seconds, and with a gain of six, corresponds to 180 electrons and a sky noise of approximately 13.5 electrons. Therefore, in most cases, an exposure time of approximately 300 seconds is required for the sky noise between OH lines to equal the read noise. For longer exposures than this the array is background limited and best s/n is achieved. With the two pixel wide slit (which still gives high enough resolution to work between many OH line pairs) the exposure time must be greater than about 200 seconds. Beyond about 2.2 microns, the background increases rapidly as the thermal background from the sky and telescope begin to increase, and the background-limited exposure time drops rapidly.

The drawbacks to using such long exposures are variations in the sky background and OH line intensities, OH line saturation (at H and K), and increasing likelihood of spikes on individual or small groups of detectors. If the critical wavelengths are well clear of the OH lines, then you probably don't have to worry about their approximate 5-10 minute variation timescales or strength for OH variations, but if you are close to one than these can become problems (but see the two paragraphs below for ways to minimise these). Add to this that you will probably need to oversample your spectra, your time on source will become at least 600 seconds before you nod to sky. If you are using the 1-pixel wide slit and 2x2 sampling, it will be 20 minutes before you can nod the telescope. In addition to the dangers of sky variations these long times mean that, although in principle maximum sensitivity is achieved, a lot of time is wasted if something goes wrong.

For extended sources, nodding to sky is required, and the brightness of the source and stability of the sky background on that night will effectively determine the time between nods and hence the exposure time; these may be considerably less than the above ideals.

For spectra obtained while nodding along the slit, subtraction of the negative spectrum from the positive spectrum will remove most of the sky and OH fluctuations because both vary slowly across the rows of the array. When observing faint and compact sources it is always advisable to nod a small number of rows along the slit (e.g., much less than the canonical 30 rows), so that the cancellation of sky and OH residuals is as accurate as possible. Remaining residuals can be removed by polyfitting techniques, using blank sky rows adjacent to the rows of interest, but doing this will increase the noise in the final spectrum.

The frequency of spikes is difficult to judge and their effect difficult to assess, because spikes sometimes are severe, sometimes are only somewhat above noise levels, sometimes effect only one pixel, sometimes effect a few adjacent pixels, and their frequency may vary. Clearly they are more likely to affect observations of an extended source than a pointlike source.  Empirically they do not appear to be a serious problem when observing point sources with exposures of a few hundred seconds.

40 l/mm Grating

Approximate maximum exposure times (sec) for the 40 l/mm grating (J, H, K)

Assume a 1-pixel wide slit and that the light falls on one row of the array. Typically light falls over three rows and these exposure times can be increased by about 30%. Half these times when using the 2-pixel wide slit.

¹ The strongest OH line in the band will be saturated using this exposure time (on a good night).

Approximate maximum exposure times (sec) for the 40 l/mm grating (L, M)

This table is for 1-pixel slit and the long camera. Half exposures for 2-pixel wide slit.

* These figures refer to the 256 x 32 subarray. There is also a slightly larger 256 x 48 subarray with a minimum exposure time of 0.023 sec. Therefore the brightest observable magnitude is 0.4m fainter when using this array.

40 l/mm grating and background limited exposures.

In most cases the 40 l/mm grating is background limited at much shorter exposure times at all wavelengths than the 150 l/mm grating due mainly to its lower resolution, which ensures that an OH line is present in almost every resolution element.

Typical background-limited exposure times are about 30 seconds at H and K (less than 2.3um), giving 2 minutes between nods with 2x2 sampling. In the J band the OH lines are weaker and exposures of ~75 seconds are required to reach the background limit (5 minutes between nods). The same concerns and optimal procedures regarding OH fluctuations as discussed for the 150 l/mm grating apply here, except that spikes are less of a problem because super-long exposures are not needed.

The Echelle

Optimum exposure times for the echelle are difficult to predict due to the small wavelength coverage of this grating, the exact wavelength of a particular observation and the changes in sky transmission with wavelength. The best course of action is to consult with your support scientist or with; Paul Hirst before your CGS4 run.

Resolutions and wavelength coverage (with the long camera)

40 l/mm grating¹:

150 l/mm grating¹:

Echelle^1,2:

• Resolving power is 37000 at the optimum order.
• Coverage is 0.006 x lambda.

1: These are the resolving powers for the 1-pixel wide slit (0.609"). Half the values when using the 2-pixel wide slit. They will be x4 lower when using the 4-pixel wide slit for extended object, but probably only x2 lower for guided point sources.

2: There is no 4-pixel wide slit available for use with the echelle.

40l/mm and 150l/mm grating efficiencies

40 l/mm

Use the following plot to decide which order to use when observing with the 40l/mm grating in CGS4. Use 1st order beyond 2.5 microns.

The data are from Richardson Grating Laboratory for 1st and 2nd order. 3rd order is estimated.

The above plot shows only the grating efficiencies themselves. It does not include atmospheric transmission and the throughput of the CGS4 filters. For example, if one wished to observe a feature a 1.35 microns while setting the central wavelength for the middle of the H band (around 1.6-1.7 microns), you would expect essentially no throughput at 1.35 microns. This is because i) the atmospheric transmission itself is only about 20% at this wavelength and ii) the B2 filter, used for H and K band work, cuts off at about 1.4 microns.

For those wishing to observe features that occur close to or at the cut-off wavelengths for the near-infrared bands, please contact your support scientist or Paul Hirst beforehand for advice on the most appropriate methods.

150 l/mm

CGS4 Filters

The following two tables list the filters in use with CGS4, their central wavelengths and cut-on and off wavelengths (half power).

Broad Band Filters (for low and medium resolution gratings):

Narrow Band Filters (echelle mode):

² The N2 filter is not currently installed in CGS4's filter wheels.

For wavelengths beyond 1.3-µm, the CVFs are used as order-blockers when using the echelle. When the new wedged CVFs are installed, the narrow band filters will no longer be necessary, as one of the CVF segments will extend down to 0.93 um.

CGS4 Pixel Sizes

Low resolution gratings

Grating	Perpendicular to slit	Along slit
40 l/mm	0.61"	0.61"
150 l/mm	0.595"	0.625"

Notes:

1. The 40 l/mm grating pixel sizes are independent of wavelength setting.
2. The 150 l/mm grating pixel sizes are virtually independent of wavelength setting.

Echelle Grating

Setting Slit Position Angles (PA)in CGS4

1. The array is displayed `upside down' on the movie screen so that south is to the top, and north to the bottom.
2. You need to consider in which direction the nod, or slide, should be specified.
3. Although you are asked to enter a PA which is east of north in your config, you normally have to enter a negative PA. This is discussed in a little more detail below.

The best way to demonstrate how to specify the slit PA is by showing some examples which is done below. In each example, the top and bottom of the array are marked, as well as north, south, east and west. An arrow indicates the direction of a positive slide (or nod). Remember the telescope moves in the opposite direction to this when you slide along the slit, so be specific when giving instructions to the telescope system specialist. Please be aware that, in order to try and show things as the observer sees them on the array when the slit is north-south, north is shown at the bottom of each plot.

Example 1: PA = 0 degrees (0 degrees east of north).

In this example, a position angle of 0 is entered into the config. the slit will set to a north-south direction, with the south to the top of the array. When using a positive slide, the offset beam appears to the south of the main beam (or towards the top of the array).

Example 2: PA = -45 degrees (135 degrees east of north).

Here, a PA of -45 degrees has been entered. The top of the array is now SE, the bottom NW. A positive slide moves the offset beam on the array towards the SE (i.e., the telescope moves NW)

Example 3: PA = -90 degrees (90 degrees east of north).

A PA of -90 degrees has been entered. The top of the array is in the east, the bottom is in the west. A positive slide will move the offset beam to the east, i.e., the telescope moves to the west.

Example 4: PA = -135 degrees (45 degrees east of north).

A PA of -135 degrees is entered. The top of the array is now in the NE, while the bottom is in the SW. A positive slide will move the offset beam to the NE, i.e., the telescope moves to the SW.

Some further notes on slit PAs

• The default slide_slit command in the quad_slide exec is +11.4 arcseconds. This positions the offset beam 19 rows up from the main beam. To move in the other direction (towards the bottom of the array), simply enter a negative value for the slide. Remember that the slit is 90 arcseconds long You normally do not want to specify a nod which places the offset beam off the array.
• Although the config demands a position angle east of north, it is only possible to enter such an angle to a maximum of about 10 degrees. To set to an angle greater than this, you must specify a negative angle. For example, if you wish to set to a PA of 50 degrees east of north, set to an angle of -130 degrees (simply subtract 180 from your desired PA).
• The pixel size is 0.61 arcseconds. To make sure you nod onto another row, you need to specify a value in arcesonds which is a multiple of this number.
• The system usually does a fairly good job of positioning the crosshead on the slit in the offset position. To increase the accuracy of the offset position beam, you can do one of two things (or both): i) Use a shorter slide distance than the default +11.4 arcseconds, or ask the TSS to peakup in both the main and offset beams and correct the current slide angle.
• The current r.m.s. setting accuracy of the slit PA is 0.15 degrees.

And please....

• Always inform the telescope system specialist when you change the PA. The peakup position will change with PA, and if the TSS is unaware of a change, time will be lost in reaquiring your target.

NOTES ON USING THE ECHELLE GRATING IN CGS4.

When using the echelle grating there are more details that need to be checked than with the low resolution gratings. These are summarised in this note.

1. Pixel and Slit Sizes.

Due to anamorphic demagnification, CGS4's square pixels do not view a square patch of sky. Although the solid angle seen by a pixel is constant, the shape is a function of grating angle. The difference from a square field of view is very small at the low angles of the first order gratings, but is quite prominent at echelle angles. For example, at the nominal blaze angle of 64 degrees pixels are more elongated in the spatial direction than the dispersion direction by a factor of ~1.6. With the long camera at angles close to optimum the pixel size is 0.91 arcsec (spatially) X 0.40 arcsec (spectrally). The nominally 1-pixel wide slit is in fact about 1.3 pixels wide. The 2-pixel wide slit is 2-pixels wide (ie. 2arcsec spectrally).

The change in shape of the pixels as a function of grating angle is very rapid at large angles. As a consequence, when using the echelle you should always measure the size of the pixels by peaking up in two rows. Edit your sequence to put in the correct offset between the rows being used when nodding (see also the comment on slit alignment below).

2. Curvature

The slit is slightly curved, so atmospheric and arc lines are not quite perfectly aligned on one column of the array. In addition the dispersion axis is also slightly curved, so that the spectrum of a point source is not perfectly along one row of the detector. Both of these effects are present with the low resolution gratings, but they are more significant with the echelle. The curvature of the dispersion direction means that the dispersion has slight dependance on row on the array. This means that if an arc/atmospheric/astronomical line is straight along a column of the array in the middle of the array, lines at the edge of the array will not be so well aligned. In the dispersion direction the curvature amounts to approx 0.5pixels across the 256 pixels. In the spatial direction the misaligment with the columns due to curvature is about 0.1-0.5 pixels close to the centre of the array, depending on grating angle. For point sources nodded along about 30 rows the effects are very small and it is still reasonable to combine the two nodded spectra to cancel sky lines.

There is software available, for example in Figaro, which was designed to remove these sorts of distortion for optical spectrographs. There is information about using these in the CGS4 data reduction notes in correcting curvature in CGS4 spectra . Using these techniques a residual distortion of less than 1% can be obtained. However, in conditions of good seeing, CGS4 data are undersampled in the spatial dimension and this may mean that the effects cannot be fully removed.

Slit alignment

The curvature of the slits means that even if the postion angle is nominally N-S on the sky there will be a small (0.3 - 1 arcsec) E-W offset when you nod along the slit. Since this offset depends on the grating angle and how far along the slit that you choose to nod, it means that you should measure it for each echelle wavelength/order that you observe at. After you have measured the offset between the two rows you need to update your sequence accordingly.

INFORMATION FOR CREATING CONFIGS

3. Optimum Orders

When using the Echelle it is normal to select ECHELLE_AUTO_ORDER as the grating when defining a config. If this is selected then the CGS4 software will automatically select the optimum order for your wavelength. The optimum order gives a higher throughput than other orders. The optimum ordering software has recently been improved and now works very well for all wavelenghts.

You may wish to use another order, e.g. to get lower or higher spectral resolution or to increase the spectral coverage. To use a different order than the optimum one selected automatically, choose ECHELLE as the grating when defining your config and then explicitely enter the order that you want.

You can calculate the optimum order for any wavelength as follows. The blaze angle of the echelle is 64.6 degrees. This corresponds to the product of wavelength and order (n x lambda) being about 55.0 microns. (e.g., we find that the transmission at 2.12um in 26th order (n x lambda = 55.1) is 10X higher than in 25th order (n x lambda = 53.0) In general for any wavelength, the order for which n x lambda is closest to 55.0 gives the highest efficiency. However, at lower orders (longer wavelengths), it is best to fudge this somewhat, as the efficiency drops off more rapidly at higher angles than at lower angles. The CGS4 software uses a lookup up table calculated according to the above, with appropriate adjustments at the longer wavlengths, to select the order for the echelle.

4. Order sorting

5. CVF gradients

6. CVF fringes

7. Wavelength Calibration

At some other wavelengths you will see lamp lines that were not expected - these are strong lines in a different order and wavelength being transmitted through the wings of the CVF transmission profile.

At wavelengths beyond the K window, observable lamp lines are generally few and far between. For calibration with the echelle, one often must use the above technique for finding arc lines in different orders, telluric absorption/emission lines (atlases are available in the control room at HP, and at JAC), or observations of astronomical line sources.

The Echelle and Peakups etc

There allways seems to be confusion about the Echelle grating and the need to do 2 row peakups etc. Hopefully, this text outlines the definative proceedure.

There are two complications with the Echelle that make this more complex than with the low-res gratings, firstly the curvature of the slit, and secondly, the fact that the pixel size varies significantly with echelle grating angle.

Here's my suggested proceedure, assuming that you're nodding along the slit.:

Initially, set up your ORAC Science Program with the default offsets.

Slew to the target, and ask the TSS to do a 2 row peakup, using the SAVEPEAK and SAVE_PA commands. You will need to tell them which two rows you would like them to peak up on. I suggest 140 and 160, the same as we use for the low res gratings. It will help the TSS if you can tell them the approximate offset in arc-secs between these two rows. To do this, look up the grating angle on one of the VAX terminal screens once you have set to your config, then go to the table in the "Pixel scales" section of this document and estimate the pixel scale for the grating angle that you're at.

The SAVE_PA command the TSS uses on the TCS tells the TCS the correction between the demanded slit angle in your config and the actual angle on the sky of the point joining the position of the star when placed on the slit at the two points intersecting the peakup rows. This means that you can simply ask ORAC to "offset along the slit" and it will know the exact angle to go to hit the slit on your two peakup rows.

Note that if you change to a different slit angle, there should be no need to repeat the two row peakup. Simply do a normal single row peak up on row 140 - the correction to the angle will be exactly the same as before, assuming that you're still offseting the same distance and that you haven't changed the wavelength or order settings of the grating. If these conditions (ie same configuration, same size offset) do not apply, then you will have to repeat the 2 row peakup in your new configuration.

It is advantageous to your signal-to-noise ratio if you have the spectra centred on pixel rows on the array. Peakup also helps you do this. After doing the 2 row peakup, the TSS will be able to give you the exact size of the offset between your two peakup rows. You should go into the offset iterator in your sequence and replace the default offset size (usually 11.74) with this number. Again - there is no need to enter an offset component perpendicualr to the slit unless you really do want to offset perpendicular to, and hence off, the slit. This offset size will apply to all observations in the same CGS4 config, no matter what the slit position angle.

Notes on Configuration parameters

GRATING: Select the grating to use. Only two gratings are in CGS4 at any one time - if in doubt your support scientist or telescope operator can advise which they are. When observing with the Echelle you should normally select ECHELLE_AUTO_ORDER.

WAVELENGTH: Enter the central wavelength for your spectrum in microns.

ORDER: Enter the order to use the grating in. If you have selected ECHELLE_AUTO_ORDER the value here will be ignored.

The CGS4 sensitivity page contains information about the appropriate choice of orders for the gratings as a function of wavelength. Normally echelle_auto_order should be used for echelle observations. However see the echelle notes for details of where this is not appropriate. If in doubt your support scientist can advise you.

CVF_OFFSET_(ECH_ONLY): If necessary enter an offset in microns for setting the CVF when you are using the Echelle. Normally the default of 0.0 should be used. This value is ignored for the 40 and 150 l/mm gratings. The precise calibration of the CVF for Echelle observations can depend on which row you choose to observe, the order and the slit width. Sometimes it is desirable to set the CVF to a slightly different wavelength from the grating to correct for this. Your support scientist will help you check the CVF setting for your wavelength and order. Enter a non-zero value for a CVF offset with caution and only after checking flats taken with NO CVF offset.

POLARISER: The polariser should be NONE for normal spectroscopy. Select PRISM or GRID if you want to do spectropolarimetry.

You cannot do spectropolarimetry with the echelle and prism.

SLIT_WIDTH: Choose a 1-pixel, 2-pixel or 4-pixel wide slit. There is 1 pixel per resolution element and so a two pixel wide slit will give reduced, resolution, but can be useful in poor conditions. The 4-pixel wide slit is not available with the Echelle.

POSITION_ANGLE: Enter the position angle of the slit on the sky in degrees EAST of North. 0 deg is a N-S alignment. Due to a historcal reason, CGS4 will not accept angles greater than about 10 degrees. To request a slit position angle greater than this, you need to specify an angle 180 degrees away. E.g., if you want 45 degrees east of north, you need to specify -135 degrees as the position angle.

OBJECT_SAMPLING: The sampling required x the number of pixels to sample over.

There is 1 resolution element per pixel so the detector is stepped to fully sample. To Nyquist sample your spectra a sampling of 2 should be selected (ie 2 data points per resolution element). Many users prefer to slightly over-sample and choose a sampling of 3. To help eliminate bad pixels from your spectra you can also choose to carry out the sampling over 2 pixels. This means that each data point in your final spectrum has been observed with two neighbouring pixels. When the data reduction interleaves the raw integrations data from a bad pixel is replaced by that from its good neighbour. Most observers therefore chose sampling of 2x2 or 3x2 for this reason.

As an example, if you choose sampling of 2x2 the data in the final spectrum is taken at the following detector positions :

resolution elements     |   |   |   |   |
detector pos1:          1   2   3   4   5  ...256
detector pos2:            1   2   3   4   5
detector pos3:              1   2   3   4   5     
detector pos4:                1   2   3   4   5

DATA_ACQUISITION_MODE: Choose ND_STARE, STARE or CHOP.

For exposure times less than 1 STARE is a little more efficient but NDSTARE may aso be used. Use ND_STARE for all other observations that do not require chopping. ND_STARE uses a multiple non-destructive read algorithm to give optimum read noise performance.

SINGLE_EXPOSURE__SECS: Enter the on-chip exposure time in seconds to be used for observations of your source. See the optimum exposure times for a guide to what value to enter here. The minimum exposure time is 0.12secs for the 256x178 array. For the 256x48 array, the minimum time is 0.023 secs, and for the 256x32 array, the minimum time is 0.016 secs.

EXPS/INT_OR_EXPS/CHOPBEAM: Enter the number of exposures to be coadded into an integration (integ) at each array sample position.

For long exposures on faint sources set object_exp_per_integ to 1. For very short exposures on a bright source it is a good idea to choose a value so that the time per integration is a few seconds for best observing efficiency.

CHOP_CYCLES/INTEGRATION This only applies to CHOP mode, and is ignored otherwise. Enter the number of chop cycles you want before nodding the telescope (one chop cycles is an object-sky pair).

FLAT_SAMPLING: choose AS_OBJECT in most cases

For Echelle users it is now possible for the data acquisition to take over-sampled flats with the same sampling factor as your object observations to help remove CVF ripple.

FLAT_LAMP: choose your required lamp. The numbers refer to black-body apertures. There is a table of flats of appropriate values as a function of grating wavelength and order. If you choose off then the calibration unit will not be used - useful for if you want to observe the sky, or the dome etc for a flat.

FLAT_ACQUISITION_MODE: Normally this will be NDSTARE

FLAT_EXPOSURE_SECS: typically 0.12 - 1 sec. See the table of flat exposure times.

FLAT_EXP_PER_INTEG: The number of exposures to be coadded into an integration. typically 50-100.

FLAT_INTEG_PER_OBS: The number of integrations to be taken and returned to the Vax. Typically 1.

ARC_LAMP: Choose your required lamp. There is a table of recommended arcs lamps as a function of wavelength. Plots of sample arc spectra can also be found at that page. If you choose OFF for the lamp then the calibration unit will not be used - useful for if you want to observe sky lines for wavelength calibration.

ECHELLE_ARC_CVF_WAVELENGTH: Defaults to the same wavelength as for your object observation.

Because the wavelength coverage on the array with the Echelle is not very large it is possible to observe at wavelengths where there are no lamp lines which would fall on the array. This allows you to select a different CVF wavelength from the grating, to look at lamp lines in a different order from your source.

If the value shown here is -1 the default CVF setting - ie the same CVF wavelength as for your object will be used. If you have just recalled or created a CONFIG then the default wavelength should appear here.

ARC_ACQUISITION_MODE: Usually NDSTARE

ARC_EXPOSURE_SECS: Typically 0.12 secs with the 40 l/mm grating and long camera.

ARC_EXP_PER_INTEG The number of exposures to be coadded by the into an integration at each detector sampling position. Typically 5.

All ARCS are automatically taken with the same sampling and sampling range as your object observations. Although on-chip exposure times are short, you should add sufficient exposures so that the time per sampling position is at least 0.5 secs, to prevent the background increasing due to the detector translation stage getting warmer.

ARC_INTEG_PER_OBS The number of integrations to be taken and returned to the Vax at each detector sampling position. typically 1.

CGS4 Latency

It has come to our knowledge that the 256 x 256 InSb array in CGS4 suffers from small scale  latent images. This problem has only become noticeable since long integrations have become possible due to the small pixel sizes in use with the long focal length camera.

In general, the latency only affects long exposures of very faint sources after previously observing a bright source (e.g., a standard star). The level of latency varies, but is usually less than about 5 counts (30 electrons) above the general background level.

The simplest method to rid the array of the latent image is to ask your TSS to run manpeak to take a few short exposures without changing the apperture, once you are pointing at your faint source.

If your targets are bright enough to peakup on, then the above procedure is unnecessary. The process of peaking up will remove any latent image.

CGS4 Object acquisition Procedures

Peak-up procedures with CGS4 seem to be a large source of confusion, especially for observers determining before hand what their requirements are in terms of astrometry, co-ordinates and reference stars. This page aims to clear things up a bit.

The complication arises in that there are many ways to attempt to ensure that you have accurately hit your target with the slit, all of which apply to different situations.

Concepts and Introduction

The aperture defines the position of the slit within the telescope focal plane. The default aperture is re-determined during engineering time whenever the instrument has been off the telescope, and at regular intervals inbetween. The aperture varies slightly with flexure etc. Fine adjustments to the aperture definition are made with the peak-up procedure.

The actual peak-up procedure is the process whereby the aperture definition is finely adjusted to give the maximum signal on the CGS4 array, whilst pointing at some (bright) target. This involves taking several (typically 15 or so) CGS4 integrations. Each of these must convincingly detect the object being peaked up on. It is possible to automatically subtract sky frames from the images used for peak-up. The integration time needed depends on the instrument configuration in use and on how bright your target is.

With the 40l/mm grating, peaking up on a target fainter than 14th magnitude takes a long time. If you need to estimate peak-up times for fainter targets or other configurations, refer to the CGS4 sensitivity page, and use the following: Calculate the exposure time for a 3 sigma detection of a point source at your target's magnitude. Multiply this by a factor 2 (to account for the fact that for most of the frames, you're not peaked up, so you're only seeing a fraction of the light). Multiply this by 15 (say 15 observations needed).

The Fast Guider is mounted on the cross-head. The cross-head can position the fast guider very accurately (~0.1") within the telescope focal plane. The crosshead limit is roughly a circle, 180" from the pointing centre (ie centre of the slit).

The Fast Guider brightness thresholds also vary with conditions. Because the fast guider works in the optical is is affected by scattered moon-light. In exceptional conditions - clear skies, exceptionally good seeing and no moon, we can guide on stars down to V magnitude of 18.7. A V mag limit of 16 or 17 is more realistic for average conditions. On fainter targets, we increase the integration time of the autoguider CCD, which reduces the Tip-Tilt frequency. On bright targets, we guide at 100Hz. We can go down to ~20Hz for faint sources. Bright sources are more likely to give you really good Tip-Tilt performance.

UKIRT employs a dichroic tertiary mirror, feeding the IR light to the instrumentation, and the optical light to the fast guider. This means that it is possible for the fast-guider and the IR instrument (eg CGS4) to observe the same target.

Trivial case - bright (~14th Mag or brighter in the IR) guidable targets.

In this case you guide on the target, and you peak up on it before you start taking data. The peak-up takes a few minutes.

No special co-ordinate, astrometry or guide star requirements.

Bright (14th Mag or brighter in the IR) non-guidable targets.

Reasons they might be non-guidable include: Target not point-like in the optical, or target is so red that despite being bright in the IR, it's too faint for the fast guider to see (see notes above).

In this case, you guide on an offset guide star (needs to be guidable and within 180" of target), and you peak up on the target.

Requirements: A guide star. You can pick one using the ORAC-OT preparation tool when you get to Hilo. You don't need any special astrometry. If your co-ordinates are off by more than an arc-sec or two, peak-up will take longer.

Intermediate brightness targets.

OK, the definition of "intermediate brightness" is non trivial. By this, I mean something you can guide on, but something that would take too long to peak up on. See the notes above about the fast guider sensitivity and peak-up times.

Procedure: The TSS will slew the telescope to a nearby (within a few degrees) bright CMC star, and will peak up on that whilst guiding on it. This ensures that the slit and fast guider are at the same place within the telescope focal plane. Then they'll slew back to your target and guide on it. Because peaking up on the CMC star aligned the guider and the slit, the slit will now be accurately placed on the target.

Note: The guider and slit will not move relative to each other over a small slew to the CMC and back. If it were a long slew, there would be concerns about flexure and differential refraction between the optical and IR beams.

Requirements: The TSS will locate a suitable CMC star as needed. You need reasonably accurate co-ordinates (ie within a few arc-sec). If the target is towards the fainter edge of the guider's capability, better co-ordinates will help. If the source is not point-like enough to guide on, treat this as a faint target.

Faint targets.

By "Faint", I mean too faint to guide on. This obviously implies also too faint to peak up on. There are several options in this case.

Blind offset

This is the most reliable way of acquiring very faint targets. You need an accurate astrometric offset between your target and a nearby (within 180") guide star (see notes above on fast guider for what qualifies as a guide star). You would usually measure such offsets from a deep image of your target field. By "accurate", I mean to within a fraction of the slit width you will be using. Say 0.2" for the 0.6" slit. The more accurate your offset, the more light you'll get down the slit.

Proceedure: Simply enter the RA and Dec co-ordinates for the target and guide star in the OT. Ensure that the co-ordinates you enter have the correct offset between them, taking into account the factor 15 between seconds of RA time and seconds of arc. When you slew to the field, inform the TSS that you have an accurate crosshead offset set, and thus to adjust the telescope position rather than the crosshead position to bring the guide star into the fast guider if necessary.

The TSS will ensure that the telescope pointing model is good prior to you starting to take data. This will involve at least going to a nearby CMC star, and probably doing a peak-up on it. If necessary they will collimate the telescope pointing model to the CMC star co-ordinates at this point.

Requirements: Accurate astrometric offset to a nearby guide star.

Blind Pointing

This is the "last resort" method, though the UKIRT Telescope Control System and Pointing model is sufficiently good that this method usually works well.

You would use this method if you don't have the astrometric offset to a guide star necessary to carry out the previous method. You do, however, need accurate absolute co-ordinates. You shouldn't rely on this method with the 0.6" slit. Many observers have had great success using this method to observe radio sources, with accurate co-ordinates from high resolution radio interferometers, using the 1.2" slit.

Proceedure: Type your accurate co-ordinates into the OT. Use the OT to find a nearby offset guide star. The TSS will go to a CMC star close to your field and collimate the telescope pointing model. When they slew back to your field, inform the TSS that the target co-ordinates are accurate, and to move the crosshead to bring the guide star into the guider if necessary.

Threats: You need accurate, co-ordinates. You might need to be aware of the co-ordinate frame your co-ordinates are referenced to (how well is this frame tied to the Hipparcos or Radio reference frames?). This method becomes less reliable in high wind conditions - during the time the TSS is adjusting the guider position to acquire the guide star, the telescope is sat on it's main drives, as opposed to being locked onto a guide star. If wind gusts are knocking the telescope around at this point, the drives are unlikely to be able to hold it in position to great accuracy.

Requirements: Accurate absolute co-ordinates.

Absolute Desperation

If your targets are too faint to guide on, and you don't have either sufficiently accurate co-ordinates or astrometric offsets, then your best option is probably to use some time at the start of your observing run to get UFTI images of your fields, from which you can measure offsets in order to do a blind offset. You should discuss this with your support scientist and Paul Hirst, the CGS4 instrument scientist, well in advance of your arrival in Hilo.

Preparing for CGS4 observations with the ORAC-OT

This document overviews the preperation phase of observing with CGS4 under ORAC. This mainly involves the use of the ORAC-OT - the Observing tool. Whilst you will no doubt be running the OT whilst you are observing to make any last minute changes, you should have the bulk of your preperation done before arriving at the telescope.

General ORAC-OT introduction

The general ORAC-OT documentation overviews the various concepts of the ORAC system, and makes a good introduction to this more specific document on how to use the ORAC-OT to prepare for CGS4 observing.

Getting started with the ORAC-OT

First up, launch the oracot and open up the "UKIRT Template Library" from the file menu. Also in the File menu, select "new program" to create yourself an empty program.

Now a trivial example of editing soemthing: In the new program window that just appeared, double click on where it says "Science Program". An edit window appears immediately to the right of your science program window. Type in a title for this science program into the box labeled "Title". Ignore the other fields.

Basically, you prepare your science program by copying items from the template library, and editing them to your needs. In the template library, open the CGS4 folder by clicking on the little handle icon to it's left - the handle twists down and you can see the contents of the section. You should see a list of template cgs4 observations, looking somewhat like this:

Adding a Flat and Arc

Next, you will want to take a flat field and arc lamp observation. Drag over the "flat and an arc" observation from the template library. This time, when you drop it, you'll want to have the pointer over your array tests, and you should see a white and red arrow sign, with the arrow pointing straight down.

A note on the little arrow signs: The arrow pointing straight down indicates that when dropped, the new item will be placed below the one where the arrow appears. A diagnoally down/right arrow indicates that the idem will appear inside the one where the arrow appears. We'll see more of this later.

At this point, you might like to change the title of the flat and arc, for example to add a comment about which band this is. Do this in the same way that you edited the title for your science progam.

Now, we'll look inside the flat and arc at the components that make it up. Click in the little handle next to "flat and an arc" to expand the view. Notice how things inside other things get indented to the right (inside the flat and arc observation are four components, one of which is a "Sequence" component, itself containing more items). Whenever something contains things inside it, it has a little handle sign to it's left, demoting whether it's being displayed expanded (handle vertical) or condensed (handle horizontal). Simply click the handle to toggle this. Things should now look like this:

The "CGS4" component contains the instrument configuration for CGS4. Double click on it to bring up the CGS4 configuration editor into the right hand panel of the window:

Edit any of the values as necessary. Don't worry about the exposure time and coadds that you set here, as these ones aren't actually used - the exposure times for the flat and arc are set specifically, as we'll get to shortly. When you're happy with the values, click on the "Flat" component inside the sequence. You should get a flat component editor looking like this:

Note carefully: The parameters for the flat field observation don't automatically update if you edit the fields in the CGS4 configuration component. To have the software estimate the flat field parameters based on what's set in the CGS4 configuration component, click the "Default" button in the flat field editor. If you then go and change the settings in the CGS4 component, you'll need to go back into the flat field and hit default again. If after taking a flat, you find that the default values aren't quite right, then you can simply edit the exposure time etc directly in the flat field component.

Now go into the Arc component, and hit the default button to get the default arc parameters for the configuration you've selected.

Adding a Standard Star

We have a library of bright G stars built availiable in the OT to speed things up here. Don't worry if you want to use a star that's not in there, we'll get back to that shortly.

Open up the CGS4_bright_G_library from the file menu of the main OT window. Simply pick a star, then drag it into your science program, taking care when you drop it that you've got a vertically downward pointing red and white arrow sign on the flat and arc observation. You might want to collapse the display of the flat and arc first, by clicking the little minus sign to the left of the "flat and an arc" label.

Once you've got a star there, you need to edit that observation to match the configuration you're actually using. There's an easy way to do this. First expand the flat and arc observation and the standard star observation so that you can see all their components. You don't need the details of the sequence at this point, so you can collapse the sequences in each to save screen space if you like. Now double click the cgs4 component in the standard star, and note the magnitude of the star. Now, single-click the CGS4 component in the flat and arc observation, and click the copy button (the one on the right of the scissors (cut) button). Now single click the CGS4 component in the standard star, and hit the paste button (the one to the right of the copy button - looks like a clipboard). When it asks if you want to replace the component, say yes. Now double click the CGS4 component in the standard star to get the editor window back, and set the magnitude back to what it was. The software will then autmatically set the exposure time and co-adds for that magnitude. you can over-ride these manually by simply changing the values. We're still working on the defaults so you might have to do this. The best thing to do is to ask your TO for the count rate after they complete the peakup, then set the time to give you around 3000 counts.

Adding a Target observation

First of all, you have to decide which of the observations in the template library is most appropriate for your target. For point sources, this is probably point source, nod along slit. For extended sources, you'll want extended source, nod to blank sky. If you are in doubt as to which sequence to use, ask your support scientist or contact the CGS4 instrument scientist for advice.Drag the one you want from the template library into your science program. As an example here, we'll use the point source, nod along slit one. Drop it so as to appear after your standard star.

Now, in your science program, double click on where it says "point source, not along slit" and in the editor panel that pops up, type in a title for this observation. This isn't used as the target name or anything, it's for your own reference, and should be reasonaby descriptive as you will choose this name from a list of your observations to specify that this is the one you want to observe.

Setting the target co-ordinates etc

Now click the little handle next to your target observation to expand the view, and click on the "Target List" component. In the panel that appears, fill in your target name (this is what will go into the data headers etc) and the RA and Dec of your target. If you wish, you can enter a target name and click the "Resolve" button to have the OT query the target name on SIMBAD and get the co-ordinates from there. If you want the name resolver to query an different database, simply select it in the pull down to the left of the resolve button.

Next, we'll go into the plot window to check things and to set a guide star etc. Click on the "Plot" button in the lower left of the target editor window. In the window that appears, go into the "Calalog" menu and under "Image Servers", select "Digitised Sky at JAC". After a pause and some flashing lights, a digitised sky survey image of the sky area you're looking at should fill in. To the lower left of the image are a set of togle buttons, collectively labeled "View". Turn on the ones for "Sci Area" - shows the slit, "Dichroic" and "X-head" - the latter two between them show you the area of sky from which you can select a guide star. Now go to the "Catalog" menu again and under "Catalogs", select "Guide star catalog at CADC". When the progres box disapears, a list of HST guide stars will have been loaded. Turn on the "Catalog" view button, and these will be highlighted on the sky survey image. To manually inspect the list of stars, select "Browse" from the "Catalog" menu.

To the left of the window, there's a selection of buttons labeled "Mode". Click on the one labeled "GUIDE", now point and click on the star that you wish to use as a guide star. If you select one of the ones from the catalog, the positions from the calalog will be used. If you prefer, you can just click on a star at any position on the sky survey image. If you're doing this, then you might want to use the zoom facility to give you more accuracy. You must select a star that is within the purple X-head circles (and avoid ones close to the edge as you're going to be nodding) and not hidden by the green dichroic edges (again, and not too close).The position editor window should now look something like this:

Returning to the target editor panel in your science program window, you'll notice that it has filled in the guide star co-ordinates you chose, and if you edited your position using the "drag" facility, the co-ordinates have updated.

Setting Exposure times etc

Next, go back to the flat and arc observation and copy the CGS4 component again. Replace the one in your target observation with this, then go into it and set the magnitude or exposure time that you wish to use.

Note: The BL option in the magnitude pull down selects the minimum time necessary to become background limited. You might want to observe for longer than this, but bear in mind that the time between nods equalls this time multiplied by the coadds and the sampling. See the CGS4 handbook for more details.

The sequence

The only thing you'll usually wish to change in the sequence is the number of repeats. The "Offset" itterator executes a 4 position jitter (Object - Sky - Sky - Object). The repeat iterator sets how many times to repeat this sequence. Simply double click the repeat iterator and set the number.

Data Reduction Recipies for CGS4

In general, if you based your observations on the template library, the DR-RECIPE component will be all set up for you, and you won't need to chnage anything.

The ORAC-DR section of the CGS4 manual provides more info on what the individual recipies do and the observing sequences they are appropriate for. If you are unsure or if you think you will need a recipe that is not provided in our standard selection, you should contact your support scientist or the CGS4 instrument scientist well in advance of your observing run.

The Mauna Kea OH Line Emission Spectrum

At the bottom of the page are links to more detailed spectra of individual regions of each band. Use these to check the details of the OH emission lines in your wavelength region of interest. The spectra were wavelength calibrated using this table of OH wavelengths.

• Please be aware that each spectrum is not shown to the same scale. The OH lines in the H window are much stronger than in K, and those in K are stronger than those in the J band.
• The flux units are given as counts, 1 count = 6 electrons, and are per pixel per 100 seconds.
• The spectra are not corrected for atmospheric transmission.
• Wavelengths are in vacuo.
• The solid angle for a 0.61" x 0.61" pixel is 8.7455x10^-12 sr
• The data were obtained by Tom Geballe and Tom Kerr on UT date 1997 19 December
• The CSO taumeter read approximately 0.05 while the data were obtained. This corresponds to an H₂O column of 1mm, a good night on Mauna Kea.

J Band

H Band

K Band

Individual wavelength regions

The spectra below show individual spectral segments covered by the 150 l/mm grating at the listed wavelengths. Approximate airmass is given in brackets. In the J band 3rd order was used (wavelength coverage 0.055um), 2nd order was used for H & K (0.08um).

J Band

H band

K band

Atmospheric Transmission

See the details in the UKIRT astronomy calibration area, here.

Atmospheric Extinction

Suggested Flat Exposure Times

40 l/mm grating:

150 l/mm grating:

Echelle:

1. Write an astronomical config for the wavelength you wish to observe at.
2. Set to this config using the Set_Single_Observation menu in the CGS4 software and specify a flat observation.
3. Select "Movie", select an exposure time in "Set_Movie" (e.g., 0.5 secs) and then "Run_Movie"
4. Note the counts on the movie screen.
5. Select "Direct_Motor_Control" and select another blackbody aperture. You will see the counts change.
6. When you are happy with your selection (i.e., 3000 - 4000 counts) abort the movie and edit your config with the appropriate numbers.

CGS4 Arcs

For a given wavelength, we do recommend that specific arc lamps are used. These will give the best coverage of unsaturated spectral lines. They are:

List of available arc spectra.

Below is a list of arc spectra obtained with CGS4 at UKIRT. You may use these to help wavelength calibrate your CGS4 data both during and after your run. Currently, only low resolution spectra (75 l/mm grating, short focal length camera) are available on the web.

Lamp lines in the 3 to 5 micron region cannot be observed due to absorption by the lamp bulb glass. However, you can obtain lines in this region by observing 1 and 2 micron arc lines in 2nd order. In the spectra listed below, we have not indicated the wavelength value in 1st order for lines beyond 3 microns. If you are interested in this number, simply divide the indicated value by 2.

GIF files:

Argon

Krypton

Xenon

PostScript files:

Shift-Click these to save them to local disk.

Argon

Krypton

Xenon

Observing with CGS4 and ORACDR

This document gives a guide to the oracdr pipeline for CGS4 data. It will give you a preview of how your data will be reduced and displayed whilst you are at the telescope observing. It might also be usefull for anyone running oracdr on CGS4 data offline.

General ORAC-DR documentation

The ORAC team have produced some general ORAC-DR documentation, which overviews the software. The rest of this document gives information specific to using ORAC-DR with CGS4.

Running up the pipeline

Type runup at a shell prompt to get current instructions on starting the pipeline.

Other things to note: If for some reason you need to stop the pipeline at any point, simlpy issue a Ctrl-C in the xterm window where you started it. If the pipeline is part way through a recipe at the time, several Ctrl-Cs might be required, and there will be a short delay before the pipeline exits.

If you suspect that the pipeline did not exit cleanly, issue the oracdr_nuke command to tidy up any crash debris.

To re-start the pipeline, use: oracdr -loop flag -from NUMBER, where NUMBER is the frame that you want your re-started pipeline to start from. You should generally re-start the pipeline from the first observation in a group. If you're not sure where the group starts, the oracom window shows you the current group number, which is equal to the number of the first frame in the group. If you're a group or more ahead of yourself, then see the later section on viewing or re-creating a nightlog file.

Display Overview

You can change what the pipeline display system shows you and how it displays it by editing the disp.dat file, either directly or by using the oracdisp utility.

The default displays should be fine for most people. These are described here. The main reason why you'd want to change anything from the defaults at the moment is that when plotting a spectrum, the display system will autoscale, which you don't want to do if there's a large spike or other anomoly in the data. See "Changing the plotting scales" below for more details.

Generally, two windows are used to show you data as soon as possible after it comes off the array; one GAIA window, which shows you an image containg the data, and a KAPPA view window which shows histograms, extracted spectra and the like.

A similar two windows are used to show you more reduced data to display intermediate results and show you how well you're accumulating your signal to noise ratio etc. A GAIA window shows you the current group file image - ie the sky subtracted frame, or the difference of the main beam and offset pairs aquired so far. A KAPPA window is then used to show you the divided by standard and flux calibrated spectra.

Changing the plotting scales

The pipeline display system is controlled by a text file called disp.dat, which resides in your $ORAC_DATA_OUT directory. You can edit this file manually with your favourite text editor, or you can use the oracdisp utility.

The disp.dat file contains one line for each type of data that is to be displayed, specifying the file type that this refers to, the plotting tool to use and various parameters of the plot - ie axis scales, autoscaling etc. One important thing to remember is that the display system allways works in array co-ordinates, ie. x is wavelength, y is along the slit, and z is the data value.

To turn off autoscaling of your spectral plots:

• Go either to the xterm where you launched oracdr from, or get a new xterm and run oracdr_cgs4 in it.
• run oracdisp
• Select the line for the type of plot you wish to change. This will probably be DBS for the divided by standard spectra, or FC for the flux calibrated spectra. Double-Click on the appropriate line in the lower pane of the oracdisp window. You may have to scroll down using the scrollbar to find the line you want.
• In the upper portion of the oracdisp window, find the Z: line and click the button next to "Set" to go from autoscale to set mode, and change the zmin and zmax values to the axes range you would like displayed.
• Click the "Modify" button at the bottom of the top pane of the oracdisp window.
• Click the "Configure" button at the bottom of the oracdisp window.

Starting Observing

Array Tests

The first data you should take are the ARRAY_TESTS data. When the first of these frames arrives, two of the aforementioned display windows will be opened to display them.

When the array tests have completed, oracdr will analyse them and print out a message telling you whether the array performance is as expected. The actuall text should end with something like this:

Double correlated readnoise = 40.1 electrons is nominal
Median Dark current =  0.89 is nominal
Modal Dark current =  0.44 is nominal

If it declares any of the values to by HIGH, then you should consult your support scientist, or the CGS4 instrument scientist, for advice. LOW values are beneficial, not a problem!

Flat and Arc

After completing the array tests, you will probably want to take a flat field and an arc spectrum. These serve as a good example to explain what gets displayed.

First of all, a GAIA window opens up showing your flat field frame. If you move the mouse cursor over the image, you can read off the data value at the current mouse location in the box labeled Value towards the top right of the numeric display area. The window should look somewhat like this:

Next a KAPPA window opens. The top left quadrant shows a histogram of the data values in the flat field frame, the bottom left quadrant shows you a histogram of data values in the normalised flat fied, and the bottom right shows you an image of the normalised flat field. It should look somewhat like this:

You should use the GAIA window and the Histrogram display to check that your flat field frame has sufficient counts - should be around 3000 in the brighter areas, and not more than around 4500, where the array responce starts to go non-linear.

If the count rate is not suitable, then go back to the OT, and edit the flat field component - adjust the exposure time, or the black body lamp apperture if necessary.

Next, your Arc spectrum should arrive. Again, the frame will be displayed in the GAIA window and a histogram of data values will be plotted in the top left of the KAPPA window. Again, you should check for a suitable number of counts in the data and adjust the exposure time if necessary. You should also check for a suitable number of lines to wavelength calibrate the spectrum. You could try one of the other arc lamps if you are low on lines. Do these by editing your program in the OT.

The lower right panel in the KAPPA window shows you the arc spectrum with an estimated wavelength scale on it (this is derived from the grating parameters (angle, order etc) reported by the instrument). Use this to identify a few lines and check that your wavelength region has been selected with suitable accuracy.

What actually gets displayed

OK, time for a word on what's actually getting displayed.

First up, the GAIA window. We do simply display "raw" data here, but this isn't necessarily easy to interpret - there may be multiple integrations in your observation ( see the note on exposures, integrations, observations and co-adds), and/or the data might be oversampled by array stepping. The pipeline replaces the display of raw data in the gaia window with the data in a form more easy to interpret as soon as it has been reduced into such. In fact, this goes through several iterations. Usually, you end up with a _wce frame in the gaia window, which is the most reduced form that single frames go to.

Next up, the KAPPA window. the top left quadrant of this allways shows you a histogram of data values. The actual image that this comes from is the same one as what gets displayed in the GAIA window. Note that especially with the echelle, the histrogram can be changed significantly by the flat-fielding step, as echelle flat fields can have significant CVF gradients across them, and thus when normalised, still contain a range of values. Thus, if you want to check whether you're saturating, make sure you check a pre-flat-fielding frame when using the echelle.

The top right of the KAPPA window, shows you the "bgl" file. This is a frame that shows you how background limited your observations were. The colour scale for this image goes from 0 to 2, where 1 is when the Poisson noise from the number of detected photoelectrons equals the readnoise of the array. For maximum sensitivity to faint objects, your exposures should be long enough to make almost all the pixels background limited - ie this frame should be well filled with values greater that 1. Of course, when observing bright targets, this is not possible as to do so whoudl saturate the array on the target.

When you're observing a Flat, the lower half of this window shows you the histogram of pixel values from the normalised flat field frame on the left, and an image of the normalised flat field frame on the right. You shouldn't be able to see large amounts of structure in this image other than the bad pixel mask which will be apparent.

Other than when taking flats, the lower right panel of the KAPPA window shows an extraction of rows 139-141 of the lastest image, with an estimated wavelength scale applied. Thus, this is useful for checking wavelength regions with arc observation. During normal observations of a target on the sky, this will show either a simple extracted spectrum of your target, with no sky subtraction, or a sky spectrum, depending on whether you're observing in the main or offset position at that time. This assumes that you are using the conventional peakup row for your targets (row 140).

The lower right of this KAPPA shows you the y-profile of your sky subtracted group image, once you have observed sufficient data to form the group image. Generally, this is useful to see how well you're detecting your object and to check that you're getting equal flux in all beams if you're nodding (or chopping) along the slit. If you see here that your beams are unequal, you may need to stop and do a 2-row peakup.

Continuing Observations

Once you have completed a pair of main and offset beam observations, the pipeline forms a group file, into which it subtracts the main and offset images. This image is then displayed in a seperate GAIA window, the spectrum extracted from both rows in it is displayed in the top half of a second KAPPA window and the y-profile is displayed on the lower left of the first KAPPA window and mentioned above. Examples:

If this object has been flagged as a standard star (in the OT), then the pipeline will consult the BS catalogue or SIMBAD to determine the spectral type (and hence temperature) and V magnitude of the star (which are displayed in the extracted spectrum title). It will use these to create a black body model of the star (nb. no interpolation over stellar features currently takes place), which will be used to flux calibrate subsequent data.

As soon as you have observed a non standard star tagret in the main and offset beam positions, a group file will be created and displayed and spectra will be extracted and displayed as before. An additional KAPPA window is created to show you the extracted spectrum (_sp) and flux calibrated (fc) spectra. These are obviously all updated as more data is observed and signal to noise ratio is accumulated. Examples follow:

/

Creating and viewing the Nightlog

The nightlog is a software generated text file, summarising the observations over the night. This file is created when the pipeline sees the first data of the night, and a one line entry for each frame is added as it is reduced by the pipeline. The file is in your reduced ($ORAC_DATA_OUT) directory, and has the name UTDATE.nightlog, where UTDATE is obviosuly the current UT date (eg 20000915.nightlog). If you stop and re-start the pipeline, and any frames are processed twice, they get two entries in the night log file.

During the day, after you finish observing, a nightlog file is automatically created in your raw ($ORAC_DATA_IN) directory, containing the whole nights observing. If the file in your reduced area gets into a mess, you can create the one in your raw area showing the observations so far. In a new xterm window, issue the oracdr_cgs4 command to setup the pipeline, then use something like: oracdr -log sf -skip -resume -from 1 NIGHT_LOG to create the nightlog file. A full version containing the whole night will be created here during the day anyway, overwriting any part-night one you leave there.

Nightlog files are best viewed by stretching an Xterm window to be at least 132 columns wide, then simply using more to scroll through the file.

Changing your mind about the recipe

Or - the DR keeps complaining about the flat and exiting

Occasionally, you will find that for some reason, the recipe that you specified whilst you were using the OT is nolonger appropriate, but you've allready started taking data with that recipe. This will usually be brought to your attention by the fact that oracdr will complain that it's unable to reduce the data and will exit. Normally, this is due to the absence of a pre-requisite for the recipe that you have specified. Most of the recipes use a flat field, and will fail if there is not one availiable. The target recipes that attempt to divide by a standard star observation and flux calibrate the data will fail if there is no suitable standard star.

There seem to be a few common reasons why this occurs:

• You're convinced that you have taken suitable calibration data, but oracdr refuses to use it for some reason.
• Your obsject is about to set, so you intentionally deffered taking flat, arc and standard star observations untill after your object frames.

Starting with the first case. Oracdr will tell you why it is refusing to calibrate, even though it can be a bit crypic sometimes.

First a note on notation. We refer to flats, arcs and other similar frames as calibration frames.

The first thing to check is that oracdr knows about the calibration data which you consider to be suitable. The pipeline keeps an index of calibration frames, and looks to this index to find a suitable one when it needs one (eg to flat field some new data). It adds the details of calibration frames to this index as they pass through the pipeline, therefor if the frame (say the flat field) hasn't been reduced by the pipeline - say for some other reason you didn't have the pipeline running when you took the flat field data, the oracdr doesn't know about the frame and thus won't use it. Simply pour the calibration data through the pipeline with a command like oracdr -list NN where NN is the frame number of say the flat field, then restart the pipeline on the frame where it fell over. If you did a sequence like Flat, Arc, star, target, then you might want to simply re-start the pipeline from the start of that sequence - ie oracdr -loop flag -from NN.

If the pipeline has processed the calibration data, but still refuses to use it, examine the output of oracdr to find out why it refuses to use it. Whe oracdr requires a calibration frame, it works backwards through it's index file of that type of frame (eg flat fields. The actuall index is a human readable text file - in this case index.flat in your reduced ($ORAC_DATA_OUT) directory), checking the headers of the indexed frames against a rule set to see if they are suitable. It will use the most recent frame that matches the rules for use. Typically, the rules file specifies that the optical configuration must be the same for the calibration and data frames - ie the grating, order, wavelength, etc etc must match. With CGS4 there is the added complication that if you move the motors to change from one optical configuration to another, then attmept to move back to the original, the optics will be at slightly different positions, simply due to the inability of the motors to position that accurately. This effect is such that flats and arcs taken before the change and change-back are NOT suitable for calibrating the data. Therefor we have this concept of a configuration index - the CNFINDEX FITS header. This is simply an integer which gets incremented each time an optical configuration motor is moved. We demand a CNFINDEX match between data and calibration frames to be sure of suing appropriate calibration frames. Therefor if you took flats and arcs then moved the motors (perhaps something failed and you had to re-datum, or you accidentally ran the wrong sequence), you need to re-do your flats and arcs.

OK, now onto the second case where you deliberately don't have the calibration data because you decided to defer those observations untill after you'd observed your target (most likely because it's setting on you, or there's some other time-critical constraint). Now, or course, it's impossible for the DR to do the normall reduction sequence, but you still want it to display your data s it comes in, as best it can, so that you can see how you're doing. The best way to do this is to specify an alternate recipe wih which to reduce the data. Note. This doesn't change the recipe specified in the headers of the data files, it simply forces oracdr to use a specified recipe for the moment. The recipies you are most likely to want in this situation are the ones ending in _NOSTD (it it's trying to divide by standard and flux calibrate, yet you don't have the standard star observations yet) or the ones ending in _NOFLAT if you don't have a flat field yet.

Later on, when you come to re-process the data after you've taken the necessary calibration data, all you have to do is reduce the calibration frames before the target frames, by means of the -list option to oracdr, then when you process the target data, it will use the originally specified recipe, with the correct (albeit taken later) calibration frames.

Data Reduction Recipies for CGS4

In general, if you based your observations on the template library, the DR-RECIPE component will be all set up for you, and you won't need to chnage anything.

The ORAC-DR section of the CGS4 manual provides more info on what the individual recipies do and the observing sequences they are appropriate for. If you are unsure or if you think you will need a recipe that is not provided in our standard selection, you should contact your support scientist or the CGS4 instrument scientist well in advance of your observing run.

CGS4 data files under ORAC

Raw files in $ORAC_DATA_IN

The CGS4 raw data files are now stored as starlink HDS containers. Each file is equivalent to 1 observation, and as such contains a header component and 1 or more (actually NINT) integrations. Each integration is stored as an NDF component of the HDS file.

The filenames are thus: cYYYYMMDD_NNNNN.sdf, where YYYYMMDD is the numeric UT date (year, month and day) and NNNNN is the observation number, padded with leading zeros when necessary.

Reduced single frame files in $ORAC_DATA_OUT

First, some conventions:

The filename structure is: (PREFIX)(UTDATE)_(FRAME NUMBER)[_(EXTENSION)].sdf, where (THIS) is allways there and [THIS] is optional.

(PREFIX) is the letter 'c' if the file contains data from a single observation. It is 'gc' if the file contains data from a number of observations - ie a group.

_(EXTENSION) is used by individual primitives (think of a primitive as a single step within a recipe) for their output files. The pipeline its self keeps track of passing these files between primitives, though all the useful ones are left on the disk at the end so you can look at intermediate data products if you wish.

For example, c20000410_00123_ff.sdf would be data from a single observation, number 123, that has been flat fielded (the table later tells you the _ff means flat fielded).

So is that and HDS or an NDF?

Well, often, it depends; the pipeline passes files between primitives as either HDS or NDF, depending on which is most appropriate. For example, with 2x2 sampled data, the raw file will be an HDS container containg the 4 NDF data arrays from the 4 sample positions. If we're using a 1x1 sampled flat field, the flat field primitive will flat field each component, and write out an HDS container containg the four flat fielded data arrays as NDFs. On the otherhand, if the flat field is taken with the same sampling as the data, the pipeline will interleave the samples of both the data and the flat field before carrying out the flatfielding, thus the _ff file would be a single NDF.

Of course, some primitives will only write out single-NDF files; for example, the primitive that interleaves and/or coadds the samples into one larger image writes out _inc files, and these are allways single component NDFs.

An additional factor is that later on in the processing, the pipeline may go back to using HDS containers. This happens for example when we start extracting beams and spectra from the reduced group image - HDS containers are used, containing information for each beam - for example opt-extract profiles, and the spectra themselves, whilst they pass through the primitives that operate on the individual extracted spectra before these are combined to give the final spectrum - for example de-rippling.

This figure illustrates the data flow between primitives for the reduction of a typical single frame.

Reduced group files in $ORAC_DATA_OUT

The pipeline adds the individual frames into the group as they are processed. The group number is usually the frame number of the first frame in the group. Group files are allways single NDFs.

Introduction

This guide is not meant to be a complete cgs4 data reduction manual. It outlines the steps a typical UKIRT/CGS4 observer will want to carry out on their data after the observing run. These steps could be carried out using many different data reduction packages, for example starlink or IRAF.

I will assume that you have a nightlog file from the orac-dr pipeline, and that you have the _wce files for each science frame, which will consitute the starting point for this guide. I will also assume that the _wce files you have have been processed satisfactoraly by the pipeline, and have been flat-fielded. This will usually be the case.

Stage 1: co-add into groups.

With reference to your nightlog, select the _wce files that consitute each "group" of observations. A group would typically be an observation of one target at one instrument configuration.

Inspect each of these frames and check for any obvious defects. If you discard and frames, be sure to discard the same number of main-beam and offset-beam frames. The main-beam frames will have 0,0 as the RA and DEC offsets in the nightlog, the offset-beam frames will typically be 11.74 arcsec away from 0,0. If you were nodding to blank sky, the offset will be much larger, and the offset-beam frames will also be SKY frames.

Form a group frame which consists of the sum of all the main beam observations minus the sum of all the offset beam observations.

Do this for each group of observations you are going to reduce at this time. You should at least have a standard star group and a target group at this point.

In these group files, the "sky" areas should be relatively free of sky-lines. Sky line residuals up to a few tens of counts can be removed (see later). You should have a positive band acorss the image representing the positive image of the spectrum of the target. If you were nodding along the slit, you should also have a negative band across the image representing the offset-beam negative image of the target spectrum.

If your observations spanned a long time interval, ie a large change in position of the telescope as you tracked the object across the sky, then you should consider adding your observations into "sub-groups" of an hour or so's data, extracting the spectra from each of these seperately, then doing a cross-correlation to determine any shift due to instrument flexure, and applying this shift before adding the spectra together

If you wish, at this point, you can subtract off the residual sky lines. Use your favourite DR package. You should mask off the areas of the image containing the target spectra, then have the package fit a low order polynomial to the residual sky flux in each column. The polynomial fit should then be subtracted from the whole image, including the areas where the target spectra are, obviosuly.

Stage 2: Extracting the spectra

Extract the +ve and -ve images of the spectrum seperately. You can use optimal extraction if you like, and if you used the same nod distance for the standard star, you can use the standard star observations to generate the profiles with which to optimally extract the target spectra. After you extract the -ve spectrum, multiply it by -1 to make is positive. Keep the profiles that you use around for later use.

Check for a shift between the specta. This needs to be done on something bright; I suggest doing it only on the standard star spectra, however if your target is brighter than your standard (you might have been doing monitoring, or looking for weak lines on a strong continuum etc), then you could do it to the object spectra too.

Basically, cross-correlate the main-beam and offset-beam spectra. If you get a shift of more that say 0.2 pixels, shift the offset beam spectrum to match the main-beam spectrum. If you're only measuring this from the standard star spectra, apply the same shift to the offset spectrum from the target data too.

Add the main and offset beam spectra together. This forms the "observed spectrum" of each object (be it the standard star or your target).

It'll probably keep things simple if you normalise each spectrum by its exposure time at this point.

Stage 3: Wavelength Calibration

You'll have noticed that the data allready have a wavelength scale. This is approximate - it's from an estimation based on the cgs4 motor positions. You should now do an accurate wavelength calibration using the arc spectra you took.

Look at the nightlog file and find the _wce frame for the arc-lamp observation you're going to use. This will normally have been taken shortly before the 1st standard star at that confiuration. If several are availiable, use the one at closest telescope position to where your target was observed, to minimise effects from instrument flexure.

Extract a spectrum from the arc frame, using the same rows you used for the target frame main-beam. If you did an optimal extraction, use the same profile as you did for the main-beam.

Use the arc-lamp maps on the web to identify the lines in your arc spectrum. Use the wavelength calibration routine in your data reduction software. The principle of these routines is that you tell the software the exact wavelength of a number of lines. The software measures the position of the peaks of these lines and comes up with a function to relate the wavelength to pixel number. You should use as low-order function as gives a reasonable fit. A 3rd order polymonial is usually sifficient, though 5th order is sometimes usefull, especially if you have a large number of identified lines in your arc spectrum.

Apply the calibration you've just generated to the target and standard star spectra you extracted earlier.

Stage 4: Flux calibration

There are many ways to do this. This what I do for a reasonably simple case

Create a black-body model of the standard star

Look up the spectral type of your standard star. Each spectal type corresponds to a black body temperature. There's a table of these on the ukirt web pages. Have your DR software generate a black body spectrum at the appropriate temperature, on the same pixel and wavelength scale that your standard star is on.

Next, deduce the flux of your standard star at some wavelength which is on your spectrum. Usually you'd use the band centre, and you'd deduce the flux from either the known magnitude of the standard in that band, or the magnitude in some other band, determining the colour from the spectral type. Scale your black body spectrum so that it has the correct flux at this wavelength.

Create a sensitivity spectrum

Take the black body spectrum you've just made (which you've scaled to be in flux units, say W/m2/um), and divide it by the "observed spectrum" of your standard star (which is probably in counts per second or similar). This gives a sensitivity spectrum - ie the value at each wavelength is the flux needed to produce 1 count per second at that wavelength.

BUT, there's a small problem in that the standard star probably doesn't really have an exact black-body spectrum. It more than likely has some lines in it. You should be able to identify these lines in the sensitivity spectrum. Ask a local expert or your support scientist if you're not sure. Different types of star have different lines. try starting off looking for hydrogen recombination lines.

When you find a feature in the sensitivity spectrum that you think arrises from a line in the star, interpolate over it using the "continuum" either side of it.

Apply the calibration

Simply multiply your sensitivity spectrum by your "observed spectrum" of your target, to get a flux calibrated spectrum of your target.