[SanghyunKo]

Pandora algorithms for the particle flow reconstruction with the IDEA option 2 detector. This is designed to work on ECAL clusters built by HEP-FCC/k4RecCalorimeter#271 via edm4hep::Cluster to pandora::Cluster conversion using key4hep/k4GaudiPandora#26. HCAL clusters are built within the pandora, seeded by the input ECAL clusters. There are also 2 algorithms that use ML via ONNX inference (photon ID, satellite cluster merging).

The ONNX-dependent algorithms are isolated in the folder MLInference and built only when the flag LCContent_BUILD_ML is set to ON. While the default build flag is OFF, I added CI workflows for LCContent_BUILD_ML=ON too.

Requires PandoraSDK version 04.00.01 and beyond (requires PandoraPFAOrg/PandoraSDK#26)

A presentation related to the physics contents took place in https://indico.cern.ch/event/1707528/#9-pandora-for-idea-updates

[SanghyunKo]

A note on the test - I'm not sure whether we can have any type of test in LCContent. Nevertheless I plan to create a follow-up PR in k4GaudiPandora and prepare a test workflow there.

[jmcarcell]

Did you check if none of the existing algorithms can do what the new ones do? There are a lot of completely new ones. And for the one algorithms that changes the downside is that it has to be validated, for example, on the CLD reconstruction. In addition it adds the onnxruntime dependency. I wonder if future changes are going in the direction of not modifying the existing ones, if it would be better to create another repository with Pandora algorithms.

[SanghyunKo]

I did try to reuse the existing ones as much as possible - this PR obviously includes only the new ones (or modified/extended ones) while I have also other LCContent algorithms that I reuse in the full reconstruction chain. Hence, I personally opt to have everything in LCContent, but we can discuss the strategy in one of the key4hep meetings.

Perhaps we can adopt the LArTPC approach, i.e. keep LCContent without ML dependencies and create another repo dedicated to algorithms with ML use cases.

[Zehvogel]

I cannot estimate yet how much discussion there will be here in total, but you might want to consider splitting the changes to the IsolatedHitMergingAlgorithm from this into a separate PR. :)
Regarding ONNX, I guess it is fine if it (and the algorithms relying on it) are toggleable in the build.

[SanghyunKo]

Seems like the build test is using PandoraSDK v03.04.01, where this PR requires at least v04-00-01.

[jmcarcell]

Seems like the build test is using PandoraSDK v03.04.01, where this PR requires at least v04-00-01.

Please update the requirements wherever find_package(PandoraSDK REQUIRED <VERSION>) (if version is not there then it should be added). Now, in the Key4hep stack in LCG (alma9, ubuntu26 in CI, PandoraSDK has the latest version, 5.0.0).

[SanghyunKo]

Since HEP-FCC/k4RecCalorimeter#271 is now merged, I flipped the PR ready to be reviewed. Comments received so far have been addressed and the PR description is updated accordingly.

[SanghyunKo]

A small note: I don't expect this PR to land in the next Key4hep release, though I'd appreciate timely review since I was pinged by several interested groups/users (so that people can access via nightly releases).

[SanghyunKo]

Hi! I wonder there is any further comment on this PR, otherwise I'd appreciate merging this so that we can move to the last missing piece in the chain key4hep/k4GaudiPandora#52 (and prepare a working CI test there).

[jmcarcell]

This is an AI-generated review (Claude), done on request. Feel free to dismiss any comment that doesn't apply.

General comment: none of the new algorithms or the DualReadoutCorrection plugin are registered in LCContent::RegisterAlgorithms (src/LCContent.cc), so every client has to register them by hand. It may be worth adding them there, plus an equivalent registration function for LCContentML when it's built.

[SanghyunKo]

@jmcarcell Most of your Claude's comments sound reasonable and addressed accordingly. I took liberty of resolving few comments that I refuted. On registering algorithms, I kept as they are because 1) DualReadoutCorrection requires to be configured in the client application anyway, and 2) I didn't dare to touch LCContent.cc as the pre-commit hook does a quite interesting job there 😅