Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.eso.org/~qc/procs/checklist.pdf Дата изменения: Thu Jun 18 11:58:02 2015 Дата индексирования: Sun Apr 10 00:38:11 2016 Кодировка: Поисковые слова: п п п п п п п п п п п п п п

European Organisation for Astronomical Research in the Southern Hemisphere

Internal Memorandum To From Date Subject QC group Wolfgang Hummel, QC scientist, with feedback from QC group 2015-03-30 New Instruments Checklist for the QC Scientist

This summary collects hints on how to manage the following task: The QC scientist participates in the review of DRS related documents as part of the PDR, FDR or PAE of an upcoming new ESO-VLT instrument, which is planned to be put into operation. The problem is that items mentioned in documents are easily spot-able and can be addressed but unclear and missing statements (the unknown unknowns) bear the risk, that DRS related design issues being not compliant with the VLT-dataflow are overlooked because they are not documented at all. For reason to minimize bad surprises in later stages of the commissioning a check list for the QC scientist is given here:

Basics
The INSTRUME key should be specified. If the value has non-alpha-numerical characters, it should be cross-checked with DICD (e.g. NAOS+CONICA, HAW K-I, FORS2). If the string length is larger than five characters, it should be cross-checked with DICD. The instrument modes and arms should be indicated and described, and the keywords that distinguish between different modes should be indicated (usually INS.MODE is used if it is a mode and OCS keys are used in case it is related to an arm). It should be made clear what an instrument mode (e.g. polarizer in the same optical path) is and what an arm (different optical path, detector ...) is.

Raw frames
The format of the raw frames for each mode and arm should be described. Typical format questions could be: Single unit fits frames versus MEF. The distribution of headers within the raw frame (e.g. is there one primary header with INS and DET keys, or are the DET keys in the fits extension). Are the binary (pixel) units in the raw fits frames of the same importance (e.g. vircam/ocam) or is there a main binary and the other binary unit is of auxiliary data (e.g. psf/ao matrix in NACO)

European Southern Observatory Headquarters Germany Karl-Schwarzschild-Straъe 2 85748 Garching bei MЭnchen

Phone +49 89 320 06-0 Fax +49 89 320 23 62 information@eso.org | www.eso.org ESO -- Reaching New Heights in Astronomy

Commerzbank MЭnchen, Account No. 2 102 002 BLZ 700 400 41 SWIFT-Code COBADEFF700 IBAN DE09 7004 0041 0210 2002 00




The distribution of pixel/binary units per extension (does the primary header contain binary units or not ?) A unique identification of each extension should be provided (EXTNAME, DET.ID, ...) For most of the keys like DPR and PRO.CATG a size limit of 30 characters has to be matched. The way the detector is operated should be mentioned: For optical CCDs this can be: clocking parameters, binning, gain, windowing For NIR detectors this can be: DIT range, NDIT range, NDIT averaging on the chip or NDIT summing up, windowing, cube mode, and the correlation mode (uncorrelated, double correlated or Fowler sampling).

OCA
For each arm and mode, the calibration cascade should be given: The calibration plan document should cover all modes. The distinction between science data, calibration data (used to calibrate science data) and technical data (used to monitor the instrument health) should be consistent. It should be checked for uniqueness in match rules (e.g. if filter=A calibrate in this way, if filter=B calibrate optionally another way) to be avoided as far as possible. The design should be checked on pre-processing or processing, which involves products only (no trigger via raw frames). There should be no iterative processing outside a recipe (don't call the recipe again and again with its own product as input) recipes, which require only products as input, which in this case requires a 2-step processing within operations should be investigated for possible 1-step solutions. The classification keys (DPRs) should be indicated and the set of classification keys should be unique per RAW _TYPE. Static calibrations must be in the format of a DICD compliant FITS table or pixel image, but not as plain text file. The match keys should be clearly mentioned per raw type.

Pipeline products
The format of the products must be DICD compliant The PRO.CATG, also that of static calibrations, should be unique within the cascade. The PRO.DATANCOM should really give the number non-rejected frames, contributing to the product. PRO.CATG of the product should be the DO.CLASS of the requesting recipe. Exceptions should be justified. If two different RAW-TYPEs call the same recipe (e.g. Flux standard and science call the same recipe), the DO.CLASS and the resulting PRO.CATGs should be different.




The format of the products should be as far as possible inherited from the format of the raw frames. MEF products should contain EXTNAME, unique within the product.

QC parameters


There should be a QC parameter dictionary with explanations of the parameters and the units. The name should be related to the contents (don't call RON RMS, don't call flux ADU and vice-verse) For multiple arms/modes instruments, QC parameters should come for each arm separately or each arm has its own dictionary All calibration products that require a lamp should give basic QC parameters (per lamp) like number of counts [ ADU ] lamp flux [ ADU/sec ] number of saturated pixel It should be parameters The algorith The comme documented if all QC parameters are in the primary header, or if QC are in the product extensions m for the QC parameter should be indicated nts section in the fits header should explain the QC parameter.



Pipeline user manual
QC group has no mandate to decide on the content and structure of the pipeline user manual, but as the main customer should take the opportunity to ask for corrections and completeness. There should be a calibration map per arm and mode. On the recipe description level, the following items should be described: T T T T T he he he he he purpose number and the contents of the input raw frames. algorithms number and content of the products. QC parameters.

Wolfgang Hummel 30. 3. 2015