We need to be able to do two things:

1. Given an identifier (root name, observation number, whatever), read
   in the whole FPA (e.g., for phase 1 and 3).  This means that we
   need to be able to identify the files for each chip, and the
   extensions.

2. Given a file, identify what it is: observation number + chip/cell.
   This is so that we can identify the filter, airmass, etc.  We can't
   expect that these will always be specified in the chip level FITS
   headers, but might be stored in a database under the observation
   number.

That is, we need to be able to identify the components given the
whole, and we need to identify the whole given the component.



Here is the list of IPP concepts, each of which must be specified somewhere.

FPA-level:
FPA.AIRMASS		Airmass at which the observation is made (boresight)
FPA.FILTER		Filter used
FPA.POSANGLE		Position angle
FPA.RA			Right Ascension of boresight
FPA.DEC			Declination of boresight
FPA.RADECSYS		System of RA,Dec (e.g., J2000 or ICRS)
FPA.NAME		An identifier (e.g., observation number) for the FPA instance
FPA.DATE		UT date (YYYY-MM-DD)
FPA.TIME		UT time (HH:MM:SS.sss)
FPA.DATETIME		UT date and time (YYYY-MM-DDTHH:MM:SS.ss)
FPA.MJD			Modified Julian Date

Chip-level:
CHIP.NAME		The name of the chip (unique within the FPA) --- set at read
CHIP.FPA		FPA identifier

Cell/Readout-level:
CELL.NAME		The name of the cell (unique within the parent chip) --- set at read
CELL.CHIP		Chip identifier --- might be set at read
CELL.DATE		Date of observation start
CELL.TIME		Time of observation start
CELL.EXPOSURE		Exposure time of image
CELL.DARKTIME		Dark time for image
CELL.BIASSEC		Overscan region(s)
CELL.TRIMSEC		Trim region
CELL.GAIN		CCD gain (e/ADU)
CELL.READNOISE		CCD read noise (e)
CELL.SATURATION		CCD saturation point (ADU)
CELL.BAD		CCD bad pixel point (ADU)

CELL.XBIN		Binning in x
CELL.YBIN		Binning in y
CELL.XPARITY		Direction of readout in x
CELL.YPARITY		Direction of readout in y

There is no reason why concepts higher up can't be specified lower
down (multiple times, at the risk of introducing the potential for
value to become out of sync).  And there is no reason why (most)
concepts lower down can't be specified higher up, and simply be
inherited.  The exception to this is the FPA.NAME (observation
number), which allows an FPA to be identified given a cell, etc.

There are so many ways of specifying dates and times.  We probably
want a high-level function, psCellGetTimeObs() to sort through all of the
possibilities.

Similarly with binning: CCDSUM is a common header, or the bin factors
might be in separate headers.


Retrieval
=========

Each of the concepts can be retrieved in the following ways:

1. FITS header translation: the camera configuration contains a
   "TRANSLATION" entry, which gives the concept along with the FITS
   header equivalent.

2. Database: the camera configuration "DATABASE" entry contains
   information on how to poll the database for the required concept.
   The DATABASE entry contains metadatas specified using the TYPE:

	TYPE		dbEntry		TABLE		COLUMN		GIVENDBCOL	GIVENPS

   An example DATABASE entry is:

	CELL.GAIN	dbEntry		Camera		gain		chipId,cellId	CHIP.NAME,CELL.NAME

   This says, in the database, you basically do: "SELECT gain IN
   Camera where chipId == CHIP.NAME and cellId == CELL.NAME" (where I
   have, no doubt, taken liberty with the SQL query).  In this case,
   CHIP.NAME and CELL.NAME are looked up before the query is executed,
   using means other than a DB query (otherwise we could get stuck in
   an infinite loop).

3. Defaults: the camera configuration "DEFAULTS" entry contains
   default values.  These default values may simply be specified, or
   they may be dependent upon another value.  In the latter case, an
   additional keyword, "CONCEPT_DEPEND", where "CONCEPT" is the
   concept of interest, and "DEPEND" is literal, is specified with the
   value being the concept on which it is dependent.  Then, the
   concept is a METADATA type, with the elements being values of the
   other concept on which it is dependent.  An example is helpful:

	CELL.YPARITY_DEPEND	STR	CHIP.NAME
	CELL.YPARITY	METADATA
		ccd00	S32	-1
		ccd35	S32	1
	END

   This says that the CELL.YPARITY is dependent upon the CHIP.NAME:
   ccd00 has negative parity, and ccd35 has positive parity.

