Choose timezone
Your profile timezone:
Powered by Indico
v3.3.3-pre
This is a document for taking notes during EDM4HEP meetings.
Present: Graeme, Frank, Andre, Geri, Valentin, Xiaomei, Weidong, Jiaheng, Paul
Will doodle for next meeting. Try to arrange for Acts presentation.
Have a look at the examples that Frank put in - ACTION on everyone.
(Valentin): both test/write_events.cpp and test/read_events.cpp look good to me, the only exception is the bit of code used to write the daughter relations (https://github.com/HSF/EDM4HEP/blob/master/test/write_events.cc#L114) where I agree with Frank that a utility function would be more readable.
There were a few tabs for intendation that I just replaced with spaces.
LCIO does quite a few space saving things that helps reduce file sizes (e.g. store only parents). Not so clear how to do that in PODIO - will need some thought. (Let’s create a PODIO issue.)
PODIO
It’s in the LCG stack now.
EDM4hep was discussed at https://indico.cern.ch/e/PPP66 two weeks ago (although the discussion was mostly on the technical side / Podio and less on the content of the data model).
The idea of having a “library of lambdas” acting on the POD types was agreed to be sensible. Will try to add those. Axel stressed that it is important to be able to do selective reads of a subsets of branches in the tree, which might be difficult with the object relations (but trivial for the PODS).
Geri tested an FCC NTuple generated with PODIO, looks like single valued reads will read more than expected/needed. Issue with ROOT persistification? Need to dig into this in more details to understand properly. Object relations obviously imply reading more than a single branch.
Acts has a variable track parametrisation, where the user interperents the data. There is a maximum number of parameters, then interpreted out of the data store.
Should the data types be fixed at the PODIO level? Do you want to restrict to float? This is needed by PODIO, of course. How could a different experiment use a different precision? At the moment that’s not possible - the data model needs to be well defined. Note that conversions should be minimised, they can be quite expensive. The idea is convert once at the persistification point. Different experiment setups might also use different working points and ranges.
This datatype is optimised for a fairly ‘standard’ HEP detector setup at colliders. Acts is very flexible, beyond this target use case. Acts has its own internal representaion.
4D Tracking
Add another type with timing information?
Acts has added this and always propgates it internally (x, y, z, t). Costs of always doing this have to be evaluated. Particle mass is only useful for long low momentum tracks, where one can implement a PID.
Could timing be optional? PODIO feature request and would also impact on the covariance matrix. We need schema evolution! This would read old files, but populate new objects.
Propagation can be extended to be more sophisticated, e.g. with mass.
We think this track information is complete enough to put into a first implementaion.
Hits
TPCHit not needed right now, we can start with TrackHit alone.
LCIO has also planar hits, which are in local coordinates for the sensor. ATLAS ITk has a fancy parametrisaton for the endcaps, not linear, also conceptually a specialised hit type. These are possible specialisations, but not needed in the first iteration.
EDM4hep is a contract, so it has to be quite concrete in its meaning.