JeffersonLab / gluex_root_analysis

9 stars 9 forks source link

tree_to_amptools expects masses are constrained if kinFit performed #136

Closed lan13005 closed 3 years ago

lan13005 commented 3 years ago

If any kinematic fit is performed then tree_to_amptools expects that it can get the P4s of the Decaying particles (i.e. pi0 or eta) directly from the tree. These branches with the "Decaying" prefix for instance is only available if the masses are constrained in the Kinematic Fitter which is obviously not always the case. We can check if these "Decaying" branches exist to to see which masses are constrained and get them "directly" and if they don't exist then proceed to the calculation of the P4s through the decay map.

aaust commented 3 years ago

I tested the conversion for trees with one and two unconstrained particles and did not see any problems. I appreciate the additional print out.

jrstevenjlab commented 3 years ago

Line 565 of the modified file https://github.com/JeffersonLab/gluex_root_analysis/blob/dd11da433fa1620493ef053fc6a71335c0d9ef8b/programs/tree_to_amptools/tree_to_amptools.cc#L565

looks for particles with constrained masses or the Proton and gets their P4 from the locDirectP4 array, but how does it handle other charged particles that come from the primary vertex, like a pi+ or pi-? I tried this with the final state proton pi0 pi+ pi+ pi- pi- and the output tree contained only the proton and pi0.

Instead of checking for the Proton specifically, should this be checking if "Decaying" is in the particle name and if not getting the P4 from locDirectP4 with something like

if(locListIndex >= 0 && (((string)locNameObject->GetName()).find("Decaying") == string::npos || locKinFitMassConstrained[(string)locNameObject->GetName()])

For the 5 pion final state above, this seems to work but I haven't checked others.