Use case for a physics analysis with a high branching ratio

Outline of use case

This is high branching ratio channel which means that including sidebands the final number of selected events is of the same order as the number of events selected in the stripping - ie no additional selection possible in a subsequent analysis. The CP asymmetry is small (measuring gamma), which requires a very good understanding of any CP-faking effect in the background and the tagging.

CP biases

In the following there are many mentions of PID. What actually counts is a good knowledge of CP-biases due to the detector. The flavour will be determined from the charge of the slow and fast pions and the charge of the kaon. Biases can be induced by charge-dependent kaon-ID, the different interaction rat of positive and negative particles in the detector and left-right asymetries in the detector efficiency. All these efefcts can be controlled using the PID-blind D* sample, which is why they are all labelled as "PID".

Expected number of events

The branching ratio for with and is (0.28%) * (68%) * (3.8%) = 7.2 * 10-5. Folding in the reconstruction, selection and trigger efficiencies Lisa & UE expect 206'000 signal events per year and B/S < 0.3 (lhcb-2003-126). If one allows for more than only the fast pion the number of events may even double with B/S < 0.5 (lhcb-2001-153). All the B/S ratios are based on inclusive BB only. If one assumes that BB forms 50% of the HLT output, all these B/S have to be multiplied by about 2.

This is all without sidebands. To achieve a very good understanding of the CP asymmetry in the background a very large B mass side band will be needed (how large? Let's take 10 times the tight window.). Sidebands of about 4 times the window will also be taken for the D* and D0. Taking into account the fraction of real D* and D0 in the background I estimate that the background will be multiplied by 10*2*1.5=30. One could also control CP asymmetries in the background by subtracting events reconstructed using a wrong sign D*. This would get another factor 2. Adding other D decay modes would also increase this number, but I ignore that for the moment.

This leads to a total signal of 200k and 40 (0.3*2*30*2) times as much background for the exclusive case. That's 0.8 Hz with all final cuts applied, a sizable fraction of the approximately 5Hz (=0.1*200Hz/(4 WG)) that can be devoted to the CP studies after the stripping.

Consequences for stripping

There is little room left for loosening the cuts in the stripping and hence a requirement from this channel is that the reconstruction and the PID have to be as good as possible already in the stripping. There will be several iterations before the stripping selection is OK but at the time of the stripping used for the final fit the PID and the tracking has to be properly calibrated.

Selection

The category for the stream where this selection belongs is physics. This selection does not rely on tight PID cuts, yet the effect of the kaon-ID needs to be measured in data. The tagging performance also needs to be measured. Finally the time resolution is needed, but is not as crucial as for Bs studies. Here comes the additional complication that one uses a slow pion that can be an upstream track. I assume it does not contribute significantly to the vertex position.

Issues

Number of streams from the detector

This channel is likely to be selected in the trigger as well by the exclusive B trigger as by the inclusive D*. It is thus essential that these two "streams" are stripped together.

Information required on trigger, stripping and luminosity

As this is a CP measurement an absolute normalization of the BR is not necessary. Yet one has to make sure that a proper PID calibration is available for each run period as the quality of PID might change with external conditions.

As this is a self-tagging decay there is no need of external information to get the tagging efficiency.

Number of streams in the stripping

This selection will have a strong overlap with all D*-based physics selections, which are all designed for measuring gamma. It thus makes sense to store them all in the same stream. Other D*-based selections are the tagging calibration D*mu and the inclusive D* PID calibration stream. Although this data will be used as input in the analysis it seems not to be needed to have it available in the final fit. As the workflow is likely to be different I'd prefer to have them in three streams.

Information stored for each event

Given the large number of events to analyse and the large combinatorics it would be very helpful to already have the stripping candidates stored in the DST. Since harldly any additional cut can be applied offline it does little sense to repeat the selection process in a user job. -- UlrikEgede - 14 Jul 2006 -- PatrickKoppenburg - 20 Jul 2006 -- PatrickKoppenburg - 21 Jul 2006
Topic attachments
I Attachment History Action Size Date Who Comment
png 372d83f335bf18ce08594e70e9e32866.png   manage 0.5 K 2006-07-14 - 17:25 UnknownUser
png 512b06dc89e8b46b0fd29f904feaaa84.png   manage 0.5 K 2006-07-14 - 17:25 UnknownUser
png 8ca4d69364f47c4ba2a7783b0f54e0f0.png   manage 0.5 K 2006-07-21 - 12:09 UnknownUser
Topic revision: r6 - 2007-11-07 - TWikiGuest

Welcome Guest

 Cern Search TWiki Search Google Search LHCb All webs
Copyright &© 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback