Re: BRAT-2-1-40, dNdEta calculations added

From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Sat Nov 24 2001 - 12:48:52 EST

  • Next message: Stephen J. Sanders: "Re: BRAT-2-1-40, dNdEta calculations added"

    Hi Steve, 
    
    On Sat, 24 Nov 2001 10:12:50 -0600
    "Stephen J. Sanders" <ssanders@ku.edu> wrote
    concerning "BRAT-2-1-40, dNdEta calculations added":
    > Hi,
    
    Please write annoucements on new BRAT version to brahms-soft-l. 
    
    > I've modified a number of si and tile classes (BrSiCalibration,
    > BrTileCalibration, BrMultRdo, BrMultRdoModule) to add event-by-event
    > calculations of dNdEta for each si and tile ring.  I also added a
    > calculation of the HIJING weighted average pseudorapdity for each
    > ring.
    
    We should register the two new parameter sets with the database too.
    Please read the DB info avaliable from [1] and in "The Guide". 
    
    You need to store the order of the two functions along with the actual
    parameters.  Otherwise, you're locking yourself into one specific
    parameterisation, and experience has shown that to be bad.  See how I
    did this for the centrality functions.  Also, if you could store the
    vertex cutoff, that'll be optimal, and I again something we'd like
    very much (read: must have). 
    
    Why do you add 50 to the ADC gap in the Tiles?  Why don't you simply
    add those 50 to the calibration numbers? 
    
    Remember, hardcoded constants are BAAAD.  Calibration paramters in the
    database is GOOD. 
    
    
    > We were already calculating the number of "primary" particles
    > hitting each detector element based on HIJING simulations that
    > relate these particle multiplicites to the observed energy deposited
    > in each si and tile element. I have now added calibrations that
    > relate the particle multiplicites to a dNdEta value based on the
    > measured vertex position. To obtain the calibrations I position a
    > simulated vertex between -46 cm and +46 cm, in 2 cm steps, and at
    > each position did a "throw" of HIJING 0-2 fm primary events (no
    > CASCADE...).  Each particle was checked to see if it hit on the si
    > or tile detectors.  I also kept track of the total number of
    > particles within the pseudorapity range covered by each
    > detector. This procedure allows for a simple geometric efficiency
    > calculation.
    
    Why the do we need this extra conversion from single element
    multiplicity to ring multiplicity?  Are the conversion functions not
    enough?  
    
    I'm not sure I understand this "Hijing-weighted mean
    pseudo-rapidity".  Could you please explain what that is.  And what's
    the difference between that, and the one calculated by
    BrMultRdoModule::CalibrateEta()?  It seems that it's (again) some
    parameterisation, but why is that needed?  Since you know the z
    position of the ring (r_z), the distance of the ring to the beam (d),
    and the z-position of the primary vertex, I should think that the eta
    would simply be: 
    
      eta = -log (tan(atan(d/(r_z - v_z))/2)
    
    Ofcourse you could weight that by the geometrical acceptance of the
    element for the specific element.  The solid angle sustented by an
    element is given by 
    
      theta_1     = atan(d/(r_z - v_z - w/2)) 
      theta_2     = atan(d/(r_z - v_z + w/2)) 
      deltaOmega  = deltaPhi (cos theta_1 - cos theta_2) 
    
    where w is the width (along z) of an element, deltaPhi is the coverage
    in phi (roughly pi/3), and the rest as above.  This should be compared
    to the solid angle covered by the element, if the v_z = r_z: 
    
      theta_1'     = atan(d/(-w/2)) 
      theta_2'     = atan(d/(w/2)) 
      deltaOmega'  = deltaPhi (cos theta_1 - cos theta_2) 
    
    In other words, I think it's possible to calculate the mean eta from
    pure geometrical principels. 
    
    > Although the dNdEta and <eta> values are calculated internally for
    > each si and tile detector elements, I am only placing the average
    > value obtained for each si and tile "ring" in the BrMultRdo data
    > structure. (42 values for the Si, 8 for the tiles).  I have retagged
    > brat as 2.1.40 and I have bumped the BrMultRdo classdef to 2.
    
    Argh! You need to bump the version number of the nested class
    BrMultRdo::BrRing as well!  A nested public class is a class like
    anyother, and hence the version defently need to be bumped, jsut as
    for anyother class.  In fact, I don't think you need to bump the
    version of the mother class in the first place.  Did you try and read
    back a file that contains the old format of those classes? 
    
    Yours, 
    
    Christian Holm Christensen -------------------------------------------
    Address: Sankt Hansgade 23, 1. th.           Phone:  (+45) 35 35 96 91 
             DK-2200 Copenhagen N                Cell:   (+45) 28 82 16 23
             Denmark                             Office: (+45) 353  25 305 
    Email:   cholm@nbi.dk                        Web:    www.nbi.dk/~cholm
    
    [1] http://www.sdcc.bnl.gov/brahms/private/database/index.html
    



    This archive was generated by hypermail 2b30 : Sat Nov 24 2001 - 12:50:08 EST