Fix TileHitVecToCntTool (and LArPileUpTool) for AthenaMT pile-up digitization
Currently IPileUpTool
implementations can be called using ReadHandleKeys to read containers from a single StoreGateSvc
instance (for Overlay and digitization without pile-up) and using just the container name to access multiple instances of each input container from multiple random StoreGateSvc
instance (for pile-up digitization).
When pile-up digitization is run in AthenaMT, the tools are cloned per thread, as they are not currently reentrant.
It looks like the cloning procedure is as follows:
- create a new default tool instance
- take the set of property names to override from their defaults from the configuration
- obtain the property value from the initialized tool (not necessarily the values set the configuration)
- use those to set the properties of the cloned tool.
This works if the values of properties are not updated during initialize()
, but calls of the form ReadHandleKeyArrayProperty.initialize(false)
call violate this, by clearing the contents of the ReadHandleKeyArrayProperty
instance.
This merge request works around the issue for TileHitVecToCntTool
by using a regular StringArrayProperty
for the input container names and using that to populate a ReadHandleKeyArray
member variable during initialize()
. This should mean that the data dependencies of the PileUpTools are correctly determined still.
LArPileUpTool
does not show the issue as the ReadHandleKeyArray
properties are not set in the configuration (this seems to be sufficient to avoid it), but have made the same C++ changes for robustness.
This addresses ATLASSIM-6382.