New SecVtx Framework Description

Mission Statement: To create a common framework for making secondary vertex taggers (i.e. merge BVtx with SecVtx, after a split in the past).

Description of this document: This will describe changes to the SecVtx coding framework. It is not a recipe of how to use SecVtx. This is intended for the audience of people who already know how to use SecVtx, and are interested in the structural changes that have taken place in the merge with BVtx.

---

Graphical Representation of the New SecVtx Framework

---

Class Overview of new SecVtx framework

---

Tagging Class Overview of new SecVtx framework

• Framework Overview: Description of the system.
  • Each tagger now has up to four classes associated with it:
  1. A module (inherited from AppFilterModule, for example) to run supervisory tasks such as getting the primary vertex, and deciding which tagging algorithm to use.
  2. An algorithm class (inherited from TaggingAlg) to run specific tagger setup and initialization such as associating tracks to jets and deciding on seed tracks, and decides which strategy to use.
  3. A strategy class (inherited from TaggingStrategy) to actually perform the tagging on selected tracks, jets, and any other object such as leptons.
  4. A parameters class (inherited from TaggingParams) that pass information amongst the various levels of control.
  • Each tagger has the same interface for tagging (via a common base class).
  • Taggers to be implemented with no framework development:
    1. SecVtx : pruning style tagger.
    2. BVtx : pruning style a la B physics group.
    3. LepVtx : lepton seeded pruning style tagger.
  • Taggers that CAN be implemented, but will require a little development, such as adding variables to SecVtxTrack or SecVtxObj
    1. JetProb : impact parameter pull style tagger
    2. Multivariate taggers : neural nets, statistical combinations, etc.
    3. Soft lepton taggers : tag on leptons in jets
• Advantages: Why do I care? This just looks like more fandangled C++ complication to me!
  • A common interface will allow studies with different taggers:
    • Study correlations between taggers.
    • Use different taggers in the same event (i.e. a loose SecVtx and a tight SecVtx): I see this as the major advantage to this type of system.
    • Easy re-use of ntuplizing and analysis tools. Just write functions on SecVtxObj and SecVtxTrack, and put in a variable telling you what tagger you used!
  • Addition of new taggers will be easy and streamlined:
    • No need to create storage objects.
    • No need to create lots of utility functions.
    • Easy-to-follow interfaces allow for fast implementation of new algorithms.
    • Can use the Object Oriented Mantra: Reuse, Reuse, Reuse!!!!

• BTagObjects:
  • SecVtxTrack: Object that holds information about secondary vertex tracks.
    1. Inherits from CdfTrack_clnk, so you can access all the functions from CdfTrack, as well as use any algorithm that takes a CdfTrack_clnk.
    2. Holds additional information about expected hits, corrected impact parameters, etc.
  • SecVtxObj: Object that holds information about jets and secondary vertices attached to them.
    1. Holds IndexViewVectors of SecVtxTracks for good tracks, pass 1 tracks, and pass 2 tracks, allowing use of powerful STL algorithms such as sorting, searching, finding maximum elements, etc.
    2. C++ looping style, in keeping with CdfCode standards and conventions.
  • SecVtxTracks: Object that holds collections of SecVtxTrack
    1. Holds STL-style collections of SecVtxTrack.
    2. Legacy interface to SecVtxTrack has been left intact.
  • SecVtxColl: Object that holds collections of SecVtxObj
    1. Holds STL-style collections of SecVtxObj.
  • TaggingParams: Virtual base class to act as a go-between from the module to the tagger.
    1. This class is here to enforce a common base class for all tagging parameter classes.
  • SecVtxParams: SecVtx parameters class.
    1. This class is mainly intact from it's previous incarnation.
    2. Holds information about cuts for the different passes for SecVtx
  • Any New Params Classes: Inherits from TaggingParams
    1. This is where you would pass tagger-specific information from your module to your tagger.
    2. Could, for example, include an ntuple that would look at your algorithm at various stages of progression to do expert-level studies that are transparent to the average user.
  • SecVtxTrackCut framework: Exactly the same interface style as CdfTrackCut
    1. Allows STL style looping, sorting, cuts, etc.
    2. For now, SecVtx does not use this framework, but a seperate class that simply does the track cuts for Pass 1 and Pass 2. This will eventually go away.
  • jetMistag: Has not changed at all.
• BTagAlgs:
  • TaggingAlg: Virtual base class for algorithms. Enforces the interface of the "tag" utility. The Alg classes perform general setup for the strategy, such as setting up the seed tracks.
  • TaggingStrategy: Virtual base class for strategies. Enforces the interface of the "strategy" utility. The Strategy classes actually perform the tag itself.
  • SecVtxAlg: SecVtxAlg does track-to-jet association, calls the appropriate track selector, and calls SecVtxStrategy to actually perform the tag. This can be reused for any strategy that has a loop over tracks in jets.
  • SecVtxStrategy: SecVtxStrategy has a loop that prunes input tracks based on chi2 of a CTVMFT fit, and fills the object with that vertex's quantites should it pass certain cuts.
  • SecVtxTrackSelector: Does track selection on the number of good hits that you expect, and removes tracks from lambdas and K_s.
• BTagMods:
  • SecVtxModule: SecVtxModule has been largely untouched. It still does decisions as to what to use as the interaction point estimate, and tag the jets in the specified jet collection.
  • SecVtxNtupleModule: SecVtxNtupleModule has been entirely untouched, save for compatibility issues. This has been the benchmark with which to see if we had changed anything in the code. We made SecVtxNtuple's for before and after changes, and subtracted every entry in the two ntuples to see if there was any difference at all.

1. Phase 1: Preparation (1-2 days)
1. Create "2" files (i.e. rename everything to SecVtx*2.cc,hh)
2. Create "ntdiff" program to make two ntuples and take differences, entry by entry
3. Test ntdiff program
4. Create 2000 top MC following b-tagging prescription
2. Phase 2: Clarification (1 week)
1. "Boolean-izing" code
2. Indenting
3. Commenting
3. Phase 3: Modify code (2-3 weeks)
1. "Functionalize" existing code
2. Rename some variables for clarification
4. Phase 4: Compatibility with CDF C++ (3-4 weeks)
1. Make classes and namespaces out of logical items (SecVtxTrack, SecVtxTrackSelectors, etc.)
2. Clean up interface (using C++ object collections)
3. Leave in legacy interface for other people.

• Erik Brubaker
• Joao Guimaraes da Costa
• Petar Maksimovic
• Matthew Martin
• Lester Miller
• Salvatore Rappoccio