Project

General

Profile

Bug #15049

Segfault on Backtracker and PhotonBackTracker with ProdMarley simulated events.

Added by Jason Stock over 3 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Simulation
Target version:
-
Start date:
01/09/2017
Due date:
% Done:

0%

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

Description

Some events from prodmarley have issues with incomplete particle information.

Example on event 2 of
/pnfs/dune/persistent/users/jstock/v06_19_00/reco/prodmarley_nue_spectrum_ar39_dune10kt_1x2x6/16122721_0/prodmarley_nue_spectrum_ar39_dune10kt_1x2x6_87_20170107T181347_detsim2_c33ba759-a0ef-47ad-add0-d39ff409c280_reco.root

generated with

prodmarley_nue_spectrum_ar39_dune10kt_1x2x6.fcl
supernova_g4_dune10kt_1x2x6.fcl
standard_detsim_dune10kt_1x2x6.fcl
standard_reco_dune10kt_1x2x6.fcl

Code sample with error:

for(const sim::TrackIDE eveIDE : eveIDEs){
auto tID = eveIDE.trackID;
const simb::MCParticle* particle=bt->TrackIDToParticle(tID);
int pid = particle->PdgCode(); //SEGFAULT HAPPENS HERE

Non-existent particles are giving us ionization.

dump.fcl (14.6 KB) dump.fcl Generator fcl that produces problem. Issue occures multiple times in the first 50 events. Jason Stock, 01/10/2017 10:25 AM

Related issues

Related to NuTools - Bug #15123: sim::ParticleList::clear() does not clear the set of primary particlesClosed01/12/2017

History

#1 Updated by Jason Stock over 3 years ago

  • Category set to Simulation
  • Experiment DUNE added
  • Experiment deleted (-)

#2 Updated by Jason Stock over 3 years ago

The issue persists when marley is run without the Ar39 Background.

#3 Updated by Gianluca Petrillo over 3 years ago

I haven't studied the issue yet, but I add an observation.
It is an acceptable scenario the one where some ionisation comes from particles that are not available any more.
The only case I can think of, though, is when the configuration asks for dropping the electrons from a shower (which can be many).
If I remember correctly, in that case the track ID is stored negative.

Steven, please let us know if you need support in debugging and solving the issue.

#4 Updated by Jason Stock over 3 years ago

Steven and I worked on this for some time today, and determined that the trackID for the problem events is recorded as "0". There is suspicion that the 'phantom' hits are related to nuclei simulated in Marley. We will try a hacky fix for that tomorrow with a known problem seed and see if it persists. If so, a more elegant fix will be requested upstream.

#5 Updated by Jason Stock over 3 years ago

The "hacky" fix did address one issue, but not the problem at hand. We will submit a bug for nusimtools for the issue just addressed, but this problem will still need to be examined further.

#6 Updated by Gianluca Petrillo over 3 years ago

  • Status changed from New to Assigned
  • Occurs In v06_16_00, v06_17_00 added

#7 Updated by Jason Stock over 3 years ago

  • Assignee changed from Steven Gardiner to Jason Stock

Events are correct after LG4, DetSim, and through Reco. The issue of TrackID=0 Problem appears to be from BackTracker, and is propagated into PhotonBackTracker from there. We are still not sure why the issue has only come up with MARLEY generated events, but I will take over investigating it from here.

#8 Updated by Jason Stock over 3 years ago

Found where TID 0 is being introduced.

sim::EveIDCalculator
74 if ( particleHistory.empty() ){
75 // Something went wrong; most likely the track ID isn't
76 // present in the event.
77 return 0;
78 }

This should probably not be handled in this way. We don't want to return a EveTrackID of 0 when we can't find the eve of a given TrackID.

#9 Updated by Jason Stock over 3 years ago

Two things seem to be happening in the event.

In some cases, there is a hit that immediately fails to backtrack. This could be a noise hit (need to look into this a bit more), or could be related to the same issue as the next type of failure observed.
%MSG-w PhotonBackTracker: Nyarlathotep:Nyarlathotep 11-Jan-2017 11:32:11 CST run: 20000047 subRun: 0 event: 31
can't find particle with track id 0 in sim::ParticleList returning null pointer
%MSG

The next type of event is a Compton Scatter. These backtrack through some number of electrons and ultimately end in a gamma which does not know where it came from, and is not recognized as an Eve particle. This is the currently the most concerning failure.

Begin processing the 34th record. run: 20000047 subRun: 0 event: 34 at 11-Jan-2017 11:32:11 CST
analyze
Track 5 failed to backtrack to a particle.
Particle for this track has PDGID:11 and trackID 5
Next Mother for this track has PDGID:22 and trackID 4

TID==0
EveIDE = 0 energy 0.0266422
Track 6 failed to backtrack to a particle.
Particle for this track has PDGID:11 and trackID 6
Next Mother for this track has PDGID:22 and trackID 3

TID==0
EveIDE = 0 energy 0.861524
Track 6 failed to backtrack to a particle.
Particle for this track has PDGID:11 and trackID 6
Next Mother for this track has PDGID:22 and trackID 3

TID==0
EveIDE = 0 energy 0.534046
%MSG-w BackTracker: Nyarlathotep:Nyarlathotep 11-Jan-2017 11:32:11 CST run: 20000047 subRun: 0 event: 34
can't find particle with track id 0 in sim::ParticleList returning null pointer
%MSG
%MSG-w BackTracker: Nyarlathotep:Nyarlathotep 11-Jan-2017 11:32:11 CST run: 20000047 subRun: 0 event: 34
can't find particle with track id 0 in sim::ParticleList returning null pointer

#10 Updated by Erin Conley over 3 years ago

I have also encountered this bug while using BackTracker.

Geometry: 1x2x6
Generator: dunefd_1x2x6_supernova
LG4: dunefd_largeant

#11 Updated by Steven Gardiner over 3 years ago

In nutools v2_09_00, the sim::ParticleHistory class uses the creator process name string to determine whether a particle is a primary or not. Specifically, the creator process name must contain "rimary" or the sim::ParticleList will fail to identify the simb::MCParticle as a primary. The function that uses this technique is sim::ParticleList::insert(simb::MCParticle* particle) which is implemented in nutools/ParticleNavigation/ParticleList.cxx:

void sim::ParticleList::insert ( simb::MCParticle * value )
{
  int trackID = key(particle);
  iterator insertion = m_particleList.lower_bound( trackID );
  if ( insertion == m_particleList.end() ){
    // The best "hint" we can give is that the particle will go at
    // the end of the list.
    m_particleList.insert( insertion, value_type( trackID, particle ) );
  }
  else if ( (*insertion).first == trackID ){
    throw cet::exception("ParticleList") << "sim::ParticleList::insert - ERROR - " 
                                 << "track ID=" << trackID
                                 << " is already in the list\n";
  }
  else{
    // It turns out that the best hint we can give is one more
    // than the result of lower_bound.
    m_particleList.insert( ++insertion, value_type( trackID, particle ) );
  }

  // If this is a primary particle, add it to the list.  use 
  // rimary as the process string to look for as the P may or may not
  // be capitalized
  if ( particle->Process().find("rimary") != std::string::npos )
    m_primaries.insert( trackID );
}

In LArSoft v06_19_00, the MarleyGen module sets the creator process name for the simb::MCParticle objects that it produces to "MARLEY". This doesn't appear to be the source of this bug, however. In larsim/LArG4/ParticleListAction.cxx, the particle list is loaded with new simb::MCParticles that are distinct from those that appear in the simb::MCTruth objects:

// Create our initial simb::MCParticle object and add it to the sim::ParticleList.
void ParticleListAction::PreTrackingAction(const G4Track* track)
{
...
  std::string process_name = "unknown";

  // Is there an MCTruth object associated with this G4Track?  We
  // have to go up a "chain" of information to find out:
  const G4DynamicParticle* dynamicParticle = track->GetDynamicParticle();
  const G4PrimaryParticle* primaryParticle = dynamicParticle->GetPrimaryParticle();
  if ( primaryParticle != 0 ){
    const G4VUserPrimaryParticleInformation* gppi = primaryParticle->GetUserInformation();
    const g4b::PrimaryParticleInformation* ppi = dynamic_cast<const g4b::PrimaryParticleInformation*>(gppi);
    if ( ppi != 0 ){
      // If we've made it this far, a PrimaryParticleInformation
      // object exists and we are using a primary particle, set the
      // process name accordingly
      process_name = "primary";

      // primary particles should have parentID = 0, even if there
      // are multiple MCTruths for this event
      parentID = 0;
    } // end else no primary particle information
  } // Is there a G4PrimaryParticle?
...
  fCurrentParticle.particle = new simb::MCParticle( trackID, pdgCode, process_name, parentID, mass);
...
  // Save the particle in the ParticleList.
  fparticleList->Add( fCurrentParticle.particle );
}

Note that, when the track corresponds to a G4PrimaryParticle, the process name for the new simb::MCParticle in the particle list will be set to "primary" regardless of what is used in the simb::MCTruth object. Thus, the primary particles added to the particle list should be correctly identified, even if the generator module created primaries with a process name that does not contain "rimary".

#12 Updated by Steven Gardiner over 3 years ago

Useful breakpoints for watching the failure to identify the primary particle correctly:

nutools/ParticleNavigation/EveIdCalculator.cxx line 49
nutools/ParticleNavigation/EmEveIdCalculator.cxx line 43
nutools/ParticleNavigation/ParticleList.cxx line 402

#13 Updated by Jason Stock over 3 years ago

Failure only happens if more than 1 event is run.

#14 Updated by Steven Gardiner over 3 years ago

  • Related to Bug #15123: sim::ParticleList::clear() does not clear the set of primary particles added

#15 Updated by Jason Stock over 3 years ago

  • Status changed from Assigned to Resolved

Shifted to nutools issue #15123

#16 Updated by Jason Stock over 3 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF