Groupvel Kludge Unintended Consequences

See ggv-pmt-test-notes.

Following the g4gun generalizations viz shows very different behaviour. Very slow moving photons...

• switching back to old PhysicsList shows same mis-behaviour

• pmt_test.py indicate material/flag sequence histories are matching... points to problem with time

• running with –steppingdbg shows the photons are moving very slowly taking 200ns to get to the PMT. What was that groupvel kludge ?

• pmt_test_distrib.py shows problem is with G4 times, looks like always getting smth close to -10 for other than 1st:

  ===================================== ===== ===== ===== ======== ===== ===== ===== =====
  4/PmtInBox/torch : 107598/107251  :   X     Y     Z     T        A     B     C     R
  ===================================== ===== ===== ===== ======== ===== ===== ===== =====
  [TO] BT SD                             0.91  0.73  0.56  0.56     0.98  1.09  0.56  0.94
  TO [BT] SD                             0.91  0.73  0.81 11936.06  0.98  1.09  0.56  0.94
  TO BT [SD]                             1.00  0.83  0.97 9341.26   0.98  1.09  0.56  0.93
  ===================================== ===== ===== ===== ======== ===== ===== ===== =====

(lldb) b "G4OpBoundaryProcess::PostStepDoIt(G4Track const&, G4Step const&)"

(lldb) b 537
Breakpoint 2: where = libG4processes.dylib`G4OpBoundaryProcess::PostStepDoIt(G4Track const&, G4Step const&) + 8675 at G4OpBoundaryProcess.cc:537, address = 0x00000001042b7123
(lldb) c
   ...
   534             G4MaterialPropertyVector* groupvel =
   535             Material2->GetMaterialPropertiesTable()->GetProperty("GROUPVEL");
   536             G4double finalVelocity = groupvel->Value(thePhotonMomentum);
-> 537             aParticleChange.ProposeVelocity(finalVelocity);
   538          }
   539
(lldb) p finalVelocity
(G4double) $0 = 0.99930819333333331

## huh : speed of light should be ~300 mm/ns

(lldb) p groupvel
(G4MaterialPropertyVector *) $1 = 0x00000001091d3bc0
(lldb) p *groupvel
(G4MaterialPropertyVector) $2 = {
  G4PhysicsVector = {
    type = T_G4PhysicsOrderedFreeVector
    edgeMin = 0.0000015120022870975581
    edgeMax = 0.000020664031256999959
    numberOfNodes = 39
    dataVector = size=39 {
      [0] = 0.99930819333333331
      [1] = 0.99930819333333331
      [2] = 0.99930819333333331
      [3] = 0.99930819333333331
      [4] = 0.99930819333333331
      [5] = 0.99930819333333331
      [6] = 0.99930819333333331
      [7] = 0.99930819333333331
      [8] = 0.99930819333333331

Disabling the groupvel kludge via testconfig leads to G4ParticleChange not OK for velocity and loadsa output. This suggests RINDEX is messed up ?

• the disabling failed to do so, as the former kludged GROUPVEL was living as ggeo “groupvel” properties in the geocache and got sprung into G4 materials by CPropLib
• also somehow (maybe related to no-name extra props) RINDEX was stomped on and got crazy low GROUPVEL of 0.999308193333

Check the GROUPVEL calc:

(lldb) b "G4Track::CalculateVelocityForOpticalPhoton() const"