Re: follow up of pid...

From: Peter H. L. Christiansen (pchristi@nbi.dk)
Date: Wed Nov 20 2002 - 04:36:57 EST

  • Next message: Yin Zhongbao: "Re: follow up of pid..."
    Hi
    
    Just a short comment. I think it is a really good idea to build a better 
    commeon framework. I think that half of the output of this module should 
    be some diagnostic histograms that shows if things are sound. 
    
    One way one could make the framework a bit flexible is (like I believe 
    Christian once suggested) to have the pid class ionherit from some 
    pregenerated root class. This pregenerated root class can be easily 
    updated when things are changed in the ntuple and it might be easy to make 
    the same framework for different ntuples (pp, Au+Au, new, old).
    
    Another idea could be to have the class have methods like GlobalCut,
    TrackCut, PionCut etc. that can be overloaded by the user. There he could
    also add his own methods to set individual parameters while in the base
    class we have some cut variables like triggerword etc.
    
    So the structure would be something like this (in a non-standard way) :
    DstClass (BASE)         <- Analysis class   (<- MRS <-FS ?) <- User class 
    ROOT/auto generated        Claus generated - common methods    User defined cuts  
    
    The user class could also contain extra histograms (fx diagnostic and/or 
    data) variables etc. 
    
    Cheers
       Peter 
    
    On Tue, 19 Nov 2002, Flemming Videbaek wrote:
    
    > Dear Brahms-dev
    > 
    > I think I will like to repeat + expand on some of the comments that I send to Claus a few days ago and which he incorporated in the most recent note, mainly because not all have seen this.
    > 
    > A general comment is that for
    > this to be truely utilized more commonly as is, rather than people appliing individual changes, there
    > has to be a general way of settings options since not all analysis will be the same anyhow)(as also promoted from Norway). Some general comments
    > 
    > a) one should be able to use the same analysis
    > classes for pp as for AuAu - this implies different rejection based on BB
    > and or Inel counters.
    > b) There are places in the code where specific trigger requirements are
    > chekced and code breaks.
    > 
    


    This archive was generated by hypermail 2.1.5 : Wed Nov 20 2002 - 04:37:20 EST