# Key4hep Live Notes
Date: October 06, 2026
Agenda: https://indico.cern.ch/event/1738194/
Connected: Markus, Ianna, Joseph, Andre, Leonhard, Joshua, Andrea, Thomas, Benedikt, Andreas, Juraj, Sanghyun, David, Mahmoud, Juan, Wouter
Apologies: Brieuc
## Github project
- https://github.com/issues?q=is%3Aopen+is%3Aissue+user%3Akey4hep
## Discussions
[Github Project Discussions](https://github.com/orgs/key4hep/projects/2/views/1?visibleFields=%5B%22Repository%22%2C%22Title%22%2C3970156%2C%22Status%22%2C%22Assignees%22%5D)
## Presentations
https://github.com/orgs/key4hep/projects/4/views/1
* Idea of having a Key4hep workshop first week of December (Mon 7th) at CERN
* Second half of the week has analysis tools workshop
* [ ] Blockers for anyone?
## Communities Round Table
* Status of the release?
* Need the release for production and testing of workflows etc.
* Upstreaming of `PropertyChoices` to k4FWCore (see https://github.com/key4hep/k4RecTracker/pull/107)
* Make it a Util header in k4FWCore
## LCContent and k4GaudiPandora
- Introduce `LCCaloHit` customization point in `LCContent`: [LCContent#45](https://github.com/PandoraPFAOrg/LCContent/pull/45)
- Corresponding factory update in `k4GaudiPandora`: [k4GaudiPandora#55](https://github.com/key4hep/k4GaudiPandora/pull/55)
- **Validated with CLD that this doesn't change the behavior of Pandora**
- [ ] Review & merge
- Add some *status bits* to the `LCCaloHit` and reserve one of them for *isPossibleBIB*: [LCContent#46](https://github.com/PandoraPFAOrg/LCContent/pull/46)
- Requested by MuonCollider
- **Validated with CLD that this doesn't change the behavior of existing algorithms**
- [ ] Review & merge
- From MuonCollider: Algorithms that could profit from additional flags in `CaloHit` (see [LCContent#43](https://github.com/PandoraPFAOrg/LCContent/pull/43))
- Review once the two above are merged
## EDM4hep & podio vs ROOT
- ROOT migrated from `cppyy` to `cppjit` [root#21261](https://github.com/root-project/root/pull/21261)
- Breaks a few things in `dev3` based CI workflows
- Not yet entirely clear what needs fixing and what doesn't -> should all be transparent
- Hope to get answers via https://root-forum.cern.ch/t/question-s-about-the-migration-to-cppjit/65010
- Some temporary fixes in [podio#1031](https://github.com/AIDASoft/podio/pull/1031), [EDM4hep#532](https://github.com/key4hep/EDM4hep/pull/532)
- [ ] Clarify what should be merged
## EDM4hep
* Add a `timeError` to all tracker hit types (and interface): [EDM4hep#528](https://github.com/key4hep/EDM4hep/pull/528)
* Triggered by 4D tracking work in [k4ActsTracking#72](https://github.com/key4hep/k4ActsTracking/pull/72)
* Will come with a `schema_version` bump for EDM4hep
* [ ] Schema evolution PoV: Existing 1.0 files remain readable? What is the value for old files?
* Revival of discussion about how to have "raw hits" attached to a `TrackerHit`: [EDM4hep#382](https://github.com/key4hep/EDM4hep/issues/382)
- Context now: `k4GaudiPandora` does track extrapolation and for ILD *SET* hits are composite space points that would like to point to two 1D measurements
- A bit further into the future: Need to clarify what a *TrackerHit* actually represents (also in light of slightly different ACTS nomenclature)
* Handling / storage of *track only vertices* [EDM4hep#526](https://github.com/key4hep/EDM4hep/issues/526)
* Triggered by vertex finder work in [k4ActsTracking#109](https://github.com/key4hep/k4ActsTracking/pull/109)
* Should not block the release in any case
* Feedback from DELPHI open data conversion to EDM4hep [EDM4hep#530](https://github.com/key4hep/EDM4hep/issues/530)
* Expect a similar report from ALEPH and potentially OPAL
* Should have a look to see what we can (and want to) accommodate in EDM4hep
## k4MarlinWrapper
## Gaudi
## k4CEDViewer
## k4Clue
Recap of the past few months (on top of writing the PhD thesis):
* few PRs merged
* #79 to have different clustering strategies and different coordinates --> improve generality
* #80, #81 and #82 by Juan to fix bugs and clean the repo
* #83 by Sangh Yun to fix the position computation
* comparison with Pandora in terms of physics and computing performance
* the full Pandora chain is better but slower, only the topological clustering is worse (and slower) than k4Clue
* while testing the computing performance I ran into a crash due to the Conformal Tracking algo finding too many tracks
* sample with 50 photons (tracks probably from pair production)
* I suspect the reason is that the algo branched on every parent cell (instead of only the longest-chain one), with the combinatorial exploding.
* Tracks in the event that crashes (after putting a break in the while loop when >15000 tracks are found):
```
--- Event 17 ---
n tracks : 9
track 0: chi2/ndf=0.78 nHits=22 nHoles=0
track 1: chi2/ndf=7.84 nHits=20 nHoles=0
track 2: chi2/ndf=1.19 nHits=20 nHoles=0
track 3: chi2/ndf=12.48 nHits=7 nHoles=0
track 4: chi2/ndf=31.87 nHits=3 nHoles=0
track 5: chi2/ndf=56.96 nHits=3 nHoles=0
track 6: chi2/ndf=49.08 nHits=3 nHoles=0
track 7: chi2/ndf=47.25 nHits=3 nHoles=0
track 8: chi2/ndf=62.44 nHits=3 nHoles=0
```
* my temporary fix was to run with the truth tracking, I also [changed the logic](https://github.com/AuroraPerego/k4Reco/tree/fixConformal) by following only the longest branch, it runs without crashing (but the results have to be validated)
## (Re-)organization of repository content
* Started to move interfaces from k4FWCore to downstream where they are defined
* See discusion from last time
* https://github.com/key4hep/k4FWCore/pull/386 and https://github.com/key4hep/k4SimGeant4/pull/90
* https://github.com/key4hep/k4FWCore/pull/387 and https://github.com/HEP-FCC/k4RecCalorimeter/pull/224
* [ ] Moving of packages / algorithms
* [x] Overlay -> k4FWCore
* [ ] DDPlanarDigi -> k4RecTracker
* [ ] GaudiLumiCalClustering -> k4RecCalorimeter
* [ ] DDCaloDigi, DDSimpleMuonDigi, DDScintillatorPpdDigi -> k4RecCalorimeter
* Three components for Tracking: ConformalTracking, GaudiTrkUtils, Other (RefitFinal, TruthTrackFinder, ClonesAndSplitTracksFinder)
- ConformalTracking, RefitFinal, TruthTrackFinder depend on GaudiTrkUtils
- GaudiTrkUtils depends on KalTest, DDKalTest (iLCSoft)
- ClonesAndSplitTracksFinder does not, it could be moved
* **Is someone actively working on this?**
* Not at the moment
## Documentation of existing algorithms
- [ ] Versioning
- Key4hep releases?
### ACTS integration
### Podio
## GSoC
### Documentation
- [ ] Add page with logos on documentation page
- E.g. add an archive / tarball that is easy to download
- LICENSE, allowed usage (also wrt altering logo), copyright, credits...
- CERN Design Office doesn't care about attribution
- [x] Confirm License and standard CERN rules
- e.g. CERN logo usage guidelines: https://design-guidelines.web.cern.ch/guidelines/logo
## [k4Reco](https://github.com/key4hep/k4Reco)
* Migration / port of LCFIPlus
* https://github.com/key4hep/k4Reco/pull/63
* Split this into different parts? (Vertexing, FlavorTagging, PID)
* Try to figure out what is still necessary and if there are things that could be let go
## k4FWCore
* Code generator for algorithm boilerplate and a key4hep tutorial:
* https://github.com/key4hep/k4FWCore/pull/372
* fully functional with compiled examples and documentation. Please review
* https://github.com/key4hep/key4hep-tutorials/pull/33
## k4Geo
## CEPCSW
## k4SimDelphes
## ML-based Flavourtagger
## k4SimGeant4
## Tooling in Key4hep
## FCC-Analyses
## Analysers
## Build system / Target compiler / dependencies
## k4EDM4hep2LcioConv
## Distributed Computing, Workload Management, Data Management
## Validation system
## FCC Calo reconstruction
## AOB
* https://github.com/AIDASoft/DD4hep/pull/1689
* Bigger topic question: expectations on generator - simulation interface
* See also k4GeneratorsConfig for another conversion
* Do we need / want to always be compatible with HepMC3? E.g. for some MDI studies the HepMC3 format might be too tight (e.g. needs a beam particle at some point).
* (Long term) storage of minutes (Archiv IV has become full today)
* Preference for archive vs. attaching minutes to indico agenda? -> Can just do both
## Next meetings
* Oct 13, 2026, 9:00 CEST