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).