| 3 | | * Queuing |
| 4 | | * Processing |
| 5 | | * Stacking |
| 6 | | * Normalization |
| 7 | | * Residuals |
| 8 | | * Rejection |
| 9 | | * Registration |
| 10 | | |
| | 3 | * '''Queuing'''. Most detrends can be constructed simply by issuing a dettool command with the appropriate selections and det_type as in the following example. Note that if specific input exposures are to be used (instead of a random selection from matching database entries), the -definebytag mode must be used for dettool. |
| | 4 | {{{ |
| | 5 | dettool -definebyquery -pretend -select_dateobs_begin 2011-05-01T00:00:00 -select_dateobs_end 2011-08-01T00:00:00 -ccd_temp_min -86.755 -ccd_temp_max -72.1583 -random_subset -random_limit 150 -det_type DARKTEST -mode master -workdir neb://any/gpc1/detrend_easter2012/dark.20110501/ -inst GPC1 -select_exp_type DARK -select_exp_time_min 0.001 -select_exp_time_max 300 -comment '%exp%' -time_begin 2012-03-07T00:00:00 -time_end 2012-03-07T00:00:00 |
| | 6 | }}} |
| | 7 | * '''Processing'''. The first stage of detrend creation involves the processing of the raw detrend exposures into the form necessary to be stacked (or combined in some way). ppImage.config contains the recipes used for this processing, with the exact recipe chosen from the reductionClasses.mdc file |
| | 8 | * '''Stacking'''. The individual exposures are combined to yield an appropriate detrend model. The method of combination is defined in the ppMerge.config file. |
| | 9 | * '''Normalization'''. Normalization of the stacked exposure. A number of these operations are simply no-ops, so the stacked and normalized versions are identical. |
| | 10 | * '''Residuals'''. The normalized detrend model is applied to the input detrend frames, to identify any discrepancy between the model and the inputs. These residuals are shown on ippmonitor, although the exact scaling of the jpeg images is not necessarily optimal. |
| | 11 | * '''Rejection'''. Using a set of rejection rules defined in rejections.config, some of the least consistent input frames may be rejected and a new iteration constructed without these inputs. This process is not well defined for some detrends (such as FLATs), where the rules for rejection are not well constrained. |
| | 12 | * '''Registration'''. An alternate method of constructing a detrend is to simply register a valid detrend file as the appropriate type. This is the main way manually constructed detrends (MASKs, LINEARITY models) are input into the system. This can also be used on automatically generated detrends that will be used for different det_ids (see below for examples). A detrend can be registered by issuing the following example commands. Note that the det_id is not known until after the -register_detrend command is issued, but is required for all subsequent registration commands. |
| | 13 | {{{ |
| | 14 | dettool -dbname gpc1 -register_detrend -filelevel chip -inst GPC1 -telescope PS1 -det_type NOISEMAP -time_begin 2010-09-01T00:00:00 -time_end 2011-05-01T00:00:00 |
| | 15 | dettool -dbname gpc1 -register_detrend_imfile -det_id 868 -class_id XY01 -uri neb://any/gpc1/detrend_easter2012/noisemap.20100901//GPC1.NOISEMAP.860/GPC1.NOISEMAP.norm.860.0.XY01.fits |
| | 16 | [...] |
| | 17 | dettool -updatedetrun -det_id 868 -state stop |
| | 18 | }}} |
