|
Another consideration:
If we ask for a lepton, I would think that at least for the
current production a cut higher than P*>0.5 GeV is ok, since the background
rises very fast. Thorsten never used data below 0.6 GeV/c so far, and an even higher limit may be acceptable to get going.
For muon, the cut should be higher anyway.
Also, there should be a cut in the lab. frame!
Vera
-----Original Message-----
From: Faccini, Riccardo
Sent: Wednesday, April 14, 2004 4:56 AM
To: Urs Langenegger
Cc: vub-recoil
Subject: Re: Production 2004: CPU and disk projection
Hi Everybody,
regardless of the availability or not of the hbook disk space, I think we need to seriously consider the option of saving only events with an energetic lepton or photon. I would also consider applying a purity cut (looser than the final one) at the ntuple generation level.
I would say that, assuming we use PID weighting for PID systematics, the semileptonic and b->s gamma analyses would not be affected.
While I test the filter to do this, does anybody see any drawback on such a decision?
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, 14 Apr 2004, Urs Langenegger wrote:
>
> Hoi,
>
> modulo any errors in my computations, the production 2004 for 150/fb
> data and 500/fb BB MC will need
>
> 1.3TB disk space (+/- 150GB)
> O(60000) CPU hours (assuming that the tagbits are functional in SP5)
> O(150000) CPU hours (worst case)
>
> Deleting the moments-analysis (and other) hbook files will free up
> O(750GB) of AWG diskspace, i.e., we'd need to find about 600GB.
>
> Neither scenario is a serious problem to achieve in two months
> (barring catastrophic SCS/batch breakdowns). See below for details.
>
> Seems like a good deal to get two theses out by fall and produce
> publication-ready results before BELLE publishes their combination of
> b->sg and b->ulnu as another "first" ...
>
>
> Cheers,
> --U.
>
>
> ----------------------------------------------------------------------
> 1. Current ISL disks
> ====================
>
> We have the following AWG disks:
>
> shire01>df -k /nfs/farm/babar/AWG37/. /nfs/farm/babar/AWG23/. /nfs/farm/babar/AWG18/.
> Filesystem kbytes used avail capacity Mounted on
> sulky25:/AWG18 619788288 616803143 2800045 100% /a/sulky25/AWG18
> sulky26:/AWG23 619788288 613374726 6013098 100% /a/sulky26/AWG23
> sulky13:/AWG37 619788288 607730751 11310159 99% /a/sulky13/AWG37
>
> They contain a mixture of files:
> -----------------------------------------------------------------------------
> Disk User Size What
> -----------------------------------------------------------------------------
> AWG18 vub-recoil 515948923 ISL/sx-080702: gen BB MC
> data
> skimmed data rfiles
> moments -
> miscellaneous
>
> AWG23 vub-recoil 107038654 ISL/sx-080702: signal MC
> cocktail MC
> skimmed MC rfiles
> hbook_gen_mar ???
> ISL/VubAna-out: DELETE ???
> moments 498613341
>
> AWG37 vub-recoil 262869337 ISL/sx-080702: skimmed MC rfiles
> ISL/sx-080702/newgenbb: gen BB MC
> vub-combo 152832512
> moments 191845657
> ----------------------------------------------------------------------
> -------
>
> In vub-recoil space the following HBOOK files are around (why??):
> ----------------------------------------------------------------------
> AWG23: ca 50GB in ISL/sx-080702/hbook_gen_mar/ and
> ISL/sx-080702/newsig/output/outputdir/
>
> AWG18: ca 12GB in ISL/sx-080702/newsignal/output/outputdir/ and
> ISL/sx-080702/signalMC/FIXED/
> ----------------------------------------------------------------------
>
>
> There is a minor problem in that many of the files and directories
> belong to Alessio, and his account is gone. Will have to send a mail
> to SCS.
>
>
> We also occupy diskspace of group EC:
>
> shire01>du -ks /nfs/farm/g/ec/u05/users/*
> 2126409 /nfs/farm/g/ec/u05/users/asarti
> 509917864 /nfs/farm/g/ec/u05/users/henning
>
> vub-recoil does not use this diskspace, I think (I found no symlinks
> to this disk and nothing in our chains). The story is different for
> the moments-analysis, I guess.
>
>
> -> There are hbook files to be deleted, and some logfiles are not
> gzip'ed. We can free up >50 GB on relatively short notice, I guess.
>
>
>
> 2. CPU and Disk Usage for old production
> ========================================
>
> I assume that we dump identical ntuples (root format) as before.
>
> o ca. 25% of the generic BB allevents make it into the ntuples.
> o Without tagbits, the jobs are CPU limited:
>
> barb: 1.4sec CPU/allEvent
> noma: 0.7sec CPU/allEvent
>
> The wall clock time is only marginally (<5% .. 10%) higher. We'll
> have to see how this is with a CM2 executable on OBJY.
>
> o Running with tagbits was mostly relevant in the old (K0S bug
> affected) MC. I cannot find tcl, log and rootfiles for this case.
> Since the jobs are CPU limited I assume that the time gain is
> proportional to the events skipped.
>
> The skim fractions are 20% (somewhat less than what I see above,
> but this may be due to updated(?) purity tables), see the full list
> in
> http://www.slac.stanford.edu/BFROOT/www/Physics/Analysis/AWG/EHBDOC/sk
> ims/allskims.html
>
> o Diskspace: 7.5 kB/tupleEvent
>
>
> The above was generic BB MC. Now for data:
>
> o CPU: 3.6sec CPU/filterEvent, 0.16sec CPU/allEvent,
> o Disk: 4.5 kB/tupleEvent
>
>
>
> 3. Projection for new production
> ================================
>
> Data: assume 150/fb skimmed CM2
> -------------------------------
>
> There are 1.5e7allEvents/fb-1 (see
> http://www.slac.stanford.edu/BFROOT/www/Computing/DataQuality/SkimmedD
> ata.html)
>
> This implies for the semiExcl skim (with a rate of 4% on data)
>
> -> 150 * 1.5e7 * 0.04 = 9.0e7 events
> -> 9e7*4.5kB = 4.1e8kB = 410 GB
>
> Assuming 1sec CPU/event, this is 25000 CPU hours. (This assumption may
> be somewhat optimistic with CM2 ...) This is what a user can get from
> the compute farm in about ONE month (if "run" is running 24/7).
>
>
> generic BB MC: first assume 400/fb unskimmed SP5 OBJY
> -----------------------------------------------------
>
> This is ca. 420e6 allEvents. Assume 20% with semiExcl BRECO skim.
>
> -> 0.2 * 420e6 = 8.4e7 events
> -> 8.4e7*7.5kB = 630GB
>
> Assuming again 1sec CPU/event and the availability of the tag bits,
> this is 23000 CPU hours. If the "skim rate" is higher (because the tag
> bits are based on older purity tables(?), the disk space could
> increase by up to 25%, to 780GB).
>
> If the tagbits are not available, the total time would be 125khours,
> doable for a team in one month.
>
>
> Now add 120/fb of skimmed CM2 SP6
> ---------------------------------
> This is ca 24e6 events for the ntuple
>
> -> 24e6 * 7.5kB = 180GB
>
> The time to run on this is small, O(6000h).
>
>
|
