WSA Interface Control Document
------------------------------
------------------------------
Document control table(s)
Abstract:
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.0 INTRODUCTION:
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.0 FUNDAMENTALS
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.0 DATA SPECIFICATION
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: r..YYYY-MM-DDThh.mm.ss.fits
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 w_yyyymmdd_nnnnn.fit
and processed filenames of the form w_yyyymmdd_nnnnn_suffix.fit 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 rootname_conf.fit. 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.0 DETAILED DATA SPECIFICATION
4.1 Data obtained at the time of observation
Observations will be described via the keywords OBSERVER, USERID, OBSREF,
PROJECT, MSBID and OBJECT keywords.
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
applicability.
**** 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
5.0 TRANSFER METHODS & PROCEDURES
[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.
6.0 BACKUPS AND OTHER SECURITY ISSUES
- 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......
7.0 SUMMARY
REFERENCES
[1] ESO Data Interface Control Document, GEN-SPE-ESO-19940-794/2.0
http://archive.eso.org/DICB/dic-2.0/dic-2.0.4.pdf
[2] VDFS document...?
[3] ATC WFCAM HDS container and FITS headers, WFCAM project Document No. ?
[4] JAC-CASU Interface Control Document,
http://www.jach.hawaii.edu/JACpublic/UKIRT/instruments/wfcam/ICD/
[5] WFCAM Pipeline Design
http://www.ast.cam.ac.uk/~wfcam/docs/wfcampipedoc_v2.ps.gz
[6] WFCAM/VISTA Science Archive Development
http://www.roe.ac.uk/~nch/wfcam/
[7] WFCAM Science Archive hardware design document,
http://www.roe.ac.uk/~nch/wfcam/...
[8] Definition of the Flexible Image Transport System (FITS), document
NOST 100-2.0
http://fits.gsfc.nasa.gov/fits_home.html
[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)
GLOSSARY
APPENDICES
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
OBSTYPE = 'OBJECT ' / Type (BIAS|DARK|ARC|FLAT|OBJECT|SKY)
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
END
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: J_flat_1.fit'
RSTANOM = 'Done with medlinfilt: 50 25'
CIR_CPM = 'wfcam_6523_conf.fit[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'
CTYPE2 = 'DEC--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 $
END
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
END
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 $
END
Last modified: Thu Mar 6 14:40:13 2003