
Date: Wed, 28 Mar 2001 13:59:34 +0200
From: Peter Kretschmar <peter.kretschmar@obs.unige.ch>
Subject: Re: j_performance
To: Carol Anne Oxborrow <oxborrow@dsri.dk>, smaisala@astro.helsinki.fi
Cc: njw@dsri.dk, stefan@astro.su.se, juhani.huovelin@astro.helsinki.fi
MIME-version: 1.0
Content-transfer-encoding: 7bit
X-Accept-Language: de,fr


  Dear Carol Anne,

  thanks for listing the detailed requirements for performance monitoring
of calibration data. In the following I am trying to repeat in written form 
my interpretation of the outcome of our discussions at the last meetings
and what it translates into. Comments and questions are welcome.


* Basic structure

  j_performance consists of (at least) two separate entities:

  (1) An executable - let's call it for the moment j_perf_build_table -
      called manually (commandline, or from within isdcroot) which creates 
      parameter tables to be monitored.

  (2) Some isdcroot code to access these tables, display the parameters, the 
      accompanying limits, etc. By virtue of ROOT's object orientation some 
      analysis possibilities come for free with the plots, e.g. fitting of 
      arbitrary functions. Some others may need to be added.

  In addition, detector performance can also be assessed by viewing data
  (shadowgrams, spectra, ...) produced from Core Program data. Currently
  this would be a purely manual procedure, though one could imagine, e.g.,
  to have a tool scanning shadowgrams for suspicious hotspots.

  Performance Monitoring does not produce data to be stored in the
  INTEGRAL Archive. The created tables are not saveguarded except if
  the user decides to so herself.

* Implementation details
  
  j_perf_build_table requires at least the following parameters:
  - the DOL of either an Observation Group or of a calibration data Index
    Group (like the gain cal. Index).
  - a start and end time to be monitored in IJD
  - alternatively: start/stop revolution or ScW number
  - one or more parameter(s) specifying that averaged values are supposed
    to be used and how the averaging is to be done (summing/sliding/...).
  - either: a string with comma-separated parameter names
    or:     the name of an ASCII file with parameter names

  Regarding the averaging, we must always do it ourselves for the gain and
  el. calibration data. For HK data we have in addition the option to use 
  the ScW averages created during Data Preparation. 

  The ASCII file trick is forbidden in our pipelines because we might
  not be able to reconstruct exactly the input of a program later 
  (all parameter readings go into the log file, but the ASCII file would
  not). For software used interactively and which creates no archived
  data products, this limit does not apply.

  The display application (j_perf_display???) can borrow a lot of code
  from Reiner, but it will require some adaption nevertheless. Reiner
  also told me that his OSM displays contain some lengthy and complex
  code that is by now unnecessary - ROOT has evolved to do things by 
  itself, that Reiner did manually. While we do not want to change a
  running display for OSM, it may be easier for Sami to redo some 
  parts from scratch than to try and figure out what Reiner is doing.
  Other parts of Reiner's code will still be very useful. Looks like
  a "Frankenstein" operation, let's hope the end product is prettier :-).


  Looking forward to your comments,
  Peter
