 |
 |
Hi Henning, the piece of work we underestimated at the time of the statement is that we need to rerun the full sequence to get this done. This means that we need to implement this missing bit from analysis-20. We have two alternatives: a) add the full sequences with a switch in IslBRecoilUser b) add the MC filtering in 'or' with our stream in SkimApp I would say that maybe 'b' is cleaner, but none of us has experience in this. Since Daniele's skimming has started we can stay with what we have for this iteration of MC checks and develop the mising piece of code later (but not too late, say in a couple of weeks). Does this sound ok to everybody? ciao ric ______________________________________________________ Riccardo Faccini Universita' "La Sapienza" & I.N.F.N. Roma tel +39/06/49914798 Fax.: +39/06/4957697 http://www.slac.stanford.edu/~rfaccini Univ. La Sapienza. 2,Ple Aldo Moro, I-00185 Roma Dipartimento di Fisica "I don't understand what you say, but I believe I disagree" On Wed, 21 Apr 2004, Henning Ulrik Flaecher wrote: > > Hi Ric, > > I would still like to have all the true bsg decays written out in the > cocktail. As far as I can see it, this is the most straightforward way to > study photon efficiencies as a function of energy and correct for possible > biases in a _consistent framework_, without having to start some > patchworking. I think we learned from the hadr. mass moment analysis that > this needs to be done. > From an earlier email I remember that 'filtering on the truth block > requires little more work but is technically feasible'. > > I realise that it takes longer to run over all cocktail events as the > Breco candidate needs to be reconstructed but suppose that that was also > the case in the summer 2002 production. > Then, it took me (alone) 1 or 2 days to run over all the available > cocktail, ~3.5M events, so this shouldn't delay the production much. > > Cheers, > Henning > > > On Tue, 20 Apr 2004, Riccardo Faccini wrote: > > > today we had a meeting to discuss details of the production. It was agreed > > that : > > - we will run on CM2 skimmed collections as much as possible and resort > > to CM2 unskimmed or CM1 only if stuck. > > - we will start dumping only skimmed events, in any case. I believe all > > studies done with 'all signal events' can be done using a combination of > > GeneratorsQA and ntuples on skimmed events. Please think of it and > > prepare an argument against this statement: running on unskimmed stuff is > > extremely painful in CM2 and would also need some code development. > > - here is the production order. Productions are coordinated by Henning > > unless otherwise stated > > * skim cocktail SP5 (Daniele) > > * run1-3 skimmed > > Here finishes what is currently available, the rest should be available > > when the above production is over > > * SP6 generic MC > > * run4 (65fb-1) skimmed > > * SP5 generic MC > > > > I would say that we should how long it takes to run the first two items > > and how much of the rest is available when the first two items are done. > > > > > > - disk space: daniele will partition the available disk while Henning > > takes care of cleaning the unneeded material > > > > ciao > > ric >