Project

General

Profile

Bug #17609

Problem building larsoft with art v2_08_02

Added by Lynn Garren almost 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
08/29/2017
Due date:
% Done:

100%

Estimated time:
Spent time:
Scope:
Internal
Experiment:
-
SSI Package:
art
Duration:

Description

The uboonecode unit test production.sh fails when attempting to use art v2_08_02.

The error shown is

        Invalid FindManyP
        ---- ProductNotFound BEGIN
          getByLabel: Found zero products matching all criteria
          Looking for type: art::Assns<recob::Track,recob::Hit,void>

Gianluca points out that

1) the nested exception messed with the name of the label for the error message; 
   in the test, the label should be "pandoraCosmicKHit" 

2) art is failing to fetch art::Assns<recob::Track, recob::Hit, void> 
   given that there is also a art::Assns<recob::Track, recob::Hit, recob::TrackHitMeta> available.
   This used to work in the past.

McRecoStage2 | pandoraCosmicKHit....... | ..................... | art::Assns<recob::SpacePoint,recob::Hit,void>.......... | 1442
McRecoStage2 | pandoraCosmicKHit....... | ..................... | art::Assns<recob::Track,recob::SpacePoint,void>........ | .708
McRecoStage2 | pandoraCosmicKHit....... | ..................... | art::Assns<recob::PFParticle,recob::Track,void>........ | ...2
McRecoStage2 | pandoraCosmicKHit....... | ..................... | art::Assns<recob::Track,recob::Hit,void>............... | 2143
McRecoStage2 | pandoraCosmicKHit....... | ..................... | art::Assns<recob::Track,recob::Hit,recob::TrackHitMeta> | 2143
McRecoStage2 | pandoraCosmicKHit....... | ..................... | std::vector<recob::Track>.............................. | ...2
McRecoStage2 | pandoraCosmicKHit....... | ..................... | std::vector<recob::SpacePoint>......................... | .708

There is no release candidate for this build, but there is a local build on woof. The build uses branch feature/team_for_art_2_08. The installed build is available at /home/garren/scratch/larsoft/v06_47_01_01/p/localProducts_larsoft_v06_47_01_01_e14_prof This product directory also includes local builds of updated dependencies.

mrb t -j40 will reproduce the problem. Gianluca has also supplied a shorter fcl file which reproduces the problem.

To reproduce the problem, make a mrb build of uboonecode and ubutil, using /products and the above local product directory. Make sure you use the feature branch.

reco_uboone_mcc8_driver_stage2_shorter.fcl (1.03 KB) reco_uboone_mcc8_driver_stage2_shorter.fcl Lynn Garren, 08/29/2017 04:46 PM
reco_uboone_mcc8_driver_stage2_n1.root (1.11 MB) reco_uboone_mcc8_driver_stage2_n1.root An example input file Gianluca Petrillo, 08/29/2017 05:20 PM
reco_uboone_mcc8_driver_stage2_taggerOnly.fcl (433 Bytes) reco_uboone_mcc8_driver_stage2_taggerOnly.fcl A minimal configuration on the input file Gianluca Petrillo, 08/29/2017 05:20 PM

History

#1 Updated by Kyle Knoepfel almost 2 years ago

  • Status changed from New to Feedback

Can you provide a debug build so that we can more easily diagnose?

#2 Updated by Gianluca Petrillo almost 2 years ago

The product list Lynn showed above is from the shorter FHiCL configuration (attached), re-enabling the output module and omitting the last, failing module.
The art RootOutput file was processed via art event dumper, and the output shows only the data products produced by pandoraCosmicKHit module instance, which is used as input by the failing module.

The failing module is larana:source:larana/CosmicRemoval/CosmicTrackTagger_module.cc#L128 .

#4 Updated by Gianluca Petrillo almost 2 years ago

I can reproduce the problem using a reduced input file (attached) and a simpler configuration (reco_uboone_mcc8_driver_stage2_taggerOnly.fcl, also attached).
Probably a module with a single well-crafted Event::get() line would be enough.

Note that this situation is slightly different from the original one, since in that one the association data product is present in the event but not in the input file, while using the input file I provide the situation is the opposite.

#5 Updated by Lynn Garren almost 2 years ago

A debug build is now available in /scratch/garren/larsoft/v06_47_01_01/d/localProducts_larsoft_v06_47_01_01_e14_debug

#6 Updated by Kyle Knoepfel almost 2 years ago

  • Status changed from Feedback to Assigned
  • Assignee set to Kyle Knoepfel

Exception throw confirmed. Now debugging.

#7 Updated by Kyle Knoepfel almost 2 years ago

  • Project changed from cet-is to canvas
  • Subject changed from problem building larsoft with art v2_08_02 to Problem building larsoft with art v2_08_02
  • SSI Package art added

The problem is understood. The lookup of Assns products has not changed. Instead, a reference to a temporary InputTag object was unintentionally introduced in art 2.08.00. The effect is that the module label of the InputTag used in the FindMany object was garbled--unsurprisingly, the lookups failed due to searching for a garbled module label.

In fact, the mangled module label that was reported in the original exception was not a problem with the exception message, but it was an indication of the problem itself.

Lynn, is there a good reason to introduce a bug-fix release (i.e. art 2.08.03), instead of just including the fix in art 2.09.00? I believe the features for art 2.09.00 are complete, and we could tag maybe even today if desired.

#8 Updated by Kyle Knoepfel almost 2 years ago

  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 100

Implemented with commit canvas:bee13b3.

#9 Updated by Lynn Garren almost 2 years ago

After consulting with Kyle and Marc Paterno, we have requested art 2.08.03.

#10 Updated by Kyle Knoepfel almost 2 years ago

  • Status changed from Resolved to Closed

#11 Updated by Kyle Knoepfel almost 2 years ago

  • Target version set to 2.08.03


Also available in: Atom PDF