Changes between Version 72 and Version 73 of MD10.refstack.20130715

Timestamp:

Sep 12, 2013, 2:49:38 PM (13 years ago)

Author:

Mark Huber

Comment:

--

MD10.refstack.20130715

@@ -539 +539 @@
 +----------------+-------------------+------------------------+---------------------+---------+
 |              4 | MD10.pv2.20130828 | MD10.20120825          | 2012-08-25 13:20:29 | y.00000 | 
+|             16 | MD10.pv2.20130828 | MD10.20121014          | 2012-10-14 07:14:56 | g.00000 | 
+|              2 | MD10.pv2.20130828 | MD10.20121211          | 2012-12-11 05:52:58 | i.00000 | 
+|             19 | MD10.pv2.20130828 | MD10.20121215          | 2012-12-15 05:47:47 | y.00000 | 
+
+|              5 | MD10.pv2.20130828 | MD10.pv1.20130324      | 2010-11-03 08:01:45 | g.00000 | 
+|              3 | MD10.pv2.20130828 | MD10.refstack.20120705 | 2010-11-03 08:14:32 | g.00000 | 
+
+|             22 | MD10.pv2.20130828 | MD10.20121023          | 2012-10-23 07:07:21 | y.00000 | 
+|             18 | MD10.pv2.20130828 | MD10.refstack.20130715 | 2012-10-23 07:28:34 | y.00000 | 
+
+|              8 | MD10.pv2.20130828 | MD10.20130714          | 2013-07-14 13:13:17 | i.00000 | -- already PV2 so a normal update process without updating the camera stage
+
+}}}
+
+When doing the update process, have found cases where only a single, valid instance exists for a not insignificant amount of raw data.. this is tracked more in the full MD04 update ([wiki:MD04.pv2_deeptest.20130903]).
+
+
+=== PV2 Update Masking Losses in Warp ===
+Odd mask lost in PV2 updates -- seems to be limited to 
+{{{
+    PM_SOURCE_MODE_CR_LIMIT
+    PM_SOURCE_MODE_BLEND
+}}}
+
+Was suggested that possibly from photometry not being run on update -- since masks being remade in PV2 updates then lost, while a normal update uses the already defined mask? Since PV2 is mainly for improved inputs to stacks, should be minor and just rejected? (except for low N..)
+
+
+Example -- one masked CR is lost (full reprocessing retains it while the PV2 update method loses it) and one is gained (as with the full reprocessing and should be)
+{{{
+exposure.exp_id: o5503g0240o.250240
+new chip/cam/warp_id = 883673 / 854492 / 835018
+old/pv1/up chip/cam/warp_id = 810251 / 786993 / 766825
+skycell.045
+}}}
+
+ * Image panels --
+
+|| full reprocessing || pv1 normal update || pv2 s/ camera update || cleanup and normal update of pv2 ||
+
+[[Image(o5503g0240o.s045im_cr_center.jpg,500px)]]
+
+ * Mask panels left to right -- (same sequence)
+
+[[Image(o5503g0240o.s045mk_cr_center.jpg,500px)]]
+
+
+=== PV2 Update Night Stacks ===
+Only focusing on the unconvolved stacks as those are only used for the SSdiff, the convolved stacks will be looked at in more detail when stack photometry is evaluated.
+
+Default/current operations config version with PV2 update warps --
+ * label -- meh_md10nstest20130831
+ * data_group -- meh_md10.<obsdate>ns20130831  (i.e., meh_md10.20101103ns20130831)
+
+Suggested config option version with PV2 update warps -- 
+ * label --  meh_md10nstest20130830 
+ * data_group -- meh_md10.<obsdate>nstest20130830 (i.e. meh_md10.20101103ns20130830)
+
+
+{{{
+| count(warp_id) | label             | data_group             | dateobs             | filter  |
++----------------+-------------------+------------------------+---------------------+---------+
+|              4 | MD10.pv2.20130828 | MD10.20120825          | 2012-08-25 13:20:29 | y.00000 | 
 --> only 4/8 as the other exposures have >12 pixel FWHM and fail the camera stage. Remaining 4 have near limit FWHM
 |             16 | MD10.pv2.20130828 | MD10.20121014          | 2012-10-14 07:14:56 | g.00000 | 
@@ -570 +632 @@
 
 
-When doing the update process, have found cases where only a single, valid instance exists for a not insignificant amount of raw data.. this is tracked more in the full MD04 update ([wiki:MD04.pv2_deeptest.20130903]).
-
-
-=== PV2 Update Masking Losses in Warp ===
-Odd mask lost in PV2 updates -- seems to be limited to 
-{{{
-    PM_SOURCE_MODE_CR_LIMIT
-    PM_SOURCE_MODE_BLEND
-}}}
-
-Was suggested that possibly from photometry not being run on update -- since masks being remade in PV2 updates then lost, while a normal update uses the already defined mask? Since PV2 is mainly for improved inputs to stacks, should be minor and just rejected? (except for low N..)
-
-
-Example -- one masked CR is lost (full reprocessing retains it while the PV2 update method loses it) and one is gained (as with the full reprocessing and should be)
-{{{
-exposure.exp_id: o5503g0240o.250240
-new chip/cam/warp_id = 883673 / 854492 / 835018
-old/pv1/up chip/cam/warp_id = 810251 / 786993 / 766825
-skycell.045
-}}}
-
- * Image panels --
-
-|| full reprocessing || pv1 normal update || pv2 s/ camera update || cleanup and normal update of pv2 ||
-
-[[Image(o5503g0240o.s045im_cr_center.jpg,500px)]]
-
- * Mask panels left to right -- (same sequence)
-
-[[Image(o5503g0240o.s045mk_cr_center.jpg,500px)]]
-
-
-=== PV2 Update Night Stacks ===
-Only focusing on the unconvolved stacks as those are only used for the SSdiff, the convolved stacks will be looked at in more detail when stack photometry is evaluated.
-
-Default/current operations config version with PV2 update warps --
- * label -- meh_md10nstest20130831
- * data_group -- meh_md10.<obsdate>ns20130831  (i.e., meh_md10.20101103ns20130831)
-
-Suggested config option version with PV2 update warps -- 
- * label --  meh_md10nstest20130830 
- * data_group -- meh_md10.<obsdate>nstest20130830 (i.e. meh_md10.20101103ns20130830)
-
-
-Rejection comparison -- 
+Rejection and detection number comparison -- 
 
 Skycell coverage comparison -- edges and central dither
 
-Detection number comparison --
 
 Depth comparison --