An exception occurs in the HitRefinerAssociator in LineCluster and TrajCluster when RawDigits are not present
I found a strange problem when reconstructing protoDUNE events with cosmic muons with both TrajCluster and LineCluster using larsoft v06_56_01. Here is the error message:
%MSG-w ScheduleExecutionFailure: LineCluster:linecluster@ 20-Nov-2017 08:08:42 CST run: 1 subRun: 150 event: 1491 an exception occurred and all paths for the event are being skipped: ---- ScheduleExecutionFailure BEGIN Path: ProcessingStopped. ---- ProductNotFound BEGIN A request to resolve an art::Ptr to a product containing items of type: raw::RawDigit with ProductID 567948068 cannot be satisfied because the product cannot be found. The productGetter was not set -- are you trying to dereference a Ptr during mixing? cet::exception going through module LineCluster/linecluster run: 1 subRun: 150 event: 1491 ---- ProductNotFound END Exception going through path reco ---- ScheduleExecutionFailure END %MSG 20-Nov-2017 08:08:42 CST Closed input file "../dunedata/physweek/ProtoDUNE_beam_3GeV_cosmics_reco_tagged_mu.root"
The exception occurs in the call to put_into(event) method. Both TrajCluster and LineCluster use the HitRefinerAssociator. The reason this is strange is that there is no exception when reconstructing uB events or protoDUNE single pion events. I would have guessed that all of these hit collections have associations to RawDigits.
Ah, if only I read e-mails in full...
The debugger told me that the exception happens in
HitRefinerAssociator, more precisely in a call to
put_into(event)method. I bet you did not expect that, huh?
The hit refiner optionally produces associations between the new hit and the
recob::Wireobjects they are made out of. To do that, it creates a map of
recob::Wire, and then it uses to find which
recob::Wireto associate to each new hit, which contains a
The map is created by reading from only the
recob::Wirewhich channel they are on (e.g.
digits->Channel()). This is done only for the
recob::Wireassociated to the original hits (to make the knowledge of their label unnecessary, I suppose). But if the
recob::Wireare not there, the method fails.
It is possible to use other route, by assuming that the channel of a
recob::Wirepointer is the same as the hit it's associated with, hence asking the channel to the associated hit, which being a mandatory input, doesn't have the luxury not to exist. This may be more and more relevant as the
recob::Wireare going to be dropped more often. Please open a feature request to implement this change. So far, the
HitRefinerAssociatordoes not support the use case where
recob::Wirehave been dropped from the input.
#2 Updated by Gianluca Petrillo about 2 years ago
- Description updated (diff)
The feature I propose to implement should allow to create the associations for all the new hits for which at least an old hit exists, without resorting to the wire and raw digit data products.In the meanwhile, two workaround are possible:
- have the
raw::RawDigitin the input: it is possible to use the secondary input files feature of art to do that
- disable the creation of associations to the missing data products (
doRawDigitAssnsarguments); of course this will have permanent consequences on the output files created with the workaround.
#3 Updated by Gianluca Petrillo about 2 years ago
Attached the FHiCL configuration to reproduce the issue (spreco.fcl).
A suitable source file is currently available at
#5 Updated by Katherine Lato almost 2 years ago
- Tracker changed from Bug to Feature
- Status changed from Assigned to Accepted
- Assignee deleted (
- Occurs In deleted (
SInce there are workarounds, this is going to be relabeled a feature request, and it's going to the accepted state since we don't have anyone to work on it right now.