Feature #18393

An exception occurs in the HitRefinerAssociator in LineCluster and TrajCluster when RawDigits are not present

Added by Bruce Baller over 3 years ago. Updated about 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
8.00 h



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
20-Nov-2017 08:08:42 CST  Closed input file

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.

E-mail reply:

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 raw::RawDigit and recob::Wire objects they are made out of. To do that, it creates a map of raw::ChannelID_t -> raw::RawDigit/recob::Wire, and then it uses to find which raw::RawDigit/recob::Wire to associate to each new hit, which contains a raw::ChannelID_t.

The map is created by reading from only the raw::RawDigit/recob::Wire which channel they are on (e.g. digits->Channel()). This is done only for the raw::RawDigit/recob::Wire associated to the original hits (to make the knowledge of their label unnecessary, I suppose). But if the raw::RawDigit/recob::Wire are not there, the method fails.

It is possible to use other route, by assuming that the channel of a raw::RawDigit/recob::Wire pointer 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 raw::RawDigit/recob::Wire are going to be dropped more often. Please open a feature request to implement this change. So far, the HitRefinerAssociator does not support the use case where raw::RawDigit/recob::Wire have been dropped from the input.

spreco.fcl (6.02 KB) spreco.fcl FHiCL configuration to reproduce the issue Gianluca Petrillo, 11/29/2017 11:47 AM


#1 Updated by Gianluca Petrillo over 3 years ago

  • Description updated (diff)
  • Category set to Usability
  • Occurs In v06_57_00 added

#2 Updated by Gianluca Petrillo over 3 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 recob::Wire and raw::RawDigit in 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 (recob::HitRefinerAssociator constructor constructor doWireAssns and doRawDigitAssns arguments); of course this will have permanent consequences on the output files created with the workaround.

#3 Updated by Gianluca Petrillo over 3 years ago

Attached the FHiCL configuration to reproduce the issue (spreco.fcl).
A suitable source file is currently available at /pnfs/dune/persistent/users/dstefan/physicsweek/beam_cosmics_tagged/ProtoDUNE_beam_3GeV_cosmics_reco_tagged_mu.root.

#4 Updated by Lynn Garren over 3 years ago

  • Status changed from New to Assigned
  • Assignee set to Gianluca Petrillo
  • Estimated time set to 8.00 h

#5 Updated by Katherine Lato about 3 years ago

  • Tracker changed from Bug to Feature
  • Status changed from Assigned to Accepted
  • Assignee deleted (Gianluca Petrillo)
  • Occurs In deleted (v06_57_00)

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.

Also available in: Atom PDF