Re: new mult centrality classes

From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Wed Apr 18 2001 - 05:55:50 EDT

  • Next message: Yury Blyakhman: "Re: new mult centrality classes"

    Hi Steve et al, 
    
    On Tue, 17 Apr 2001 22:53:44 -0500
    "Stephen J. Sanders" <ssanders@ukans.edu> wrote
    concerning ": new mult centrality classes":
    > Hi,  I have added the classes BrCent, BrCentModule, and
    > BrCentCalibration to the mult directory of BRAT.  These classes are
    > modeled after the corresponding BrTileCent classes that Christian
    > wrote (and which have not been changed).  The new classes return the
    > average of the Si and Tile multiplicities and the corresponding
    > centralities. 
    
    As I wrote to Hiro, I would have prefered calling such classes 
    
       BrMultCent
       BrMultCentModule 
       BrMultCentCalibration 
    
    since "Mult" is the detector. The unqualified "BrCent..." is sort of
    misleading since it doesn't tell you which detector system you've
    extracted the information from. Particulary if some one decided to
    make a set of classes for determining the centrality from the BB and
    ZDC data. The data of BrCent would then be the grand total of the
    TMA, SMA, MULT, BB, and ZDC cantralities. Please refer to the draft
    guide I sent out recently, avaliable from  
    
      http://pii3.brahms.bnl.gov/~brahmlib/
    
    Also, the solid angle scale factor "1.4679" should really either be
    calculated or obtained from somewhere else, like geometry/calibration
    data base.   
    
    Can you make a class Br(Mult)CentCalModule that determinds the
    calibration polynomials coeffiecents? (just how many polynomials is in
    that directory now?) 
    
    What about classes BrSiCent, BrSiCentModule, BrSiCentCalModule? (no
    BrSiCentCalibration needed - the information is in BrSiCalibration.) 
    And if so, couldn't one just use the centralities of BrSiCent and
    BrTileCent to form a "grand total" for the entire Mult detector? 
    
    Steve, please PLEASE comment your code!
    
    > With the new classes, all of the functionality of BrRdoModuleMult
    > can be  found in "proper" brat classes.  
    
    Does that mean that you accept BrTileRdoModule and BrSiRdoModule as
    "doing the right thing"? 
    
    > Future changes in the multiplicity or centrality calculations will 
    > be done in the new classes.  A number of secondary calculations,
    > such as correcting the multiplicity for excessive energy events,
    > hasve not yet been checked for the new classes, however,
    > and so, for the present, I would like to keep BrRdoModuleMult
    > available. 
    
    Which classes? The Rdo ones? I was under the impression that you'd
    checkedd it and found that the fOutlierMethod member of the SMA and
    TMA Rdo classes should be set to kNoCorrection. Have I misunderstood
    something here? 
    
    > A note of caution:  I currently  have a 2cm vertex offset
    > incorporated in the BB vertex location,  as needed for run 2336.
    > Hiro informs me that this offset is not  necessary for later runs
    > where Yuri's calibrations work fine. 
    
    Uh. So the classes only work for run 2336 or what? Didn't Yury say
    that his calibrations are constant over all runs (or at least in
    between the runs he did test). 
    
    > The same vertex calculation (currently with offset) is found in four
    > separate modules: BrTileRdoModule, BrSiRdoModule, BrTileCentModule,
    > and BrCentModule. 
    > Question for the experts:  what is the best way to handle this run 
    > dependent offset without breaking the rules
    > for brat modules?
    
    I should be a part of the BB calibrations, and not something you have
    to "fix by hand" in other codes. Maybe Yury should check that
    particular run. 
    
    If you want to do some very VERY temporary, you can put it in the
    appropiate ASCII file in params/mult (as the first thing to read I
    would suggest). However, this is _not_ a viable solution and I
    _strongly_ discourage anyone else to follow that example. 
    
    My suggestion is: Take out the fix! Ok, so the modules give incorrect
    results for run 2336 but every other run should be ok. Presumably Yury
    will check the offset and fix what ever need to be fixed with on a
    reasonable timescale. 
    
    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 : Wed Apr 18 2001 - 05:56:57 EDT