Project

General

Profile

Bug #15702

order of list the generators issue with PhotonBackTracker

Added by Aaron Higuera Pichardo over 2 years ago. Updated over 2 years ago.

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

0%

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

Description

Hi,

I'm generating Ar39 and proton decay using two generators as

generator2: @local::standard_ndk
generator: @local::dunefd_1x2x6_ar39

I have ran all stages from gen to reco without any problem using v06_24_00, however when I’m looking at recob::OpHit, all recob::OpHit come from the electron (beta decay of 39Ar), there wasn’t any OpHit generated by the kaon neither by the muon from the kaon decay or positron from the muon decay. In order to identify the particle that generated the OpHit I'm doing the following
      art::ServiceHandle<cheat::PhotonBackTracker> Photon_bt;
      std::vector<sim::TrackSDP> trkSDPs = Photon_bt->OpHitToEveSDPs(op_hit);
      if( trkSDPs.size() != 0 ){  
         for(const sim::TrackSDP trkSDP : trkSDPs){
            if( trkSDP.trackID != 0){//Why ??
              const simb::MCParticle* particle = Photon_bt->TrackIDToParticle(trkSDP.trackID); 
              cout<<particle->PdgCode()<<" "<<particle->TrackId()<<" "<<particle->Mother()<<endl; 
              ...
            }
          }
      }

You can find an example file at /dune/data/users/higuera/Ar39andNDK_wBUG/

However if I switch the order for the generators as

generator: @local::standard_ndk
generator2: @local::dunefd_1x2x6_ar39

and do exactly the same, I can see OpHits that are generated by electron (Ar39 betas), kaon, muon and positron.
you can find a produced files at /pnfs/dune/scratch/users/higuera/v06_24_00/

Thanks
Aaron Higuera

History

#1 Updated by Gianluca Petrillo over 2 years ago

  • Description updated (diff)

(edited format of the original request)

#2 Updated by Gianluca Petrillo over 2 years ago

Note that the producers section of the configuration that you quote does not define the execution order. The trigger_paths content does.
I assume you are switching also the two in the list of producers (something like simulation: [ rnd, generator, generator2 ], with trigger_paths: [ simulation ], all in physics table).
If that's not so, please remark it, since the issue is then different.

#3 Updated by Gianluca Petrillo over 2 years ago

  • Occurs In v06_24_00 added
  • Occurs In deleted (with_root6)

#4 Updated by Gianluca Petrillo over 2 years ago

  • Status changed from New to Assigned

#5 Updated by Jason Stock over 2 years ago

I took a look at the "track 0" issue (mentioned but not directly the subject of the bug), and think it may need a bug report for NuTools. I have found an example of it happening and tracked it down to ParticleHistory coming up empty. The fact that we can get a particle from the trackID itself, but that when we try to get the history of the particle we get an empty list does not make sense to me.

#6 Updated by Jason Stock over 2 years ago

The issue happens when the order the generators are run in is switched. I am inclined to believe that either one of the generators does not properly apply a trackID offset, or LArG4 does not properly apply a trackID offset when the SDPs are added to OpDetBacktrackerRecords. For now I am focusing on the latter. If this is indeed the case, I should be able to test it with a simple G4 Simulation of two Singles Gun generators.

#7 Updated by Jason Stock over 2 years ago

I think the issue may be in LArG4's implimentation of the OpDetBackTrackerRecord. The G4Track IDs written do not seem to include the offset for tracks from subsequent generators, as observed from the information recorded. This is from a dump from a simulation of one muon and one gamma each from a separate instance of the singles gun.

G4Track ID: 1 and Step ID: 0x9631830
Doing a dump of this Particle.
--- G4ParticleDefinition ---
 Particle Name : gamma
 PDG particle code : 22 [PDG anti-particle code: 22]
 Mass [GeV/c2] : 0     Width : 0
 Lifetime [nsec] : 0
 Charge [e]: 0
 Spin : 2/2
 Parity : -1
 Charge conjugation : -1
 Isospin : (I,Iz): (0/2 , 0/2 )
 GParity : 0
 Quark contents     (d,u,s,c,b,t) : 0, 0, 0, 0, 0, 0
 AntiQuark contents               : 0, 0, 0, 0, 0, 0
 Lepton number : 0 Baryon number : 0
 Particle type : gamma [photon]
 Stable : stable

G4Track ID: 1 and Step ID: 0x999ed60
Doing a dump of this Particle.
--- G4ParticleDefinition ---
 Particle Name : mu-
 PDG particle code : 13 [PDG anti-particle code: -13]
 Mass [GeV/c2] : 0.105658     Width : 2.99598e-19
 Lifetime [nsec] : 2196.98
 Charge [e]: -1
 Spin : 1/2
 Parity : 0
 Charge conjugation : 0
 Isospin : (I,Iz): (0/2 , 0/2 )
 GParity : 0
 MagneticMoment [MeV/T] : -2.80272e-13
 Quark contents     (d,u,s,c,b,t) : 0, 0, 0, 0, 0, 0
 AntiQuark contents               : 0, 0, 0, 0, 0, 0
 Lepton number : 1 Baryon number : 0
 Particle type : lepton [mu]
G4DecayTable:  mu-
0:  BR:  1  [Muon Decay]   :   e- anti_nu_e nu_mu

I am looking at OpFastScintillation to see if I can address the problem.

#8 Updated by Jason Stock over 2 years ago

I have a fix. The OpDetBackTrackerRecords were constructed using the G4Track ID as reported by the track depositing energy as opposed to using the ParticleListAction. This resulted in tracks not getting the correct offset, and reporting incorrect TrackIDs when compared to the stored values. I am getting a clean copy of LArSim to commit the changes now.

#9 Updated by Jason Stock over 2 years ago

This should be fixed with commit:
larsim:c04aa592a1c710c60a23d522b6fef718a3e9bc25

OpFastScintillation now uses ParticleListAction to calculate TrackIDs when making OpDetBackTrackerRecords during LArG4.

#10 Updated by Jason Stock over 2 years ago

  • Status changed from Assigned to Resolved

As mentioned previously, this issue was patched out, and no new problems associated with it have come up. I am marking it as resolved now. I will change this to closed after the fix is merged into the next official release.

#11 Updated by Jason Stock over 2 years ago

  • Status changed from Resolved to Closed

Marking this issue as closed as the fix is successfully merged for several weeks.



Also available in: Atom PDF