|
|||
| Joint Astronomy Centre |
|
|
|
| Show document only |
The Telescope Systems Specialist (TSS)
will run the instrument up and down.
The TSS runs UIST from the "cassControl" gui. (Note - cassControlEng gives a similar Gui, though data are then saved to engineering directories.)
From the above window open the uist_oper screen. From here, datum the wheels and turn the black-body on. (Use the uist-ccs console to reboot the CCS [mechanisms - grism, filter wheels, etc.] if necessary.) To run-up UIST the TSS and observer simply run through the steps on the left of the window:
The run-down sequence is displayed in red (steps [6] to [9]).
IMPORTANT: In you are unsure about whether the array is enabled or disabled, check the LEDs on the controller in the dome. Most of the green LEDs should be OFF. Once the software has been run down, set UIST to dark from the uist_oper screen, switch off the black-body and arc lamps, and put the calibration unit in the beam. ENGINEERING: Instead of running cassControlEng, "ocs_up -simTel -eng" can be run from the command line, together with "uistMenu". NUKE: use this to kill drama and rtai processes if you are having problems running up.
Preparing an Observing Programme: the UKIRT-OTFIRST TIME USERS: Please read the General Introduction to the OMP before reading the notes below (which are specific only to the IFU). If after doing this these notes are still as clear as mud, try the long-slit spectroscopy page on programme preparation. Your complete observing programme can be prepared either in Hilo or before you arrive in Hawaii from your home institute (provided you have access to the ukirt-ot). From any Unix or Linux box in Hilo (or at the summit) type ukirtot to run-up the observing tool (the OT).
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 ORAC, close the copyright box and read on... The UIST Template Library The expectation is that most users will work from "Template observations" (available Template observations are described on a separate page - a table of DR recipes is also available). The "Template Library" contains observations that can be modified to suit your specific needs (see Fig.1). It is probably unwise to try and write an observation completely from scratch. Thus, with this in mind, 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 the one shown in Fig.1 - will appear. In the template library, click on the button to the left of the "folder" icon labelled IFU templates. There you'll find the available observations or "sequences" for IFU spectroscopy. Examine those that may be of use to you by clicking on the button to the left of the blue/pink icon; the component observations should be displayed as a flow chart, as in the example below. Like ordinary spectroscopy, an IFU observation should comprise a flat, an arc and a sequence of "object" and "sky" exposures of a standard star, followed by a similar sequence of object/sky frames on the target itself. The example below contains all of these components. Point sources should be "nodded" in and out of the IFU field of view, unless the seeing is very good, in which case it may be possible to nod the star between the top and the bottom half of the elongated IFU field. Subtraction of the sky frames from the object frames will remove OH line and thermal background emissions, giving a series of spectra in adjacent slices in the scrunched spectral image. An arc spectrum will be used by the DR to accurately wavelength-calibrate the data, and a similarly-reduced standard star spectrum can be used to divide out atmospheric absorption bands and flux-calibrate the source spectra. The DR will then "chop up" the scrunched spectral image and create a data cube (see the ORAC-DR pages for full details). For an extended source, nodding to blank sky is likewise necessary. A larger nod (than the default in the template observation) may be necessary. Flexible Scheduling and Minimum Schedulable Blocks: From semester 03A onwards all UKIRT observing will be 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. In the OT, an MSB is represented by a blue and pink cube. 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. For IFU spectroscopy, an MSB usually includes flat, arc, standard star and target observations. Flats, arcs, standards... In Fig.1 the "IFU, Nod to blank sky" MSB has been opened; it contains a Calibration (flat and arc) observation , a Bright (standard) star observation and a Science target observation. UIST must be set up in exactly the same way for the flat and arc as for the standard and target observations (i.e. same position angle, grism, etc.). This is achieved by placing the UIST component (the broken blue square labelled UIST in Fig.1) above the three observations. The observations then "inherit" the UIST component parameters; the slit width, position angle, grism, etc. Only the exposure time is changed in each observation, as described below. The flat and arc have default exposure times, set by clicking "Use defaults" in the flat and arc observations. The UIST instrument component and Target component are described further below.
 Fig.1 An IFU Observation in the template library (click for a full-sized image).
The components of an IFU observationEach observation (the blue squares) needs three components (the "broken" blue squares), which specify the Target information (target and guide star coordinates), the UIST instrument configuration and the Data Reduction Recipe (DRRecipe). These can be contained "within" each observation, or they can be "inherited". In Fig.1, for example, all three observations inherit the UIST configuration from the component above them. The flat/arc and standard star observations also inherit the standard star coordinates (so that the flat and arc are observed at the location of the standard). The science target observation contains its own coordinate information, which overrides the inherited standard star information (see Fig.2 below, where the target is called HH2). The data reduction recipes, to be used to reduce the calibration, standard and science target data, are then specified individually inside each observation (see e.g. Fig.2).
 Fig.2 An IFU MSB showing the components of the science target observation. Below the DRRecipe component in Fig.2 there is a "running man" icon or "iterator" labelled Sequence. Embedded "within" this Sequence iterator is the Imaging Acquisition observation, five optional short darks (used to flush the array after acquisition), then a UIST IFU/Spec iterator, a Repeat iterator and the actual Offset iterators (more running-man symbols) which nod the telescope between the object and sky positions. The "eye" symbols are the actual exposures at each position. IMPORTANT: the observes (the eye symbols) must be labelled as "Observe" and "Sky" (as they are in the above example, and in the template library) for the IFU DR to work properly. After source acquisition and array "flushing" (both discussed below), the UIST Spec/IFU iterator changes the exposure time. This iterator is needed because the UIST component, inherited by the observation of HH2, is set up for 7sec exposures on the standard. Longer exposures will probably be needed on the science target. (By selecting a source magnitude, a sensible exposure time will be set.) The iterators below "UIST IFU/Spec" are then stacked much like "embedded do-loops" in a computer programme. With the setup in Figs.2 an object-sky-sky-object "quad", defined by the offset iterators, will be repeated five times (specified by the repeat iterator) to build up signal-to-noise on HH2. The offsets are set in the offset iterators by "p" and "q" parameters, q being along the long (6") axis of the IFU, with p being perpendicular to it, regardless of the IFU position angle. The standard star observation will be essentially the same as that shown above, except that the "UIST IFU/Spec" iterator is not needed, because the exposure time has already been defined in the UIST component (broken square) higher up. Also, fewer repeats may be required. Finally, to view the whole sequence of observations (telescope moves and filter changes) written as a simple text list click on the Sequence "running-man" icon and hit "show". IMPORTANT: If you change the wavelength (or anything for that matter) in the UIST component, you must click on "Use default" in the FLAT, ARC and the flush-array DARK. This ensures that these observations pick up the changes made in the UIST component. Remember, though, to set the flush-array dark exposure time back to 1 or a few seconds (and 1 co-add) - you don't want to be taking lengthy darks to flush the array.
Imaging acquisitionFor both the bright standard and faint science target the source will be "acquired", or centred in the 3.3"x6.0" IFU field-of-view, in imaging acquisition mode. The TSS will do this for you. However, the standard and science target observations must include the "Spec/IFU Target Acquisition" eyeball (Fig.2) for this to be possible. Exposure times for acquisition: By clicking on the acquisition "eyeball" in the OT, you can enter either 9-10th mag for the standard star or a higher magnitude for a fainter science target. An appropriate exposure time and number of coadds will then be automatically set. For the bright standard the shortest possible exposure time must be used (9-10th gives the minimum 1sec full-array readout). For a faint science target a total of 10 or 20secs may be needed. Source acquisition is discussed further in the long-slit spectroscopy pages. Beware of latency, however (see below) - on faint targets use short exposure times and a few coadds (e.g. 4 x 5sec for the HK grism) rather than one long exposure (1 x 20sec).
Image LatencyUIST suffers from image latency, i.e. residual signal (like dark current) at the less than 1% level. Because imaging acquisition involves taking images, often with longish exposures through a very broad spectral blocking filter, this can leave some residual sky signal on subsequent frames. Likewise, if a bright star is observed in acquisition, there may be a residual (weak) image of the star in the next frame or two. This latent signal gets weaker with time, and it should "subtract off" when skies are subtracted from object frames. The problem can (to some extent) be avoided by using short exposures and a few coadds for imaging acquisition, rather than one long exposure. The penalty is readout overheads, specifically 1-2 seconds per coadd. We recommend using three or four 5sec exposures for faint targets (one 1sec exposure for a bright target). However, even with these short exposures, residual signal from imaging acquisition could still introduce additional noise to the first few frames taken directly after imaging acquisition. Consequently, it may be a good idea to "flush" the array, by taking a few short darks after imaging acquisition, and before taking a first long (perhaps two or three-hundred second) spectrum of the science target. The optional flush darks are avaiulable for this purpose; they are potentially useful for very faint targets and/or long spectroscopy exposure times and/or short wavelengths, although their usefulness is limited - the residual signal fades with time, not the number of read-outs. Exposure timesGenerally, the "longest possible" exposure time will give the best performance. Background-limited performance with most of the UIST grisms requires long exposure times. With the HK grism this is a few minutes in the K-band and 5-10 minutes in the H-band; with the short-K grism 5-10 minutes is also required (depending on wavelength and whether an emission line coincides with a sky line or not). Note, however, that OH sky-line intensities will vary on these time scales, so the importance of perfect sky subtraction may limit the exposure time you can use (as well as saturation on the source, of course). For recommendations on exposure times please have a look at the section on preparing observations for UIST spectroscopy.
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. You may then store it to the telescope site (Database - store to telescope site), using your project ID (e.g. u/03a/99) and password (received through email). The programme can later be retrieved from the database at the summit and your observation executed. HOT TIP: Set up one MSB - for just one flat/arc, standard and science target, say - then send this to your Support Scientist. He or she will check it over. In most cases, you can then simply copy this MSB "n" times and just change the coordinates of the standards and science targets. The above discussion and example is of course meant only as a brief guide. A more comprehensive guide to the OMP, the OT and flexible scheduling in general is avaliable here. A UKIRT Support Scientist is assigned to each project (Visitor or Queue-scheduled) to assist with the preparation of OT observations.
NOTE: All observers will be introduced to this software by their support scientist. UIST observing programmes are run from the UKIRT "Querie Tool", or "QT". The observer at the summit uses the QT to access, sort and extract observations from the database (observations previously prepared in the OT; discussed on the previous page). Briefly, the QT allows the user to select observations based on their "observability", i.e. using constraints such as seeing, photometric requirements, dryness and of course source accessibility. A copy of the QT screen is shown below.
Click above for an expanded image An observing programme will comprise a list of "Minimum Schedulable Blocks", or MSBs. For example, a flat, arc, standard star and source observation might constitute an MSB, since these represent the mimimum amount of data needed for the calibration of an IFU/spectroscopic observation. By entering the semester or a specific project ID in the QT (this is usually the project PATT number, e.g. u/03a/99), a list of MSBs can be displayed in the bottom half of the QT window. MSBs may then be selected and their components (individual observations of, in our example, the flat, arc, standard star and source) displayed on a second tab in the QT window, as shown below.
Click above for an expanded image
Click above for an expanded image The "Sequence Console" will show the individual steps of the observation (the slew to the source, the configuration of the instrument, and the actual observations intersperced with jitters around the array or slides along the slit). A typical console window is shown below. With an observation loaded into this third window, the observer is finally ready to take data...
Click above for an expanded image A more general guide to using the OMP is available elsewhere.
IntroductionThe pipeline reduction through ORAC-DR will produce a datacube from the IFU spectral images which can be viewed in Gaia and manipulated using the 'Datacube' software developed for STARLINK by Alasdair Allan, or by using various KAPPA and FIGARO routines (described below). The template observing sequences discussed above will already contain the appropriate DR recipes. You should not normally need to change the recipe. If you do, please be careful, as many have specific requirements, e.g. flat fields and standards, 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. Below we give an overview of the pipeline, and offer some tips on post-pipeline reduction. The IFU version of ORAC-DR is also described in a Starlink User Note, which can be accessed by typing showme sun246 (if you're at a starlink site), or from the starlink homepage: SUN246
Running ORAC-DRTo run ORAC-DR at UKIRT or JAC (or at your home institute, if it is installed) type oracdr_uistThe software will then point to the current night's data directories. (If you wish to reduce, say, the previous nights data, you can specify the UT date on the command line, e.g. oracdr_uist 20001031 .) The above command should be followed by oracdr -loop flagSeveral windows will (eventually) open: an ORAC text display, GAIA windows and kapview wndows. The pipeline will reduce the data as they are stored to disk, using the recipe name in the file header (i.e. the one specified when you set up the observations). The pipeline is meant to run without interference from the observer. Thus, although you can use the various GAIA tools to examine images, the pipeline should not need to be stopped and/or restarted. If, however, you do need to re-reduce a block of data, this is possible with the command oracdr -loop flag -from 199or with oracdr -loop flag -list 199:210 If you have chosen to postpone observation of your standard star until after your object you may wish to specify the _NOSTD form of the recipe on the command line, for example: oracdr -loop flag -list 199:210 EXTENDED_SOURCE_NOSTDThe original recipe name is still written into the header of each file, so once you have observed and reduced your standard you can re-run the DR on your object frames. Help on this and other ORAC-DR topics is available by typing oracdr -helpTo exit (or abort) ORACDR click on EXIT in the text log window, or type ctrl-c in the xterm where the pipeline was started. The command oracdr_nuke can be used to kill all DR-related processes, should you be having problems.
Flats, Arcs and Standard Stars...Observers should always take a flat as the first IFU frame. If the flat is not observed, then the DR will fail. The flat is used not only for flat fielding but also to locate the slices on the array. An arc is required next so that subsequent frames can be scrunched to a common wavelength scale (note that the DR cannot currently handle arcs from the Kypton lamp - please use only the Argon lamp). It may sometimes be necessary or convenient to postpone observation of a standard star until after observing your object. In this case it is possible to run the _NOSTD versions of the recipes. There are some tips on how to deal with bad wavelength calibration later on this page...
An Overview of IFU Data ReductionThe IFU pipeline DR will wavelength-calibrate and "scrunch" (align arc or sky lines in the spectral images) spectral images, extract spectral "slices", and compile a datacube. At present the most important/useful displayed data products are the "white-light" image (the gu(UTdate)_(num)_im frame) and the scrunched spectral image (the gu(UTdate)_(num) frame). Both will appear in a Gaia window. Note, however, that by specifying an "extract.images" file, images across narrow wavelength ranges can also be extracted from the data (see below). For standard stars, a wavelength-calibrated spectrum will also be extracted and displayed. The extracted spectra and spectral-images will be continually updated as data are taken, so that the observer can follow the increase in signal-to-noise on their source with time. Note that extended, line-emission sources may be more-clearly seen in the scrunched spectral image, while continuum and/or point sources should show up nicely in the white-light image. Don't expect to see an emission-line object in a white-light image; there will probably be too much noise from the background - you'll need to set up the extract.images file to see an image of such a target (discussed below). The pages listed below give more details, and show example images of what you might expect to see at each stage of the reduction of IFU data.
Reducing flat field frames
Scrunched Spectral Images and White-Light ImagesAs already mentioned, arguably the most important data products from the DR are the "scrunched" spectral image and the white light image. By viewing these a user can be confident that s/he has (1) detected the source and/or its emission lines, and (2) centred the target in the 3.3"x6.0" IFU FOV. Because the spectra in a "raw" IFU spectral image are jumbled on the array (below-left), one of the first things the DR does is rearrange the spectral slices (below-centre). For a bright target, the standard star say, this "scunched" image informs the observer that the target is well-centred left-right, within the available 3.3" - because the spectra in the scrunched image are distributed about the centre of the array. However, in many cases its impossible to see the edges of each IFU slice, so one can't easily establish that the star is centred up-down. Observers should therefore consult the white-light image (below-right) to make sure that the target is well centred in both axes.
As a general rule of thumb - in the white-light image:
Further example spectral images, of flats, arcs, point sources and, in particular, extended emission-line targets, are given in the previous section.
Choosing what should be displayed - the "extract.images" fileThe white-light image created automatically by the pipeline (the file with the suffix _im) simply represents the full datacube collapsed over its entire wavelength range. Consequently, its unlikely that it will show a pure line-emission object, since it includes the noise from the whole array. Instead, users can "instruct" the pipeline to extract images across a narrow wavelength range by using an "extract.images" file. This simple ascii text file must be written to the reduced data directory before the DR is run. An example is shown below. # An example extract.images file # Extract a broad-band K image K 2.1 2.3 # and a continuum subtracted H_2 1-0 S(1) image S1 2.1208 2.1228 2.1250 2.1270 Each line of the file should contain a suffix for the output image file and either two or four wavelengths (in microns). If a line contains two wavelengths then an image will be extracted from the cube between those wavelengths. If four wavelengths are given then two images will be extracted and the second will be subtracted from the first (for continuum-subtraction, say). Any lines in the file beginning with # are ignored. When the DR is run with the extract.images file shown above present in the reduced data director ($ORAC_DATA_OUT), the DR will produce files with the sufix "_S1" and "_K". The S1 image will be continuum-subtracted, since emission over the second wavelength range will be subtracted from the image over the first wavelength range. Examples of extracted images are shown in the previous section on reducing observations of an extended source. To view the extracted images simply open them in Gaia - you'll probably need to zoom in with the "Z" button... Getting the right aspect ratio... Note that at present the white-light and extracted images displayed by ORAC-DR will appear compressed by a factor of two in the X direction. This is due to the non-square (0.24 x 0.12 arcsec) pixels of the IFU. Images can be displayed with the correct aspect ratio by running KAPPA:DISPLAY (type "kappa" then "kaphelp" for info.) with the options xmagn=2 ymagn=1 specified on the command line, or of course by binning in one dimension to give images with square 0.24 arcsec pixels. Alternatively, try KAPPA:PIXDUPE. With an expansion factor of 2,1 each pixel in X is copied to two pixels, so that when the processed image is displayed in Gaia; (1) the image dimensions are correct, (2) the dimensions of each pixel look correct (0.24" x 0.12"), (3) resolution is not lost along the long axis (it remains 0.12"), and finally (4) flux calibration (on a pixel-by-pixel basis) is retained.
Examining Datacubes in GAIAGaia is a very powerful image analysis tool routinely used at UKIRT with all of our instruments. It now (as of December '05) includes a tool for examining data cubes.If Gaia is already open, use "open cube" under the "File" menu; alternatively, open an IFU cube in Gaia from the command line (e.g. > gaia gu20050101_100_cube). The cube control panel should open automatically. Any two of the three dimensions of the cube may be displayed, although typically axes one and two (the spatial dimensions) are displayed and axis three (wavelength) is used for the animation. With axis three selected (as is the case below), the cube control panel allows users to run through the cube between the wavelengths (coordinates) specified under Animation controls, or display (and save) a collapsed image extracted from the cube between the wavelengths entered under the Collapse tab.
The cube display panel in Gaia. Note that the "coordinates" The Starlink DATACUBE library of routines may also be used to examine IFU cubes. This tool is briefly described below.
EXTENDED_SOURCE versus MAP_EXTENDED_SOURCEThree observing methods are currently in use with the IFU. The first, and simplest, called "nod to blank sky", uses the EXTENDED_SOURCE recipe, which is similar to a spectroscopy quad in that 4 frames are observed in the order object-sky-sky-object, the object frames being at the same position on the source and the sky frames being on blank regions well off the target. This quad can be repeated many times to build up signal-to-noise. However, because essentially all of the array is used with the IFU, with long exposure and repeat observations, cosmic ray hits and bad pixels can become a nuisance. Therefore, a second, similar mode, called "nod to blank sky with jitters", is now available. In this mode, the same object-sky-sky-object quad is repeated. However, the object frames are slightly jittered, by one or two pixels. Because the object frames are not all spatially coincident, a recipe that takes into account the jittering is required: MAP_EXTENDED_SOURCE. An example offset sequence is listed below: 0",0" 60",0" 60",0" 0",0.12" 0",-0.12" 60",0" 60",0" 0",0" Finally, for targets that over-fill the 3.3"x6.0" field-of-view of the IFU, a third observing mode, "map extended source", is available. Here the IFU is stepped across the extended target so that the resulting cube is much larger than the nominal 3.3"x6.0" field of view. Again, the MAP_EXTENDED_SOURCE recipe must be used. An example offset sequence is shown below: 60",60" 1.5",0" 1.5",0" 60",60" 60",60" -1.5",0" -1.5",0" 60",60" Note that the first ("p") offset is always orthogonal to the long-axis of the IFU, regardless of position angle. Consequently, with the above sequence the IFU will be offset 1.5" either side of the nominal centre of the target, so that an almost square 6"x6" field is observed. By necessity, the MAP_EXTENDED_SOURCE recipe deals with the data in a slightly different manner to the EXTENDED_SOURCE recipe. A scrunched spectral image containing all of the data is NOT produced, since not all object frames are centred on the same position on the target (as is the case with the EXTENDED_SOURCE recipe and observing mode). However, scrunched images from individual object-sky pairs are produced and left on disk for you to view in Gaia (suffix _scr). These are wavelength-calibrated, so use these to check wavelength-ranges for your extract.images file. Also, by adding the appropriate _scr frames together, you should be able to see all the data at a given position on the target and establish the true depth of the data (are those faint lines there?). (Note however that these scrunched spectral images are NOT divided by a standard.) A data cube is of course produced by MAP_EXTENDED_SOURCE from all of the data (as is a cube that has been divided by the standard star cube and flux calibrated). The X and Y axes of the cube will obviously be larger than the usual 3.3"x6.0" field, depending on the offsets used. Finally, extracted images are also produced from the flux-calibrated data cube; again these will cover larger spatial areas on the sky, depending on the offsets used. Similar images, though over narrower wavelength ranges (for specific emission lines), can be acquired by running the recipe with an extract.images file in the reduced data directory, as described in the previous section. The meaning of all suffixes used are given on the next page (data format).
Post-reduction of IFU data with Starlink SoftwareThe pipeline DR probably goes most -- if not all -- of the way to reducing your data. However, there may be some additional steps that you wish to take. Starlink Kappa and Figaro routines are available which should facilitate this. Here we give some suggestions: Creating your own Cubes The pipeline flags deviant pixels (identified in the array tests run at the start fo the night) as bad. However, it does not try and fill in these pixels; nor does it deal with cosmic ray hits. Consequently, with long exposures and the ifu's use of the full array, bad pixels can become a problem. If you find that you need to clean up a scrunched spectral image, starlink software may then be used to create a datacube from the cleaned 2-D spectral image. The KAPPA routines ndfcopy, slide and paste can be used to do this, provided the locations of the slices are known in the 2-D image, and the slides necessary to align columns in the final cube are known. Notes on how to flux-calibrate the cleaned cube with standard star observations are given below. An example script, provided by Kris Lowe, is provided here. The script includes the slice locations and slides mentioned above. Division by a standard and flux-calibration To do the flux-calibration yourself, first reduce the science target data with the EXTENDED_SOURCE_NOSTD recipe. This will yield a flat-fielded, sky-subtracted, and wavelength-calibrated data cube. Next, create a similar-sized cube from the standard-star observations. Reduce the standard star data as normal with the ORAC-DR routine STANDARD_STAR. From the scrunched (wavelength-calibrated) spectral image, extract six or seven spectra (optimal extraction works best; e.g. FIGARO:PROFILE and FIGARO:OPTEXTRACT) and coadd these. This spectrum can then be cleaned (e.g. FIGARO:ISEDIT), flux-scaled and divided by a blackbody function (FIGARO:BBODY) before it is "grown" into a data cube. The Figaro commands to grow a 1-D spectrum into a 3-D cube are: growx spectrum=standard_spec new=true image=temp ystart=1 yend=54 ysize=54 growyt image=temp new=true cube=stdcube xstart=1 xend=14 xsize=14 "growx" will create an image by copying the spectrum to 50 adjacent rows. "growyt" then copies this image plane to 14 adjacent image planes to give a cube with dimensions 14-pixels by 54-pixels, equivalent to the (14x0.24") by (54x0.12") = 3.4" x 6.0" IFU field-of-view. The standard star cube can then simply be divided into the science target data cube (KAPPA:DIV). An example c-shell script is show here. Extracting images and spectra By careful examination of extracted images, spectra covering a limited area across a target can be extracted from a fully-reduced data cube. Likewise, by examining a scrunched and therefore wavelength-calibrated spectral image of a target, images in individual emission lines or over limited wavelength ranges can be extracted. For the latter, note that the spectral resolution with the IFU is two pixels, so extraction over four pixels in wavelength space (twice the FWHM) will probably give best results. To extract an image from a reduced data cube, use FIGARO:XYPLANE, e.g. xyplane cube=data_cube image=data_cube_brgamma The "xyplane" routine will prompt for the wavelength range for the extraction. Obviously, by extracting images over adjacent continuum wavelengths (take the mean of two images extracted from the red and blue sides of the emission line), a continuum image, that takes into account the colour of the continuum slope, can be created and subtracted from the line image. To extract a spectrum from a reduced data cube, first use FIGARO:XTPLANE to extract a 2-D image plane, then FIGARO:YSTRACT to extract and coadd adjacent rows to give a 1-D spectrum, e.g. xtplane cube=data_cube image=tempplane ystract image=tempplane spectrum=nice_spectrum Again, the two commands will prompt for the spatial ranges over which to extract data. Look at an image of the target with the 3.3"x6.0" orientated with the long-axis in Y (as shown below): xtplane requires the x-axis range; ystract the y-axis range.
As an example, the above figure shows two extracted images and an extracted spectrum - all data were taken from the same cube. At left, the image is extracted over 2.03-2.37 micron (the bandpass of a typical K-band filter). The image at right is extracted over 2.1204-2.1234 micron, so it shows only line emission (adjacent continuum images have been subtracted to remove the star). The two images thus show a central star and an associated jet in molecular hydrogen - and note the perfect subtraction of the star in the latter! Finally, the spectrum of the central red star is also shown; this has been extracted over spatial pixels 7.5-10.5 (xtplane) and 26.5-31.5 (ystract). (Note that the first pixel in the image plane is 0.5,0.5.) An example c-shell script for extracting images and/or spectra is show here. Alternatively, use KAPPA routines COLLAPSE or NDFCOPY to collapse a cube into a 1-D spectrum. Note that KAPPA has been better supported than FIGARO in recent years... Datacube - the IFU Data Handling Software Finally, "DATACUBE", starlink software written specifically for use with IFU data, can be used to analyse a fully-reduced data cube. For example, the STEP routine can be used to step though a series of images extracted from the cube. Each image is also saved to disk as an individual sdf file (chunk_1.sdf, chunk_2.sdf, etc.). E.G.:
> datacube
DATACUBE applications are now available -- (Version 1.0-4)
Support is available by emailing datacube@star.rl.ac.uk
Type cubehelp for help on DATACUBE commands.
Type 'showme sun237' to browse the hypertext documentation
or 'showme sc16' to consult the IFU data product cookbook.
> step -p
NDF input file: ifu_20031016_91_cube
Input NDF:
File: ifu_20031016_91_cube.sdf
Shape:
No. of dimensions: 3
Dimension size(s): 14 x 53 x 1024
Pixel bounds : 1:14, 1:53, 1:1024
Total pixels : 759808
Lambda bounds : 1:2.4999
Lower lambda bound: 2.1
Upper lambda bound: 2.4
Lambda step size: 0.1
Stepping:
Range: 2.1 - 2.4
Step: 0.1
Collapsing:
White light image: 14 x 53
Wavelength range: 2.1 - 2.2
Output NDF:
File: chunk_1.sdf
Title: Setting to 2.1 - 2.2
Collapsing:
White light image: 14 x 53
Wavelength range: 2.2 - 2.3
Output NDF:
File: chunk_2.sdf
Title: Setting to 2.2 - 2.3
Collapsing:
White light image: 14 x 53
Wavelength range: 2.3 - 2.4
Output NDF:
File: chunk_3.sdf
Title: Setting to 2.3 - 2.4
Display:
chunk_1.sdf
chunk_2.sdf
chunk_3.sdf
With the "-p" option the images should be displayed in a kapview display.
The COMPARE routine allows you to display a white-light image and select and display spectra from this image. As its name suggests, two spectra can be extracted and compared at the same time, as illustrated below.
There are other routines in the DATACUBE library which may be of use to you, notably RIPPER and SQUASH. The former reads a 3D IFU NDF datacube as input, presents the user with a white light image of the cube and allows him/her to select an x,y position using the cursor. It then extracts (and optionally displays) a spectrum for that x,y position. SQUASH allows the user to extract from the cube an image over a specific wavelength range. The command "cubehelp" will list the available routines in DATACUBE.
Bad wavelength calibrationIf the DR doesn't do a great job at wavelength calibration and, in particular, if it doesn't produce a scrunched arc spectrum where arc lines run almost seamlessly from slice to slice (a "bad" frame is shown here), then you can try tweaking the parameters used by the DR with FIGARO/IARC. To do this you must: (1) copy the appropriate primitive to the directory you're working in, (2) edit the parameters in the primitive that are used by IARC, and (3) set the environment variable so that orac-dr knows where to find the updated primitive. With step (3) the pipeline will first look in your data directory for all primitives before resorting to files in the default primitive directory (in $ORAC_DIR).For example:
> cp /ukirt_sw/oracdr/primitives/ifu/_WAVELENGTH_CALIBRATE_ .
> setenv ORAC_PRIMITIVE_DIR `pwd`
> xemacs _WAVELENGTH_CALIBRATE_
When editing the _WAVELENGTH_CALIBRATE_ primitive, look for the section
that looks like:
# Do the Iarc, starting from the centre of a central slice
orac_print "Running IARC on $in, starting at row $row.\n";
my $param1;
my $param2;
if( starversion_gt('figaro', '5.6-1') ) {
$param1 = "image=$in rstart=$row file=$in.iar chanshift=$shift";
$param2 = "rwidth=1 rsigma=3 spread=t lock=f xcorr=f gap=1 sigmin=5";
} else {
orac_warn "FIGARO is v5.6-1 or earlier. Will not use cross-correlation...";
$param1 = "image=$in rstart=$row file=$in.iar";
$param2 = "rwidth=1 rsigma=20 spread=t lock=f xcorr=f gap=1 sigmin=5";
}
$Mon{'figaro3'}->obeyw("iarc", "$param1 $param2");
In the above code, the input parameters used by FIGARO/IARC are
collectively defined by $param1 and $param2. For FIGARO
versions later than 5.6-1 the top two parameter
definitions will be used. (Type "figaro" to see which version you
have installed.)
The parameters rsigma and rwidth are the arc line width and the number of consecutive rows to be binned and fit. (These and all other parameters are defined in the FIGARO on-line documentation.) If, as in the above case, rwidth is set to 1, IARC will try and fit every row individually. Since bad pixels may skew the fit, increasing rwidth might help. However, adjusting rsigma is often a better option, since it can help stop the pipeline from mis-identifying arc lines in adjacent rows. Try fiddling with these parameters and re-reducing just the arc frame; you should see a noticeable change in the arc spectral image displayed in Gaia. You should also edit the orac_print line slightly (or add a new line) so that you know for sure that the pipeline is using your updated primitive. See the starlink document SUN/232 and the section on "Customising Recipes" for further details on tailoring the pipeline to your specific needs.
Raw filesRaw, unreduced, data files are in /ukirtdata/raw/uist/YYYYMMDD (where YYYYMMDD is the numeric UT date); at the telscope this is equivalent to $ORAC_DATA_IN. The files are stored as starlink HDS containers (a file with multiple data arrays). 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 (single data array) of the HDS file. The raw filenames are uYYYYMMDD_NNNNN.sdf where NNNNN is the observation number, padded with leading zeros when necessary. Reduced filesReduced data files are in /ukirtdata/reduced/uist/YYYYMMDD; at the telescope this is equivalent to $ORAC_DATA_OUT. The filename structure is: (PREFIX)(UTDATE)_(FRAME NUMBER)_(EXTENSION).sdf. (PREFIX) is the letter 'u' if the file contains data from a single observation. It is 'gu' if the file contains data from a number of observations - i.e. a group. The suffix _(EXTENSION) defines the file in terms of the reduction process (see the table below). The DR produces many "intermediate" frames. Useful frames are left on disk after ORAC-DR has finished so that you can look at these if you wish (these are marked with ** in the table below). As an example; u20000410_00123_ff.sdf would be data from a single observation, number 123, that has been flat fielded. u20000410_00123_scr.sdf would then be the difference of frames 123 (object) and 124 (sky); this frame has also been "scrunched", i.e. wavelength corrected and the individual slices re-arranged in a logical order across the array. As a consequence, this frame is arguably more useful to you than the _ff frame.
NOTE: For the standard star, the processed spectrum (the _std file) is copied to an std_(num) file. This is grown into an image and then a data-cube (the std_(num)_im and _std_(num)_cube files), for use with the science-target datacube.
NOTE: All files except those marked with ** in the above tables are deleted by the DR after reduction (these are intermediate files). Reduced files can have either HDS (multiple data arrays) or NDF (single data array) format as appropriate (see above). The philosophy behind the MAP_EXTENDED_SOURCE recipe and associated mode of observing is to nod between the target and blank sky, but also to offset the IFU when on the target to map a more extended region. Because the "on-source" frames are offset with respect to each other, obviously the _scrspectral images cannot be (trivially) coadded into a summed spectral image. Consequently, MAP_EXTENDED_SOURCE does not produce a coadded, scrunched spectral image for all data on a given target.
So what should I take home with me...?If you don't have access to ORAC at your home institute, then reducing completely raw data frames may be a challenge, to say the least. Instead, it may be preferable to work with some of the products of the DR. I've highlighted (in red) the data products that I think may be of most use to users, though at the end of the day, this decision is up to you! In terms of "fully reduced data":
Non-Starlink users may convert their data to fits format (before they leave) with the Starlink routines:
> convert
> ndf2fits "*" "*"
or, to get .fits as the file extension (instead of .fit)
> ndf2fits "*" "*|.fit|.fits|"
Note that the complete Starlink software library, which includes ORAC-DR, is available free (speak with your support scientist). You can then simply work with the raw ".sdf" files available from the OMP web pages.
Orientation of IFU field on the skyBelow we list the orientation of the IFU cube and white-light image on the sky for various position angles.
To view with the correct orientation, images need flipping along
BOTH axes. In Gaia, click on Note that the top of each slice in an IFU scrunched image should correspond to the top of the white-light image and cube. Similarly, moving up the array - from one slice to the next in a scrunched image - corresponds to moving from left to right across a white-light image/data cube. The direction this corresponds to on the sky is given in the above table.
Imaging acquisition of IFU sourcesIFU targets are acquired in essentially the same way as long-slit spectroscopy sources. Remember to use short exposures and a few coadds rather than one long exposure to avoid latency affects. This issue is particularly important with the IFU, since almost all of the array is used for the spectroscopy. By looking at a raw IFU image, it is very difficult to figure out whether a source is well centred within the IFU 3.3"x6.0" field-of-view. For example, consider the following (hope you've had your coffee)...
If you can't see the star in the white light image in the Gaia
display, try zooming in with the Z button, or changing the
autoscaling (under the "Auto Cut" pull-down menu). Alternatively, you
could try your favourite display tool, after converting the
|
and 
.
