Choose timezone
Your profile timezone:
EDM4hep Discussion (MCParticle contents)
→
Europe/Zurich
Zoom
Zoom
Videoconference
EDM4hep Discussion
- Zoom Meeting ID
- 98484040528
- Host
- Andre Sailer
- Useful links
- Join via phone
- Zoom URL
-
EDM4hep Live Notes
==================
Date: May 21, 2024
Indico: https://indico.cern.ch/event/1414706/
Connected: Sanghyun, Juraj, Benedikt, Jacopo, Tao, Brieuc, Swathi, Dirk, Mateusz, Thomas, Pere, Graeme, Frank, Andre, Gerri
Apologies: Juan
## Introduction and General Points
### Upcoming workshops / conferences
https://github.com/orgs/key4hep/projects/4/views/1
## Progress and discussion
### `edm4hep::MCParticle` discussion
- https://github.com/key4hep/EDM4hep/issues/208
- HepMC3 structure vs. EDM4hep (Dirk & Alan) https://github.com/key4hep/EDM4hep/files/15331800/EDM.Comparison.pdf
- See presentation(s)
- Target audience?
- Duplicated information and where to get that information (e.g. from other tool for charge from PDG)
- Which dependencies would that require?
- Keep as is at the moment (and not pull in another dependency)
- Dedicated classes + utilities for certain information from HepMC?
- E.g ToolInfo, GenPdfInfo
- Currently using Frame parameters
- Event level parameters
- Preference for structured information where possible. Start with superset of "common things"?
- Is there a superset that already exists now?
- Can all the attributes from HepMC be mapped to EDM4hep? Should be possible via Frame parameters
- `MCTruthMetaInfo` (`GenEventHeader`) to contain all event level meta data (PDF, Xsec, ...)
- One object / event (similar to `EventHeader`)
- Try to keep number of sources that need to be contacted for related informtaion as small as possible
- `edm4hep::MCParticle` already does quite well in combining information from several sources from HepMC
- (De)duplication of information (or empty information) handed off to compression of I/O backend
- [ ] Respond to comments of Andy explaining decision
- Finish things on our end and come back to HepMC developers for EDM4hep wtiting plugin
- MCnet discussion in Durham end of June, someone participating?
## Podio
* https://github.com/AIDASoft/podio/pulls
* https://github.com/AIDASoft/podio/issues
* https://github.com/orgs/AIDASoft/projects/2/views/1
### Merged PRs
* Pythonizations for collections
- https://github.com/AIDASoft/podio/pull/570
* Add missing include to fix build on gcc14
* https://github.com/AIDASoft/podio/pull/600
### RDataSource for podio
* https://github.com/AIDASoft/podio/pull/593
* Possible to have a generice `RDataSource` for all generated EDMs
* See [presentation](https://indico.cern.ch/event/1387419/contributions/5943467/attachments/2851061/4985208/podio%20(ROOT)DataSource.pdf) from Juraj for early results
* Large memory and runtime overhead (x2 wrt "normal" FCCAnalyses) for simple cases (expected?)
* Memory only increasing, what is going on?
* To be understood. Could be ROOT baskets? Leak in podio?
### Reader & Writer interface
* https://github.com/AIDASoft/podio/pull/522
* Effectively done
* One CI workflow (`clang-12` based failing), see [this comment](https://github.com/AIDASoft/podio/pull/522#issuecomment-2070762263)
* [x] Upgrade CI?
* [ ] Check for `clang-15`
### Change of return types for GenericParamters (and Frame parameters)
* Currently no way of distinguishing between empty (default valued) and unet parameters
* https://github.com/AIDASoft/podio/pull/580
* [ ] Waiting for some downstream PRs to be merged for transparent switch
### Fix param type determination for python bindings on macOS
* https://github.com/AIDASoft/podio/pull/602
* Issue not reproducible by ROOT team(?)
* Hardcoding supported types for GenericParameters in python rather than determining them from the c++ type list.
* Could be easier to maintain(?)
### Proper install prefix for python bindings
* https://github.com/AIDASoft/podio/pull/599
### Add ExtraCode declarationFile and implementationFile
* https://github.com/AIDASoft/podio/pull/601
* Part of the grammer but not implement up to now
* Can be used to solve https://github.com/key4hep/EDM4hep/issues/296
### Improve generated interface function name to obtain the actual type
* https://github.com/AIDASoft/podio/pull/595
* `getValue` -> `as`
```cpp
auto hit = track.getTrackerHits()[0];
hit.as<TrackerHitPlane>();
```
### Frame serialization / deserialization
* https://github.com/AIDASoft/podio/issues/565
* Not part of v1.0
* Proposal from D. Lawrence: https://github.com/AIDASoft/podio/pull/579
### Store GenericParameters as pairs of vectors
* https://github.com/AIDASoft/podio/issues/590
### Leak in SIO Frame reading
* https://github.com/AIDASoft/podio/issues/594
## EDM4hep
* https://github.com/key4hep/EDM4hep/pulls
* https://github.com/key4hep/EDM4hep/issues
* https://github.com/orgs/key4hep/projects/5
### Merged PRs
### Reconstructed TOF
* https://github.com/key4hep/EDM4hep/pull/299
* Do we need the 5 different path lengths and expected times for the 5 particle species?
* Different track length / time for different species
* Could create new tracks for the different species and link to that
* Refitting (and storing) the track might be prohibitive due to size (and information duplication)
* No clear best solution to this yet. Needs some further discussion
### Use MurmurHash3 to hash the algorithm name for the algorithm type in ParticleIDMeta
* https://github.com/key4hep/EDM4hep/pull/307
## Converter & MarlinWrapper
### Possible issue in k4Clue because some conversions are not happening correctly
* Problem happens before in CLIC reconstruction
* Need to investigate where problem acutally is
### Broken conversion of lcio particle IDs that were not created using the PID handler
* https://github.com/key4hep/k4EDM4hep2LcioConv/issues/62
* LCFIPlus / Vertex not attaching a PIDHandler to an empty output collection
* See discussion in https://github.com/key4hep/CLDConfig/pull/30
## AoB
## Next meeting:
* June 04 09:00
There are minutes attached to this event.
Show them.
