Possible bug in EmLivermore and optical photon generation

Physics Processes, Models and Cross Sections
1

Please fill out the following information to help in answering your question, and also see tips for posting code snippets. If you don’t provide this information it will take more time to help with your problem!

_Geant4 Version:_11.2.2
_Operating System:_macOS Sonoma 14.6
_Compiler/Version:_gcc 15.0.0
_CMake Version:_3.29.4

Dear experts,

I have been conducting some simulations of 1MeV electrons in a liquid scintillator (LAB) using Geant4 v11.2.2 and found some discrepancies when adding or not the optical processes while using the EmLivermore physics list.

I am only using the EmLivermore physics list to generate the electromagnetic processes as well as G4OpticalPhysics to generate the optical processes (Scintillation and Cerenkov). However, during the energy loss steps, the processes seems to change drastically when one add or not the optical processes.

Here is a few distributions that highlight the issue I am facing (10 000 electrons of 1 MeV).

NbStep_Livermore
NbStep_Livermore798×475 30.9 KB

I also noticed that most eIoni processes disappeared from the list of processes when the optics is added.
Most processes are now msc when we used to have only 1 msc without the optics.
I observed this feature using LIV, and EMZ (option 4) EM physics lists but default (option 0) and EMY (option 3) EM physics lists do not have this type of issues.

I was wondering if there were some potential conflict between, msc models and optical photon generation

You can see below an output of Geant4 for one event

No optics:

  • G4Track Information: Particle = e-, Track ID = 1, Parent ID = 0

Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName
0 0 0 0 0.612 0 0 0 pTarget initStep
1 0.000149 -0.000252 -0.000725 0.612 7.87e-05 0.000782 0.000782 pTarget msc
2 0.119 -0.206 -0.586 0.499 0.113 0.701 0.701 pTarget eIoni
3 0.199 -0.426 -1.03 0.369 0.129 0.563 1.26 pTarget eIoni
4 0.117 -0.343 -1.37 0.27 0.099 0.415 1.68 pTarget eIoni
5 0.32 -0.434 -1.51 0.206 0.0643 0.312 1.99 pTarget eIoni
6 0.508 -0.467 -1.45 0.153 0.0534 0.25 2.24 pTarget eIoni
7 0.519 -0.343 -1.37 0.0968 0.0557 0.199 2.44 pTarget eIoni
8 0.539 -0.31 -1.3 0.0158 0.081 0.137 2.58 pTarget eIoni
9 0.54 -0.311 -1.3 0 0.0158 0.00604 2.58 pTarget eIoni

With optics:

  • G4Track Information: Particle = e-, Track ID = 1, Parent ID = 0

Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName
0 0 0 0 0.612 0 0 0 pTarget initStep
1 0.000305 -0.000514 -0.00148 0.612 0.00017 0.0016 0.0016 pTarget msc
:----- List of 2ndaries - #SpawnInStep= 1(Rest= 0,Along= 0,Post= 1), #SpawnTotal= 1 ---------------
: 0.000116 -0.000196 -0.000564 2.78e-06 opticalphoton

  • G4Track Information: Particle = e-, Track ID = 1, Parent ID = 0

Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName
1 0.000305 -0.000514 -0.00148 0.612 0 0 0.0016 pTarget initStep
2 0.0413 -0.0857 -0.197 0.554 0.0575 0.217 0.219 pTarget msc
:----- List of 2ndaries - #SpawnInStep=566(Rest= 0,Along= 0,Post=566), #SpawnTotal=566 ———————

  • G4Track Information: Particle = e-, Track ID = 1, Parent ID = 0

Step# X(mm) Y(mm) Z(mm) KinE(MeV) dE(MeV) StepLeng TrackLeng NextVolume ProcName
2 0.0413 -0.0857 -0.197 0.554 0 0 0.219 pTarget initStep
3 0.0753 -0.168 -0.364 0.526 0.0287 0.189 0.408 pTarget msc
:----- List of 2ndaries - #SpawnInStep=271(Rest= 0,Along= 0,Post=271), #SpawnTotal=271 ———————

About 90 steps are similar to these ones (only msc processes).

Thank you in advance !

2

Here is the dE distribution

dE_Livermore
dE_Livermore798×475 30.9 KB

3

Dear @Matthieu_Lecocq

Welcome to Geant4 forum.

I guess that Optical processes may limit the step length, leading to more steps (first plot), and therefore smaller energy deposits (second plot). In case of Cherenkov effect, there is a parameter called setMaxBetaChange that limit the step explicitly. See documentation here.

Regarding the frequency of MSC, I am not sure if it derives from the step limit caused by the optical processes. @civanch @dsawkey can you confirm that MSC is not affected by optical physics?

Thank you for your time.

Best,
Alvaro

4

Dear All,

I have investigated this issue and I would like to add some information:

I found out that this behavior is due to the different msc model used in the Livermore and option4 physics lists: G4GoudsmitSaundersonMscModel vs G4UrbanMscModel

This is extracted from the source code of the model (lines 513 +):

 // Possible optimization : if the distance is samller than the safety -> the
 // particle will never leave this volume -> dispalcement
 // as the effect of multiple elastic scattering can be skipped
 // Important : this optimization can cause problems if one does scoring
 // in a bigger volume since MSC won't be done deep inside the volume when
 // distance < safety so don't use optimized-mode in such case.
if (gIsOptimizationOn && (distance<presafety)) {
     // Indicate that we need to do MSC after transportation and no dispalcement.
     fIsMultipleSacettring = true;
     fIsNoDisplace = true;
  } else if (steppingAlgorithm==fUseDistanceToBoundary) {
   ...
  } else if (steppingAlgorithm==fUseSafetyPlus) { // THE ERROR_FREE stepping alg.
   ...
  } else {
    // This is the default stepping algorithm: the fastest but the least
    // accurate that corresponds to fUseSafety in Urban model. Note, that GS
    // model can handle any short steps so we do not need the minimum limits
   ...
  }

I found out that:

  • When the optical physics is not registered (or the particle is tracked inside a volume with no optical properties) the “presafety” variable is equal to the distance of the particle from the boundary of the volume so, in the posted example, the condition is True and the first block of the IF is executed.
    In this case, msc does not limit the steps and the total number of steps is small.
  • When the optical physics is registered, the “presafety” variable is always 0 so, in the posted example, the condition is False and the “fUseSafetyPlus” code is executed, according to the default value of the steppingAlgorithm. In this case, msc limits the steps and the total number of steps is high.
  • If the optical physics is registered and the steppingAlgorithm is set to “fUseSafety” the last code of the if-else block is executed with the Urban-like model and again the msc does not limit the steps (like in the option 0 Em PL)

In conclusion, it seems that the activation of the optical physics modifies the computation of the presafety parameters.

Now, my question is: Why and how is this value affected by the activation of optical physics? Is that right?

I hope this can help find a motivation or solution to this behavior.

Best,
Andrea

5

Dear @atolosad

Thank you for your answer. Sorry for the delay, I was trying various things to understand this behaviour.
I tired playing with the parameter you mentioned (setMaxBetaChange) by setting different values (0%, 10%, 50%, 100%) but I see no changements on my distributions.
I also tried turning off the Cerenkov processes and leaving only Scintillation but it doesn’t have a big impact on my number of step. I only noticed a decrease of 0.5% in my step number when removing Cerenkov processes.

On average, the ratio of steps produced by msc (msc/tot_processes) is around 92% when the optical processes are activated and only 9% when there is no optics. The Cerenkov processes amount to around 3% when optics is enabled.

I don’t understand this sudden increase in step number and why the msc process is dominating when the optical processes are activated.

If you have any hints or other suggestions I’ll be happy to test them.

Thank you in advance !

Best,
Matthieu

6

Hi,

First note that neither step size, nor the process that limits the step, are physically meaningful. They are artifacts of the way the simulation works. If these change, but the physics result don’t, there may not be a problem.

Also note that msc and eIoni will be active every step. The process reported by /tracking/verbose is only the process that limits the step size. Every process that should be active, is active.

It is still a valid question to ask what is changing the step size or limiting process. If you run a few particles with /tracking/verbose 3 [I think; try different values] for each step, all the active processes, and the proposed step limit for each, will be printed out. This might give us a clue to what is going on.

Aside from step size, I don’t any mechanism for which enabling optical processes would affect msc.

Another question, do you observe the same behaviour with the example extended/optical/OpNovice2?

7

Dear @dsawkey,

Thank you for your comment !
I followed your suggestion and tried with extended/optical/OpNovice2 and I have something very different from my simulation. I find no differences with and without the optical processes enabled.

However I tried extend/optical/LXe, since it’s similar to my simulation of a scintillator, and I observed something similar when I simulate a 1MeV electron at the center:

  • Without optics on there is 1 msc process followed by 15 eIoni processes.
  • If I enable optics, I go from 16 steps to 24 steps and all step-limiting process become msc

I don’t understand how the number of steps changes and why the eIoni process doesn’t limit the step anymore but it’s now done by msc.

I think @Andrea made an interesting comment on how the msc parameters are handled in the different models, is there something to understand from this?

Best,
Matthieu

8

Interesting. OpNovice2 has scintillation as well (try macro electron.mac).

Could you please try

/tracking/verbose 3

which will give a list of all active processes, and each proposed step limit, for each step. Knowledge of the process that limits the step is only a partial picture.

I don’t know how or what could be affecting msc. Optics doesn’t explicitly modify the safety.

9

My previous test was using electron.mac.
With our without the optical process enabled the step is limited by msc. In the list of all active process I can see either msc, eIoni or eBrem but most of the steps are limited by msc.

I looked a bit in the source code and changed msc1 definition from G4GoudsmithSaundersonMscModel to G4UrbanMscModel in G4EmLivermorePhysics and I have now dE distributions that matches well

UrbandE
UrbandE798×475 68 KB

The list of process doesn’t change anymore when I enable the optical processes.

Is there something interfering with the process list in G4GoudsmithSaundersonMscModel and thus increasing the step when optical processes are enabled?

10

There are at least two points (1. and 2.) to clarify here that I try below without getting lost in details.

  1. Before them:
    As Daren(dsawkey) mentioned, the number of simulation steps is arbitrary. We can limit the simulation steps more/less frequently while the simulation results (e.g. energy deposit or interaction frequencies, etc.) stays the same. Multiple Coulomb scattering (MSC) models (like G4UrbanMscModel and G4GoudsmithSaundersonMscModel) often use their arbitrary step limit in order to ensure that the tracking is only as accurate as expected (not more but not less). The different tracking/stepping algorithm types of the MSC models (like Minimal, Safety, DistanceToBoundary, SafetyPlus) correspond to different required level of tracking accuracy (increasing in that order) and eventually implemented separately for the different MSC models and usually mean different algorithms.
    Therefore, switching to a different MSC model will very likely result in different number of simulation steps, as you can see when comparing using G4UrbanMscModel vs G4GoudsmithSaundersonMscModel in the Livermore or the option4 EM constructors, even if the MSC step limit type (and all other parameters) stay the same.
    In this particular case, this is because the G4GoudsmithSaundersonMscModel will ensure an accurate tracking of electrons across volume boundaries when the SafetyPlus stepping algorithm is used (which is the case when using it in the Livermore or option4 EM physics constructors) while G4UrbanMscModel is not.
    (The GS model achieves this by crossing the volume boundaries in single scattering mode, i.e. whenever the track is closer to a volume boundary than 1-3 times the elastic scattering mean free path, MSC will be single scattering. If you start tracking from or close to a boundary then you will have several such msc limited steps, i.e. single scattering steps, while the track moves further away from that boundary.)

  2. What is different when using or not using the optical physics? Well, the answer is the tracking. Without optical physics, the (primary) electron is kept tracking till its kinetic energy goes to zero or leaves the detector. In contrary, when optical physics is active,
    tracking of electrons might be suspended and resumed several times time: suspended in order to track the secondary optical particles before and resumed when those are done.
    Whenever the tracking of a particle is resumed, after being suspended, it’s a bit like a new start of tracking leading to the pre-step status of initStep that stands for initial step point. The important is that the value of the safety (i.e. distance to the closest volume boundary) is not computed neither set to anything else but zero.
    What happens in normal tracking, i.e. without optical physics, safety is zero only if the step-point is on a volume boundary or at the beginning of tracking, in the pre-step point of the very first step (because that’s the initStep). When the tracking is suspended and resumed, the safety is still zero when the step point is on a volume boundary but also zero anytime when the tracking is resumed.
    (This answers @Andrea’s question regarding why that pre-step point safety is zero more often with an active optical physics.)

  3. There is an optimisation in the G4GoudsmitSaundersonMscModel that @Andrea mentioned. That’s noting but checking if the closest volume boundary is further than the range of the electron (or similar) and MSC do not limit the step in that case. This is just because that electron will never go out of this volume so details of the tracking is usually just wasting time.
    Due to the zero pre-step point safety when resuming tracking (that I explained above), this is not active in the very first step whenever the tracking is resumed so MSC might limit the step in that case. The correct safety is calculated then at the end of this step so the optimisation would be active in the next step (if the track is deep inside compared to its range). However, if optical photons are generated in that step, then the electron track will be suspended again after this single step leading to a pattern like: a single, short electron step limited by msc, then suspended tracking of the electron while tracking of the optical photons generated during that short step, then resuming tracking of the electron but again a short msc limited step as the pre-step point safety is zero so no optimisation in the step when just resuming tracking.

1 Like
11

Dear Mihaly Novak,

Thank you very much for your very clear and complete explanation!
Indeed, if I make G4 track the optical photons after tracking the primary particle (SetTrackSecondariesFirst to false) the number of steps decreases.

I just wonder why the safety is “zero anytime when the tracking is resumed”. Why isn’t it just calculated as the distance to the boundary? This would avoid this kind of unxpected beahvior, since the particle is deep inside of the volume.

Morever, has this behavior been changed in the most recent releases of G4? Because older versions the behavior is not like this.

Thank you very much
Andrea