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.
