UIST – Instrument Run Up and Down
The Telescope Systems Specialist (TSS) will run the instrument up and down.
The observer takes the data using the OCS and runs the data-reduction pipeline (orac-dr).
The TSS runs UIST from the “tssSoft” gui. (Note – select “instControl” and then “eng” for runningup in engineering mode and the data getting saved to the engineering directories).
From the above window open DM screens, uist, oper to get 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:
- START [1] – this starts the low level software AND launches a GAIA quick-look display on Ohi. The log in the right-half of the window should say Starting camera 5 and then (after 10 secs or so) wfacq5: drama:Running filesave:Running camera:Running rtai:Running. If you DON’T get a GAIA display – don’t go any further – since you won’t get one later in the run-up sequence.
- OCS_UP [2] – this runs the “Query Tool” (QT) – used for selecting which MSBs to observe, the “Queue monitor” – used for lining up observations to be executed, and the “Sequence Console”, which will actually run (execute) the observations. The observer should run this on Ohi.
- ADD INST [3] – this will activate the Sequence Console on Ohi (which will have come up blank).
- ENABLE [4] – this will enable the array. Note that the array says “On” on the sequence console.
Once the above four steps have been executed successfully, the observer can run the UIST Array tests and take data.
The run-down sequence is displayed in red (steps [6] to [9]).
- DISABLE [6] – to disable the array; it will say “Off” in a red box on the sequence console.
- REM INST [7] – this kills the Sequence Console.
- OCS_DOWN [8] – to be done by the observer. This should kill the QT and Queue Monitor on Ohi, though you may have to close the GAIA quick look manually.
- STOP [9] – this will finally run down the low-level software. The log in the right of the window should say: wfacq5: drama:Stopped filesave:Stopped camera:Stopped rtai:Stopped.
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.
IFU: Preparing a Programme
Preparing an Observing Programme: the UKIRT-OT
FIRST 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.
The components of an IFU observation
Each 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).
- The Target information component is used to enter the standard star or science target coordinates. It may also be used to display a Digitised Sky Survey image of the target field, the instrument aperture size, and various guide-star catalogues (see this ORAC-OMP Guide for a comprehensive description of this tool).
- The UIST instrument component is used to select grism, exposure time, position angle, etc. Here the IFU mode is also selected. In Fig.2 the UIST component is highlighted, so that the UIST configuration is displayed on the right half of the window: in this case, UIST has been set for HK IFU spectroscopy with the IFU’s major (6-arcsecond long) axis orientated east-west. One 7sec exposure – appropriate for the standard star – will be taken with the default NDSTARE 1024×1024 readout area.
- The DRRecipe component allows you to select the recipe appropriate to the mode of observation, so that the DR can reduce your data on-line. An observation copied from the template library should already have the DR recipe set correctly, so these shouldn’t need changing. All object files obtained as part of this observation will be flagged with this recipe.
Below the DRRecipe component in Fig.2 there is a “running man” icon 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 acquisition
For 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 Latency
UIST 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 times
Generally, 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.
IFU: Template Observations
UIST observing programmes will be set up using the ORAC-OMP version of the OT. Your starting point will be the template sequences in the UIST library (under UKIRT Template Library). Available sequences are described below.
UIST Spectroscopy Template MSBs
| MSB | Contents | Description | DR Recipes Used |
|---|---|---|---|
| IFU Nod to blank sky | Flat & Arc Bright-star Target-acquisition Target-observation | Observe a flat and arc, then an obj-sky-sky-obj sequence on the standard (with offset 30″ to blank sky). Science target observed with a simple obj-sky-sky-obj sequence (with 60″ offsets to blank sky) Most basic IFU mode – for targets smaller than IFU field-of-view. | STANDARD_STAR EXTENDED_SOURCE |
| IFU Nod to blank sky with jitter | Flat & Arc Bright-star Target-acquisition Target-observation | Observe a flat and arc, then an obj-sky-sky-obj sequence on the standard (with offset 30″ to blank sky). Science target again observed with an obj-sky-sky-obj sequence (60″ offsets to blank sky), though obj frames are jittered by a few pixels to patch bad pixels, etc. Recommended IFU mode – for targets smaller than IFU field-of-view. | STANDARD_STAR MAP_EXTENDED_SOURCE |
| IFU Map extended source | Flat & Arc Bright-star Target-acquisition Target-observation | Observe a flat and arc, then an obj-sky-sky-obj sequence on the standard (with offset 30″ to blank sky). Science target again observed with an obj-sky-sky-obj sequence (60″ offsets to blank sky), though obj frames are jittered by a few arcseconds so that a larger field is mapped Recommended IFU mode – for targets larger than IFU field-of-view. | STANDARD_STAR MAP_EXTENDED_SOURCE |
Checklist for Preparing OT Programmes
Below we list a few things to check after you’ve prepared and validated your programme. This list isn’t complete (and we’ll add pointers as they occurs to us), though it may help avoid loss of telescope time…
- After changing the wavelength (or anything for that matter) in the UIST component, did you click on “Use default” in the FLAT and ARC? This ensures that these observations pick up the changes made in the UIST component.
- Did you select Guide Stars for your targets. If there’s no guide-star specified, the telescope will assume you’re guiding on your target. If the guide star is dodgey, add a “guide2” and a note to the observer describing its availability (see below).
- Imaging Acquisition: with faint targets use short exposure times and a few coadds rather than one long exposure, to avoid latency in subsequent spectroscopy/IFU frames. 3coadds x 5secs works well.
- Maximum exposure time: is currently 240seconds with UIST spectroscopy (NDSTARE readout).
- Do ALL MSBs contain a flat, arc and a standard star in addition to the science target? ALL MSBs must contain a complete, calibratable set of observations for the science target. MSBs can contain more than one science target, though they should still be short (~1 hour at most). If you don’t want calibrations taken with every target, make this extremely clear in an observer note, and flag the flat/arc and standard star observations as optional in the OT (they then appear “green”). NOTE: calibrations don’t have to have the same position angle as standard star and/or target spectra, though obviously the same grism and slit should be used.
- Are your MSBs well-documented? Notes, flagged with “show to observer”, are EXTREMELY helpful when the observer is unfamiliar with a given project. A URL for a finding chart can be very useful too. Imaging acquisition is the BIGGEST PROBLEM faced by observers, particularly if coordinates are poor or targets are in confused/busy regions. Will the observer be able to identify your target easily during acquisition? Are the coordinates good enough so that s/he can assume that the blob nearest the nominal field centre is the target? Or will s/he need some guidance…?
IFU: Loading and Running 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.
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.
Once an MSB has been selected, it can be sent to a second window, the “Queue Manager”. Here the individual observations in the MSB are queued, ready for execution. With the queue running, each observation will be sent automatically to a third window, the “Sequence Console” (shown below).
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…
A more general guide to using the OMP is available elsewhere.
IFU: Data Reduction
Introduction
The 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-DR
1. To run ORAC-DR at the telescope type the following:
oracdr_uist oracdr -loop flag
2. To run ORAC-DR at your home institute type the following:
oracdr_uist 20071225 setenv ORAC_DATA_IN /home/cdavis/my/raw/data/ setenv ORAC_DATA_OUT /home/cdavis/my/reduced/data/ oracdr -list 1:100 &
When running ORAC-DR at your home institution, the pipeline needs to know when the data were taken (since files are labelled with the UT data), where the raw data are, and where reduced data are to be written. Obviously these directories need to exist on your machine, and the raw data need to be in the specified directory. In the above example, frames 1 to 100 from 20071225 will be reduced.
Note that the “array test” observations taken at the start of the night MUST be reduced BEFORE you try and reduce a block of your own data. Use the -list option to specify the data range. For example, if frames 1-19 were darks taken to measure the readnoise and set up a bad pixel mask (in the log the DR recipe will be set to MEASURE_READNOISE and DARK_AND_BPM), and frames 38,39,40-43 were the flat, arc and ABBA-style “quad” of observations on your standard star, you could type the following:
oracdr -list 1:19,38:43 &
Having reduced the array tests and flat/arc/standard star calibrations, you can then reduce your target observations, e.g.
oracdr -from 44 &
When running ORAC-DR, several windows will open as they are needed; an ORAC text display, GAIA windows and kapview 1-D spectral plotting windows. If you are at the telescope the pipeline will reduce the data as they are stored to disk, using the recipe name in the image header.
The DR recipe name stored in each file header will be used by the pipeline. However, this can be overridden if, for example, you decide you do not want to ratio the target spectra by a standard star, e.g.:
oracdr EXTENDED_SOURCE_NOSTD -list 31:38
where 31 to 38 were the eight observations of the target.
To exit (or abort) ORACDR click on EXIT in the text log window, or type ctrl-c in the xterm. The command oracdr_nuke can be used to kill all DR-related processes, should you be having problems.
Help on this and other ORAC-DR topics is available by typing
oracdr -help
Notes on what the pipeline actually does are given below…
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 Reduction
The 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
Reducing arc frames
Reducing observations of a standard star
Reducing observations of an extended source
Scrunched Spectral Images and White-Light Images
As 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.
RAW Image
SCRUNCHED Image
WHITE LIGHT
As a general rule of thumb – in the white-light image:
- if the target is TOO LOW, the telescope should be moved UP
- if the target is TOO FAR TO THE LEFT, the telescope should be moved LEFT
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” file
The 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 GAIA
Gaia 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.
1.40 and 2.50 are the start and end wavelengths of the HK grism in UIST
(and of course UIST has a 1024 pix array)
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_SOURCE
Three 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 Software
The 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 (14×0.24″) by (54×0.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.
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.
The command “cubehelp” will list the available routines in DATACUBE.
Bad wavelength calibration
If 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.
Further reading…
There are further tips on how to reduce and analyse general spectroscopy data in these Starlink Cookbooks.
IFU: Data Reduction Recipes
The following tables describe the UIST IFU ORACDR recipes; click on the recipe name for more information. The Requirements listed below are frames that should be obtained prior to use of the recipe, although data can always be re-reduced when the appropriate frames have been taken.
IMPORTANT: Please note that with EXTENDED_SOURCE the observes in an OT sequence (in a “quad”) must be labelled as “Object” and “Sky”, even when sliding a point source between the top and bottom halves of the IFU field of view. With MAP_EXTENDED_SOURCE all observes should be labelled as “Object”. Use the sequences provided in the template library if you’re not sure.
| Recipe Name | Requirements | Comments |
|---|---|---|
| REDUCE_FLAT | None | Stores as a flat |
| REDUCE_ARC | Flat | Stores as an arc |
| Recipe Name | Requirements | Comments |
|---|---|---|
| EXTENDED_SOURCE | Flat, arc, standard | For observations with one position and offset to sky |
| EXTENDED_SOURCE_NOSTD | Flat, arc | As above, but with no standard |
| MAP_EXTENDED_SOURCE* | Flat, arc, standard | Map a source with several IFU positions |
| MAP_EXTENDED_SOURCE_NOSTD * | Flat, arc | Map a source without a standard |
*Use these recipes (in preference to EXTENDED_SOURCE) and the associated Template Library Sequence in the OT if you want to dither the on-source frames, e.g. by a few tenths of an arcsecond.
| Recipe Name | Requirements | Comments |
|---|---|---|
| STANDARD_STAR | Flat, arc | Standard star with offset to sky |
| STANDARD_STAR_NOD_ON_IFU | Flat, arc | Standard star, nodding within the IFU field |
| Recipe Name | Requirements | Comments |
|---|---|---|
| NIGHT_LOG | None | Generate an ascii log |
IFU: Data Reduction Recipes
The following tables describe the UIST IFU ORACDR recipes; click on the recipe name for more information. The Requirements listed below are frames that should be obtained prior to use of the recipe, although data can always be re-reduced when the appropriate frames have been taken.
IMPORTANT: Please note that with EXTENDED_SOURCE the observes in an OT sequence (in a “quad”) must be labelled as “Object” and “Sky”, even when sliding a point source between the top and bottom halves of the IFU field of view. With MAP_EXTENDED_SOURCE all observes should be labelled as “Object”. Use the sequences provided in the template library if you’re not sure.
| Recipe Name | Requirements | Comments |
|---|---|---|
| REDUCE_FLAT | None | Stores as a flat |
| REDUCE_ARC | Flat | Stores as an arc |
| Recipe Name | Requirements | Comments |
|---|---|---|
| EXTENDED_SOURCE | Flat, arc, standard | For observations with one position and offset to sky |
| EXTENDED_SOURCE_NOSTD | Flat, arc | As above, but with no standard |
| MAP_EXTENDED_SOURCE* | Flat, arc, standard | Map a source with several IFU positions |
| MAP_EXTENDED_SOURCE_NOSTD * | Flat, arc | Map a source without a standard |
*Use these recipes (in preference to EXTENDED_SOURCE) and the associated Template Library Sequence in the OT if you want to dither the on-source frames, e.g. by a few tenths of an arcsecond.
| Recipe Name | Requirements | Comments |
|---|---|---|
| STANDARD_STAR | Flat, arc | Standard star with offset to sky |
| STANDARD_STAR_NOD_ON_IFU | Flat, arc | Standard star, nodding within the IFU field |
| Recipe Name | Requirements | Comments |
|---|---|---|
| NIGHT_LOG | None | Generate an ascii log |
IFU: Data Format and Location
Raw files
Raw, 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 files
Reduced 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.
File Extensions for INDIVIDUAL IFU files
(all recipes)
| Extension | Description |
|---|---|
| **_raw | The raw frame |
| _bp | Bad pixels masked |
| _rnv | Readnoise variance added |
| _sbf | Bias frame subtracted (only present for STARE observations) |
| _pov | Poisson variance added |
| _ext | Slices extracted and approximately aligned |
| **_ff | Flat fielded |
| **_ss | Sky subtracted (result from difference of 2 _ff frames) |
| **_scr | All rows in _ss frame scrunched and wavelength calibrated |
| **_quad | 2 _scr frames averaged (1 _quad per repeat of “obj-sky-sky-obj” sequence) |
File Extensions for GROUPED/CO-ADDED IFU files
(STANDARD_STAR recipe)
| Extension | Description |
|---|---|
| **no extension | Coadded “scrunched” spectral image |
| **_cube | Scrunched spec image converted to a datacube |
| **_im | _cube collapsed into a 2D image |
| **_sp | _im collapsed into a 1D spectrum |
| **_std | _sp spectrum normalised and divided by BB function |
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.
File Extensions for GROUPED/CO-ADDED IFU files
(EXTENDED_SOURCE and MAP_EXTENDED_SOURCE recipes)
| Extension | Description |
|---|---|
| **no extension | Coadded “scrunched” spectral image (EXTENDED_SOURCE only) |
| **_cube | Scrunched spec image converted to a datacube |
| **_cube_dbs | _cube divided by standard star cube (the std_(num)_cube file) |
| **_fc | _cube_dbs file flux-calibrated |
| **_fc_sp | _fc cube collapsed into a 1D spectrum |
| **_im | _cube collapsed into a 2D white-light image |
| **_im_fc | _fc collapsed into a 2D white-light image |
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”:
- From EXTENDED_SOURCE, the final “scrunched” spectral image, which is the co-addition of all the object-minus-sky spectral images, flat-fielded and scrunched to a common wavelength scale (i.e. the sum of all the u(UTdate)_(num)_scr frames), is one of the most useful product of the DR. This file has no suffix .
- The white-light image displayed by the DR has the suffix _im. This may also be useful, though images across individual emission lines are probably what you’re really after. These can be produced by re-reducing the data with ORAC-DR using an “extract.images” file.
- The data cube, which of course contains all the data on your target and may be manipulated with other 3-D data analysis software. This file has the suffix _cube. The flux-calibrated version has the suffix _fc.
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 sky
Below we list the orientation of the IFU cube and white-light image on the sky for various position angles.
| Angle | Top of cube/extracted image | Right side of cube/extracted image |
|---|---|---|
| -90 degs | East | North |
| -45 degs | SouthEast | NorthEast |
| 0 degs | South | East |
| +45 degs | SouthWest | SouthEast |
| +90 degs | West | South |
To view with the correct orientation, images need flipping along BOTH axes. In Gaia, click on and
.
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.
IFU: Target Acquisition
Imaging acquisition of IFU sources
IFU 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)…
Before Centering
After Centering
Before Centering
After Centering
Before Centering
After Centering
Above we show the effect of moving the telescope “up 1.5 arcsec” and “left 1.5 arcsec”. In the left-hand images, the target is off-center, though this is only apparent in the reduced data (center and bottom); the “scrunched” spectral image (where the IFU slices have been wavelength-calibrated and re-ordered so that the slices — from top to bottom — span the source region — from right to left) and the “white light image” (where the IFU data cube has been collapsed along its dispersion axis).
The main target is clearly:
1) Too far to the left in the IFU field, so it is only covered by the left hand “columns” in the white-light image, and it only appears in the lower IFU slices in the “scrunched” spectral image.
| It is also: 2) Too low in the IFU field, so the spectra in the scrunched image are low in each of the individual slices in the “scrunched” spectral image. Note that a second, fainter star appears (at left) in the IFU field after shifting the telescope. This secondary source is evident in the scrunched and white-light image. The above data were obtained with a position angle of 68 degrees. [The axes in the white-light images are in arcseconds.] |
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 file to fits with the convert package.
IFU: Target Acquisition
Imaging acquisition of IFU sources
IFU 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)…
Before Centering
After Centering
Before Centering
After Centering
Before Centering
After Centering
Above we show the effect of moving the telescope “up 1.5 arcsec” and “left 1.5 arcsec”. In the left-hand images, the target is off-center, though this is only apparent in the reduced data (center and bottom); the “scrunched” spectral image (where the IFU slices have been wavelength-calibrated and re-ordered so that the slices — from top to bottom — span the source region — from right to left) and the “white light image” (where the IFU data cube has been collapsed along its dispersion axis).
The main target is clearly:
1) Too far to the left in the IFU field, so it is only covered by the left hand “columns” in the white-light image, and it only appears in the lower IFU slices in the “scrunched” spectral image.
| It is also: 2) Too low in the IFU field, so the spectra in the scrunched image are low in each of the individual slices in the “scrunched” spectral image. Note that a second, fainter star appears (at left) in the IFU field after shifting the telescope. This secondary source is evident in the scrunched and white-light image. The above data were obtained with a position angle of 68 degrees. [The axes in the white-light images are in arcseconds.] |
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 file to fits with the convert package.