Present: Graeme, Andre, Valentin, Xiomei, David, Frank, Tommaso, Pere
CEPC are migrating to Gaudi. Trying to use pLCIO.
We would like at least part of the reconstruction to
work. As close as possible to the current LCIO would
make this easy.
Define the EDM up to end of October. CHEP will be a break.
After that look at the scale of the modifications
need to get pieces of ILCSoft to work, with a mini-milestone
before Christmas.
Valentin will start to look at FCC algorithms and
their interfaces.
Doodle for a regular meeting slot…
Should be adding a 3rd column for EDM4HEP - what shall
we put in.
FCC misses doubles in primitives. Comment that
for precision measurements, few microns in
O(10m) really does require doubles.
Are the hits really stored as global coordinates?
CMS uses local coordinates in persistent version
(which can manage with less precision).
Frank - would like to have names like vector3d and
vector3f. More generic and easier to understand.
LorentzVector - in ILC don’t always want to couple
these so wasn’t added to the EDM. (Have a vector4d
primitive, for example.)
Can we have aliases for these primitives in
concrete cases? Then LorentzVector is a class or
utility based on a suitable primitive.
FCC EDM having such low level components Bare*
was sometimes not so helpful.
ObjectId can be reimplemented more naturally in
PODIO as a collection ID, so we don’t need it.
Run and event information is needed for beam tests.
MC can get away with EventInfo only, hence the FCC’s
more limited information here.
LCIO EDM had an EventHeader for every event. This
has not been redone in pLCIO, assume that every event
has the same content.
We need metainformation, but at which scale?
Are these really needed to be in the EDM? FCC now
don’t need it.
ILC - rationale was to restrict things, so there was
a need to sometimes store an extra piece of information
that has a specific meaning… Question is would
EDM4HEP be extensible? Want this to be there, but there
is a serious risk of abuse.
Can we just use the native (C++) types here? This is
not possible in PODIO at the moment. FCC work around
(for FloatValue) is directly coupled to ROOT, so not generic.
Different information available for MC and data.
Do these share a common base?
LCIO ReconstructedParticle point back to tracks
and clusters then to hits. Through an LC relation
there is a way to point back to the MC truth.
You need relation navigators to help with this.
This was considered to be a success. (We seem to
favour this approach.)
FCC ParticleMCParticleAssociation is actually
limited as it’s 1-1.
No good argument for a GenVertex.
FCC is missing low level track data types. In LCIO
these are for test beams, but they are really used.
TrackState has the track parameters. A lot of
detector development, things like timing information
are coming, and that means a lot more parameters.
Core set of track parameters with extensions?
This is a tricky point to come back to.
CaloHitContribition is a way to accumulate
deposition from different particles. There are
different ways to store this and sometimes all
of the information is needed for particular
studies. (Detailed MC information that blows
up the file size!)
How do we keep the filesize reasonable…? 32bit vs.
64bit. FCC used unsigned long long that in ROOT
can even be cast to 32bits at times (difficult bugs!).
Compression of short ranges in large integers is usually
effective, so favour longs.
FCC EDM was also used for analysis, so there were
jet types. Too many for sure!
LCIO stores jets as reconstructed particles (have
back navigation). Meta information stores, e.g.,
b-tags. Philosophy is to reuse types as much as
possible.
LCRelation is fundamental to link between
objects.