Add trident/wab and track efficiency analysis processors

[bloodyyugo]

No description provided.

[tomeichlersmith]

@cbravo135 and I talked and I will be working on the trident analysis processor using a branch on my fork: https://github.com/tomeichlersmith/hpstr/tree/89-trident-track-analysis

[bloodyyugo]

Wow...this is very old! I have something I did way back then that I never committed. Let me take a look.

[tomeichlersmith]

Shoulda just checked the branch listing, is your work the branch iss89 in this repo?

[bloodyyugo]

Yeah, I guess so. I have no idea what shape it is in. Give me a day or so to figure this out...IIRC I added a bunch of things, not just the processor but to other classes, some of which I think maybe got included to the master in other commits.

[tomeichlersmith]

That's what it looks like from a quick browse. Please let me know if a merge or rebase works and then I can just use your branch and/or make updates from there.

[bloodyyugo]

Ugh. Well, I think I merged the master into my old stuff. Not sure if it will work out of box (but it does build). The config I was using is https://github.com/JeffersonLab/hpstr/blob/iss89/processors/config/anaTrident_2016_cfg.py
There are a couple of configs with similar names, one using KF. No promises they work!!!

Also, a warning that these create a lot of plots probably with inscrutable names....that's just how I roll. Anyway, welcome! And feel free to ask me any questions.

[tomeichlersmith]

...just putting notes here so I don't forget...

Loose Full Trident

Look at combinations of 3 ecal clusters at a time and plot their energy sum. Should see beam energy peak produced by the three leptons from a full trident within acceptance. We can refine this by using the x position; roughly, high enough positive x are generally positrons while negative x direction are generally electrons.

Full Trident

Actually use PID to select events with one positron and two electrons within acceptance. First pass was done with this and it seems to be too tight of a cut at the moment.

[normangraf]

https://indico.slac.stanford.edu/event/6895/contributions/2507/attachments/993/2633/20210625_2019DataProcessing_CollaborationMeeting_Graf.pdf

[tomeichlersmith]

This is great @normangraf ! Do you have a branch of hpstr with this work I can base my work on? It looks like you've already done most of the steps I am interested in doing.

[tomeichlersmith]

Found (what I believe to be) the java-based Trident analysis.

https://github.com/JeffersonLab/hps-users/blob/master/src/main/java/org/hps/users/ngraf/dataanalysis/TridentAnalysis2019.java

[tomeichlersmith]

Copied from talk by @normangraf on June 14, 2022

Full Trident Cutflow

• Individual cluster cuts: remove super low energy or super high energy clusters
• Label clusters with x > 100 as positron candidates, and clusters with x < 0 as electron candidates
  • index candidates by energy
• Call highest energy positron candidate "the" positron and two highest energy electron candidates as "the" electrons
• Require these three clusters to be within 2ns of each other
• Sum these three clusters to produce the cluster E sum
• Fiducial cuts making sure clusters aren't "partially" in detector ?? don't know how to do this
• Get tracks matching these three clusters ?? don't know how to do this
• Calculate P sum from these tracks

[normangraf]

Tom, there is no need to implement these selection cuts for any of the analyses in hpstr. Preliminary event selection can all be done using existing code in hps-java which writes out files containing only the candidate events in the lcio output files.

[tomeichlersmith]

Can you point me to how to run these selection cuts? I am interested in using the work you have already done, but I am just very unfamiliar with how to use a java-based framework.

[normangraf]

The plan is to settle on a set of ECal-only selection cuts and then make files available that only contain candidates passing those cuts. I'm still refining the selection analyses I discussed at this morning's meeting and plan to have some files available soon.

[cbravo135]

This is the plan Norman has proposed, but not what HPS has decided to implement. The spokes people of HPS have explicitly asked for these analyses to be made available to our analyzers via hpstr, so that is what we are doing. We want to be able to collaborate on the decision of these selection cuts. Norman is free to use whatever analysis framework he wants but does not get to solely decide what framework everyone else must use. We are capable of reiterating this analysis several times in the time it takes Norman to produce one skim pass, and hpstr uses nearly a factor of ten less disk space doing that. The advantages of having this analysis available in hpstr justify the existence of this issue.

[bloodyyugo]

For sure we want to put the 3-prong selection in hpstr. People (I) will (should) want to use 3-prongs for lots of things and it's easy to run multiple regions (e.g. all 3 cluster-matched, 2 out of 3, 1 out of three; same-side e+e- or e-e-, different selections, etc) in a single pass of the dataset with hpstr. This whole issue is from my analysis for at WAB+Tridents looking at track efficiency, LXLY content in different ESum regions etc....I always meant to put three-prong in here as well but never got around to it. Plus, the physics analyses will be done in hpstr; no reason not to have this there as well.