Agora:
the information portal QC - PSO

The information inserted by the Paranal daytime astronomer about the validity/non-validity of an OB is evaluated by QC when it comes to assessing and certifying the pipeline products. It might result (although not automatically) in one of the following actions:

- the calibration is indeed faulty (e.g. over or under exposed, contaminated): then the products are deleted, the raw files are hidden in the archive (not visible anymore on the archive web interface). This applies to calibrations which can be used to reduce science data. Calibrations taken purely for monitoring purposes may in some cases stay in the archive.

- the calibration has wrong keyword information but is otherwise ok: keywords are corrected (per request to dbcm-help@eso.org), corrected raw files are visible on the archive web interface, calibration products from the corrected raw files are certified and ingested.

- the calibration is good: the data are certified, products are ingested and are available for further use

It is obvious that it is important to have as specific as possible information available why the calibrations were deemed not valid.

back to main

QC extracts and reads nightlogs directly from the Paranal database. The nightlog comes as an overview of the full night. It is displayed and carefully checked when the data are processed and certified. The content is essentially the same as the emailed nightlogs, however with slightly more user-focused display. All comments (external and internal) are available (and read), all names, summaries, grades etc. The keyword information in the OB details is suppressed (unless requested).

The content is dynamic, it includes all updates being entered in the meantime.

Each QC scientist can dynamically create and read anytime such nightlog, either per telescope (all UTs and VLTI), or per instrument.

back to main

QC extracts nightlogs directly from the Paranal database. SM users receive an extracted nightlog.

This contains: night information (for all nights with OBs for that run); OB information, including grades and external comments; no names, no internal comments, no daytime calibration logs. This customized, extracted nightlog is dynamic, it includes all updates being entered in the meantime.

The extracted nightlogs also contain links to the ambient database. Find an example here.

back to main

Only exceptionally, in case of quality problems. Examples:

• if it is found in the course of the data processing that calibrations are bad or are missing;
• if a problem has been found with the science data.

Then QC informs USD and asks them to check if an OB needs to be repeated.

back to main

The health check (HC) monitor is fed by two data sources: one is the opslog files from Paranal, the other is the QC1 database in Garching. The opslog information is the most up-to-date component. It is currently transfered once per hour to Garching. In Garching, a cronjob parses all recent opslog files and creates the HC plots.

The daytime astronomer can expect the HC monitor to be up-to-date, i.e. include the most recent QC1 parameters from the pipeline, about two hours after the data were processed at Paranal.

Execution times are plotted on each HC plot and web page. Remember this marks the time of cronjob execution in Garching, not necessarily the time of ops log file transfer. In addition the last ftp and parser are marked with green (within the past two hours), gray (more than two hours, but since 12:00 UT - i.e. very probably the daytime calibrations were finished before 12:00 UT), or red (more than two hours, not since 12:00 UT).

back to main

All QC1 parameters derived from calibration data are stored in the QC1 Database. A subset of that information is plotted in the Health Check monitor. However, in order to keep the amount of health check plots down to a manageable number we cannot provide all information present in the QC1 Database. The interface to the tables for the individual instruments allows to browse the contents or to plots certain datasets. For an example see here (FORS2 example). If you do not find what you need in the QC1 database feel free to contact the QC scientist responsible for the instrument (here).

back to main

Direct access to master calibrations is still not possible. Requests for an access tool should be directed to archive@eso.org, aligned with QC.

Indirect access is possible:

• in some cases, an instrument specific interface exists which gives access to master calibrations if they associate to science data. Thus is currently (2008-01-22) the case for FORS1, FORS2, ISAAC, and UVES.
• Another option is to ask QC directly (for addresses see here). We will help you whenever possible.

back to main

For many instruments, a set of master calibrations is stored on the pipeline machines under the /cal tree. This is called the calibration database (calibDB). The calibDB is delivered with the pipeline package.

Many of these master calibrations change with time (dynamic calibrations), and it makes sense to refresh the content from time to time.

QC is able and willing to deliver complete or partial calibDB updates. Their frequency can be negotiated. It will typically range between say 2 months and once a year. The instrument scientist can also request such updates directly from the QC scientist.

back to main