Linkage between 'low-level' and 'high-level' reco objects

[chenel]

At the moment there's no way to tell which low-level (detector-specific) object(s) a SRRecoParticle was made from. This is often information needed to make further high-level decisions.

I attemped (in branch feature/reco_linkage) a structure where every low-level CAF reco object would inherit from a base class, and the SRRecoParticle would maintain a pointer back to it. Unfortunately that isn't compatible with SRProxy, which only understands POD types (and vectors of them), nor with flat CAFs, which want to serialize the values in every branch to POD types.

I also have considered a structure where SRRecoParticles maintain something like the SRNDLArID (etc.) that gives the relevant indicies back to their reco-obj-of-origin. The trouble with this is that this object-of-origin could be anywhere in the StandardRecord and we'd have to do some very unwieldy thing that can map out all the possible places it could live.

[chenel]

I've been thinking more about this problem lately. I think it would be solvable with some special-casing inside SRProxy and the flat-CAF maker to serialize and deserialize these pointers using specially named branches. For a representative SPINE SRRecoParticle object, the representative fields might look like the following when serialized to a flat CAF:

rec.common.ixn.dlp.part.dlp.base.ptr_br
rec.common.ixn.dlp.part.dlp.base.ptr_idx

where:

• base would correspond to the name of the SRRecoParticle field containing the pointer:

class SRRecoParticle
{
...
  std::vector<const SRRecoObjBase*> base;  ///< list of all low-level reco objects that contributed to this reco particle
...
};

• ptr_br would be a std::vector<std::string>, containing the (serialized) branch names of the target base objects;
• ptr_idx would be a std::vector<unsigned int>, containing the offsets in the branch for each base object.

The tricky part of this will be to figure out what to put in ptr_br. I think it must be possible to keep some kind of cache as the serializer moves through the StandardRecord, and delay filling the ptr_br instances until the end, when it has a table of all the SRRecoObjBase* instances it's seen and where they went. But this will need some study.

SRProxy will then need some similar logic to re-construct the SRRecoObjBase* from the branches it sees when deserializing.