Use case describing how to recover from a bug in the stripping

Outline of use case

A given analysis use as its incoming dataset data from two different processings. Summer conferences are close and there is no time to get a consistent dataset. At the last moment a bug is found in the selection for part of the data causing a known in-efficiency. What is required in terms of information for correcting for this to the affected part of the data.

We need to consider here what can potentially go wrong in the stripping for a given selection. We should then consider in what cases it is possible to recover from this with a new stripping rather than a total reprocessing of the data.



Number of streams from the detector

Pros and cons for this particular analysis for having one or more streams from the detector.

Information required on trigger, stripping and luminosity

Number of streams in the stripping

Pros and cons for this particular analysis of many/few streams.

Information stored for each event

Pros and cons for storing composite candidates and/or other extra data in the DST for the selection. -- UlrikEgede - 14 Jul 2006
Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 2006-09-26 - UlrikEgede
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback