Re: Convention

From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Fri Mar 16 2001 - 11:05:56 EST

  • Next message: Hironori Ito: "ZDC Vertex"

    Hi Flemming et al, 
    
    On Fri, 16 Mar 2001 09:29:53 -0500
    "Flemming Videbaek" <videbaek@sgs1.hirg.bnl.gov> wrote
    concerning ": Re: Convention":
    > Dear List
    > 
    > There is some confusion on this subject, and I will like to return
    > to this later when back at BNL in some details. In brief, RDO are
    > not meant to be calibrated variable but dataobject well on the way
    > to physics quanbtities, and thoiese you would store in intermediate
    > file. examples are 
    > -- tracks
    > -- pid information
    > -- multiplicity vertex info
    > 
    > they are not calibrated adc signals.
    
    What Claus (I believe) objected to was "model dependent data", and
    what I meant to say with "essentially calibrated digits" was in the
    context of the TMA and SMA. For the TPCs, DCs, TOFs, Cherenkovs,
    etc. other, more elaborate objects could be defined. 
    
    However, we should not loose sight of the value of being able to store
    intermediate data like clusters, energy signals, and so on. Recent
    experience here at NBI has shown that that may be very valuable. 
    
    For  example, it would be nice to be able to store BrDetectorHits on
    disk, so that one can choose the tracking algorithm at a later point,
    after doing the Rdo's on CRS, and so on. This is currently not
    possible as BrDetectorHit are not derived from BrDataObject and is put
    in a BrClonesArray rather then a BrDataTable. 
    
    This goes back to my previous mail on the classes in BRAT. "They
    [modules]",  I said, "map one data set into another". That means the
    input of a module must come from a BrEventNode and the output should
    be stored on a BrEventNode. That's the only way a module should accept
    input and write output data. 
    
    This principel is violated many places in the code of BRAT, I'm sad to
    say. The reason for this principel is modularity. If all modules look
    for data in the passed BrEventNode, they do not need to know anything
    about anyone else, and so you can plugin as many modules as you like
    in a fairly simple way (see my brahms_app area, sub-directory jobs).  
    
    Yours, 
    
    Christian  -----------------------------------------------------------
    Holm Christensen                             Phone:  (+45) 35 35 96 91 
      Sankt Hansgade 23, 1. th.                  Office: (+45) 353  25 305 
      DK-2200 Copenhagen N                       Web:    www.nbi.dk/~cholm    
      Denmark                                    Email:       cholm@nbi.dk
    



    This archive was generated by hypermail 2b29 : Fri Mar 16 2001 - 11:06:54 EST