ANNSvc labelling and configuration for HLT1, HLT2 and Sprucing
The following ideas were raised when attempting to implement one ANNSvc
for reading in data and one ANNSvc
for writing out data (as required in the sprucing MR !763 (comment 4321900))
-
(GR) Propose to label the service used for writing with the 'process' which does the writing, eg. Hlt2 uses
Hlt2ANNSvc
for writing, sprucing usesHlt2ANNSvc
for reading, andSprucingANNSvc
for writing, and then job reading the output of the sprucing usesSprucingANNSvc
for reading. -
(GR) When a TCK is finally used, then the reading side can be updated to use a
TCKANNSvc
instance which is configured withInstanceName = "{}ANNSvc"%NameOfWritingProcess
, and so deal with multiple TCKs inside the same reading job -- so the 'reading' side use of an explicit namedANNSvc
should be labelled withtodo - replace me with
TCKANNSvc.InstanceName=...` -
(RM) For the reading side of HLT1, we should do the same. And then, we don't need HltANNSvc to have Hlt1SelectionID and Hlt2SelectionID but just SelectionID is enough (and it is then almost not specific to HLT, modulo the name and the RoutingBits map).
-
(GR) Given that this service defines the 'meta-information' which is required for encoding/decoding the data, I would expect that any method doing or configuration any encoding/decoding needs to be told explicitly where to get that meta-data. So any function involved should just require that to be part of the arguments -- and it should not be magically derived from some global variable, because that becomes very hard to understand, as it relies on 'conventions' which are typically hard to reverse-engineer without knowing what the person who came up with had in mind (just as for example the name 'ANN' is hard to reverse-engineer, and only becomes clear once you know the answer), and it uses a 'hidden channel' to communicate this information. Better be explicit and pass it along, as from first principles this information has to be passed some way or another (either explicit, or implicit). So to be specific, serialise_packed_containers should get an extra argument corresponding to the service instance it should use. And then when some code calls serialise_packed_containers and the caller doesn't know, then it should add its own arguments, and in that way let this requirement trickle 'to the top' where, hopefully, at some point there will be a natural place where it can then be actually set. Now, there is one (bigger) suggestion that could be made, and that is to actually treat this as a real data dependency and let it go through the TES, i.e. one could imagine a small algorithm which just 'produces' the mapping table for the current event and then we can use the existing infrastructure to track this dependency -- but that requires a bit of a phase change, and does sound a bit like looking for a nail when you happen to have a hammer. On the other hand, it is also kind of what we're doing for MDF I/O -- some 'backend service' which does reading, and then an algorithm to 'enter' it in the data flow...
Please see also LHCb!2965 (comment 4311937)