Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.eso.org/~qc/procs/guidelines_trendPlotter.pdf Дата изменения: Tue Jul 17 18:40:18 2007 Дата индексирования: Tue Oct 2 09:19:53 2012 Кодировка: Поисковые слова: http www.astronomy.com

trendPlotter: Good-practice guidelines for report design
Reinhard Hanuschik, v1.0 (2007-06-27) Daytime astronomers: up to 6 instruments to check (!), usually per UT Need clear, fast, easy-to-navigate design; and speed! Do this test yourself: scan through all HC plots per UT, not just your own ... ... and you will find the following guidelines useful.

Health Check vs. trending plots
Traditionally we had for a long time the distinction between Health Check (HC) plots and trending plots. The HC plots contained a comparison between OPSLOG data and our data. The trending plots were the same without OPSLOG data, plus all other plots having never OPSLOG data. HC plots were all connected to the central HC site, while trending plots were accessible through the QC web site (after some research and clicks). With trendPlotter, things have changed, and actually simplified. There is one central site for HC plots: the HC monitor (same URL as before, now easier to find: www.eso.org/HEALTH). It now hosts all trending plots, including the HISTORY and the ones without OPSLOG data. All plots are created by the same tool and give a common look&feel. This has become possible with a small change of the concept of HC plots: they should contain OPSLOG data whenever possible, but they are not required to do so. Now you may want to group together reports with and without OPSLOG data. Their arrangement is now dominated by higher-level principles, like instrument components, while preserving the main concept of offering a central site for Paranal data QC. This fits into the medium-term strategy to make OPSLOG data (almost) obsolete, which will be the case with near-real time data deliveries. In that sense, the HC monitor will remain stable and independent of any changes in the data delivery pattern. As said above, the HC monitor is the main web site for the closed-loop QC process. It is used every single day by the daytime astronomers on Paranal, by the Instrument Scientists and, of course, by you. It has gained us an excellent reputation. W e should continue to spend time on optimizing, extending and maintaining its content. The following guide is intended to give some higher-level principles and guidelines which are not evident from the so far existing documentation1.

1

Tool: http://www.eso.org/~qc/tqs/trendPlotter.html ; configuration: config_tp.html (same URL); operations: ops_tp.html (same URL)


Navigation and labels
Navigation needs to be supported effectively. trendPlotter has two types of navigation bars: The group navigation bar ("same group:") (optional but strongly recommended!) The vertical navigation bar (mandatory) There is a third kind, the HISTORY navigation bar which however is completely controlled by the tool.

Vertical navigation bar
Guidelines for populating the vertical navigation bar: use simple and clear navigation tags, avoid unnecessary technical slang. 'bias', or ,,bias (low, 1x1), is better than 'MBIA_low_1x1' avoid acronyms whenever possible; use 'short' instead of 'SW A' (even if SWA is known to every GIRAFFE specialist: it is not known to anyone else) ideally, navigation bar items should come per logical unit (see Table 1; Figure 1) Go from simple to complex items (e.g.: detector first, then lamps, then wave-cal etc.)

Figure 1: Example for vertical navigation bar

Table 1: Principles for navigation bar population
Logical unit instrument component Other standard items Reduction step, or raw file type examples detector|filter|lamps|grating|masks|fibre etc. zeropoints|sky|Strehl bias|flat-field|arc comments Preferred Good Not so good, although sometimes unavoidable; remember we want to do QC on instrument components.


Maintenance of vertical navigation bars is currently not supported by a TQS tool but will (hopefully soon).

Group bar
Use grouping within a navigation item per similar setup (e.g.: filters U|B|V|R|I, or read modes, or detector IDs) or per logical item (detector-related items: bias|dark|RON|linearity)

Figure 2: Example for grouping by filters

Figure 3: Example for grouping by item

Maintenance of group bars is done by trendPlotter: edit the group configuration file; call trendPlotter ­N -f Each item in a group bar should have a title which pops up on mouse over; use TITLE in the group config file; if possible the TITLE should include 'daily' or 'weekly' or 'monthly' or similar. Each item should have a tag DAILY/NONDAILY under REPORT_FREQ. This marks the most important reports for the daytime astronomer. These should of course be correspondingly often fed by calibrations (HC data, daily standards etc.). The term DAILY stands for: daily, or often, or regularly measured (e.g. every 3 days). NONDAILY means anything else. The DAILY reports are marked in the group bar (see Figure 2 and 3) Sort within each group bar all items such that DAILY reports come first, then enter SPACE, and then have the NONDAILY items.

Report design
Avoid packing too much information into the reports. Try to use no more than 6 boxes if possible. Try to avoid having more than one parameter set in a plot. Although trendPlotter has no problem with multi-data sets, the user may have! In any case, it is formally strictly


forbidden (although technically possible) to use statistics in multi-data sets. That's the most efficient way to make the user completely screwed up.

Plots
use the PLABEL key to have a short plot tag; control the output plot to see that it is short enough. use the ADD_TEXT key, make sure it displays nice in the product plot (not too long since then it gets truncated which looks very unprofessional). Carefully select symbol colours and size. Find the proper balance between too small (unreadable) and too large symbols (loss of details). Use the standard colours whenever possible. In terms of readability, red, black, blue and probably green display best (although blue is reserved for OPSLOG data if there are any); then comes yellow and the others. Y-range: select carefully and find the best balance between large range (compressing the data to almost zero scatter) and small range (possibly over-emphasizing scatter and hiding trends). Take care about HISTORY plots, check them one by one to avoid displaying outliers only! Use the delta configuration if a Y-range is optimal for current plots but inappropriate for older ones.

Statistics
In many but not all cases statistics make sense. Here are some concepts and their preferred implementation in terms of statistics: A mean value is expected, data points scatter statistically: use MEAN or MEDIAN, and 3SIG thresholds. MEDIAN is more stable against outliers, especially in case of asymmetric distribution (e.g. zeropoints). Both averages use clipping (statistics in 2 steps: first step to find outliers, second step statistics without these outliers). If data are not linear (e.g. magnitudes), you may want to use PERCENTAGE thresholds rather than 3SIG. In many cases there is no strict expectation about mean values, and a configuration of upper and lower thresholds (THRESH) is sufficient, to have an outlier warning mechanism. For instance, lamp flux values should be within certain upper and lower limits. As long as they do, nobody cares about their mean value. Statistics dont make sense in sparsely populated plots, and in correlation plots.


History
To ensure homogeneity and logical consistency among all HC plots, always provide the HISTORY plots. No plot without HISTORY!

Tutorial
For maximum user friendliness, always provide a tutorial link and page (could be shared among several plots). This is also good for your own documentation. The tutorial page should reside in your public QC web site, under www.eso.org/qc//qc/. It should also contain navigation to the other tutorial web pages, and to the corresponding HC plots. It should explain all important things, like plot content, how and why it is measured.

News
Use this optional message file (extension .msg) to propagate actual information (like "2007-05-10: problem with the flat field signal"). These files should only display information related to the actual HC plot. Make sure to empty it after the problem has been solved, or is outdated. The "News" file is not intended to describe a complete history of all effects.

Review/ release
In order to align the HC sites with these principles, and among each other, I want each HC site to undergo a formalized release procedure. A HC review will cover technical, functional and logical aspects.


Technical aspects: are labels understandable/compliant with above rules; are plots readable (no labels truncated; plot colors, symbol sizes, plot ranges ok?); chosen time range reasonable? Functional: do the links work? Do all plots have HISTORY and TUTORIAL links? Thresholding, statistics ok? Logical: is the arrangement reasonable (navigation, grouping)? Are the remarks reasonable? Is "Information and research" used? Is "This plot" reasonably filled? Review will be done either by me or one of your colleagues to be nominated. Cross-review could be a good idea. In general, others may discover things which you will never see. Needless to say, this should take place in a good constructive team spirit. In the end, it helps us to deliver an excellent product. The HC monitor is the interface to QC for the mountain (often they refer to it as "the QC page"). It is operational critical. This is our "best-selling product" where we become visible, similar to the package quality where we become visible to the community. W e should do our best to maintain its quality and to continuously improve it.