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