Warning about Decfiles and how to avoid common pitfalls #310
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…nd to verify for themselves the consistency and relevance of the decfiles they want to use
…one or more final states with description of a common mistake and how to avoid it.
xlr91
reviewed
Oct 29, 2024
…anguage precision)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In many published decfiles, there is no correction to the Branching fraction to account for the fact that a diversity of intermediate final states are forced to the same final state, i.e. here.
The BFs of all decays are normalized to one, but in a cocktail of intermediate states you can have different decay rates to the forced final state which must be corrected. For example in the Decfile I linked, D*+ is forced to D0 100% of the time despite its actual BF of 67%. This means that 33% of the D*+ produced do not result in the final state in data, so the MC would have an excess of D*+ coming directly from B0 with respect to the other intermediate states (D** in this case) when compared to data. The relative frequency of D+ coming from B0 -> D*+ mu nu is off with respect to the frequency of D+ coming from other channels such as B0->D+ mu nu or any of the D** modes. Yes they still end up as D+ all the same, but the other event content will matter for i.e. kinematics and polarization, and different modes in the cocktail will for example also produce different numbers of pi+ and pi0. This seems to me to be quite an important point for any analyst who would use such decfiles.
Here, I update the language in the relevant documentation to caution analysts against this, since otherwise the temptation to copy and paste BFs from i.e. the PDG without thinking more deeply about the physics could result in MC samples which are not actually reflective of the desired physics.