Changes between Version 7 and Version 8 of ippReleaseManagement

Timestamp:

Sep 20, 2012, 4:21:37 PM (14 years ago)

Author:

bills

Comment:

--

ippReleaseManagement

@@ -237 +237 @@
 
 === Life cycle of a relExp ===
+==== Nightly science ====
 We envision the following potential events in the history of a released exposure for the nightly science
 releases
  * created during nightly science processing once the warp has been completed before the addRun is processed. State active.
- * updated to include the add_id of the addRun 
-
-For a "GR" release
+ * updated to include the add_id of the addRun
+
+==== Grand Reprocessing ====
+For the grand reprocessing, the relExp goes through two states
+
  * row is created when addstar is performed. State set to pending.
- * row is updated when ipptoPSPS is run. At that time the calibration data is updated with the resulting values and the state is changed to reflect the PSPS export.
-
-
-
+ * row is updated when ipptoPSPS is run. At that time the calibration data is updated with the resulting values and the state columns are changed to reflect the PSPS export. state => active
+
+Separating the state into two steps allows the results of the re-processing to be made available prior to 
+PSPS injest if the user requests data from the corresponding release. The data will not be the "default" for
+the given exposure until the calibration is complete at the time of PSPS ingest.
+
+==== DVO Release ====
+This schema allows (but does not require) the contents of DVO releases to be recorded. This would allow users
+of the DVO catalog to refer explicitly to a given set of pixels and calibration.
+
+== Released Skycell ==
+The concepts for sky cells are similar to individual exposures. A row in the table refers to a particular
+release and (tess_id, skycell_id).
+
+Here is the proposed table definition
+
+{{{
+REATE TABLE relSkycell (
+    relstack_id BIGINT AUTO_INCREMENT,
+    rel_id      BIGINT,
+    skycell_id  varchar(64)
+    tess_id     varchar(64)
+    state       VARCHAR(16),    -- current, pending, archive, drop  
+    data_state  VARCHAR(16),    -- nightly, relphot, relastro, psps
+    skycal_id   BIGINT,         -- link to the run that supplied the data
+                                -- for this release. 
+                                -- NOTE: it is the skycal_id that we save,
+                                -- not the stack_id
+    add_id      BIGINT,
+    zpt_obs     FLOAT,          -- calibrated zero point for this release of
+                                -- this skycell
+    zpt_stdev   FLOAT,
+    path_base   VARCHAR(255),   -- path_base of any supporting files,
+                                -- updated WCS for example,
+                                -- we may just build a new cmf
+    flags       UNSIGNED INT,
+    registered  DATETIME,
+    time_stamp  DATETIME,
+    PRIMARY KEY (rel_id),
+    KEY (rel_id, tess_id, skycell_id),  -- NOTE: no foreign key constraint
+                                        -- becase we don't reference the
+                                        -- stack directly. Insert query should
+                                        -- enforce match.
+    FOREIGN KEY(rel_id) REFERENCES ippRelease(rel_id),
+    FOREIGN KEY(skycal_id) REFERENCES skycalRun(skycal_id),
+    FOREIGN KEY(add_id) REFERENCES addRun(add_id)
+) ENGINE=innodb DEFAULT CHARASET=latin1;
+}}}
+
+Note that the skycell is defined by the id of the sky calibration run, not the stack_id. The idea
+is that processing for the stack is not complete until stack photometry and sky calibration is performed.
+
+XXX: What about nightly science stacks? We don't do photometry and calibration on them currently and it's not
+clear if the results of those stages are necessary. Now those data *are* easily findable in the current
+system because the label is not changed. I.E. MD09 nightly stack from 2012-09-06 can be found from data_group
+MD09.20120906 or by selection by MJD-OBS.
+