VUB-RECOIL Archives

Vub measurement using recoil of fully reconstructed Bs

VUB-RECOIL@LISTSERV.SLAC.STANFORD.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Daniele del Re <[log in to unmask]>
Date:
14 Apr 2004 09:45:48 -0700 (PDT)Wed, 14 Apr 2004 09:45:48 -0700 (PDT)
Content-Type:
TEXT/PLAIN
Parts/Attachments:
TEXT/PLAIN (193 lines)

Hi,

 I talked to Jeff. I told him that recoil production was usually on
ISL resources and that it would be nice to have a "recoil" new
disk space for the new production (run1-3 sp5).
 At the moment there are many requests to Jeff and Howard. He said
that we can have something now but not the full request. He suggested to
send him a timescale (now 200Gb, 200Gb in three weeks, remaing later in
one month) and they will manage to satisfy our requests.

 I would propose to ask 200Gb now and ask for more in two weeks and the
remaining later (~1 month). What is the new total disk space we need
(removing useless stuff)? 1 Tb?

 Let me know

 Daniele



>
> 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/skims/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/SkimmedData.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).
>
>
>



ATOM RSS1 RSS2