refactor: Enable Fatras interactions by default / make configurable in addFatras(...)

[benjaminhuth]

It turned out that all interactions in Fatras where turned off by default... This is not optimal I think. This PR enables these by default both on the C++ site and on the python side, to be explicit.

As a consequence, all root hashes relying on FATRAs should change...

[codecov]

Codecov Report

Merging #1631 (ee53840) into main (12c2774) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1631   +/-   ##
=======================================
  Coverage   48.54%   48.54%           
=======================================
  Files         384      384           
  Lines       21042    21042           
  Branches     9693     9693           
=======================================
  Hits        10214    10214           
  Misses       4106     4106           
  Partials     6722     6722           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[github-actions]

📊 Physics performance monitoring for ee53840

Full report
CKF: seeded, truth smeared, truth estimated
IVF: seeded, truth smeared, truth estimated
Ambiguity resolution
Truth tracking

Vertexing

IVF seeded

IVF truth smeared

IVF truth estimated

CKF

seeded

truth smeared

truth estimated

Ambiguity resolution

seeded

Truth tracking

Truth tracking

[benjaminhuth]

If I see it correctely in the physics performance monitor, this has significant impact with respect to some plots, e.g. qop for truth-tracking, this looks not really good...
I'm not sure how to proceed from here actually. Is this expected? Is this a problem of Fatras or of the Algorithms? What do you think, @asalzburger @paulgessinger ?

[andiwand]

the downstream performance does not look so bad but truth tracking q/p looks really bad

it was biased in the first place but with those changes even more.

@benjaminhuth do you think it makes sense to try a subset of the interactions?

[benjaminhuth]

Could make sense... We use only muons here, right? so effects like bremsstrahlung and pair production should not be important anyways (I think?). However, it might be worth to see if maybe ionization loss or multiple scattering has a bigger impact.

However, I had a quick chat with @paulgessinger and I seems there are a lot of possible reasons for that, including also the material description etc...

Running with Geant could also be good to check. But acutally I do not have the capacity right now to investigate this in-depth...

[andiwand]

Running with Geant could also be good to check. But acutally I do not have the capacity right now to investigate this in-depth...

I agree running Geant4 would be interesting. we can let this rest for now until someone runs into this as well or you want to follow up when you have more time

[paulgessinger]

Thoughts @asalzburger?

[benjaminhuth]

Hmm how about we go like this: We introduce a flag in the addFatras(...) method to let this be enabled easily (e.g. for running the GSF or other testing), but is off by default to let the physmon pass.
For these physics issues we open an issue, and discuss it there.
What do you think @andiwand @paulgessinger @asalzburger ?

[andiwand]

I agree 👍 ping me if you need a review

[benjaminhuth]

@andiwand I think this is ready to review (mainly the title has changed to be more appropriate^^)

[beomki-yeo]

@paulgessinger @benjaminhuth In physmon truth tracking kalman, I got this:

1. Eta fixed to 0, all physics disabled in simulation
   

2. Eta fixed to 0, all physics enabled in simulation
   

Both don't look right. Let me think about it more...

[beomki-yeo]

nce does not look so bad but truth tracking q/p looks really bad

@andiwand Actually the monitored graph looks better than reference one (the sigma is closer to 1)