XOasis News #1 - February 20, 2006

This document is a status report from the ING on a number of issues related to XOasis (the data reduction package for OASIS). Please note that it is biased towards the Linux release of the software, as this is the version that the ING now runs.

Important warnings (discussed in more detail below):

XOasis for Linux

On 16th December 2005, v6.4 of XOasis (for Linux) was withdrawn from the Lyon website, due to problems with the ‘Create mask’ routine. Since that time, it has been possible to download version 6.3.

On 1st February 2006, Lyon released a new version called v6.3.1, which incorporates the improvements to the handling of the OAFCLASS headers that were present in v6.4 but not v6.3. We therefore recommend users of the Linux version of XOasis to download this latest release from:


Datacube file formats

The long term goal is that XOasis will operate with the Euro3D data format, and this has been partly implemented in the current version of XOasis (v6.3.1). Nevertheless, the software has only been tested with this format up to the wavelength calibration stage. We therefore advise users not to use the Euro3D format until more testing has taken place. Note that the ING has successfully worked with the ‘Tiger+FITS’ format.

If XOasis users wish to convert their final reduced data from the ‘Tiger+Fits’ format to the ‘Euro3D’ format, in order to use other software, there is a binary in the XOasis download that can be used to do this. It is located in the directory ‘${IFU_PATH}/IFU_gentools-6.3/user/bin/’, and is entitled convert_file. The command line nomenclature can be displayed by typing:

`path'/convert_file -h

An example of its usuage is:

/usr/local/IFU/IFU_gentools-6.3/user/bin/convert_file -in myinputfile.tig -out myoutputfile -inputformat tiger+fits -outputformat euro3d

OASIS Overscan Strip

During the OASIS commissioning at the WHT, a suitable overscan strip was measured to be from columns 4 to 14, and these are the defaults in all versions of XOasis. A temporal change in the behaviour of this strip has now been observed, which means that not all of these columns are suitable, particularly for computing the readout noise. (The clearest warning sign of a problem with your overscan region is if the computed read out noise is very high, e.g. 12 electrons, instead of ~3 electrons.)

We therefore recommend that you average your data over a large number of rows, plot columns 4 to 14, and determine whether there is any structure in the bias level in these columns. If so, select an new range for the columns that avoids this structure. (Note that the defaults could not be changed in v6.4, but this version has anyway been withdrawn.)

Offset – Check overscan

This feature does not work for raw WHT images in v6.3.1 (and older versions). (It did function correctly in the withdrawn v6.4.)

Compute CCD Fringing Correction

If you decide to use this routine, with a medianed “preprocessed continuum frame”, you will probably get an error message complaining that the header NB_EXP is not present. You simply need to create an NB_EXP header, and set its value to the number of frames that were medianed to produce your input frame.

Absolute paths

When you run routines in XOasis, be careful if (i) the input files are expressed with their absolute paths (as can be the case when you select the file with the directory icon), and (ii) if the absolute path is long. XOasis cannot handle very long paths, and the routine will return an error message.

Coordinates Recentering

This routine requests that you enter a datacube, yet only works if one enters the associated FITS table.

WHT File Format

The WHT generates “multi-extension .fit” files, instead of “single extension .fits” files. These fit files are handled correctly by v6.3.1 and the version of v6.3 currently on the Lyon website. Older versions (perhaps also called v6.3) suffered from problems (i) displaying the files in the reduction folder, and (ii) viewing images from the reduction folder, using the Image Display.

APPENDIX: Discussion of the OAFCLASS , FCLASS and OBSTYPE headers

This section is intended to clarify the behaviour of the OAFCLASS, FCLASS and OBSTYPE headers.

OAFCLASS: This header is collected from the OASIS configuration tool, and records the exposure type that was selected when the tool was configured. The document OAFCLASS_list.ps gives a list of the mappings between the OAFCLASS integers and the exposure type.

OBSTYPE: This is a standard WHT header that is collected for all instruments. It is similar to the OAFCLASS, in the sense that it also defines the type of exposure, but its value (e.g. ARC, FLAT, TARGET) depends on the ULTRADAS command used to initiate the exposure, e.g. ‘arc oasis 2’, ‘flat oasis 5’, ‘run oasis 1800 “Object name”’.

FCLASS: This header does not appear in raw WHT files, and is introduced and updated by XOasis during the data reduction. It is used to track the reduction steps, with values corresponding to those given in the document FCLASS_list.ps.

The long-term goal has always been that XOasis will determine the FCLASS header from the OAFCLASS header (during the first reduction step) and that the OBSTYPE header will be ignored. The reduction folder should display an appropriate icon for each file based on the FCLASS if it exists or, if not, on the OAFCLASS (e.g. if it is a raw file).

Some confusion may arise because (i) the way in which XOasis has handled the different headers has evolved with different releases, and (ii) the WHT headers have been modified and improved with time. Although we have now reached a stage where the headers are dealt with correctly (both at the telescope and by XOasis), we list some of the implications of this evolution:

We suggest that you cross-check the image titles, the OAFCLASS header, the OBSTYPE header, the actual image, and any comments in the WHT log, to ensure that both you and XOasis know which type of file you are working with! Note that due to some minor problems with the prototype OASIS configuration tool, your support astronomer may have deliberately not changed the exposure type (and consequently the OAFCLASS header) of some of your exposures. Upgrades to the configuration tool mean that these inconsistencies should no longer arise.

1In order to cope with historical data, where no OAFCLASS header was recorded, these versions will attempt to reconstruct the FCLASS header from the OBSTYPE header if and only if the OAFCLASS header is missing.

2Note that when raw dome flats are preprocessed, they will be converted to continuum frames, as there is no way to distinguish between dome and continuum exposures from the OBSTYPE header.