Fee smearing

[cbravo135]

@alspellm also reported that this branch breaks his analysis code, so we should be sure it doesn't before merging this

[alspellm]

That's not the case. Was a miscommunication on my part.

On Mon, Feb 12, 2024, 5:10 PM Cameron Bravo @.***> wrote:

@alspellm https://github.com/alspellm also reported that this branch breaks his analysis code, so we should be sure it doesn't before merging this

— Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/hpstr/pull/187#issuecomment-1940015112, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALKJUATLTIJDU5L77X7DHLTYTK4RXAVCNFSM6AAAAABC2K34BSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBQGAYTKMJRGI . You are receiving this because you were mentioned.Message ID: @.***>

[tomeichlersmith]

So I ran into this error when attempting to run. I enabled debug_ in TrackSmearingTool locally in order to get the extra printouts.

Track nhits=12 bin=3
Track isTop: 1 nHits: 12 p: 0.993493 deltaP=-0.16636 p'=0.827133
Track nhits=12 bin=3
Track isTop: 0 nHits: 12 p: 0.834609 deltaP=-0.0315946 p'=0.803014
Track nhits=12 bin=3
Track isTop: 0 nHits: 12 p: 0.698569 deltaP=0.105552 p'=0.804121
Track nhits=11 bin=2
Track isTop: 1 nHits: 11 p: 0.896728 deltaP=-0.0805587 p'=0.816169
Track nhits=11 bin=2
Track isTop: 0 nHits: 11 p: 0.622917 deltaP=-0.0144043 p'=0.608513
Track nhits=10 bin=1
Track isTop: 1 nHits: 10 p: 1.25236 deltaP=-0.163196 p'=1.08916
Track nhits=12 bin=3
Track isTop: 1 nHits: 12 p: 0.805661 deltaP=-0.0290028 p'=0.776658
Track nhits=12 bin=3
Track isTop: 0 nHits: 12 p: 1.06335 deltaP=-0.00297324 p'=1.06038
Track nhits=10 bin=1
Track isTop: 0 nHits: 10 p: 0.902764 deltaP=-0.103399 p'=0.799365
Track nhits=12 bin=3
Track isTop: 1 nHits: 12 p: 1.03264 deltaP=0.123815 p'=1.15646
Track nhits=10 bin=1
Track isTop: 1 nHits: 10 p: 0.910685 deltaP=0.120995 p'=1.03168
Track nhits=12 bin=3
Track isTop: 0 nHits: 12 p: 1.12335 deltaP=-0.13851 p'=0.984837
Track nhits=9 bin=0
Error:Bin not found in smearing histogram
---- [ hpstr ]: Event processing complete  --------

It looks like there isn't a bin for 9-hit tracks which makes sense if the smearing histogram was created from FEEs. What should I do with these tracks? Smear with the 10-hit smearing? Skip smearing? Cut them out?

[tomeichlersmith]

Ok, I forced a test by just using the lowest hit count bin in the available smearing histogram.

@@ -43,7 +42,11 @@ double TrackSmearingTool::smearTrackP(const Track& track) {
   if (debug_)
     std::cout<<"Track nhits="<<nhits<<" bin="<<binN<<std::endl;

-  if (binN < 1 || binN > smearing_histo_top_->GetXaxis()->GetNbins()) {
+  if (binN < 1) {
+    std::cout<<"Track nhits="<<nhits<<" bin="<<binN;
+    binN=1;
+    std::cout<<" rounding to bin=1"<< std::endl;
+  } else if (binN > smearing_histo_top_->GetXaxis()->GetNbins()) {
     throw std::invalid_argument("Bin not found in smearing histogram");
   }

This seemed to allow for smearing so I moved to checking if the smearing was applied. I am using the 30MeV mass point A' tuples as a test point because the file is quick to run over.[^1] First, looking at the Psum, I am hopeful. We see some broadening due to the smearing applied but the overall shape is maintained.

However, when I try to look at Vertex-level variables recalculating them with the smeared four-momenta, I get a very different result. Below, I compare the smeared four-momenta mass ((p_ele+p_pos).M()) against the mass read in from the input file with the reconstructed vertex (vtx->getInvM()). These are wildly different. I printed out the value of the manually calculated mass and it just appears to be really wrong most of the time. This would make sense if the Vertex fit is getting the InvM through a smarter calculation than just naively combining the track momentum and cluster energy like I'm doing.

[^1]: Available at JLab: /w/hallb-scshelf2102/hps/teichler/re-reach-vanilla/tuples/ap-30/ap-30_hpstr_tuples.root

[tomeichlersmith]

Alright, following @cbravo135 's advice, I am applying the Moeller invariant mass smearing factor as calculated from the tracks that eventually formed the vertex. For validation purposes, I am creating a separated smeared histogram so we can see the smeared (vtx_smear_InvM_h) compared to the unsmeared (vtx_InvM_h).

[tomeichlersmith]

using relative smearing gives more appropriate results. In addition, when looking at invariant mass, we should use the radMatchTight region since that requires the radiated electron to be tightly matched to truth MC particles.

[tomeichlersmith]

More thorough (and direct) checking of the momentum smearing can be done by applying the smearing to a known distribution of momenta rather than using a more complicated simulation and reconstruction to provide the testing distribution. The list below was written by @pbutti as some ideas on what to test (of varying levels of complexity).

• Smear fixed momentum and check if you get a gaussian
• Smear a gaussian and check that you get a gaussian
• Generate a mass by choosing 2 fixed momenta p1 and p2. Smear the momenta and check the smeared mass distribution
• Generate 2 momenta p1 and p2 with gaussian distributions, smear them, check the mass distribution.
• Generate 2 momenta p1 and p2 with non gaussian distributions (like throw from a crystal ball with large low tail). Smear those and check the mass distribution.

[tomeichlersmith]

Alright, I've added a simple executable that can do trials directly testing the smearing tool itself. Right now, it just does the first two of tests listed above, but that easily confirms that the tool is working as expected. With this evidence, along with the update from Tuesday showing that the correct selection brings the final mass resolution closer to the expected result, I think this is ready to merge.

@cbravo135 Can you re-review?

[pbutti]

Hi @cbravo135 @tomeichlersmith Anything preventing this branch to be merged into master? I would like to add some track biasing support for this tool as well (e.g. p -> p + deltaP). This could be used to improve plotting, momentum estimate and also take into account track-level systematics in analysis. But before making additional changes I would like the current version to go in hpstr.