Changeset 4386 for trunk/archive/scripts/src/concepts.txt

Timestamp:

Jun 24, 2005, 3:05:59 PM (21 years ago)

Author:

Paul Price

Message:

Retrieval of concepts seems to be working.

File:

• trunk/archive/scripts/src/concepts.txt (modified) (3 diffs)

trunk/archive/scripts/src/concepts.txt

@@ -27 +27 @@
 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:
@@ -43 +47 @@
 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.XOFFSET            Offset on the CCD of window start in x
-CELL.YOFFSET            Offset on the CCD of window start in y
 CELL.XBIN               Binning in x
 CELL.YBIN               Binning in y
@@ -55 +59 @@
 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 OBSNUM (observation number),
-which allows an FPA to be identified given a cell, etc.
+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.
 
 
-These are optional:
+Retrieval
+=========
 
-DB.HOST         Database host name (for psDBInit)
-DB.NAME         Database name (for psDBInit)
-DB.USER         Database user name (for psDBInit)
-DB.PASSWORD     Database password (for psDBInit)
+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.
+