Support "extra info" in new/v2 particle event model
The old/v1 Particle
class contained a map of "extra info":
/// has information for specified key
bool hasInfo( int key ) const;
/// add new information, associated with the key
bool addInfo( int key, double info );
/// extract the information associated with the given key. If there is no such information the default value will be
/// returned.
double info( int key, double def ) const;
/// erase the information associated with the given key
unsigned long eraseInfo( int key );
with int
keys and double
values. Valid keys are (mainly -- there are also some "user defined" keys that are not centrally managed) maintained in an enum
definition.
In general we hope to minimise the need for this extra information, but it should still be supported. There is a conceptual difference between extra information that is saved to avoid repeatedly recomputing it (example: the ghost probability MVA) and extra information that is saved because it cannot be computed later (example: isolation information that requires the full event, for a signal that is saved to a Turbo-like stream), but these should probably be computed and stored in the same way and the same structure (in the persistency, one might opt to save only a subset of stored values).
An SOACollection
-based structure should be added that contains a runtime variable number of "columns" of 32bit values. It would be relatively straightforward to support a mix of integer and floating point values, but in practice there may not be any problem with storing everything as float
.
This structure can be created and "zipped" with other event model classes to add extra information. The current zip implementation does not allow multiple instances of the same type to be zipped together, so the full structure should be populated by one algorithm. In pseudocode:
extra_info = AddExtraInfo(Input=input_particles,
Columns={
'SelectionBDT': MVA(...),
'IsolationBDT': MVA(...),
}).Output
where some string ('SelectionBDT'
) -> integer translation via an ANNSvc
should be built in and the output extra_info
can be zipped with the input input_particles
in subsequent algorithms.
While conceptually messier, it might be simpler to always include the extra info container in the definition of certain kinds of particles (using ChargedBasics = zip_t<FittedTracks, RichPIDs, ExtraInfo, ...>
) and swap out an empty container for a populated one after the AddExtraInfo
algorithm has run. This would help limit the number of template instantiations that need to be compiled, but it is not necessary.