Project

General

Profile

Bug #19023

Problem with MCTruth, MCParticle and hit associations

Added by Bruce Baller almost 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
02/19/2018
Due date:
% Done:

0%

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

Description

I found a problem with the Origin of primary particles in a MicroBooNE electron neutrino event with cosmic overlay. The primary particles in this nue event are identified as simb::kBeamNeutrino (Origin = 1) in MCTruth but simb::kCosmicRay (Origin = 2) in the ParticleInventoryService

MCTruth vec size 2. Looking for origin 1
MCtruth Part TrkID PDGCode KE Mother Process
mcvec 0 Origin 2 NParticles 519
mcvec 1 Origin 1 NParticles 11
1 0 0 12 1404 -1 primary
1 1 1 1000180400 0 -1 primary
1 4 4 11 963 0 primary
1 8 8 2112 78 6 primary
1 9 9 211 212 7 primary
ParticleInventoryService ParticleList size 21090
Prim KE 963 trackID 1184537 Origin 2
Prim KE 212 trackID 1184539 Origin 2

A second problem, perhaps related to the first, is that the BackTrackerHitMatchingData for different hit collections is different for the same recob::Hits. I printed out the MCParticle matching for hits in plane 2 on wire 2510 with StartTick 4293. This is near the primary interaction where an electron hit and a pion hit are in the same hit multiplet and have the same StartTick. The electron hit is at tick 4305 and the pion hit is at tick 4321. In the first section below, the MCParticle associations are printed using the pandoraCosmicHitRemoval and using gaushit in the second section. I don’t think it is possible to have a hIoni process for an electron.

physics.producers.trajcluster2.TrajClusterAlg.HitFinderModuleLabel: "pandoraCosmicHitRemoval"
physics.producers.trajcluster2.TrajClusterAlg.HitTruthModuleLabel: "crHitRemovalTruthMatch"

Hit 2:2510:4305_0 key 1562 StartTick 4293
im 0 trackID 1184539 ideFraction 0.329
im 1 trackID 1184543 ideFraction 0.671
hit 2:2510:4305_0 -> trackID 1184543 Origin 2 pdg 11 E 3.03 Process hIoni
Hit 2:2510:4321_0 key 1563 StartTick 4293
im 0 trackID 1184539 ideFraction 0.329
im 1 trackID 1184543 ideFraction 0.671
hit 2:2510:4321_0 -> trackID 1184543 Origin 2 pdg 11 E 3.03 Process hIoni

physics.producers.trajcluster2.TrajClusterAlg.HitFinderModuleLabel: "gaushit"
physics.producers.trajcluster2.TrajClusterAlg.HitTruthModuleLabel: "gaushitTruthMatch"

Hit 2:2510:4305_0 key 14194 StartTick 4293
im 0 trackID 1184537 ideFraction 0.85
hit 2:2510:4305_0 -> trackID 1184537 Origin 2 pdg 11 E 964 Process primary
Hit 2:2510:4321_0 key 14195 StartTick 4293
im 0 trackID 1184539 ideFraction 0.329
im 1 trackID 1184543 ideFraction 0.671
hit 2:2510:4321_0 -> trackID 1184543 Origin 2 pdg 11 E 3.03 Process hIoni

The code used to produce the output above is in feature/bb_TJWork in TrajClusterAlg::GetHitCollection. This feature branch is based on uboonecode v06_68_00 using a debug build on mac Sierra.

The file used to investigate this problem is prodgenie_bnb_intrinsic_nue_cosmic_uboone_0_20170507T190852_gen2_9341f905-d5c7-402f-b315-9d6d1ef8d50d_20180105T215708_reco1_20180106T003020_reco2.root

mcc8.fcl (9.54 KB) mcc8.fcl Bruce Baller, 02/19/2018 09:54 AM

Associated revisions

Revision b33fadb9 (diff)
Added by Jason Stock almost 2 years ago

A bug was found the ParticleInventory by Bruce Baller where TrackIdToMCTruth was not being correctly resolved. This was found to be due to an overflow error casting an int as a short.
This resolves LArSoft issue #19023

Revision 46af0f61 (diff)
Added by Jason Stock almost 2 years ago

A bug was found the ParticleInventory by Bruce Baller where TrackIdToMCTruth was not being correctly resolved. This was found to be due to an overflow error casting an int as a short.
This resolves LArSoft issue #19023

History

#1 Updated by Bruce Baller almost 2 years ago

Additional information: The event mentioned above is Run 1, Event 247908 (using --nskip 7). The fcl file is attached.

#2 Updated by Lynn Garren almost 2 years ago

  • Status changed from New to Assigned
  • Assignee set to Jason Stock

Jason, are you able to take a look at this? In case it is relevant, there is a bug fix feature branch for larpandora and dunetpc: feature/TrkShwId3D

#3 Updated by Jason Stock almost 2 years ago

Starting on it. I followed the e-mail chain for this earlier this morning.

#4 Updated by Jason Stock almost 2 years ago

Lynn, do you happen to know what the issue # is for the bug in larpandora?

#5 Updated by Lynn Garren almost 2 years ago

There is no bug report. We received this communication from Lorena Escudero:

Following up with the updates regarding the 3D implementation of the SVM-based track/shower Id in 
Pandora that were included in last week’s LArSoft release, I realised there was still a minor update
needed for consistency, and thus I would like to ask the following feature branches to be merged in 
this week’s release. The changes are just two lines in two Pandora settings files. 
The feature branches are ready and tested, and pushed to redmine, and they are called 
feature/TrkShwId3D of the packages dunetpc and larpandora. This affects DUNE and ProtoDUNE, 
and people involved know all the details. 

#6 Updated by Jason Stock almost 2 years ago

Thank Lynn. That answers the questions I had!

#7 Updated by Tingjun Yang almost 2 years ago

Here are some tests I did.
I first setup uboonecode v06_26_01_11 and produced an analysis tree file.
Here is the genie information:

anatree->Scan("genie_Eng:genie_primaries_pdg:genie_trackID")
***********************************************************
*    Row   * Instance * genie_Eng * genie_pri * genie_tra *
***********************************************************
*        0 *        0 * 1.4047136 *        12 *         0 *
*        0 *        1 * 37.215526 * 1.000e+09 *         1 *
*        0 *        2 * 0.9290655 *      2112 *         2 *
*        0 *        3 * 36.286460 * 1.000e+09 *         3 *
*        0 *        4 * 0.9636076 *        11 *         4 *
*        0 *        5 * 1.3701715 *     2e+09 *         5 *
*        0 *        6 * 1.0177373 *      2112 *         6 *
*        0 *        7 * 0.3524341 *       211 *         7 *
*        0 *        8 * 1.0177373 *      2112 *         8 *
*        0 *        9 * 0.3524341 *       211 *         9 *
*        0 *       10 * 36.286460 *     2e+09 *        10 *
***********************************************************

Here are the first geant particles with origin 1 (neutrino)
anatree->Scan("Eng:pdg:TrackId","origin==1")
Type <CR> to continue or q to quit ==> 
Type <CR> to continue or q to quit ==> 
***********************************************************
*    Row   * Instance *       Eng *       pdg *   TrackId *
***********************************************************
*        0 *      738 * 0.9636076 *        11 *   1184537 *  <== primary electron
*        0 *      739 * 1.0177332 *      2112 *   1184538 *
*        0 *      740 * 0.3524341 *       211 *   1184539 *  <== primary pion
*        0 *      741 * 0.9980926 *      2112 *   1184545 *
*        0 *      742 * 0.9933339 *      2112 *   1184546 *
*        0 *      743 * 0.9679082 *      2112 *   1184547 *
*        0 *      744 * 0.9657381 *      2112 *   1184548 *
*        0 *      745 * 0.9611794 *      2212 *   1184549 *
*        0 *      746 * 0.9508032 *      2212 *   1184550 *
*        0 *      747 * 0.9493561 *      2212 *   1184551 *
*        0 *      748 * 0.9483317 *      2212 *   1184552 *
*        0 *      749 * 0.9451022 *      2212 *   1184553 *
*        0 *      750 * 0.9413251 *      2112 *   1184554 *
*        0 *      751 * 0.9397375 *      2112 *   1184555 *

Note both the electron and pion have origin 1. This is inconsistent with what Bruce showed. This is still using the old implementation of backtracker.

Then I setup uboonecode v06_68_00 which uses the new backtracker/particle inventory. The genie information is the same. However, here is the geant information:

anatree->Scan("Eng:pdg:TrackId","origin==1")
***********************************************************
*    Row   * Instance *       Eng *       pdg *   TrackId *
***********************************************************
*        0 *      768 * 0.0970245 *        22 *   1184605 *
*        0 *      799 * 0.9411398 *      2112 *   1184687 *
*        0 *      800 * 0.9432047 *      2112 *   1184705 *
*        0 *      801 * 0.9426622 *      2112 *   1184706 *
*        0 *      802 * 0.9418876 *      2112 *   1184707 *
*        0 *      803 * 35.354229 * 1.000e+09 *   1184710 *
*        0 *      804 * 0.9397451 *      2112 *   1184713 *
*        0 *      805 * 37.215595 * 1.000e+09 *   1184714 *
*        0 *      806 * 37.215671 * 1.000e+09 *   1184715 *
*        0 *      807 * 37.215736 * 1.000e+09 *   1184716 *

Particles with id 1184537 and 1184539 are missing in this list. They are indeed tagged with origin 2:
anatree->Scan("TrackId:origin","TrackId==1184537||TrackId==1184539")
***********************************************
*    Row   * Instance *   TrackId *    origin *
***********************************************
*        0 *      738 *   1184537 *         2 *
*        0 *      740 *   1184539 *         2 *
***********************************************

So there does seem to be something old in the new backtracker/particle inventory service.

#8 Updated by Jason Stock almost 2 years ago

  • Status changed from Assigned to Work in progress

#9 Updated by Bruce Baller almost 2 years ago

  • Priority changed from Normal to High

This problem significantly impacts shower reconstruction development and needs to be fixed soon.

#10 Updated by Jason Stock almost 2 years ago

Bruce, I don't see the feature branch you posted originally on uboonecode. Would you please push it?

#11 Updated by Tingjun Yang almost 2 years ago

The feature branch is in larreco.

#12 Updated by Jason Stock almost 2 years ago

Thanks. Pulling it now.

#13 Updated by Jason Stock almost 2 years ago

I am unable to access the uboone files (not being a collaborator), or at the very least SAM doesn't know where they are when I try to look them up. Would either Bruce or Tingjun be able/willing to copy the test file mentioned in Bruce's initial report to a location I can access so that I can test a fix?

#14 Updated by Tingjun Yang almost 2 years ago

I emailed Jason a link.

#15 Updated by Jason Stock almost 2 years ago

  • Status changed from Work in progress to Resolved

This was patched in the head of develop on Feb-24-18. The issue was an overflow where TrackIds were cast as "short".

#16 Updated by Jason Stock over 1 year ago

  • Status changed from Resolved to Closed

There have been no further issues raised by this fix. I am closing the ticket.



Also available in: Atom PDF