M-C pileup simulation 

1. Prepare 2 .fzd files, use the same geometry
   1. phys.fzd ( hard process simulation you want to study). You need 100-1000 events
   2. minb.fzd (minb Pythia events), you need 10k-100K events, they were out fast at large lumi, then files is recycled
2. Decide about :
   1. time spacing between bunches in ns (in 2009 it was 107 ns) & # of available bunches in the ring (in 2009 it was 120 ). 
   2. peak luminosity you want to probe. I'd recommend to scan lumi up to  factor 2 above peak lumi achieved last year. It may be hard to undoable. 
3. Compute avr # of interactions per bXing, lets say it is 0.15,  this see example http://www.star.bnl.gov/protected/spin/balewski/2005-PPV-vertex/lumin.html,
4. Fire regular BFC on 10 events using file phys.fzd, make sure all works well. Say your command was:
   

       bfc.C(10,"dAuMDC ..... BeamLine bigbig","phys.fzd")
   

5. Now add pileup using pileup probability of 0.15,  by extending the second string as follows:
   

     bfc.C(10,"dAuMDC ..... BeamLine bigbig","phys.fzd; 
            gfile B test2/mc2003-9.fzd; 
            mode BTOF back 35135; 
            mode TPCE back 3761376;
            mode CTB?? back 1; 
            gback 470 470 0.15 106. 1.5; 
            rndm 10 1200") 
   

   where :
   1. '35135' means try pileup for BTOF for 35 bXing before, trigger bXing and 35 after trigger bXing. Note, BTOF slow simu must be enable to handle out of time hits for .zdf file. I do not know how many pre/post trigger events can BTOF seen. It is up to you
   2. '3761376' means for TPC try pileup for 376 bXing before , in, and after trigger event. TRS is set up to handle  pileup correctly. Note, 376*107=40 musec - the TPC drift time.
   3. there is a switch for fast detectors (CTB? is not right) - because all fast detectors are sensitive to pileup in the trigger bXIng. You need to find it  & tell me .
   4. gback is deciding how pileup events will be pooled from your minb.fzd file.
      • '470' is # of tried bXIngs back & forward in time.
      • 0.15 is average # of added events for given bXIng, drawn with Poisson distribution - multiple interactions for the same bXing may happen if prob is large.
      • 106.0 is time interval , multiplied by bXIng offset and presented to the peilup-enabled slow simulators, so the code know how much in time analog signal needs to be shifted and in which direction.
      •  1.5 if averaged # of skipped events in minb.fzd file. Once file is exhausted it reopens it again. If you skip too few soon your pileup events start to repeat. If you skip too much you read inpute file like creazy
   5. 'rndm' is probably seed for pileup random pileup generator - I do not remember.
6. Good luck. Start with low pileup probability - you will notice how CPU time goes  up - it almost scales with pileup prob, because of TRS.
7. aaaa