Home » Blogs » jwebb's blog

StGammaMaker Status/Issues

Updated on Wed, 2008-07-23 14:35. Originally created by jwebb on 2008-07-16 11:05.
Abstract:  A quick summary of the status of the StGammaMaker software, and issues related to producing a large MC event sample.
 
Current plan (as I understand it) is that MIT will be producing a large MC data sample, using pythia and BFC filters to (significantly) increase speed and reduce disk space footprint.  Plan which was discussed was to further reduce footprint (at RCF) by storing only the gamma trees there.   fzd, MuDst, etc... would be stored in volatile disks... may disappear at any time.
 
We therefore need to address some issues with the gamma trees.
 
1. Before MC production converted to gamma trees, we should
   a) tag the code in cvs
   b) decide whether gamma maker will be built against DEV or an official release
   c) freeze the interface (if there are additional features which are needed, now is the time to add and/or discuss)
 
2. Data-driven shower replacements. I believe this occurs at the production (fzd --> MuDst) level, correct?  If so...
   a) technology needs to be plugged into the MC production (fzd-->MuDst), otherwise it won't be in the gamma trees
   b) need to make sure that gammas which convert in MC are handled properly (i.e. replace shower shapes for each daughter,
       not just the photons/electrons from the primary vertex).
   c) WHAT ABOUT THE BEMC -- is the geant response "good enough"? 
   d) Truth-table information-- what additional quantities need to be saved into the gamma tree so that we can better understand
        what the data-driven shower replacement code did?
        -- A second gamma candidate branch with unaltered SMD response?
       
 
3. Related issues with slow simulators
    What general configuration will be run in both BEMC and EEMC simulators.  In particular,
    a) What gain variations will be generated for towers, smd, pre/post and how do we derive this?
    b) What about cross talk (assume we punt for now, but should think about how to add this to slow simulators.)
    c) How do we handle faulty channels
   
4. Trigger Simulation (must occur during fzd-->MuDst)
    a) Triggers need to be simulated and trigger IDs stored.
    b)  How do we handle multiple run periods? 
          - run multiple instances of trigger simulator, and store all ids which are satisfied? 
             eg. 137641, 127641, 127641 each stored in a flat list (EEmc L2gamma from long1, trans1, and lon2 periods)
 

Plan: Run multiple instances of trigger simulator and fill each trigger ID which gets satisfied.
Issues:
1) trigger IDs 5 and 6 -- how do we distinguish different run periods?
2) how many distinct run periods do we need to handle? (i.e. how many instances of the simulator get run)?
3) can we run multiple copies of the trigger simulator? ====> multiple time stamps <=====

 
5. Is there any reason to reduce the cluster size in the gamma tree (currently 3x3 in both calorimeters)?
   - my feeling is no... we can alwasys reduce it further in user analysis
 

Cluster size can be reduced offline

 
6. Is there anything missing from the trees which need to be added? 
     - any additional data quantities?
     - any additional MC (geant record) quantities?
 
7. There is (at least) one place in the code where BEMC and EEMC gamma candidates are handled differently
     - StGammaCandidate::position() and StGammaCandidate::momentum()
 
     For the EEMC, this returns the position and momentum based on tower energy response and the "SMD point".
     For the BEMC, this returns the position and momentum based on tower energy, and energy weighted tower centroids.
 
     It would be useful to make the BEMC and EEMC consistent.
 
8. Shower-shape fits in BEMC
 
    At present, no facility for this exists. 
 

 

»