Go to the Indico Home Page Oldest event Older event Up to category Newer event Newest event Printable version
  • Compact style
  • Indico style
  • Indico style - inline minutes
  • Indico style - numbered
  • Indico style - numbered + minutes
  • Indico Weeks View
    • Switch to the management area of this event
    Login

    Key4hep Discussion

    → Europe/Zurich
    Zoom

    Zoom
    Live Notes
    Live Notes Archive
    Subscribe to the mailing list
    Key4hep Discussion
    Zoom Meeting ID
    95444210901
    Host
    Andre Sailer
    Useful links
    Join via phone
    Zoom URL
    Hide
    # Key4hep Live Notes
     
    Date: October 13, 2026
     
    Agenda: https://indico.cern.ch/event/1740609/
     
    Connected: Leonhard, Andre, Andreas, Joshua, Gerald, Thomas, Sung Won, Brieuc, 
    Apologies: Ianna, Juan, Juraj, Benedikt, 
     
    ## 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
     
    * Plan to having a Key4hep workshop first week of December (Mon 7th) at CERN
        * Second half of the week has analysis tools workshop
        * [ ] Make agenda
     
     
    ## Communities Round Table
    * TM: Decluttered the meeting notes. Only kept topics with open points / todo items.
        * Attempt to keep re-tracing discussions from meetings a bit easier for the future
        * (Can also be undone if desired)
     
    ## Release
    * Tagging most packages this week unless there are comments
        * Only PRs from k4RecTracker from Andrea blocking?
        * k4Gen PRs (from David & Joshua)?
     
    ## k4MarlinWrapper
    * Event seeds were not properly refreshed for wrapped Marlin processors (see [k4MarlinWrapper#490](https://github.com/key4hep/k4MarlinWrapper/pull/490))
        * Result: Many events got the same random seed
        * Reason: Compared `LCEvent` pointers, but subsequent events re-used the allocation. Hence, no refresh. (Introduced with [k4MarlinWrapper#254](https://github.com/key4hep/k4MarlinWrapper/pull/254))
        * Found with a lot of help from Claude (in a somewhat impressive tour de force through quite a bit of ILD tracking performance)
        * Fix: use the Gaudi `EventContext` to decide when to refresh seeds
     
    ## k4ActsTracking
    * **merged**
        * Support for 4D tracking - [k4ActsTracking#72](https://github.com/key4hep/k4ActsTracking/pull/72)
            * Not yet using the `timeError` from the hits, but parametrizing it based on layer
        * Removal of (legacy) `ACTSSeededCKFTrackingAlg` [k4ActsTracking#122](https://github.com/key4hep/k4ActsTracking/pull/122)
            * Fully replaced by `CKFTracking` (with more features)
    * **open**
        * Add initial ACTS adaptive multe-vertex finder [k4ActsTracking#109](https://github.com/key4hep/k4ActsTracking/pull/109) - waiting for Paul to have another look
        * Some fixes to covariance translations: [k4ActsTracking#124](https://github.com/key4hep/k4ActsTracking/pull/124), [k4ActsTracking#125](https://github.com/key4hep/k4ActsTracking/pull/125)
        * Add two way CKF [k4ActsTracking#108](https://github.com/key4hep/k4ActsTracking/pull/108)
        * Fix propagateBackward to Start at Outermost Seed Space Point [k4ActsTracking#127](https://github.com/key4hep/k4ActsTracking/pull/127)
        * Key4hep / Gaudi native material recording [k4ActsTracking#129](https://github.com/key4hep/k4ActsTracking/pull/129) (PR) & [k4ActsTracking#128](https://github.com/key4hep/k4ActsTracking/pull/128) (issue)
            * Need only TGeo, no Geant4
            * Some shapes had bugs in TGeo, (e.g. DriftChamber)
            * Pauls second solution based on Acts plugin & ddsim good to have as cross check
     
    ## LCContent and k4GaudiPandora
    - Introduced `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**
        - [ ] CI failing due to some minor numerical discrepancies
            - Is this pre-existing? Or observed before?
    - 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
    * 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)
        * **Merged** 
    * 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
        * `TrackAtVertex` proposal seems to fulfill most use cases. Could have "track only" vertices that only fill those and vertices that start from ReconstructedParticles that fill the reco particles. Essentially mutually exclusive
        * Main open question: (How) can we walk things back if we realize it doesn't work?
        
    ## k4DetectorPerformance
    * Should it be in the nightlies?
        * Yes
        * https://github.com/key4hep/k4DetectorPerformance/issues/11 should be addressed at some point
        * Update everything but `.clang-format` (do that once there are fewer PRs)
    * [ ] Need to make sure that `k4-project-template` ships the current default
     
    ## 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
     
     
    ## AOB
     
    * SDHCal digitizer moving from LCIO to EDM4hep (currently lives in MarlinReco).
        * Final goal should be `k4RecCalorimeter`
        * Once things are in a shape to be shown, could be discussed in the DRD calo SW meeting (eventually in FCC FullSim meeting)
        
    * [ ] Move `k4RecCalorimeter` from `HEP-FCC` to `key4hep`
     
     
    ## Next meetings
     
    * Oct 20, 2026, 16:00 CEST
    There are minutes attached to this event. Show them.
      • 09:00 → 09:10
        Introduction 10m
      • 09:10 → 10:00
        Discussion 50m
        Speaker: Everyone