Choose timezone
Your profile timezone:
EDM4hep Discussion
→
Europe/Zurich
Zoom
Zoom
EDM4hep Discussion
EDM4hep Live Notes
==================
Date: Dec 5, 2023
Indico: https://indico.cern.ch/event/1354755/
Connected: Pere, Juan, Swathi, Leonhard, Juraj, Tao, Joseph, Thomas, Graeme, Frank
Apologies:
## Introduction and General Points
### Upcoming workshops / conferences
https://github.com/orgs/key4hep/projects/4/views/1
## EDM4hep Julia prototype
* See presentation
* All leaves of a branch are read simultaneously (e.g. all info of the MCParticles)
* SoA approach is "clever" in what it needs to materialize, e.g. doesn't materialize the whole MCParticle if only mass and momentum is used (optimizer can see through quite a bit of things)
* `register` is not a Julia builtin but something that assigns an index to an object (potentially implicitlly)
* Still part of the prototype to figure out what the best / easiest to use syntax and behavior is
* Table types are ubiquituous in Julia and work with all the plotting libraries. Could consider enabling that for the "EventStore"
* We have an RNTuple backend for writing from C++
* [ ] Provide a test file in that format
* No work yet on writing because `UnROOT` is only able to read at the moment
* Writing will target RNTuple only (still a few months out)
* Writing in the plans for UnROOT (see https://indico.cern.ch/event/1352914/)
* Integrtion into podio code gen infrastructure?
* Currently prototyping to figure out **what** to generate, once that is fixed then we can see how to get that.
* Reading of metadata / parameters?
* Metadata e.g. CollectionID <-> names should be posssible to read because they are two vectors
* (Frame) parameters are currently stored as maps of string to something
## 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
### New tag v00-17-04 (for inclusion in LCG_105)
### Refactor the code generation and split it into language specific generators
* https://github.com/AIDASoft/podio/pull/527
* Easier to maintain
### Remove deprecated functionality
* EventStore and related readers
* https://github.com/AIDASoft/podio/pull/485
* GenericParameters untemplated access functions
* https://github.com/AIDASoft/podio/pull/531
* Reading of "old-style" component definitions in YAML
* https://github.com/AIDASoft/podio/pull/530
* No longer necessary benchmark utilities
* https://github.com/AIDASoft/podio/pull/532
### Fix issue on macOS
* https://github.com/AIDASoft/podio/pull/533
### interface types in podio
* https://github.com/AIDASoft/podio/pull/516
* Ready for review
* Should go in for v1.0
### Interface for readers / writers
* https://github.com/AIDASoft/podio/pull/522
* Would be nice for changing things easily at runtime without having to have multiple different readers
* Current "low level" readers are hard to cover with an interface (different FrameDataT)
### Infrastructure for documentation auto generation (including c++ & python API)
* https://github.com/AIDASoft/podio/pull/383
* Based on sphinx + doxygen & breathe
* Main question: Where should documentation be hosted in the end?
* FCC documentation is versioned and on github pages
### Use black to format all python sources
* https://github.com/AIDASoft/podio/pull/528
* Pretty opinionated format, but it's an automatic tool
## EDM4hep
* https://github.com/key4hep/EDM4hep/pulls
* https://github.com/key4hep/EDM4hep/issues
### Four-vector datatype / component
* https://github.com/key4hep/EDM4hep/issues/245
### Ways to store multiple event weights
* https://github.com/key4hep/EDM4hep/issues/242
* Request from Michele Selvaggi to store multiple weights from Pythia (+Delphes)
* Keep `weight` if `weights` vector is added?
* Option 3 would allow to attach more meaning to the individual weights
* Could also store that as information in the parameters
### Moving to double for MCParticle momentum
* Moving from `float` to `double` should be straight forward and can be done
* https://github.com/key4hep/EDM4hep/pull/237
* **Breaks in quite a few places throughout key4hep!**
* [x] Prepare PRs and synchronize merge
* Introduced a `Vector3d` from `Vector3f` constructor which made this much more painless than originally thought
### Avoid having relation / member names the same as type
* https://github.com/key4hep/EDM4hep/issues/247
## Converters & MarlinWrapper interplay
## AoB
## Next meeting:
* Jan 16, 09:00 (Potential clash with ILD workshop)
There are minutes attached to this event.
Show them.