Project

General

Profile

Bug #24924

0 MeV photons on LegacyOpFastScintillation

Added by Iker de Icaza Astiz about 2 months ago. Updated about 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
09/08/2020
Due date:
% Done:

100%

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

Description

I'm running version v09_01_00 on sbndcode and getting some error messages where there are photons with null energy:

%MSG-e OpDetBacktrackerRecord:  LArG4:largeant@BeginModule  08-Sep-2020 09:48:20 CDT run: 1 subRun: 0 event: 1 OpDetBacktrackerRecord.cxx:73
AddTrackPhotons() trying to add to iTimePDclock #821.548 1 photons with 0 MeV of energy from track ID=-1
%MSG

and sometimes with nan times:

%MSG-e OpDetBacktrackerRecord:  LArG4:largeant@BeginModule  08-Sep-2020 09:48:21 CDT run: 1 subRun: 0 event: 1 OpDetBacktrackerRecord.cxx:73
AddTrackPhotons() trying to add to iTimePDclock #-nan 1 photons with 0 MeV of energy from track ID=-1
%MSG

Tracking this issue for a bit it seems there's a problem with the aStep object where aStep.GetTotalEnergyDeposit()== 0 in all troublesome cases and aStep.GetStepLength()== 0 when time results in a nan.

This object gets reset at IonizationAndScintillation.cxx where certainly step->GetTotalEnergyDeposit() == 0.

History

#1 Updated by Iker de Icaza Astiz about 2 months ago

By the way it also occurs in v09_00_00, but it doesn't (or if it does is much less frequent) in v08_62_00.

#2 Updated by Kyle Knoepfel about 2 months ago

  • Status changed from New to Feedback

Iker, there were some important bug fixes that went into LArSoft v9_00_02, released last week. Can you test your code against that release and see if you still see a problem?

#3 Updated by Iker de Icaza Astiz about 2 months ago

We don't seem to have a v09_00_02, but it does occur in v09_01_00.

#4 Updated by Kyle Knoepfel about 2 months ago

Probably v09_00_01, not v09_01_00. Once you get v09_00_02, let me know if this is still a problem.

#5 Updated by Iker de Icaza Astiz about 2 months ago

sbndcode skipped v09_00_02 but we do have v09_01_00. It was on this last version that I noticed first the existence of this bug. Then checked on v09_00_00, where it also occurs.

I'm building larsim at ref #75134ceb4f1 "<LARSOFT_SUITE_v09_01_00> <v09_01_00> larsim v09_01_00 for larsoft v09_01_00"

It's fairly straightforward to reproduce:

setup sbndcode v09_01_00 -q e19:prof
lar -c prodsingle_mu_bnblike_newflux.fcl -n 1 -o gen.root
lar -c standard_g4_sbnd.fcl -s gen.root -o g4.root

then at this last one there will be a bunch of:

%MSG-e OpDetBacktrackerRecord:  LArG4:largeant@BeginModule  08-Sep-2020 12:47:15 CDT run: 1 subRun: 0 event: 1 OpDetBacktrackerRecord.cxx:73
AddTrackPhotons() trying to add to iTimePDclock #-nan 1 photons with 0 MeV of energy from track ID=-1
%MSG

#6 Updated by Kyle Knoepfel about 2 months ago

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

I apologize, Iker, for misunderstanding. I will take a look.

#7 Updated by Kyle Knoepfel about 2 months ago

Behavior confirmed. Investigating.

#8 Updated by Kyle Knoepfel about 2 months ago

Bringing Gianluca into this.

This problem is difficult to debug. What I have discovered so far:

  • Problematic cases appear to be whenever G4Step::GetTotalEnergyDeposit(), G4Step::GetStepLength(), and/or G4Step::GetDeltaTime() yield 0. I have activated the floating-point exception service which detects a divide-by-zero error in ParticleListAction::SteppingAction, where GetDeltaTime is zero. I do not yet understand the cause of this.
  • The relevant ISCalculation class is for this workflow is ISCalculationSeparate, which does have a reset function that sets its base-class data member fEnergyDeposit to zero. However, this only reacts to the actual value returned by G4Step::GetTotalEnergyDeposit, and does not appear to influence the G4Step object itself.

I would appreciate any guidance...I will keep debugging this afternoon.

#9 Updated by Kyle Knoepfel about 2 months ago

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

I've now committed the fix, which is available at https://github.com/LArSoft/larsim/pull/40 .

#10 Updated by Iker de Icaza Astiz about 2 months ago

Nice catch!

I've tested it and does solve the issue.

#11 Updated by Lynn Garren about 2 months ago

This fix is in the larsoft v09_02_00 release.

#12 Updated by Kyle Knoepfel about 2 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF