Problem 13 - time goes back if refraction index changed
Summary: time goes back if refraction index changed
Status: RESOLVED FIXED
Alias: None
Product: Geant4
Classification: Unclassified
Component: processes/electromagnetic (show other problems)
Version: 0.0
Hardware: PC Linux
: P3 major
Assignee: gum
URL:
: 14 15 (view as problem list)
Depends on:
Blocks:
 
Reported: 1999-09-29 04:45 CEST by o35
Modified: 1999-10-27 19:24 CEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this problem.
Description o35 1999-09-29 04:45:59 CEST
In writing a km3 scale simulation for the antares detector I've tried to enter
some properties of water for optical photons other than the ones used in ExN06
(I did temporalily use the ones in ExN06 and they worked just fine). Changing
absorbtion length and energy of the photons in the tables PPCKOV[NUMENTRIES]
and  ABSORPTION1[NUMENTRIES] didn't give any problems (the changes were rather
small by the way). However when I changed the RINDEX1[NUMENTRIES] from

 G4double RINDEX1[NUMENTRIES] =
 { 1.33, 1.33, 1.33, 1.33, 1.33, 1.33, 1.33,
   1.33, 1.33, 1.34, 1.34, 1.34, 1.34, 1.34,
   1.34, 1.34, 1.34, 1.34, 1.34, 1.34, 1.34,
   1.34, 1.34, 1.35, 1.35, 1.35, 1.35, 1.35,
   1.35, 1.35, 1.35, 1.35 };

to

  G4double RINDEX1[NUMENTRIES] =
  { 1.3435, 1.344,  1.3445, 1.345,  1.3455,
  1.346,  1.3465, 1.347,  1.3475, 1.348,
  1.3485, 1.3492, 1.35,   1.3505, 1.351,
  1.3518, 1.3522, 1.3530, 1.3535, 1.354,
  1.3545, 1.355,  1.3555, 1.356,  1.3568,
  1.3572, 1.358,  1.3585, 1.359,  1.3595,
  1.36,   1.3608};

and ran a high energy muon (10 GeV) through my km3 scale detector consisting out
of pure H2O and within that the Optical Modules (placed according to the 1999
proposal) which also consisted out of pure H2O I got the following error:


> !!! the global time goes back  !!! :  48.6022 -> -1.79432e+07[ns]
>  !!! the poper time goes back  !!! :  0.00460323 -> -1.21661e+07[ns]
>  G4ParticleChange::CheckIt
>  pointer : 0x8667550
>       -----------------------------------------------
>         G4ParticleChange Information
>       -----------------------------------------------
>         # of 2ndaries       :                    0
>       -----------------------------------------------
>         Energy Deposit (MeV):                    0
>         Track Status        :                Alive
>         True Path Length (mm) :                -35.3
>         Stepping Control     :                    0
>         Event Biasing        :  not used
>         Position - x (mm)   :             -4.9e+08
>         Position - y (mm)   :            -3.61e+09
>         Position - z (mm)   :             1.54e+09
>         Time (ns)           :            -1.79e+07
>         Proper Time (ns)    :            -1.22e+07
>         Momentum Direct - x :                0.124
>         Momentum Direct - y :                0.912
>         Momentum Direct - z :                -0.39
>         Kinetic Energy (MeV):                0.243
>         Polarization - x    :                    0
>         Polarization - y    :                    0
>         Polarization - z    :                    0
>         Touchable (pointer) : 0x86689e8
> G4ParticleChange::CheckIt
>
> *** G4Exception: Aborting execution ***
>

Please correct this problem. I can't get my simulation working properly without
the actual values for the refraction index.

Thanks,
Robbert Mirani
intern for the Antares Project for the NIKHEF
Comment 1 gum 1999-10-18 16:22:59 CEST
*** Bug 14 has been marked as a duplicate of this bug. ***
Comment 2 gum 1999-10-18 16:46:59 CEST
I changed the index of refraction in the ExampleN06
(ExN06DetectorConstruction.cc) to those used in the Antares Project for the
NIKHEF. I am running OS:  Linux with release: geant4.0.1; and tags
'geant4-00-01-ref-03' for everything but /global, where I use tag
'global-V00-01-01'. I have also compiled source/track and /example/novice/N06
with G4DEBUG and G4VERBOSE on, and G4OPTIMISE off.

ExampleN06 'Itworksforme' even with these changes.

Seems to me, there is a memory leak / overwrite happening somewhere (see also
problem report #15). To find it, the very application which produces this bug
needs to be debugged.
Comment 3 gum 1999-10-27 19:08:59 CEST
*** Bug 15 has been marked as a duplicate of this bug. ***
Comment 4 gum 1999-10-27 19:24:59 CEST
Turns out, when in G4Cerenkov.cc the method, GetContinuousStepLimit calls
GetAverageNumberOfPhotons the result can be (very small but)  negative. This is
possible because I use a finite constant in GetAverageNumberOfPhotons:

const G4double Rfact = 369.81/(eV * cm);

The next line in GetContinuousStepLimit then checks for

if(MeanNumPhotons == 0.0) return DBL_MAX;

G4double StepLimit = fMaxPhotons / MeanNumPhotons;

Now, when MeanNumPhotons is negative StepLimit becomes negative, and then
probably something in the transport goes haywire. This also  explains why a
change in index of refraction caused the problem. Itwould have happend anyway,
sooner or later, even with the old values. Of course, it's a very rare occasion,
when a step is very near to the Cerenkov threshold, that this bug happens.  The
numerical value for 'MeanNumPhotons' was -0.00004!

All that is needed is the change to:

if(MeanNumPhotons <= 0.0) return DBL_MAX;

The corrected version of G4Cerenkov.cc has been committed to the head of the
repository (in /source/processes/electromagnetic/xrays/src

This change was tested with Robbert Mirani's ANTARES application.

Regards, Peter Gumplinger