Choose timezone
Your profile timezone:
EDM4hep Discussion
→
Europe/Zurich
Zoom
Zoom
EDM4hep Discussion
EDM4hep Live Notes
==================
Date: Apr 01, 2025
Indico: https://indico.cern.ch/event/1533034/
Connected: Mateusz, Andre, Juan, Thomas, Aurora,
Apologies: Frank
## Introduction and General Points
* Key4hep EPPSU input submitted (thanks Juan)
### Upcoming workshops / conferences
https://github.com/orgs/key4hep/projects/4/views/1
## Progress and discussion
## Podio
* https://github.com/AIDASoft/podio/pulls
* https://github.com/AIDASoft/podio/issues
* https://github.com/orgs/AIDASoft/projects/2/views/1
### Merged PRs
* Prevent assignment to temporary datatype and link objects [#743](https://github.com/AIDASoft/podio/pull/743)
* Don't rely on ROOT JIT to define python build_version [#745](https://github.com/AIDASoft/podio/pull/745)
* Support unity builds by adding header guard and changing a few function names [#746](https://github.com/AIDASoft/podio/pull/746)
* Typo fixes [#749](https://github.com/AIDASoft/podio/pull/749), [#759](https://github.com/AIDASoft/podio/pull/759)
* Fix handling of forced python version [#747](https://github.com/AIDASoft/podio/pull/747)
* Add const to void* in OrderKey.h [#751](https://github.com/AIDASoft/podio/pull/751)
* update collection `max_size` to include limits due to ObjectID [#752](https://github.com/AIDASoft/pull/752)
* Allow `^` in units in datamodel definitions [#755](https://github.com/AIDASoft/podio/pull/755)
* add `std::ranges::interface_view`-like methods to `RelationRange` [#754](https://github.com/AIDASoft/podio/pull/754)
### [WIP] Store the collection information in a struct instead of a tuple
* https://github.com/AIDASoft/podio/pull/711
* Makes `TTree` version store information as `struct` instead of `std::tuple`
* RNTuple version already stores info without `std::tuple`, **but in different format**
* [x] Harmonize formats
* Now stored as a `vector` of structs. Previosly was AoS (effectively) for RNTuple
* [ ] Switch to that?
### Add `RVec` to root dictionaries
* https://github.com/AIDASoft/podio/pull/750
* Triggered by https://github.com/key4hep/EDM4hep/issues/416
* `RVec` dictionaries are currently (partially) defined via FCCAnalyses
* [ ] Where should the go (formally)?
* FCCAnalyses is effectively "polluting" the global environment. If we provide this, it should be done centrally
* In principle our files are not part of the public API (no schema evolution, no link resolution)
* No easy way to figure out where dictionary definitions come from via ROOT.
* E.g. bisecting `LD_LIBRARY_PATH`
* Features are used nevertheless. Users don't care about all the features always
* Other use cases: ML related studies partially use uproot
* Reality: Users do what they want, regardless of what we officially support
* We could improve usability with plain ROOT
* E.g. more schema evolution support (that we partially need to do in any case)
* [ ] Discuss again in slightly larger round
### Add `typeName` member to link collections
* https://github.com/AIDASoft/podio/pull/748
* Harmonize all collection (constexpr) interfaces
* Currently needs to be synchronzied with https://github.com/key4hep/EDM4hep/pull/414
* Could be done via proper deprecation and no breaking changes
* No deprecation. Merge today
* [ ] Improve generated documentation for links (e.g. in EDM4hep https://edm4hep.web.cern.ch/namespaceedm4hep.html#a433cea6310aef9e8e3375f59d61d64c3)
### Formalize common interface collections with a concept
* https://github.com/AIDASoft/podio/pull/758
* Better compile time checks for collection interace parts that are commonly generated but go beyond `CollectionBase`
* Make it publc?
* Currently keep it as a test to make sure that all collections provide the same interface. We have had some issues with inconsistencies in the past
## EDM4hep
* https://github.com/key4hep/EDM4hep/pulls
* https://github.com/key4hep/EDM4hep/issues
* https://github.com/orgs/key4hep/projects/5
### Merged PRs
* Documentation and typo fixes [#417](https://github.com/key4hep/EDM4hep/pull/417) [#420](https://github.com/key4hep/EDM4hep/pull/420)
* Use ICHEP2022 as "official" reference and add `CITATION.cff` [#408](https://github.com/key4hep/EDM4hep/pull/408)
### Clarification of trackerHitPlane members
* https://github.com/key4hep/EDM4hep/issues/421
### Pointer persistency in EDM4hep
* https://github.com/key4hep/EDM4hep/issues/418
* Interplay, e.g. with Pandora that expects a pointer
* Pandora is not touching this, just using this to transport information along
* E.g. could be `std::any` and Handle is kept alive because `std::any` is constructed by value (via new member)
* Need to have a way for EDM4hep
* Current workarounds would require filling a temporary vector to keep pointers to handles alive
* No really user friendly way at the moment
* Do we need a nice way? Should only appear in few central places
* [ ] Document workaround with vector
* [ ] Point uses to issue and make them indicate they use this
* [ ] Decide on number of actual users whether it's worth the effort to do a "proper solution"
### Use typeName for Link collections
* https://github.com/key4hep/EDM4hep/pull/414
* Avoids having to use a `podio::detail` namespace
### Limit the RNTuple backwards compatibility to podio 1.2
* https://github.com/key4hep/EDM4hep/pull/413
* Necessary after https://github.com/AIDASoft/podio/pull/711
### [WiP] Replace the spin by a helicity property for the MCParticle
* https://github.com/key4hep/EDM4hep/pull/404
* Debugging special schema evolution that ideally stores `spin.z` into `helicty`
* [x] Do we want / need this? -> Yes, at least would be worthwile to see if schema evolution can deal with this
* Quite a few existing LCIO files with `spin`, but could be absorved in the LCIO to EDM4hep converter
* [ ] Are there existing EDM4hep files with this?
* [ ] Need to check where this breaks downstream
* `9` as default value for "unset", why?
* Historically what some generators have been using
### add python bindings for PIDHandler
* https://github.com/key4hep/EDM4hep/pull/397
* Some details still to be clarified(?)
* Lifetimes with `std::optional` (and others) are not behaving intuitively on the python side (with cppyy)
* Could add throwing overloads for wrappers because there is better support for that. But naming could become confusing because we have `get_optional` in other cases and would need a different name here for the throwing version.
* Many use cases dictated by podio usage of `optional` (e.g. parametes).
* [ ] Potentially need to discuss / decide on how our interfaces should look like in general
### Use pre-built hooks in pre-commit
* https://github.com/key4hep/EDM4hep/pull/402
* Streamlines setup
* "Looks like other repositories"
* clang-tidy not easily packaged (no issue for EDM4hep, but other packages use it)
* [x] Can pre-commit use a different config file than `.pre-commit-config.yaml`
* Yes, can use the `--config` flag
## Converter & MarlinWrapper
* Several fixes for interplay between `IOSvc` and `PodioDataSvc`
* https://github.com/key4hep/k4MarlinWrapper/pull/225
* https://github.com/key4hep/k4MarlinWrapper/pull/233
* Now all combinations of algorithms and wrapped processors should see the same event contents always
* Still some potential issues, see https://github.com/key4hep/k4FWCore/pull/298
* Update the steering file converter script
* https://github.com/key4hep/k4MarlinWrapper/pull/228 (switch to f-string)
* [ ] https://github.com/key4hep/k4MarlinWrapper/pull/230 (replace `InitDD4hep` processor by `GeoSvc`)
* CellID encoding string missing in conversion from LCIO -> EDM4hep
* Standalone: https://github.com/key4hep/k4EDM4hep2LcioConv/issues/114
* MarlinWrapper: https://github.com/key4hep/key4hep-tutorials/pull/21
* `MetaDataHandle` read access behaving differently between `PodioDataSvc` and `IOSvc`?
## AoB
## Next meeting:
* Apr 15, 09:00 CET
There are minutes attached to this event.
Show them.
