Minutes from the March 18 Calibration meeting


Please also see the thread http://www-glast.stanford.edu/protected/mail/infrasoft/1621.html
('Core' means this meeting).


------------------
Directory Structure
------------------

The calibration files directory structure is described in

http://www-glast.slac.stanford.edu/IntegrationTest/SVAC/Instrument_Analysis/UsefulStuff/calibrationFiles_structure.html


-------------------------------------------------------------
Procedures for making official installations at external sites:
----------------------------------------------------------------

- Need procedures for making official installations outside SLAC (e.g. NRL).

- The SLAC calibration meta database is accessible from outside SLAC for
   anyone with a network connection. However, the NFS disk containing the
   calibration files CAN NOT be mounted from outside SLAC so remote sites
   will have to copy the files locally and change $LATCalibRoot
   correspondingly.

- SAS is looking into the appropriate tools for mirroring disks.
   Rsynch is currently the favoured possibility. Note that the disk is
   accessible through ftp.

- In addition (but with a lower priority) we need to cover the case of
   individual remote developers, both with and without access to the SLAC
   meta database i.e. with/without a network connection.


------------------------------------------------------------
Usage of calibration flavours and instrument names is found in
---------------------------------------------------------------

http://www-glast.slac.stanford.edu/IntegrationTest/SVAC/Instrument_Analysis/UsefulStuff/calibration_flavors.html


----------------------------------------------
Information about the calibration data itself:
-----------------------------------------------

- Need to store information about the calibration data itself
   i.e. a description of how the data was taken and processed,
   keeping track of software versions etc.

- Where to store this information? One possibility is inside the file,
   in the description field. Do we want to store files/references to files
   in the description field?


-----------------------------------------------------
Calibration code and the EngineeringModel releases:
-----------------------------------------------------

- It is desireable to have coherence between the EngineeringModel
   (EM) releases and the calibration code. The baseline is to always use
   the code in the EM release built by the release manager.

- A potential problem with this is the slower turnaround and also that
   bugfixes in the calibration code forces a new EM release which again
   forces a reprocessing of the data. If code outside the EM releases is
   used, all versions need to be recorded.


------------------------------------------------------------
Geometry dependence of the calibration files (1,2, n towers) :
------------------------------------------------------------

- Joanne will (time scale as yet undetermined) come up with a design
   for a new calibration type which describes hardware installed in the
   grid. Will contain, at a minimum, serial numbers of TKR and CAL
   modules indexed by bay position.

- Ideally, procedure to create such a "calibration" would involve reading
   the information from the (ISOC? I&T? Online?) database. This will allow
   Recon, etc., jobs to discover what the configuration was at the time an
   event was taken. It does *not*, by itself, provide a mechanism for
   fetching calibrations by serial number.


---------------------
Reuse of calibration:
---------------------

How do we reuse/mix calibrations (merge multiple tower calibrations)?


------------------------------
Time stamps for calibrations:
-----------------------------

- All timestamp information in the metadata database will be in GMT.
- For those entries updated automatically for the user, the two recognized
   tools for inserting/modifying rows (rdbGUI, function in calibUtil) will
   be upgraded to handle this properly.  For user entries, rdbGUI will
   provide a simple way to translate from one time zone to another.  Some
   comparable thing will be added for clients of calibUtil, probably in the
   facilities package.


-------------------------------
Disjoint datasets and trending:
--------------------------------

- What to do with Input_start when using disjoint datasets? This
   parameter is used for trending. If this field as currently defined -
   just a single timestamp - is not adequate, the information belongs in
   some auxiliary structure or database elsewhere.


anders