Changes between Initial Version and Version 1 of DvoSchemaChangeProposal

Timestamp:

Jul 6, 2012, 5:35:26 PM (14 years ago)

Author:

heather

Comment:

--

DvoSchemaChangeProposal

@@ +1 @@
+== DVO Schema Change Proposal ==
+
+
+In order to properly populate the Objects table in PSPS, we need to make a few schema changes to dvo. 
+
+== ippToPsps (now) ==
+
+ippToPsps makes batches out of detections (cam), stacks, and "objects" (from dvo)
+
+Detections are loaded on a per smf basis:  relevant information is pulled from the smf in question and from the dvo.
+
+Stacks are loaded on a per stack_id basis: relevant information is pulled from the cmf and from the dvo.
+
+Objects are loaded per area of sky (example, from n0000/0563.11.* part of the sky), there are no joins back to smf or cmf (and we want to keep it that way). 
+
+== PSPS ==
+
+There are missing fields in the Object table in PSPS, but it is not possible to cleanly ingest using ippToPsps
+
+ * '''xMagBest''' to be filled with kron magnitudes, using the values from the stack (however, what about overlap? how to grab the correct stack?). 
+
+ * '''xyColor''' with colors made from xMagBest (trivial)
+
+ * '''sgSep'''minimum psfLikelihood of the five filters - i.e. if it is more extended in one filter than the others, use the one that gives the strongest indication of being extended - same problem need to find the stacks (the correct ones) and calculate
+
+ * '''objInfoFlag''' might already be in dvo?
+  
+ * '''xModID''' = flag for an upper limit from aperture measurements. i.e. if no detection put an upper limit from aperture measurment in xMagBest and set xModID for that filter to 1. Default 0. Alternatively, use the xMeanFlux and xMeanFluxErr for aperature/ upperlimits.  
+   * at the moment this looks like it can be calculated in psps (correct? assuming xMagBest and xMeanFlux are both in the dvo..)
+
+ * '''XMin and XMax  (HAF) min and max mags are in PSPS.Object but are not filled.  Is this to be done on ipp side or psps side? '''
+
+ * why not fill the objects from stack?  It involves an update (bad for psps), and it causes chaos in ipptopsps (batches are for stack or for detection or for object, making a combination of those = bad)
+
+== DVO Schema changes Proposal ==
+
+ * add more information into cps:
+ {{{ 
+ FIELD MagBest,   MAGBEST,     float,       best (kron) mag in this band     mags 
+ FIELD dMagBest,  MAGBEST_ERR, float,       formal error on best mag         mags
+ FIELD extNsigma, EXT_NSIGMA,  float,       Nsigma deviation towards EXT(from stack, same stack_id as for MagBest)
+ }}}
+   * do we want to add BestObjID so that we can find more information for the "Best" object  in the future?
+   * similar question for XMin and XMax, should those also go into the cps file? or can they be calculated from dvo?
+
+ * add more information into cpm:
+ {{{
+ FIELD KronMag,  KRONMAG,     float, kron mag, mags
+ FIELD dKronMag, KRONMAG_ERR, float, kron mag err, mags
+
+ }}}
+   * ''' I don't know other fields we need other than Kron... (HAF) '''
+ 
+ * addstar needs to be modded to handle these new fields
+  
+ * relphot needs to be modded to handle these new fields
+
+ == Proposed IPPtoPSPS changes ==
+
+ If the schema is changed, the following can be added to ipptopsps:
+
+ * stacks grab kron from the cmf file - keep it that way?
+ * detections grab kron from the smf file - keep it that way?
+
+ * objects
+   * have it suck in magbest, sgsep, flags
+   * calculate colors and xmod id
+   * xMin/xMax ??? (if in dvo, trivial to add)
+
+
+