Iss1325 truthseedprocessor class separations

[vdharanikota0]

Resolves #1325

This is a draft, still debugging but code compiles and runs.

Split TruthSeedProcessor into two classes: TruthSeedProcessor and TruthTrackProcessor

• TruthSeedProcessor: handles scoring plane hit selection, hit counting,
  starts extrapolation, and seed smearing
• TruthTrackProcessor: finishes extrapolation to target surface, applies stricter momentum
  and hit cuts, and applies ecal bound state to tracks

Issues:
-histograms are not lining up in TaggerDQM and RecoilDQM
-run time is long since both classes are performing extrapolations, want input on how the processes in these classes should be split

[tvami]

There are conflicts that you'll need to resolve

[tvami]

/run-validation

[github-actions]

The validation workflow is running here: https://github.com/LDMX-Software/ldmx-sw/actions/runs/27167957798.

[github-actions]

Validation Results

Some validation samples failed! ❌

Sample	Status
cascade_history	✅ PASS
deep_ecal_gun	✅ PASS
eat_signal	✅ PASS
ecal_pn	✅ PASS
hcal	✅ PASS
inclusive	✅ PASS
it_pileup	✅ PASS
kaon_enhanced	✅ PASS
signal	✅ PASS
signal_target_al	✅ PASS
target_pn_lyso	✅ PASS
reduced_ldmx	❌ FAIL (211 histograms failed KS test) (artifact)
target_genie	❌ FAIL
target_ti_en	❌ FAIL (386 histograms failed KS test) (artifact)
wab_lhe	❌ FAIL

reduced_ldmx:

• 211 plots failed the KS test against gold.
• Text Differences Between Logs (258298 lines differ)
• Log character count differs by 0% (gold=33510645, new=33428744); within tolerance
• Timing anomaly for reduced_ldmx: new=215s vs gold=1881s (-88%, tolerance 10%)
• Timing for reduced_ldmx: gold=1881s, new=215s

target_ti_en:

• 386 plots failed the KS test against gold.
• Text Differences Between Logs (6900 lines differ)
• Log character count differs by 4%: gold=377322, new=392950
• Timing for target_ti_en: gold=3247s, new=3239s
• Timing within 0% of gold (tolerance 10%)

cascade_history:

• Text Differences Between Logs (2 lines differ)
• Timing for cascade_history: gold=6401s, new=6402s
• Timing within 0% of gold (tolerance 10%)

deep_ecal_gun:

• Text Differences Between Logs (20 lines differ)
• Timing for deep_ecal_gun: gold=3976s, new=4393s
• Timing within 10% of gold (tolerance 10%)

eat_signal:

• Timing for eat_signal: gold=1542s, new=1630s
• Timing within 5% of gold (tolerance 10%)

ecal_pn:

• Text Differences Between Logs (44 lines differ)
• Log character count differs by 0% (gold=21521436, new=21521438); within tolerance
• Timing for ecal_pn: gold=7360s, new=6954s
• Timing within 5% of gold (tolerance 10%)

hcal:

• Text Differences Between Logs (2 lines differ)
• Timing anomaly for hcal: new=715s vs gold=854s (-16%, tolerance 10%)
• Timing for hcal: gold=854s, new=715s

inclusive:

• Text Differences Between Logs (76 lines differ)
• Log character count differs by 0% (gold=21025667, new=21026593); within tolerance
• Timing for inclusive: gold=7065s, new=6944s
• Timing within 1% of gold (tolerance 10%)

it_pileup:

• Text Differences Between Logs (60 lines differ)
• Log character count differs by 0% (gold=9752960, new=9752970); within tolerance
• Timing for it_pileup: gold=580s, new=580s
• Timing within 0% of gold (tolerance 10%)

kaon_enhanced:

• Text Differences Between Logs (52 lines differ)
• Log character count differs by 0% (gold=8843741, new=8843744); within tolerance
• Timing for kaon_enhanced: gold=2867s, new=3157s
• Timing within 10% of gold (tolerance 10%)

signal:

• Text Differences Between Logs (42 lines differ)
• Log character count differs by 0% (gold=16413458, new=16413463); within tolerance
• Timing for signal: gold=1255s, new=1173s
• Timing within 6% of gold (tolerance 10%)

signal_target_al:

• Text Differences Between Logs (776 lines differ)
• Log character count differs by 0% (gold=16793364, new=16793732); within tolerance
• Timing regression for signal_target_al: new=1094s vs gold=653s (+67%, tolerance 10%)
• Timing for signal_target_al: gold=653s, new=1094s

target_pn_lyso:

• Text Differences Between Logs (52 lines differ)
• Log character count differs by 0% (gold=5130723, new=5130730); within tolerance
• Timing for target_pn_lyso: gold=6580s, new=6549s
• Timing within 0% of gold (tolerance 10%)

[tvami]

@bloodyyugo what do you think about this?

[bloodyyugo]

Can you describe in more detail what these two classes are doing? It seems like TruthSeedProcessor is making truth tracks, then TruthTrackProcessor is also making truth tracks and also making (maybe) smeared truth tracks. I am also getting confused by the term "seed" here (and in the old TruthSeedProcessor tbh).

[tvami]

The old "TruthSeedProcessor" was doing both "truth seeds" and "truth tracks", now with this change these are decoupled similar to the way we do this at reco level.

[bloodyyugo]

From what I can tell (in the old processor, which has always been hard to parse) the tracks with the "seed" label are just the truth tracks (maybe smeared) with a non-zero covariance matrix. Honestly, I'm not sure why we save both "truth" and "seed" collections though it may be from PF doing studies.

The beamelectrons are handled a bit differently (calls taggerFullSeed, the true position at the target SP is saved as as the atTarget scoring plane and sim hit IDs are added as measurement IDs). Non-beam stuff (in the tagger, recoil is ok) never get their hits added to the track, which seems like an oversight.

[tvami]

though it may be from PF doing studies.

PF actually wanted to break these up, see:
#1325

[bloodyyugo]

Right, but he's referring to having a base class and then child recoil/tagger classes taking care of (I guess) the different track states get created and handling "beamelectrons" and whatever needs to be handled differently.

And I can see how that would be sensible; createTruthTrack and seedFromTruth methods are agnostic, you could just include a loop over a single supplied scoring-plane list in the base class and maybe have a method call to "doSpecificTrackerStuff" (which does different things for recoil/tagger classes)...

But, I'm just not sure the PR here makes things that simpler. It adds 3 extra collections to the event (from the new TruthSeedProc), which (I think?) contain exactly the same info as the truth_track output of TrackTruthProc apart from the helical parameters. It does simplify the scoring plane loops, I guess.