add ONNXInference algorithm, use it to provide EcalEndcapNClusterParticleIDs

[veprbl]

Briefly, what does this PR introduce?

This provides a calorimeter PID capability using ONNXruntime inference engine. The inference algorithm is generalized into a separate algorithm which inputs and outputs edm4eic::Tensor values introduced by eic/EDM4eic#96.

A set of weights needed to run this are provided in eic/epic-data#22, and is generated using a script from eic/detector_benchmarks#91.

What kind of change does this PR introduce?

• Bug fix (issue #__)
• New feature (issue #__)
• Documentation update
• Other: __

Please check if this PR fulfills the following:

• Tests for the changes have been added
• Documentation has been added / updated
• Changes have been communicated to collaborators

Does this PR introduce breaking changes? What changes might users need to make to their code?

No

Does this PR change default behavior?

Yes

[github-actions]

Capybara summary for PR 1618

• rec_dis_10x100_minQ2=0_craterlake
• rec_dis_10x100_minQ2=1000_craterlake_tracking_only
• rec_dis_18x275_minQ2=0_craterlake_18x275
• rec_dis_18x275_minQ2=1000_craterlake_18x275
• rec_dis_5x41_minQ2=0_craterlake_5x41
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake
  ^{_{Last updated 2024-11-15T14:25-05:00 bd00e60}}

[simonge]

This feels like a lot of extra code for simply mapping values into tensors and back again. I don't have any specific suggestion as to how it could or even should be avoided or generalized.

Otherwise looks good.

[veprbl]

This feels like a lot of extra code for simply mapping values into tensors and back again. I don't have any specific suggestion as to how it could or even should be avoided or generalized.

That's either unavoidable, or a generic mapper, if it exists, can be implemented in this paradigm too. At least ONNX part can be reused, instead of having to copy it into every application, and this supports export PODIO data for training.