WSA Interface Control Document

Document control table(s)


This Interface Control Document (ICD) for the WFCAM Science Archive (WSA)
describes the data flow subsystem interface between the data processing
centre (CASU at the IoA, Cambridge) and the archive centre (WFAU at the
IfA, Edinburgh). Details of the types and specifications of processed
WFCAM data to be transfered, along with the transfer protocols
(file naming, transfer method and procedure), are given. The details of
this ICD have been agreed between CASU and WFAU; the formalities are 
being overseen by the JAC and the VISTA Data Flow System (VDFS) project.

Table of contents


1.1 Scope

This Interface Control Document (ICD) is intended to be a formal interface
control agreement between the WFCAM data processing centre at the Cambridge 
Astronomy Survey Unit (CASU) and the archive centre at the Wide Field 
Astronomy Unit (WFAU) in Edinburgh. The processing centre/archive centre
interface is the final subsystem interface in the WFCAM data flow chain, and 
is subject to the rules laid out herein. The ICD concerns WFCAM data only;
all other data ingested into the WFCAM Science Archive (WSA) are outside the
scope of interface control (the WSA will also ingest publicly released data
products, eg. SDSS and 2MASS etc., from other non-CASU sources).

The ICD is meant to be a technical reference: its intended audience is
software engineers and scientists working on processing and archiving in
the data flow. It takes the form of a formal agreement between CASU and
WFAU, but must also satisfy other external bodies, namely JAC, the UKIDSS
survey science consortium and the VISTA Data Flow System. The ICD is,
therefore, a major component of the documentation for the WSA critical
design review.

1.2 Overview

This document is structured as follows. In Section 2, we describe the
fundamental rules that the interface will adhere to, including a
statement of the primary data format, FITS. Then, in Section 3, we
describe the top-level specifications for data that will be transfered
between Cambridge and Edinburgh, including a description of FITS
conventions, keywords, file naming conventions, units, systems of
physical quantities, and unified column descriptors. Section 4
goes on to describe in explicit detail the data structures that will be
transfered. Then, Section 5 describes the transfer methods and procedures
that will achieve the data flow from Cambridge to Edinburgh. Backups and
other security issues are dealt with in Section 6, and finally a summary
is presented in Section 7.

1.3 Reference docs

Generally, this document is modelled on the ESO Data Interface Control
Document [1], and with the exception of the ESO hierarchical FITS
keyword definition, follows as closely as possible the specifications
provided therein. A data flow system overview is provided in [2].
Fundamental "meta" data description (ie. FITS frame headers and keywords)
are described in [3]. The JAC/CASU interface is defined and described in
[4]; CASU pipeline processing is described in [5]. Relevant documents
within the WSA project at WFAU, including the subset presented for the
purposes of the archive CDR, are available from [6].


2.1 WFAU Ingest

The WSA at WFAU will ingest WFCAM data from CASU; there will be no
transfer of WFCAM data between JAC and WFAU for example.

2.2 Data transfer method

The WSA will ingest data via the internet; tapes and/or "pluggable" disks
will not be employed. The implications for required network bandwidth are
discussed in [7].

2.3 Format

Data output from CASU will be provided in standard FITS format (as 
specified in [8]) only. Data will not be expressed in any "hierarchical"
system, eg. ESO hierarchical FITS, or the UK Starlink Hierarchical Data
Structure format (NDFs). The FITS standard is mature, universally accepted
and ideal for transporting both bulk pixel and catalogue data.

2.4 Content

Data transfered from CASU will consist of processed pixels (where the
processing steps are specified by the observing protocol used), confidence
maps, derived source catalogues and associated description data; no raw
pixel data will be transfered to (or held in) the WSA.  Where
irreversible stages such as stacking or mosaicing have been done as part
of the reduction procedure, the individual component images and catalogues
will also be transferred. Library calibration frames will also be
transfered into the WSA (eg. dark frames, flat fields, master skies) for
use by users (not for any processing at the archive end). 

[NB: I've bunged in extra calibration frames - OK? Sensible? I think AA
wants to see this.  **** YUP **** Also, a new
question that arises: for combined products (eg mosaics, stacks) do you
envisage explicit FITS keys detailing which images were used to make
the product? **** Yes here's Jim's comments ****

There _should_ be a list of files that went into a 'combined' file,
but I haven't gotten around to doing this yet.  It's reasonably high on
the priority list, though.  My feeling is that we store things a MEFs to
keep images of individual chips separate.  Once we have formed a tile,
then that need goes away, so it's should be sensible to store the tile's
image in a simple fits file.  It doesn't make any difference to the
software, however and if you have a real reason for wanting it to be in a
single extension MEF, then that's fine by me.

We would like to store such "provenance" info if possible;
also, does a mosaic come as a single pixel array in a primary HDU?
Can be either, for consistency probably should be as an extension.  We
also need to decide how much information to propogate with things like
mosaics.  Hmmm Jim votes for SEFs for this - can't say I'm bothered.]


3.1 Preliminaries

Processed frames will be stored in FITS format, following the guidelines
set out in [1]:

  o  The images comprising a WFCAM superframe will be stored in
     different image extensions of the same FITS container file (a
     multi-extension FITS, or MEF, file); data pixels belonging to one
     chips' image(s) will be stored in one image extension (guideline-2).

  o  The primary data array in the MEF file will be empty (guideline-3)

  o  Keywords describing the dataset in the MEF file as a whole will be
     written into the primary header, while keywords that are related to
     the data in a particular extension will be written into the HDU of
     that extension (guideline-5)

Derived source catalogues corresponding to each image extension will be
written as FITS binary tables in extensions of a single, separate
MEF file with a similarly empty primary array. The headers for the 
catalogue MEF will contain all the information of image MEF headers
plus ancilliary processing keywords and values.

3.2 General FITS keywords

Keywords will follow the standards set out in [1] and [8] as described
(for WFCAM data) in [3]. All keywords and associated values written to
the HDS container files produced by the WFCAM DAS must be propagated
through the JAC/CASU interface, through the data processing pipeline
and into the WSA.

The first keyword in any extension HDU must be XTENSION, and it's value
will take on only 'IMAGE   ' or 'BINTABLE'; the EXTNAME keyword will be
used to identify the extension with a particular device detector. Binary
tables will have every column described by keywords TTYPEn, TFORMn
and TUNITn (see later).

[NB: Jim said: "Having an identifier for the detector as the EXTNAME is a good
idea.  I've written to Alan Pickup with the suggestion that there should
be a keyword in the header with a unique name for the detector so that
should we ever have to swap one out, you can tell from the header.  This
is probably not what we want for EXTNAME, but rather something simple like
'det1', 'det2' etc, so long as we can agree a standard numbering for the
detectors.  **** More Jim response ****
I think what you have here about EXTNAME is pretty much all that
needs saying.  It's really a way of associating a data frame with a
particular location in the camera, rather than with a detector. (Imagine
what could happen if someone decided to swap two of the detectors around).]

World Co-ordinate System (WCS; ie. astrometric) information will be
propagated using a set of keywords described in the latest FITS WCS 
proposals [9,10] by Greisen and Calabretta. 

[NB: I'm going to remove this bit, since at present we don't look as if
we're going to adhere to it...:  **** OK WITH US ****
Error and statistics information will be expressed following the
convention described in [1], whereby the quantity in question has its
statistical auxilliary expressed via a keyword containing the first five
characters of the root name plus a three character suffix ERR (for a
unit standard deviation), MIN/MAX, RMS, AVG etc.]

3.3 Physical units

Physical units will comply with SI units and their derivatives with a few
exceptions for astronomical convenience (see [1] Section 9, Table 14).

Celestial co-ordinates will be expressed in a time system described by
primary HDU keyword RADECSYS; it is anticipated that this will have
value 'FK5' (ie. Hipparcos/Tycho ICRS) over the lifetime of WFCAM, but
this may of course change for VISTA.

3.4 File naming conventions

[NB: this is a proposal from the WFAU end based on clunky ESO-speak:

Files will be named according to the prescription given in [1]. In addition
to the requirements detailed there (Section 11.1.2), for processed WFCAM 
data it is necessary 

  o  to choose the timestamp for a superframe made up from the combination
     of several exposures with different start times;

  o  to distinguish between corrected superframes and object catalogues
     derived from them.
[NB: unless cats are written as extensions into the superframe MEF...]

FITS files will be named as follows:
where  is UKWFCPIX or UKWFCOBJ and the time stamp is taken as being
the earliest start time from the set of interleave microstep exposures.

[NB: this scheme does not allow for different filenames if/when (!) pipeline
and/or source extraction are rerun over the same data...!]]

[NB Alternative proposal from CASU end:]

CASU/JAC/ATC have an agreed policy on filenames [ref??]; furthermore, it
is UKIRT policy to use run numbers that reset back to 1 each night. For
ease of tracking files through the data flow system, it is proposed that
the CASU/WFAU interface follows the same policy, which is as follows.

At telescope files will be called wayyyymmdd_12345.sdf, wbyyyymmdd_12345.sdf 
and so on, where the a,b,c,d correspond to detector, w stands for wfcam and 
the 5 digit run number is just that.

CASU will create 2D raw MEF files with names of the form
and processed filenames of the form where
yyyymmdd is the UT date of observation, nnnnn is the UKIRT DAS running
number (reset to 1 on a nightly basis) and suffix is a combination of
underscore plus two-letter abbreviations indicating pipeline processing 
actions: _sf = interleaved superframe, _st = stack, _sf_st = stacked
superframe, _sf_tl = tiled superframe etc. 

Catalogues generated from frames will be rootname_cat.fits and confidence
maps for frames  For generic confidence maps ie. one
for each passband for each night for non-stacked data we could just use
soft links rather than duplicate data or not bother since info regarding
correct confidence map is in the header.

[NB: I'm happy if you're happy, except for product versioning and 
filename control.  Could append _v1 2,3,4,5,6 etc.... to rootname;
could control reruns at the archive end via directory substructure...
but I'd still prefer it if we could come up with a prescription 
that does it in the filename... sorry to be a P in the A. **** That guy
Jim again ****
I like our naming convention much better than the ESO alternative.  I'm
still not convinced by the idea of versioning in the file name.  In
general there will only be one version of a file on offer at any given
time through the archive.  Any others can be stored in different
directories.  It all depends on how often we see ourselves reprocessing
(after the initial year or so of commissioning) and whether there is a
real _need_ to keep 'inferior' quality reductions.]


4.1 Data obtained at the time of observation

Observations will be described via the keywords OBSERVER, USERID, OBSREF, 

Note that the OBJECT keyword MUST be a field identifier for survey
observations for the purposes of curation within the archive.
[NB: new thing added in - not a CASU problem - simply got to get UKIDSS
to agree to specify field identifiers...  Agree it makes life much simpler
to keep track of what has been observed - should be possible to guarantee
it for the surveys at least.  Currently we have to do this by RA Dec 
position match too since observers call things by an assortment
of different names and make typos.  **** Jim's comments ****
Although OBJECT as you say is not a CASU problem, it should be pushed for
very hard as in the absence of correct header information 
this may be the only way we can associate frames into the correct groups.]

Instrumental characteristics, set-ups and parameters will be described by
keywords as detailed in [3], including instrument detector configuration
(eg. array used DETECTOR; number of integrations NINT), detector
controller information (eg. camera read mode READMODE; read-out application
CAPPLICN), optical configuration (eg. filter name FILTER; base focus
position FOC_MM) and observing conditions/environment (eg. air temperature
AIRTEMP; relative humidity HUMIDITY; opacity data CSOTAU).

All these FITS keys will be propagated through the data flow chain from the
DAS to the WSA.

4.2 Data products (ie. derived data)

4.2.1 Corrected pixel data

The CASU pipeline will instrumentally correct WFCAM pixels into an 
product that is instrument-signature free. The
reduction steps involved in doing so, the derived astrometric and
(first-cut) photometric calibrations and resulting DQC information
generated will be propagated into the WSA using FITS keys
detailed in the Appendices. Appendix A shows the FITS keys for the
primary HDU; appendix B shows an example of an extension set.

[NB: I notice that calibration frames - sky, flat - and confidence maps
are expressed at the extension level rather than the primary HDU level...
is this deliberate? I think I can see why...; let me know if there's
anything CIRSI-specific that needs removing or changing for WFCAM
**** Jim ****
The calibration frames in the headers still refer to PHUs rather than
image extensions, because that's the way the CIRSI data were reduced and I
haven't changed that when I slapped on the WFCAM header (although I was
careful to change the extension number of the CPM). Sorry, it was me being
lazy.  I've pretty much taken out everything that is CIRSI specific.  In
fact, the only bit of the CIRSI headers that have been copied over is the
bits generated by the pipeline (obviously I've corrected the WFCAM date,
ra,dec,times etc to the CIRSI values, but have not per se copied over
the CIRSI header cards).]

4.2.2 Source catalogue attributes

The standard set of CASU source detection parameters can be found in [5];
an example FITS header for a catalogue MEF is given in appendix C.
Table 2 is an extract of the corresponding FITS binary table details for 
each attribute (TFORM is 1E throughout):

No.  Name                   TTYPE               TUNIT  

 1   Seq. no.               Sequence_number       -
 2   Isophotal flux         Isophotal_flux       ADU
 3   X co-ordinate          X_coordinate        pixels
 4   Error in X             X_coordinate_error  pixels
 5   Y co-ordinate          Y_coordinate        pixels
 6   Error in Y             Y_coordinate_error  pixels
 7   Gaussian sigma         Gaussian_sigma      pixels
 8   Ellipticity            Ellipticity           - 
 9   Position angle         Position_angle     degrees
10   Areal profile  1       Areal_1_profile     pixels
17   Areal profile  8       Areal_8_profile     pixels
18   Peak height            Peak_height          ADU
19   Peak height error      Peak_height_error    ADU
20   Core flux              Core_flux            ADU
21   Core flux error        Core_flux_error      ADU
22   Core 1 flux            Core_1_flux          ADU
23   Core 1 flux error      Core_1_flux_error    ADU
42   Core 12 flux           Core_12_flux         ADU
43   Core 12 flux error     Core_12_flux_error   ADU
44   Petrosian radius       Petrosian_radius    pixels
45   Kron radius            Kron_radius         pixels
46   FWHM radius            FWHM_radius         pixels
47   Petrosian flux         Petrosian_flux       ADU
48   Petrosian flux error   Petrosian_flux_error ADU
49   Kron flux              Kron_flux            ADU
50   Kron flux error        Kron_flux_error      ADU
51   FWHM flux              FWHM_flux            ADU
52   FWHM flux error        FWHM_flux_error      ADU
53   Error bit flag         Error_bit_flag       flag
54   Sky level              Sky_level            ADU
55   Sky variance           Sky_variance         ADU
56   Child/parent           Parent_or_child_flag flag
57   Right Ascension        RA                  radians
58   Declination            DEC                 radians
59   Classification         Classification       flag
60   Profile statistic      Profile_statistic   N-sigma
61   PSF flux               PSF_flux             ADU
62   PSF flux error         PSF_flux_error       ADU
63   PSF fitted X           X_psf_fit           pixels
64   PSF fitted X error     X_psf_fit_error     pixels
65   PSF fitted Y           Y_psf_fit           pixels
66   PSF fitted Y error     Y_psf_fit_error     pixels   

[NB: may need additional celestial PA as well as item 9 (position angle wrt 
X axis) for dumb overlay progs that can't understand WCS...? I've changed
all the above to 4-byte reals for consistency with CASU std output.  Ok
but if we opt for WCS dependent info in columns we should use doubles for
RA Dec in case people use them for other purposes.]

4.3 Other data product conventions

  - checksums for data verification, can do within cfitsio now (see below)

  - allowed/logged ranges for attributes, again for verification

  - convention for null or n/a values


[NB: more thought needed at this end for this section; many thanks for your
contributions so far; if you have any further thoughts let me know]

5.1 Methods

Transfer will be via the internet using standard methods.  The data to
be transferred will reside in Cambridge on specific RAID arrays attached
to a linux PC cluster.  WFAU will have an account on this system.
Directories of processed nights data will be setup as the pipeline is running.
While the processing is still running a directory lock file will be used to
denote the in progress operations.  After completion the lock file will be
unset/removed enabling a remotely controlled browsing script to automatically
initiate data transfer to Edinburgh.  

[NB: this kind of thing is going in a different CDR doc concerning hardware:
Tests between different locations in the UK in the day give sustained 
data transfers rates of 4 Mbyte/s and have been used to copy ~100 Gbytes 
of data between sites in 5-6 hours, add in some of what Eckhard has been 
doing.  **** probably worth mentioning here too ****]

Alternative transfer methods we have tested include, scp, grid-ftp,
sftp ........  ). Standard ftp will not be employed since it is insecure.

5.2 Procedure

  - location of data is guaranteed by the pipeline and will be in a
    observation date driven directory structure to which WFAU will have
    a secure direct access

  - "handshaking", eg. notification of readiness will be achieved using a
    lockfile system as outlined above; verification of successful transfer
    by no. and size of files transferred (eg. scp verifies as it goes so
    if preceding two are ok everything is fine; can include checksum
    type verification since cfitsio now supports this; requirement for 
    automatic procedures to flag transfer if incomplete or FU'd)

5.3 Updates

  - reruns in case of bug fixes, improvements in instrumental correction,
    improvements in source extraction: any additional interface issues
    resulting from this possibility/liklihood(!) ?

  - the interface as a whole will be the same regardless of whether
    data being transfered is first-run or re-run as long as the archive
    system can cope; filenames may still be problematical though.


  - raw data will be held online in Cambridge as the primary UK backup.
    Raw data will be also be archived/stored at the JAC

  - security ......... secure transfer, restricted acces to computers
    whatever....... firewalls......



[1] ESO Data Interface Control Document, GEN-SPE-ESO-19940-794/2.0

[2] VDFS document...?

[3] ATC WFCAM HDS container and FITS headers, WFCAM project Document No. ?

[4] JAC-CASU Interface Control Document,

[5] WFCAM Pipeline Design

[6] WFCAM/VISTA Science Archive Development

[7] WFCAM Science Archive hardware design document,

[8] Definition of the Flexible Image Transport System (FITS), document 
    NOST 100-2.0

[9] Representations of world co-ordinates in FITS
    Greisen EW, Calabretta MR, A&A, 395, 1061 (2002)

[10] Representations of celestial co-ordinates in FITS
     Calabretta MR, Greisen EW, A&A, 395, 1077 (2002)



Appendix A: primary HDU FITS keys for image data

SIMPLE  =                    T / file does conform to FITS standard
BITPIX  =                    8 / number of bits per data pixel
NAXIS   =                    0 / number of data axes
EXTEND  =                    T / FITS dataset may contain extensions
COMMENT   FITS (Flexible Image Transport System) format is defined in Astronomy
COMMENT   and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
INHERIT =                    T
TELESCOP= 'UKIRT             ' / Telescope name
INSTRUME= 'WFCAM             ' / Instrument
CAMNUM  =                    1 / Number of WFCAM array
DHSVER  = 'UKDHS 2002 Oct 31 ' / Data handling version
HDTFILE = 'wfcam.hdt         ' / Name of hdt file
HDTFILE2= 'wfcam_w.hdt       ' / Name of camera specific hdt file
OBSERVER= 'Daffy Duck        ' / Observers names
USERID  = 'DD      '           / Userid logged in as
OBSREF  = 'notPATT99'          / PATT or other reference
PROJECT = 'Example WFCAM data' / Time-allocation code
MSBID   = 'b44d9b4e3b90e6f99b7c3a032301600b' / Id min.-schedulable block
OBJECT  = 'CIRSI_NGC135A'      / Object name from telescope
RECIPE  = 'SOME_WFCAM_RECIPE'  / Data reduction recipe to be used
OBSNUM  =                    9 / Observation number
GRPNUM  =                    8 / Group number applied to all members
GRPMEM  =                    T / Group membership
STANDARD=                    F / Is the target a standard star observation?
NOFFSETS=                    4 / Number of offset positions in a pattern
NJITTER =                    4 / Number of positions in tel pattern
JITTER_I=                    1 / Serial number in this tel jitter pattern
JITTER_X=                 0.00 / [arcsec] X (RA) offset in tel jitter pattern
JITTER_Y=                 0.00 / [arcsec] Y (Dec) offset in tel jitter pattern
NUSTEP  =                    4 / Number of positions in microstep pattern
USTEP_I =                    1 / Serial number in this microstep pattern
USTEP_X =                 0.00 / [arcsec] X (RA) offset in microstep pattern
USTEP_Y =                 0.00 / [arcsec] Y (Dec) offset in microstep pattern
NFOC    =                    0 / Number of positions in focus scan
NFOCSCAN=                    0 / Number of focus scans in focus test
UTDATE  = '20010607'           / UT date as integer in yyyymmdd format
DATE-OBS= '2001-06-07T21:23:46Z' / Date and time (UTC) of start of observation
DATE-END= '2001-06-07T21:24:10Z' / Date and time (UTC) of end of observation
WCSAXES =                    2 / Number of axes in world co-ordinate system
RADESYS = 'FK5     '           / Mean IAU 1984 equatorial co-ordinates
EQUINOX =             2000.000 / [yr] Equinox of object position
RABASE  =             217.4049 / [h] Right ascension of base position
DECBASE =           0.06174444 / [deg] Declination of base position
TRAOFF  =                0.000 / [arcsec] Right ascension telescope offset
TDECOFF =                0.000 / [arcsec] Declination telescope offset
AMSTART =                1.312 / Airmass at start of observation
AMEND   =                1.310 / Airmass at end of observation
TELRA   =             217.4049 / [h] Current telescope right ascension
TELDEC  =           0.06174444 / [deg] Current telescope declination
GSRA    =             217.4049 / [h] Right ascension of guide star
GSDEC   =           0.06174444 / [deg] Declination of guide star
READMODE= 'CDS_v1  '           / Name of camera readmode
CAPPLICN= 'dunno   '           / Name of camera readout application
READOUT = 'CDS     '           / Camera readout (CDS|NDR|SAR|RRR)
EXP_TIME=                24.08 / [s] Integration time per exposure
NEXP    =                    1 / Number of exposures in integration
READINT =             0.300000 / [s] Interval between reads
NREADS  =                    0 / Number of reads per exposure
FILTER  = 'J       '           / Combined filter name
FOC_MM  =               2.4992 / [mm] Focus position
AIRTEMP =               -0.013 / [degC] Air temperature
BARPRESS=              650.000 / Ambient pressure
DEWPOINT=                2.000 / [degC] Dewpoint
DOMETEMP=                1.101 / [degC] Dome temperature
HUMIDITY=               45.816 / Relative Humidity
MIRRBSW =                7.123 / [degC] Temperature mirror B SW
MIRRNE  =                7.124 / [degC] Mirror temperature NE
MIRRNW  =                7.124 / [degC] Mirror temperature NW
MIRRSE  =                7.124 / [degC] Mirror temperature SE
MIRRSW  =                7.124 / [degC] Mirror temperature SW
MIRRBTNW=                7.128 / [degC] Mirror bottom temp. NW
MIRRTPNW=                7.128 / [degC] Mirror top temp. NW
SECONDAR=                7.133 / [degC] Temperature of secondary
TOPAIRNW=                7.134 / [degC] Top air NW
TRUSSENE=                3.286 / [degC] Truss leg ENE
TRUSSWSW=                2.048 / [degC] Truss leg WSW
WINDDIR =              265.958 / [deg] Wind direction, azimuth
WINDSPD =               48.915 / [km/h] Wind speed
CSOTAU  =                0.047 / Tau at 225 GHz from CSO
TAUDATE = '2001-11-30T04:07'   / Time and date opf Tau reading
TAUSRC  = 'CSO     '           /Source of opacity data
CNFINDEX=                    1 / Configuration index

Appendix B: extension HDU FITS keys for an image

XTENSION= 'IMAGE   '           / IMAGE extension
EXTNAME = '                   '/ Extension name/detector name...?
BITPIX  =                  -32 / number of bits per data pixel
NAXIS   =                    2 / number of data axes
NAXIS1  =                 1091 / length of data axis 1
NAXIS2  =                 1091 / length of data axis 2
PCOUNT  =                    0 / required keyword; must = 0
GCOUNT  =                    1 / required keyword; must = 1
DETECTOR= 'ALADDIN'            / Detector array used
NINT    =                    1 / Number of integrations in observation
DROWS   =                 1024 / [pixel] Number of detector rows
DCOLUMNS=                 1024 / [pixel] Number of detector columns
RDOUT_X1=                    1 / Start column of array readout
RDOUT_X2=                 1024 / Start column of array readout
RDOUT_Y1=                    1 / Start row    of array readout
RDOUT_Y2=                 1024 / Start row    of array readout
PIXLSIZE=                0.454 / [arcsec] Pixel size
FLATCOR = 'Done with:'
RSTANOM = 'Done with medlinfilt: 50 25'
CIR_CPM = '[1]' / Confidence map
SKYSUB  = 'Done TILE_SKY: sky_6523.fits[0] 1.104' / Sky subtraction info
PROJP1  =                   1.
PROJP3  =                 220.
CIRMED  =              1881.53 / Latest estimate of background
CIR_BVAR=             182.6193 / Latest estimate of background variance
CIR_ZERO=            -73.88457 / Pedestal value relative to group average
CIR_SCAL=                   1. / Background scale relative to group maximum
CIR_OPM = 'irx_6523_c1_012_opm.fits[0]' / Object mask
CTYPE1  = 'RA---ZPN'
CRVAL1  =     217.409246142543
CRVAL2  =   0.0631388007913921
CRPIX1  =     1569.17568234834 / Dither offset Y
CRPIX2  =    -402.446920842832 / Dither offset Y
CD1_1   = -1.66959860113266E-06
CD2_1   = 0.000126195921150401
CD1_2   = 0.000126124625720947
CD2_2   =  1.4709458469656E-06
WCSPASS =                    1 / Pass level of WCS
CIR_XOFF=             35.40594 / Dither offset X
CIR_YOFF=              33.1044 / Dither offset Y
NUMBRMS =                   30
STDCRMS =     0.32526138905959
HISTORY 20030305 10:28:46
HISTORY    $Id: cir_imcore.c,v 1.4 2003/02/03 09:32:36 jim Exp $

Appendix C: example FITS keys from a catalogue MEF (excluding keys inherited
from corresponding image data):

Primary HDU:

SIMPLE  =                    T / file does conform to FITS standard
BITPIX  =                    8 / number of bits per data pixel
NAXIS   =                    0 / number of data axes
EXTEND  =                    T / FITS dataset may contain extensions
COMMENT   FITS (Flexible Image Transport System) format is defined in Astronomy
COMMENT   and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H

Each extension HDU:

XTENSION= 'BINTABLE'           / binary table extension
BITPIX  =                    8 / 8-bit bytes
NAXIS   =                    2 / 2-dimensional binary table
NAXIS1  =                  264 / width of table in bytes
NAXIS2  =                  141 / number of rows in table
PCOUNT  =                    0 / size of special data area
GCOUNT  =                    1 / one data group (required keyword)
TFIELDS =                   66 / number of fields in each row

[NB: from here onwards needs altering for the full WFCAM enhanced 66 
attribute set - let me know what you think of my Table 2]

TTYPE1  = 'No.     '           / label for field   1
TFORM1  = '1E      '           / data format of field: 4-byte REAL
TUNIT1  = '        '           / physical unit of field
TTYPE2  = 'Isophotal_flux'     / label for field   2
TFORM2  = '1E      '           / data format of field: 4-byte REAL
TUNIT2  = 'Counts  '           / physical unit of field
TTYPE3  = 'Total_flux'         / label for field   3
TFORM3  = '1E      '           / data format of field: 4-byte REAL
TUNIT3  = 'Counts  '           / physical unit of field
TTYPE4  = 'Core_flux'          / Fitted flux within 1x core radius
TFORM4  = '1E      '           / data format of field: 4-byte REAL
TUNIT4  = 'Counts  '           / physical unit of field
TTYPE5  = 'X_coordinate'       / label for field   5
TFORM5  = '1E      '           / data format of field: 4-byte REAL
TUNIT5  = 'Pixels  '           / physical unit of field
TTYPE6  = 'Y_coordinate'       / label for field   6
TFORM6  = '1E      '           / data format of field: 4-byte REAL
TUNIT6  = 'Pixels  '           / physical unit of field
TTYPE7  = 'Gaussian_sigma'     / label for field   7
TFORM7  = '1E      '           / data format of field: 4-byte REAL
TUNIT7  = 'Pixels  '           / physical unit of field
TTYPE8  = 'Ellipticity'        / label for field   8
TFORM8  = '1E      '           / data format of field: 4-byte REAL
TUNIT8  = '        '           / physical unit of field
TTYPE9  = 'Position_angle'     / label for field   9
TFORM9  = '1E      '           / data format of field: 4-byte REAL
TUNIT9  = 'Degrees '           / physical unit of field
TTYPE10 = 'Peak_height'        / label for field  10
TFORM10 = '1E      '           / data format of field: 4-byte REAL
TUNIT10 = 'Counts  '           / physical unit of field
TTYPE11 = 'Areal_1_profile'    / label for field  11
TFORM11 = '1E      '           / data format of field: 4-byte REAL
TUNIT11 = 'Pixels  '           / physical unit of field
TTYPE12 = 'Areal_2_profile'    / label for field  12
TFORM12 = '1E      '           / data format of field: 4-byte REAL
TUNIT12 = 'Pixels  '           / physical unit of field
TTYPE13 = 'Areal_3_profile'    / label for field  13
TFORM13 = '1E      '           / data format of field: 4-byte REAL
TUNIT13 = 'Pixels  '           / physical unit of field
TTYPE14 = 'Areal_4_profile'    / label for field  14
TFORM14 = '1E      '           / data format of field: 4-byte REAL
TUNIT14 = 'Pixels  '           / physical unit of field
TTYPE15 = 'Areal_5_profile'    / label for field  15
TFORM15 = '1E      '           / data format of field: 4-byte REAL
TUNIT15 = 'Pixels  '           / physical unit of field
TTYPE16 = 'Areal_6_profile'    / label for field  16
TFORM16 = '1E      '           / data format of field: 4-byte REAL
TUNIT16 = 'Pixels  '           / physical unit of field
TTYPE17 = 'Areal_7_profile'    / label for field  17
TFORM17 = '1E      '           / data format of field: 4-byte REAL
TUNIT17 = 'Pixels  '           / physical unit of field
TTYPE18 = 'Areal_8_profile'    / label for field  18
TFORM18 = '1E      '           / data format of field: 4-byte REAL
TUNIT18 = 'Pixels  '           / physical unit of field
TTYPE19 = 'Core1_flux'         / Fitted flux within 1/2x core radius
TFORM19 = '1E      '           / data format of field: 4-byte REAL
TUNIT19 = 'Counts  '           / physical unit of field
TTYPE20 = 'Core2_flux'         / Fitted flux within sqrt(2)x core radius
TFORM20 = '1E      '           / data format of field: 4-byte REAL
TUNIT20 = 'Counts  '           / physical unit of field
TTYPE21 = 'Core3_flux'         / Fitted flux within 2x core radius
TFORM21 = '1E      '           / data format of field: 4-byte REAL
TUNIT21 = 'Counts  '           / physical unit of field
TTYPE22 = 'Core4_flux'         / Fitted flux within 2sqrt(2)x core radius
TFORM22 = '1E      '           / data format of field: 4-byte REAL
TUNIT22 = 'Counts  '           / physical unit of field
TTYPE23 = 'RA      '           / label for field  23
TFORM23 = '1E      '           / data format of field: 4-byte REAL
TUNIT23 = 'RADIANS '           / physical unit of field
TTYPE24 = 'DEC     '           / label for field  24
TFORM24 = '1E      '           / data format of field: 4-byte REAL
TUNIT24 = 'RADIANS '           / physical unit of field
TTYPE25 = 'Classification'     / label for field  25
TFORM25 = '1E      '           / data format of field: 4-byte REAL
TUNIT25 = 'Flag    '           / physical unit of field
TTYPE26 = 'Statistic'          / label for field  26
TFORM26 = '1E      '           / data format of field: 4-byte REAL
TUNIT26 = 'N-sigma '           / physical unit of field
TTYPE27 = 'Blank   '           / label for field  27
TFORM27 = '1E      '           / data format of field: 4-byte REAL
TUNIT27 = 'Blank   '           / physical unit of field
TTYPE28 = 'Blank   '           / label for field  28
TFORM28 = '1E      '           / data format of field: 4-byte REAL
TUNIT28 = 'Blank   '           / physical unit of field
TTYPE29 = 'Blank   '           / label for field  29
TFORM29 = '1E      '           / data format of field: 4-byte REAL
TUNIT29 = 'Blank   '           / physical unit of field
TTYPE30 = 'Blank   '           / label for field  30
TFORM30 = '1E      '           / data format of field: 4-byte REAL
TUNIT30 = 'Blank   '           / physical unit of field
TTYPE31 = 'Blank   '           / label for field  31
TFORM31 = '1E      '           / data format of field: 4-byte REAL
TUNIT31 = 'Blank   '           / physical unit of field
TTYPE32 = 'Blank   '           / label for field  32
TFORM32 = '1E      '           / data format of field: 4-byte REAL
TUNIT32 = 'Blank   '           / physical unit of field
EXTNAME = 'APM-BINARYTABLE'    / name of this binary table extension
DATE    = '2003-03-05T10:28:46' / file creation date (YYYY-MM-DDThh:mm:ss UT)
SKYLEVEL=              1880.99 / Median sky brightness (counts/pixel)
SKYNOISE=                 4.54 / Pixel noise at sky level (counts)
THRESHOL=                 9.07 / Isophotal analysis threshold (counts)
MINPIX  =                    5 / Minimum size for images (pixels)
CROWDED =                    1 / Crowded field analysis flag (0 none, 1 active)
RCORE   =                  3.5 / Core radius for default profile fit (pixels)
SEEING  =             2.061935 / Average FWHM (pixels)
COMMENT   FITS (Flexible Image Transport System) format is defined in Astronomy
COMMENT   and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
INHERIT =                    T
ELLIPTIC=           0.06848837 / Average stellar ellipticity (1-b/a)
CLASSIFD=                    T / Class flag: -1 stellar, 1 non-stellar, 0 noise
SATURATE=               30000. / Average saturation level in frame
APCORPK =             1.852217 / Stellar aperture correction - peak height
APCOR1  =            0.3795509 / Stellar aperture correction - core1 flux
APCOR   =           0.08592701 / Stellar aperture correction - core flux
APCOR2  =           0.03884411 / Stellar aperture correction - core2 flux
APCOR3  =           0.01241398 / Stellar aperture correction - core3 flux
APCOR4  =                   0. / Stellar aperture correction - core4 flux
COMMENT Symbolic translation for GAIA ellipse plotting........
SYMBOL1 = '{Ellipticity Position_angle Areal_1_profile Classification} {el'
SYMBOL2 = 'lipse blue (1.0-$Ellipticity) $Position_angle+90 {} $Classific'
SYMBOL3 = 'ation==1} {sqrt($Areal_1_profile*(1.0-$Ellipticity)/3.142)} : {'
SYMBOL4 = 'Ellipticity Position_angle Areal_1_profile Classification} {el'
SYMBOL5 = 'lipse red (1.0-$Ellipticity) $Position_angle+90 {} $Classific'
SYMBOL6 = 'ation==-1} {sqrt($Areal_1_profile*(1.0-$Ellipticity)/3.142)} :'
SYMBOL7 = '{Ellipticity Position_angle Areal_1_profile Classification} {el'
SYMBOL8 = 'lipse green (1.0-$Ellipticity) $Position_angle+90 {} $Classifi'
SYMBOL9 = 'cation==0} {sqrt($Areal_1_profile*(1.0-$Ellipticity)/3.142)}'
HISTORY 20030305 10:28:46
HISTORY    $Id: cir_classify.c,v 1.3 2003/02/03 09:32:36 jim Exp $

Last modified: Thu Mar 6 14:40:13 2003