Question regarding the lambdaFactor in G4HadronicProcess

[MathieuBoissier]

Geant4 Version:11.4.2
Operating System:Ubuntu22.04

Hello everyone,

While simulating deuteron-induced reactions in thin targets to generate neutrons, I noticed a strange behavior in the neutron energy spectrum. After some investigation, I found that this behavior was related to the use of the integral method for cross-section calculations.

In particular, I noticed a difference in how the method is implemented on the electromagnetic and hadronic sides of Geant4, and I would like to better understand this difference.

In the electromagnetic case (G4VEmProcess / G4EmParameters), the lambdaFactor (ξ, default value 0.8) used to estimate the maximum cross section σₘ over a step is exposed as a configurable parameter. It has a setter/getter (SetLambdaFactor / LambdaFactor), a UI command (/process/eLoss/lambdaFactor VALUE), input validation (0 < ξ < 1), and the documentation recommends keeping ξ consistent with dRoverRange, i.e. ξ + dRoverRange = 1, with a warning not to exceed 1.

In G4HadronicProcess.cc, however, the equivalent factor is defined as:

namespace
{
  constexpr G4double lambdaFactor = 0.8;
  constexpr G4double invLambdaFactor = 1.0/lambdaFactor;
}

Since these constants have internal linkage and are constexpr, and as far as I can tell there is no corresponding setter in G4HadronicParameters, no UI command, and no runtime configurability. The only way to change the value would therefore be to modify the source code and recompile Geant4.

This becomes relevant when changing dRoverRange. For example, if dRoverRange is reduced from 0.2 to a smaller value while ξ remains fixed at 0.8, the relation ξ + dRoverRange = 1 is no longer satisfied. In practice, this means that the cross section is not updated as frequently as one might expect from the chosen dRoverRange, but only when the particle loses at least 20% of its initial kinetic energy.

My question is therefore: is this difference between the electromagnetic and hadronic implementations intentional ?

I understand that the hadronic version of the algorithm is more elaborate than the electromagnetic one. In particular, it handles the fHadOnePeak and fHadTwoPeaks cases, including multiple peaks/dips in the cross section via G4TwoPeaksHadXS. I can therefore imagine that exposing this factor as a freely configurable parameter could be more delicate on the hadronic side than in the simpler single-peak EM case.

However, I was wondering why there is no way to tune this parameter for hadronic processes, especially since the EM documentation explicitly recommends keeping ξ consistent with dRoverRange. I have not found an equivalent recommendation or safeguard for the hadronic implementation.

Is there a particular reason why this parameter was never linked to dRoverRange or exposed as a configurable parameter for hadronic processes ?

In my particular case, I was able to obtain satisfactory results by using a step limiter to force a sufficiently large number of steps in the target, and by disabling the use of the integral method. However, I would like to make sure that this is an appropriate approach, or whether I am misunderstanding how the hadronic implementation of the integral method is intended to work.

Thanks in advance for any insight !

Mathieu

[MathieuBoissier]

Just following up on my previous question, I am adding an illustration of the phenomenon I observed; perhaps this makes the effect clearer.

I compared the neutron spectra on a disk positioned at 0° with respect to the beam direction, with SetIntegralInelasticXS enabled and disabled. I forced the incident deuteron to take 100 steps through the 2 µm-thick target using a StepLimiter, as I want to reproduce the fine structure of the peak as accurately as possible.

My understanding is that the cross section is updated only when the incident particle has lost more than 20% of its energy since the previous update, leading to this stepped profile. However, this behavior does not appear to have a physical origin to me.

Any insight from someone familiar with the implementation of G4HadronicProcess would be greatly appreciated.

Thank you !

[civanch]

Dear Mathieu,

Both curves blue and green are nearly correct. To check correctness of the integral method it is needed to score final products. In the case of EM physics, it is needed to count number of delta-electrons, for hadronic physics - number of neutrons. When you apply the step limiter with small steps the integral method is not needed and even bring some CPU overhead. The test you perform really demonstrates how integral method is working, benefit from it is only when limiter is not used. Concerning EM tracking we reduce the 1st parameter of stepping function from 0.2 to 0.1 but not more. The main improvement come from the second parameter, the default 1 mm may be reduced to 0.001 mm to provide a detailed tracking at low energies.

VI

[MathieuBoissier]

Dear Vladimir,

Thank you very much for your answer, I think I understand better now.

If I understand correctly, the integral approach is useful when I allow relatively long steps, while keeping the first EM parameter (dRoverRange) close to 0.2. This would ensure that lambdaFactor and dRoverRange roughly satisfy the relation

lambdaFactor + dRoverRange ≈ 1

which is needed to accurately determine the maximum reachable cross-section value.

Therefore, forcing small steps at the beginning of the track would not be rigorously compatible with the integral approach (green curve), since dRoverRange would then be significantly smaller than 0.2 and the relation above would no longer be satisfied.

In that case, I should instead use a StepLimiter without the integral approach (blue curve), which would be both appropriate and faster.

So, if I understand this correctly, the relation lambdaFactor + dRoverRange ≈ 1 is indeed the relevant condition for the integral approach, and this is why keeping dRoverRange close to 0.2 is important when lambdaFactor = 0.8. Please let me know if I understand correctly or if I am still missing something.

Best regards,

Mathieu