Hello,

I managed to produce tcl files with BbkDatasetTcl and also to split
individual runs with e.g.

BbkDatasetTcl -ds SP-B0B0bar-Run1 -t 10000 --splitruns

This seems to work fine as it increases the first event by 10000 from one
tcl file to the next.
I suppose we'll definitely need this as the data collections contain ~20M
events.

Now I have to figure out what datasets to use.

Looking at the list of available datasets my guess would have been that we
need the following:

For generic BB MC:

SP-B0B0bar-Run1
SP-B0B0bar-Run2
SP-B0B0bar-Run3
SP-B0B0bar-Run4
SP-BpBm-Run1
SP-BpBm-Run2
SP-BpBm-Run3
SP-BpBm-Run4

Data:
AllEventsSkim-Run1-OnPeak-R14
AllEventsSkim-Run2-OnPeak-R14
AllEventsSkim-Run3-OnPeak-R14
(still waiting for run 4)

Could someone please confirm this or tell me the names of the correct
datasets? Is there a list with description somewhere?
(what are the BRecoTo..., BSemiExcl.. and BtoXGamma datasets?)

>From Daniele's posting on the Breco HN I figuered we need the following
for
Signal:
cocktail        SP-2223 2315 2222

Vub  incl       SP-3037 3617
                SP-3618 2575

Vub excl        SP-994 1060 1057 1058
                SP-4113 1059
                SP-4759 4760 4761 4762
                SP-4763 4764 4766

b->sgamma       SP-3135 2534 2799 2800
                SP-2535 2536 3464 3134
                SP-2537 2801 2802 2538 2539
                SP-3463 3452 3453 3454 3455
                SP-3561 3458 3459 3460 3461
                SP-3462 3442 3443 3444 3445
                SP-3446 3447 3448 3449 3450
		SP-3451


Once I have a runnable executable I can start submitting jobs to see what
number of events in data and MC makes good use of the queue length. This
would be bfobjy, right?

Cheers,
Henning




On Thu, 15 Apr 2004, Urs Langenegger wrote:

>
> Hoi Thorsten,
>
> maybe you two should subscribe to this mailing list.
>
>  > Even though that may be technically possible, it may give you the wrong answer :
>  > Not that "CM2-converted" data is not really a conversion, it is a re-processing
>  > starting with the release-12 mini, but using a lot of new reconstruction
>  > algorithms. Especially for the muon-id, the extrapolation of tracks through
>  > the IFR is very different in CM2-converted data (or MC). So
>  >
>  >                   "SP5-Objy != CM2-converted SP5"
>
>
> Apparently there was a discussion about this at the PAC meeting and it
> seems that  "they" considered it OK  for analyses to use  OBJY SP5. Is
> there a solution to this? (Apart from dropping muons? :-)
>
>
>  > What has been the strategy so far ? One run per file ?
>  >
>  > In CM2, there are usually many runs per collection, and so far I did not manage
>  > to squeeze out tcl files which process single runs (or a self-defined run range)
>  > from a given collection. Does anybody know how to do this ?
>
> Even in the old setup long runs were too CPU-intensive to fit into one
> job. The solution was to split the jobs, running only over n events in
> the first tcl, while skipping the first n events in the second job. It
> has been advertised that BbkDatasetTcl  can generate tcl files to cope
> with that problem. We have not validated anything, so far.  Henning is
> working on this.
>
>  > Also, it seems that in it's current state, BbkDataSetTcl delivers somewhat
>  > unordered tcl-files, in the sense that subsequent "input add" lines do
>  > not contain collections which are subsequent in terms of run numbers.
>
> As long as  we don't double-count, loose event  or cross RUN-{1,2,3,4}
> boundaries in one tcl file, there  is no problem if the events are not
> time (or run) ordered.
>
>
>  > >         + The  size of  the tcl  files needs to  be optimized  for the
>  > >           queue length. (kanga?)
>  >
>  > You should contact the experts about that. In our PID-tuple production, the
>  > only reasonnable queue was "bfobjy", which we were told was "illegal". However,
>  > kanga and xlong had too few machines assigned at that time. Maybe it has changed
>  > in the meanwhile ???
>
> I think  the official policy for  SP5 OBJY would still  be bfobjy, and
> CM2 would  be non-bfobjy.  I am  sure they'll tell  us when  we commit
> crimes.
>
>  > >         the  unskimmed SP5  OBJY  (700/fb!) on  a relatively(?)  short
>  > >         timescale.
>  >
>  > One more comment about "unskimmed" data. If you have collections which are
>  > the output of a "Release12 -> CM2" conversion, you should be aware that
>  > the tag-part of the data has NOT been converted. So raw "converted CM2"
>  > data
>  > still contains the tag-bits as they were in release-12. No re-computation
>  > of the tag bits is done during conversion. This is why we are supposed to
>  > use the skims. In the skims (including the "AllEvents" - Skim), the tag
>  > bits are correct.
>
> Good to know! The  plan is run on skimmed CM2. At  least the data. Not
> sure yet about SP6.
>
>
>  > BTW, how are people using these ntuples ? Are analyses run directly from these
>  > ntuples, or does each analysis have its own set of "reduced ntuples" which
>  > are extracted from these "event-store" ntuples ?
>
> I don't know of anybody who does not produce reduced ntuples.
>
> Cheers,
> --U.
>
>

------------------------------------------------------------------
| Henning Flaecher                                               |
| Physics Department           [log in to unmask]           |
| Royal Holloway               Phone: +44 (0)1784 443479         |
| University of London         Fax:   +44 (0)1784 472794         |
| Egham, Surrey TW20 0EX, UK   http://www.pp.rhul.ac.uk/~henning |
|                                                                |
| SLAC M/S 35                                                    |
| 2575 Sand Hill Road          [log in to unmask]         |
| Menlo Park, CA 94025, USA    Phone: (+1) (650) 926 5269        |
------------------------------------------------------------------