The main goals of ESO data quality control (QC) are:
The QC process uses data processing pipelines. These support all VLT/VLTI instruments and all major modes. More ...
The QC process is fed by the data transfer from Paranal into the archive which takes place within minutes. The calibration data are then processed incrementally at ESO Headquarters (typically once per hour). The quality information is extracted into QC1 parameters. The most important parameters are displayed graphically on the Health Check monitor. Also, their values are scored against configured thresholds, to discover anomalies. The quality scores are also displayed graphically and are evaluated both by the QC scientists and the Paranal staff astronomers.
The complete trending history of each VLT instrument is also maintained on the Health Check monitor.
The QC0 process checks that
Typically the QC0 checks are done on raw data. QC0 is entirely done by Paranal staff astronomers.
Quality Control Level 1 consists of quality checks on pipeline-processed data. Quality is measured by numbers, the QC1 parameters. Main goals of the QC1 process are
The checks are done on calibration data. Scientific usefulness cannot be assessed with this process.
The QC1 parameters are used
The result of the QC1 process is used to
The QC1 parameters are archived. They are directly available for studies through the QC1 database interface (although in many cases the trending pages may be more interesting, see below).
Trending is monitoring QC1 parameters over time (e.g. effective resolution as function of time). A core task of QC Garching is to create trending pages (also called Health Check monitor) which are used to monitor the instrument evolution and performance.
The most recent values of important QC1 parameters are scored against configured thresholds, to discover anomalies. The quality scores are also displayed graphically and are evaluated both by the QC scientists and the Paranal staff astronomers.
The names of the pipeline products follow a certain naming convention. This is done to have human-readable rather than technical file names. The naming scheme has been chosen to have the type of product, its date of creation, and its pipeline-relevant parameter values all recognizable from the product name. With the begin of period 76 (October 2005), both science and calibration product files are renamed. The general format of user-oriented product file names is the same for all VLT/VLTI data.
The AMBER HC plots are available on the HC home page.
All AMBER pipeline product names start with AM.
Type of product
The type of product is coded in the fits key HIERARCH.ESO.PRO.CATG. A short form of this is coded in the name using a four character scheme:
Science products (if processed) have the following scheme:
The following types of science products exist:
Calibration products are named for example: AM_MCFR_051024A_3Tstd_Medium_K_1_2.1_GMR_HR201.fits. As with the science, each OB consists of several files containing fringes (5 of them in general), the merged file is a concatenation of all the frames of these individual files.
The following types of calibration products exist:
Date of origin, version:The date of origin is identical to the date of the raw data measurement. It is coded as, e.g., 051015 for Oct 15, 2005.
The version of a file is indicated by capital letters always starting with A. Versioning is supported for certain types of files, see above table. In all other cases, only one version per day is created (always A).
The resolution of the dispersive element is included in the product name.