Changeset 41208 for trunk/doc/release.2015/ps1.datasystem/response.v1.txt

Timestamp:

Dec 21, 2019, 11:52:17 AM (7 years ago)

Author:

eugene

Message:

adding references for datasystem; set textadd and textmod to bf; modify the ippFOO styles

File:

• trunk/doc/release.2015/ps1.datasystem/response.v1.txt (modified) (2 diffs)

trunk/doc/release.2015/ps1.datasystem/response.v1.txt

@@ -88 +88 @@
 affected by poor PSFs in the stack.
 
-  ** th
-
+  ** the galaxy models are not fitted on each warp.  rather we
+     calculate the normalizations and chi-square values for a grid of
+     galaxy model shape parameters for each warp image.  The values
+     for each grid point are combined across all warps to generate a
+     total stack-equivalent grid.  At this point, the best parameters
+     are determined from the grid (interpolating to the chi-square
+     minimum).  This is mathematically equivalent to simultaneously
+     fitting (via a grid search) the pixels from all warps to a single
+     model, preserving the full signal-to-noise.  We have updated the
+     text to add some detail to the description of what is being
+     measured to clarify this point. 
 
 ## Section 3.11
@@ -107 +116 @@
 aren't described until 4.1.3.
 
+ ** we added a sentence to 4.1.1 to note this point.
+
 Missing punctuation in parenthetical HST GSC reference?
 
   ** fixed
 
+## Section 4.1.4
+
+There's some inconsistency here between "detID" and "det_id" (same for
+"image"), both referring to measurement IDs in DVO. If those are
+supposed to be meaningfully different, I'm confused.
+
+  ** in the DVO section (and in the DVO schema), these should all be
+     'detID' and 'imageID'.  In the gpc1 database schema, the
+     underscored versions are used.  we have fixed the erroneous
+     det_id and image_id entries in this section.
+
+## Section 4.2
+
+I tend to associate the term "ubercal" specifically with the SDSS
+version of the algorithm that coined the term, and think it probably
+should be referenced here even if the actual algorithms used are only
+vaguely similar.
+
+  ** we agree and have added a sentence with reference.
+
+## Section 4.3
+
+Is the PSPS database another spatially-shared, file-based database
+using custom technology, a MySQL database like the Processing
+Database, or something else? I assume the same system is used at both
+IFA and MAST?
+
+  ** PSPS is based on MS SQL Server. We have added a bit of
+     description to 4.3.
+
+
+## Section 5.1.1
+
+Apparent typo or missing text: macro ex- its job successfuly".
+
+  ** this should have read 'macro exits successfully'  ("exits" was
+     beign hyphenated).  fixed.
+
+## Section 5.1.4
+
+"responsible to" -> "responsible for"
+
+  ** fixed
+
+## Section 5.2
+
+> Pairing warps together is simplified by the observing strategy in
+which the same pointing is observed multiple times in a night. By
+limiting to warp-warp pairs from the same pointing, the problem is
+significantly reduced from the arbitrary case.
+
+This (as well as the following paragraph) seems to imply that you
+typically generate differences between images taken in the same night,
+which of course limits you to detecting only very short-timescale
+transients and fast-moving objects. I suspect that's just not what you
+intended to imply, or is the nightly processing really not supposed to
+find e.g.  supernovae?
+
+  ** the wording here was unclear that the nightly processing system
+     generates warp-warp difference images (for asteroids), warp-stack
+     difference images (for 3pi supernovae), and MD nightly stack -
+     reference stacks difference images (for deep MD supernovae).  We
+     have updated the text to explain these differences.
+
+## Section 5.2
+
+Are the `projection_cells` described here the same as or related to
+the DVO partition cells of 4.1.3, or the RINGS.V3 skycells of 3.7?
+
+  ** same as RINGS.V3.  we have clarified this and also cleaned up the
+     wording of this paragraph.
+
+This is a more general concept, but it came to a head in this section:
+I found the use of so many notation styles for different concepts more
+distracting than helpful. I think I was able to infer that small caps
+were used for processing stages and non-bold italics were used for
+database tables, but it wasn't clear why some other stages were
+written in fixed-width mixed case instead (were these scripts, rather
+than stages?), or what the use of bold-italic meant (everything
+eles?). I'd recommend either adding a notation legend paragraph early
+in the paper or just cutting down on the number of styles used.
+
+  ** We agree and have simplified the typography a bit (using only aa
+     single face for both db tables and db columns), eliminating the
+     use of boldface.  We have also added a paragraph in the
+     introduction section to define the type faces.
+
+## Section 5.3
+
+Was Nebulous just used by the orchestration levels like pantasks, or
+was it used within the Perl scripts and C programs that constitute the
+algorithmic steps as well?
+
+  ** Nebulous is used by any level of the software that needs access
+     to a specific file.  the c-based processing programs have direct
+     interfaces as do the Perl-based wrappers (ippScripts).  We have
+     added a paragraph to explain this. 
+
+Was the database used by Nebulous integrated with the Processing
+Database at all (or even part of the same server)?
+
+  ** these two databases are on separate machines and kept
+     independent.  A sentence was added to the end of 6.1 to note
+     this.  
+
+It's a bit strange to first encounter what seems like a core part of
+the data access system this late in the description, given that it
+would have needed to be updated by all of the processing steps
+mentioned early. This would of course make more sense if Nebulous is
+in fact used by the lowest levels of the pipeline and hence a Nebulous
+database entry is created whenever a file is written to disk.
+
+  ** our organizational scheme is meant to place the details closest
+     to the science analysis up front and leave the more general
+     systems toward the end, with only a few necessary broad concepts
+     introduced early on for context.  Thus section 3 is about the
+     analysis steps and the related programs, section 4 is about the
+     science database and the calibration, section 5 is more generic
+     operations concepts, and section 6 is the computing hardware.
+     Within section 5, the processing organization comes first, while
+     nebulous is left to the end since it seems (to us) to be very
+     general and should not be driving the science decisions.
+