 |
 |
Hi, this is a little technical, but I would much appreaciate if some people could look over this and give feedback. I have recently seen - and Roberto said he had actually seen this since we are working with the CM2 based ntuples - that in about 8% of all events in signal MC we do not seem to have any truth match for the signal decay. My knowledge about truth matching is quite limited so please correct me if things I am writing do not make any sense or are wrong. I understand that the current truth matching we do is based on the GHits. RecoilMCUtil has a piece of code that actually takes the true Bs in the event and looks for the one with a direct lepton daughter. This does not get used for filling most of the truth variables, though, the GHit based one is. In the current implementation (running on nonres signal MC, one tcl file, so the output ntuple has 3730 events), 597 events complain that they do not have any B decaying semileptonically. Playing with this a little it turns out that actually in these cases *both* B decay semileptonically and that the current code picks up neither of them (because it wants exactly one sl decay). For the spectrum unfolding (and also for MC studies) it would be nice to reduce this 8% inefficiency and have all (if possible) events have their truth variables filled. Here is my suggestion: Why don't we do the truth matching as we did in CM1? I.e. we loop over the true B and pick out the true semileptonic decay (rather than using the GHit association). At least on signal MC, where we know we must have a semileptonic decay. If we have two, we can still use the GHit association to pick out the signal B or we could even be more aggressive and ask for the Vub decay of the two (and use GHit association in case of two Vub decays, that would also remove the Vcb decays in our signal MC). I would put in an extra flag in RecoilMCUtil that would allow this and use this option in VubXlnu. Daniele, Roberto: Am I missing some technicalities here? Does this sound ok and should/could I put that in? If the answers to the above questions are "yes": Would we want to use this on generic MC as well (I would.)? This seems to be a rather big chance and I might not be aware of all consequences and I know we are not the only ones using this code, so I better ask I guess... Cheers, Kerstin