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):
Linux users should not use v6.4 (which has been withdrawn).
Versions 6.3.1 and 6.3 can be downloaded from the Lyon website. We recommend users to download v6.3.1 due to its better handling of the OAFCLASS headers.
The ‘Euro3D’ format is currently not recommended.
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:
http://www-obs.univ-lyon1.fr/labo/oasis/download/
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:
Version 6.3.1 (which is available on the Lyon website) and version 6.4 (which was withdrawn) deal correctly with the OAFCLASS headers.1
Version 6.3 (which is available on the Lyon website alongside v6.3.1) has a number of improvements over older versions. For example, it correctly displays the files in the reduction folder with an appropriate icon, based on the FCLASS if it is present or, if not, on the OAFCLASS. However, this and previous versions of XOasis may not correctly deduce the FCLASS, because they derive it from the OBSTYPE header, rather than the OAFCLASS header.2 This behaviour is left over, historically, from a time when the OAFCLASS header had not been implemented at the WHT. We therefore recommend that users of these versions (i) preprocess their raw frames, (ii) manually fix any of the FCLASS headers that are incorrect, and then (iii) continue with the rest of the reduction. There is little point in checking if the OAFCLASS headers are correct, as they will be ignored in the first step of the reduction!
Older versions of v6.3 and previous versions, e.g. v6.2, suffer from a number of further complications. For example, while XOasis will correctly display the appropriate icon in the reduction folder if an FCLASS header is present, it will display the symbol ?? for raw frames (where the FCLASS header does not exist) because it does not recognise the OAFCLASS header.
OASIS data taken prior to March 2005 do not contain the OAFCLASS header, as it had not been implemented at the WHT.
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.
![]() |
Last Updated: 20 February 2006
Samantha Rix, srix@ing.iac.es |