Re: new mult centrality classes

From: Stephen J. Sanders (ssanders@ukans.edu)
Date: Wed Apr 18 2001 - 13:43:41 EDT

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

    Dear Christian, 
    >
    >> 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
    > 
    These names are fine.  I'll change over the next time I get to work on this.
    If you want to change them sooner, feel free.
    
    > 
    > Also, the solid angle scale factor "1.4679" should really either be
    > calculated or obtained from somewhere else, like geometry/calibration
    > data base.   
    Yes, I know.  The classes are not viewed as being final.  In particular, I
    am not particularly happy with quoting a multiplicity that can not be
    directly associated with a pseudorapidity range.
    > 
    > Can you make a class Br(Mult)CentCalModule that determinds the
    > calibration polynomials coeffiecents? (just how many polynomials is in
    > that directory now?)
    > 
    Yes, as soon as I finish writing a draft for the multiplicity paper.  This
    should not be difficult since the current calibration is done using a root
    macro.
    > 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?
    > 
    This is fine, but I question the proliferation of repetitive code.  Already,
    one is doing the same vertex calculation at least three times.  It now
    becomes important for someone who changes the criteria for vertex selection
    to be sure and make the change in 4 different classes.
    
    > 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"?
    > 
    Yes. Specifically, what I have checked are the energies, individual element
    multiplicities, and sum multiplicity.  I have not checked the treatment of
    anomalous energy event.
    
    >> 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? 
    
    We are still investigating the best way to handle excessive energy events.
    The current analysis does not account for these events.  What is known is
    that the basic centrality event selection, at least for the most central
    events,is not strongly affected.  I believe this is going to be a second
    order correction.  However, it still needs to be checked.
    > 
    >> 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. 
    > 
    I'll remove the offset.  Users beware...  From Yury's message, it sounds
    like I may be misusing the BB class?  I am running what is currently in the
    CVS, but I haven't done anything special to select a "new" vs. "old"
    calibration.  Could this be my problem?
    
    ...steve
    



    This archive was generated by hypermail 2b29 : Wed Apr 18 2001 - 13:44:44 EDT