biasing particle change is not initialized properly

[tomeichlersmith]

Somehow, it has been lost to the sands of time that G4ParticleChangeForOccurenceBiasing is never
initialized properly. This means that its internal variables are just the default-constructed values.

Good News

This bug is not affecting the physics of these distributions at all.

The G4SteppingManager is what calls PostStepDoIt in InvokePSDIP and uses the returned G4VParticleChange pointer.
The function UpdateStepForPostStep is then called to copy any particle change into the steps and then
passed onto the track with G4Step::UpdateTrack. The secondaries are also retrieved using GetNumberOfSecondaries
and GetSecondary.

• The UpdateStepFor* calls within G4ParticleChangeForOccurenceBiasing are
  all passed down to the wrapped particle change while changing the weight value (if need be).
• The Secondary* calls are not passed down, but before they are used by the stepping manager, we use StealSecondaries
  to move the secondaries from the wrapped particle change into the biasing particle change.

Bad News

What this bug does do is break when G4ParticleChangeForOccurenceBiasing uses its internal member variables instead
of the wrapped G4VParticleChange. This occurs within CheckSecondary where we make sure produced secondaries
do not have negative energy or go backwards in time. We use the internal member variable theParentGlobalTime here
to make sure the secondary track passed as an argument has a later global time than the parent. theParentGlobalTime
is 0 when not initialized which is after any particles produced upstream of the target (since we time shift the
primaries to make global t=0 at the target).

We haven't noticed this before because

1. It only happens for processes that are biased
2. It only happens when these biased processes occur in tracks that have a negative global time (upstream of the target)

I noticed this now since I want to do dimuon production in a calibration target upstream of LDMX.
tomeichlersmith/ldmx-dimuon#5

Fix

Actually initialize the particle change if we are going to return it.

diff --git a/source/processes/biasing/generic/src/G4BiasingProcessInterface.cc b/source/processes/biasing/generic/src/G4BiasingProcessInterface.cc
index 270258fcf0..8ef5dd7541 100644
--- a/source/processes/biasing/generic/src/G4BiasingProcessInterface.cc
+++ b/source/processes/biasing/generic/src/G4BiasingProcessInterface.cc
@@ -490,6 +490,7 @@ G4VParticleChange* G4BiasingProcessInterface::PostStepDoIt(const G4Track& track,
                                                                  fFinalStateBiasingOperation, finalStateParticleChange );
 
 
+  fOccurenceBiasingParticleChange->Initialize(track);
   fOccurenceBiasingParticleChange->SetOccurenceWeightForInteraction( weightForInteraction );
   fOccurenceBiasingParticleChange->SetSecondaryWeightByProcess( true );
   fOccurenceBiasingParticleChange->SetWrappedParticleChange( finalStateParticleChange );

One funky thing is that I don't know how the debugFlag within any of the G4VParticleChange is set to true (which is the only way CheckSecondary is ever called within AddSecondary). This is checked in more detail in tomeichlersmith/ldmx-dimuon#5 (comment) . I suspect some memory funkiness is happening in SetNumberOfSecondaries because I can watch the variable and see it get set from false to 2 in gdb.

Hardware watchpoint 3: ((G4GammaConversionToMuons * const) 0x55cdfa52b050)->aParticleChange.debugFlag

Old value = false
New value = 2
G4VParticleChange::SetNumberOfSecondaries (this=0x55cdfa52b0b0, totSecondaries=2) at /home/tom/code/ldmx/dimuon/geant4/source/track/include/G4VParticleChange.icc:274

[tomeichlersmith]

Well, I figured out how the debugFlag gets enabled. It looks like G4VERBOSE is defined by default

geant4/cmake/Modules/Geant4LibraryBuildOptions.cmake

Lines 180 to 191 in d61ba82

	# - G4VERBOSE
	# ON by default, switching off can improve performance, but at the cost
	# of fewer informational or warning messages. Mark as advanced because
	# most users should not need to worry about it.
	option(GEANT4_BUILD_VERBOSE_CODE
	"Enable verbose output from Geant4 code. Switch off for better performance at the cost of fewer informational messages or warnings"
	ON)
	mark_as_advanced(GEANT4_BUILD_VERBOSE_CODE)
	if(GEANT4_BUILD_VERBOSE_CODE)
	add_definitions(-DG4VERBOSE)
	endif()

I was just rg the wrong directories 😮‍💨

[tomeichlersmith]

Resolved by #14 and a part of the LDMX.10.2.3_v0.6 release.