Saving Truth information on extra partons in ttbar events
There currently exists an algorithm to save the truth-level partons in a ttbar production. However, that algorithm does not save any information on extra partons in the event that are not related to the ttbar system. This MR introduces a new module with an implementation of an algorithm to get the interesting extra partons in an event, that could then lead to extra jets at reco-level.
In particular, the algorithm concerns itself with extra partons emerging from 2 sourceS:
- The hard proces, that could be (gq->ttq) or (gg->ttqq)
- ISR/FSR (and MPIs that follows them)
The code intentionally does not try to find partons from back-evolution, proton-remenants or hadronisation.
The algorithm is only usable with Pythia8 since it relies on the use of status codes that are currently only well defined in Pythia8. The status codes are critical in this case to be able to disentangle the various sources of quarks, and simplify the scan over the entire record of quarks in the event (and all versions of each quark).
The algorithm implemented tries to follow gluon lines all the way to a parton, either by following a gluon splitting then following each of the children to their post-FSR versions, or by following the outgoing partons of a 2->2 secondary (sub)process (gq->gq or qq->qq) and again following them to their post-FSR versions. A pseudo-code description is attached in some slides to this MR.
This implementation is motivated by some truth-level checks we wanted to do, to understand the structure of the diagrams entering our analysis phase-space. I do recognise that these partons should not be used to make any "preicise" or "exact" conclusions, but we would like to use them to be able to understand the broad underlying structure of the tt+jets events we have. This is in-light of trying to compare the physics of the tt+>1b diagrams in 5FS ttbar-inclusive simulation and ttbb diagrams in 4FS simulation and understand the difference between the two MCs.
When a parton is found, the parent of the parton is saved, and the post-FSR version of that parton is also saved. The information kept on the parton are: pT, eta, phi, m, pdgId and status. The same information is kept for the parent, as well as the parent's barcode. With these branches saved, one can idenitify the origin of quarks via their parents, find those coming from the same parent (e.g. gluon splitting) and then do simple studies on the kinematics of the partons right before they enter hadronisation. Following this method, partons saved are expected to be ready to undergo hadronisation. The partons are saved after ordering them in pT and choosing first 12 partons.
There is a fraction of the partons saved whose status codes are not directly hinting that the parton is going to undergo hadronisation (not status >70). They are often split into 2 types:
- The parton has no children at all
- The parton has > 2 children, most of which are mesons with status 1 or 2
In the first case, I have no idea what's happening.
In the second case I would naively think that some copies (e.g. with status 71) of the parton that are used to start hadronisation get dropped from the record and the results of first round of hadronisation is attached directly to the parton coming from some radiation in the event. I suppose this is possible if the virtuality of the 71 parton is really large, which is a metric used by some generators to clean the record and can result in missing intermediate partons.
I am not sure what validaiton tests would be appropriate/conclusive for such implementation. I have done simple checks to make sure that all partons being accounted for did indeed start from hard process or MPI or ISR/FSR. I also compared the number of hard process extra jets in 5FS ttbar sample vs 4FS ttbb sample, finding that the 4FS sample does indeed result in 2 extra b-partons being saved every time, and they are always the hardest extra partons in the event.