Skip to content
Snippets Groups Projects

Add new options to TupleToolDecayTreeFitter

All threads resolved!

Working with @shaines this MR adds a couple new options to TupleToolDecayTreeFitter to fix some naming issues or add new features.

  1. VetoPIDs allows a list of PDG codes, which if found in the tree will be veto'ed from being filled.
  2. UseFullTreeInName When set true this changes the logic that creates the branch name for each element in the tree, to include more of the ancestor history. The reason for this is the current logic fails in certain scenarios to distinguish between particles of the same type in the tree. The example we have is B -> ( D -> Ks pi pi ) Ks pi where the old logic would not unambiguously identify the two Ks particles.

The default for 1. is clearly an empty list. So no change in the default behaviour. The default for 2. is False, however, I think a case could be made that the current behaviour is wrong in certain cases, like the one above, and so True might be a better default.

Edited by Christopher Rob Jones

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Christopher Rob Jones changed the description

    changed the description

  • What do you think to my proposal of making the default for UseFullTreeInName True ? The only reason I did not just do it by default is because it does change the branch name for some entries in the tuple. The change is in a way that makes the decay history for each much more clear, but still as its a change we should discuss if it should be the default or not...

  • added 1 commit

    • f3c797d0 - Add descriptions for new properties

    Compare with previous version

  • I like the idea. Makes sense. I would be inclined to say that we wait for the full stack on master to be out, to the make the change. That's a 1-ish week delay. Would that be OK with you? As long as you write that down somewhere, not to forget, that should be fine. This way we still give a good version for users who do not want the change (in case). The settings have not changed for so long that we can afford a tiny delay. But again, I think your suggestion is good and should be made default.

  • Christopher Rob Jones resolved all discussions

    resolved all discussions

  • Sounds fine to me.

  • OK, deal :-). Merging ...

  • mentioned in commit 1fda9da0

  • Please register or sign in to reply
    Loading