Project

General

Profile

Bug #14760

Association creation/loading in uboonecode v06_16

Added by David Caratelli almost 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Category:
Reconstruction
Target version:
-
Start date:
12/05/2016
Due date:
% Done:

100%

Estimated time:
Spent time:
Occurs In:
Experiment:
-
Co-Assignees:
Duration:

Description

I am trying to run a series of modules which I was able to run successfully, but now give me an issue when I try to create and/or load an association.

The code lives in the uboonecode repository. The uboonecode version which is giving me issues is v06_16_00 (the patch release v06_16_00_01 could also be used).

I run a producer, and then an analyzer module. The producer module creates an anab::T0 data-product, as well as recob::Track -> anab::T0 and recob::Track -> recob::OpFlash associations. The analyzer module loads both these associations. The recob::Track -> recob::OpFlash association, when loaded, does not contain the associated OpFlash objects I expect.

The producer module is: uboone/T0Reco/T0RecoAnodeCathodePiercing_module.cc
The analyzer is: uboone/T0Reco/T0RecoAnodeCathodePiercingAna_module.cc

The associations are produced with the "CreateAssn" function, and can be seen in the output with an eventdump (if using a uboonecode setup of v06_06 or earlier):

T0RecoAnodeCathodePiercing | t0reco..................... | ..................... | art::Assns<recob::Track,anab::T0,void>..................... | ....4
T0RecoAnodeCathodePiercing | t0reco..................... | ..................... | std::vector<anab::T0>...................................... | ....4
T0RecoAnodeCathodePiercing | t0reco..................... | ..................... | art::Assns<recob::Track,recob::OpFlash,void>............... | ....4

Both associations are loaded with the FindMany function:

 // grab flashes associated with tracks                                                                                                                                                             
  art::FindMany<recob::OpFlash> trk_flash_assn_v(track_h, e, fFlashProducer );

  std::cout << "There are " << trk_flash_assn_v.size() << " track -> flash associations" << std::endl;

  // grab CosmicTag objects associated with tracks                                                                                                                                                   
  art::FindMany<anab::CosmicTag> trk_cosmictag_assn_v(track_h, e, fCosmicTagProducer);

  std::cout << "There are " << trk_cosmictag_assn_v.size() << " track -> cosmictag associations" << std::endl;
 for (size_t i=0; i < track_h->size(); i++){

    auto const& track = track_h->at(i);

    const std::vector<const anab::T0*>& T0_v = trk_t0_assn_v.at(i);

    std::cout << T0_v.size() << "\tT0 objects associated to this track" << std::endl;

    const std::vector<const recob::OpFlash*>& flash_v = trk_flash_assn_v.at(i);

    std::cout << flash_v.size() << "\tflash objects associated to this track" << std::endl;

  }

While the association is found in the input file, the number of OpFlash objects associated to each track is not what expected (always 0).

How to reproduce this bug:

After setting up uboonecode, one can use the following input file:

/pnfs/uboone/scratch/uboonepro/mcc8.0_val/v06_16_00_01/reco/prodcosmics_corsika_cmc_uboone/15305736_17/prodcosmics_corsika_cmc_uboone_4_20161202T005942_gen2_68cbac5e-939a-4610-ab9d-c0c8546318dd_20161204T115027_reco1_20161204T123012_reco2.root

1st run the producer module:

lar -c run_T0RecoAnodeCathodePiercing.fcl -s /pnfs/uboone/scratch/uboonepro/mcc8.0_val/v06_16_00_01/reco/prodcosmics_corsika_cmc_uboone/15305736_17/prodcosmics_corsika_cmc_uboone_4_20161202T005942_gen2_68cbac5e-939a-4610-ab9d-c0c8546318dd_20161204T115027_reco1_20161204T123012_reco2.root

then run the analyzer module:

lar -c run_T0RecoAnodeCathodePiercingAna.fcl -s T0Reco.root

On the output just created (T0Reco.root)

Fcl files to copy locally:

/uboone/app/users/davidc1/v06_16_00/srcs/uboonecode/uboone/T0Reco/*.fcl


Related issues

Related to canvas - Bug #14763: FindMany silently ignores associations to non-available productsClosed12/05/2016

History

#1 Updated by Gianluca Petrillo almost 4 years ago

  • Description updated (diff)

#2 Updated by David Caratelli almost 4 years ago

  • Description updated (diff)

#3 Updated by Gianluca Petrillo almost 4 years ago

  • Category set to Reconstruction
  • Status changed from New to Assigned
  • Assignee set to Gianluca Petrillo

I'll take a look.

#4 Updated by Gianluca Petrillo almost 4 years ago

  • Status changed from Assigned to Work in progress

I can reproduce the problem.
Associations are present and correct, but the result extracted via one of the `FindMany` objects is not correct.

#5 Updated by Gianluca Petrillo almost 4 years ago

  • Status changed from Work in progress to Resolved
  • % Done changed from 0 to 100

The problem is that you have dropped the recob::OpFlash data product, at run_T0RecoAnodeCathodePiercing.fcl line 94.
Then, art was... less than helpful in telling you the problem.
It turns out, art::FindXXX will not include an association if they can't resolve the associated pointer.

Anyway: you don't want to drop that one, since you are using it.

#6 Updated by David Caratelli almost 4 years ago

I edited my fcl and this was indeed the problem. Thanks and sorry about causing trouble wit this...

Gianluca Petrillo wrote:

The problem is that you have dropped the recob::OpFlash data product, at run_T0RecoAnodeCathodePiercing.fcl line 94.
Then, art was... less than helpful in telling you the problem.
It turns out, art::FindXXX will not include an association if they can't resolve the associated pointer.

Anyway: you don't want to drop that one, since you are using it.

#7 Updated by Gianluca Petrillo almost 4 years ago

  • Related to Bug #14763: FindMany silently ignores associations to non-available products added

#8 Updated by Gianluca Petrillo almost 4 years ago

I have opened a ticket (issue #14763) in canvas to discuss if this is the intended behaviour, and whether that intendment is sane.

#9 Updated by Katherine Lato over 3 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF