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