Potential Issue in G4CompetitiveFission::GetEmissionProbability: Incorrect Excitation Energy Leading to Zero Fission Probability

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.3.0
Operating System:Windows 11 23H2
Compiler/Version:Visual Studio 2022 with X64_release MSVC v143
CMake Version: 3.x


Dear Geant4 Developers,

I am porting a fission model based on the G4CompetitiveFission framework to Geant4 version 11.3, and I have encountered a suspicious behavior in the calculation of the excitation energy used for fission probability estimation.

Specifically, in G4CompetitiveFission::GetEmissionProbability(G4Fragment* fragment), the excitation energy for fission (exEnergy) is computed as:
G4double exEnergy = fragment->GetExcitationEnergy() -
pairingCorrection->GetFissionPairingCorrection(A, Z);
To investigate, I inserted debug output (see modified snippet below):
G4double Ea = fragment->GetExcitationEnergy();
G4double Eb = pairingCorrection->GetFissionPairingCorrection(A, Z);
G4double ExEnergy = Ea - Eb;
G4cerr << "ExEnergy: " << ExEnergy << “\t” << “Ea=” << Ea << “\t” << “Eb=” << Eb << G4endl;

fissionBarrier = theFissionBarrierPtr->FissionBarrier(A, Z, ExEnergy);
G4cerr << "fissionBarrier: " << fissionBarrier << G4endl;
Using a simple test case: thermal neutrons (0.0253 eV) incident on a 1-mm-thick uranium-235 target, I observed the following output for a fragment satisfying A ≥ 65 and Z > 16:
ExEnergy: 4.9832 Ea=6.54547 Eb=1.56227
fissionBarrier: 5.01935
Consequently,
maxKineticEnergy = exEnergy - fissionBarrier ≈ 4.9832 − 5.01935 = −0.03615 < 0,
leading to fissionProbability = 0, and no fission fragments are produced.

This raises a concern:
Is this negative (or insufficient) excitation energy after pairing correction expected behavior, or could there be an inconsistency in the definition/usage of excitation energy in G4CompetitiveFission? For instance:

  • Should the total excitation energy (including neutron binding, etc.) be used before pairing correction is subtracted for barrier evaluation?

  • Or is the pairing correction sign/convention inconsistent with the barrier calculation?

I understand the physics rationale for subtracting the pairing correction to estimate the deformation energy available for fission, but in this case—especially for low-excitation systems like thermal-neutron-induced fission—it appears to over-correct, suppressing fission entirely in some valid configurations.

Could you please clarify whether this is intended behavior, or if it indicates a bug in the excitation energy handling within G4CompetitiveFission?

Thank you for your time and support.

Best regards

Hi @Liyinong_His

Thank you for your report.

Could you please indicate the version of Geant4 that you were using originally and that seemed to work fine?

In addition, did you notice if other parameters that may be used to calculate the fission barrier also changed between the versions of Geant4 that you are using (maybe the atomic mass; maybe the data libraries are different) ?

Thank you for your time.

Best,

Alvaro

Dear Alvaro,

Thank you for your prompt response.

I encountered this issue while porting the ParaFission model from Geant4 9.5 to Geant4 11.3. In Geant4 9.5, this problem did not appear—the fission probability behaved as expected, and fission fragments were generated normally.

Regarding nuclear data: I used the ENDF/B-VIII.0 high-precision neutron data library, downloaded from https://www-nds.iaea.org/geant4/, as the NeutronHP dataset.

In my setup, I explicitly defined the fission model and its corresponding cross-section data as follows, and reconstructed the hadronic physics (following the structure of FTFP_BERT_HP) to integrate it consistently:

void MyNeutronPHPBuilder::Build(G4NeutronFissionProcess* aP)

{

if (Myfission == 0) Myfission = new MyParaFissionModel;

Myfission->SetMinEnergy(theMin);

Myfission->SetMaxEnergy(theMax);

if (theHPFissionData == 0) theHPFissionData = new G4ParticleHPFissionData;

aP->AddDataSet(theHPFissionData);

aP->RegisterMe(Myfission);

}

Please let me know if further details (e.g., full physics list, macro, or model implementation) would be helpful for investigation.

Best regards

Dear @Liyinong_His

Could you please confirm if the values of excitation energy and fission barrier that you found for U235 in the latest version of Geant4 actually correspond to those of U238? [1]

If so, could you please confirm if in older datasets these values are correct?

This test will discard a possible mistake in the datasets, and potentially point to a problem in the code.

Thank you for your time.

Best,

Alvaro

[1] I found these values in a quick search, but there must be more official sources of numbers,

Dear Alvaro,

After extensive analysis and testing, I can now provide a comprehensive explanation of the issue we’ve been discussing regarding the failure to produce fission fragments in thermal neutron-induced fission of U-235. My investigation has revealed a fundamental problem in the physics implementation that affects the theoretical fission model in Geant4.

Core Physics Issue

The root cause lies in the implementation of G4CompetitiveFission::GetEmissionProbability, specifically in how it handles the pairing correction when calculating the excitation energy available for fission:
G4double exEnergy = fragment->GetExcitationEnergy() -
pairingCorrection->GetFissionPairingCorrection(A, Z);

This calculation effectively computes:

  • U-236 excitation energy (6.545 MeV) minus pairing correction (1.562 MeV) = 4.983 MeV

Later, this reduced energy is compared to the fission barrier:
fissionBarrier = theFissionBarrierPtr->FissionBarrier(A, Z, exEnergy);
maxKineticEnergy = exEnergy - fissionBarrier;

With the computed values:

  • fissionBarrier = 5.019 MeV

  • maxKineticEnergy = 4.983 - 5.019 = -0.036 MeV (negative!)

Since maxKineticEnergy is negative, the subsequent call to EmissionProbability() returns zero fission probability, preventing any fission fragments from being produced.

The Double Subtraction Error

The implementation contains a critical flaw: the pairing correction is being applied twice in the calculation. Examining the code reveals that the pairing correction term is first explicitly subtracted from the excitation energy in G4CompetitiveFission::GetEmissionProbability, and then the same correction is already incorporated in the fission barrier calculation within G4FissionBarrier::BarashenkovFissionBarrier:
G4double res = 0.0;
SPtr->GetPairingCorrection(N,Z,res);
static const G4double D = 1.248CLHEP::MeV;
return BF0 + Dd - res;

The term -res in the barrier calculation already accounts for the pairing effects. By also subtracting the pairing correction from the excitation energy before comparing it to the barrier, we effectively double-count this correction, artificially reducing the available energy for fission.

This double subtraction creates a physically incorrect scenario where the excitation energy of U-236 (6.545 MeV) is reduced to 4.983 MeV, which then falls below the calculated fission barrier (5.019 MeV), resulting in zero fission probability.

Conflict with Established Nuclear Physics

This implementation directly contradicts well-established nuclear physics. As stated in Gönnenwein’s authoritative text on neutron-induced fission:

“One of the reasons for the huge σf is the large neutron separation energy Sn = 6.5 MeV in 236U which exceeds the fission barrier Bf = 5.6 MeV. For thermal neutrons the excitation energy E* of the compound is E* = Sn > Bf. The isotope 235U is said to be ‘fissile’.”

This is a fundamental principle: U-235 is fissile precisely because the excitation energy of the compound nucleus (6.5 MeV) exceeds the fission barrier (5.6 MeV). The current Geant4 implementation, by artificially reducing the excitation energy through double subtraction of the pairing correction, incorrectly concludes that fission cannot occur with thermal neutrons.

Historical Context and Architectural Evolution

From examining the change logs and code history, I can see that the fission model has undergone significant evolution from Geant4 9.5 to the current 11.4 version. Particularly relevant are the changes from March 2017 and March 2012:
17 March 2017 Vladimir Ivanchenko (hadr-deex-V10-03-22)

  • G4VEmissionProbability - added private method for general treatment
    of PDF functions
  • G4EvaporationProbability, G4CompetitiveFission, G4CompetitiveFission,
    G4GEMProbability - changes are implemented according to base class
    modifications

07 March 2012 Vladimir Ivanchenko (hadr-deex-V09-05-03)

  • G4PhotonEvaporation, G4CompetitiveFission, G4EvaporationChannel,
    G4UnstableFragmentBreakUp, G4GEMChannel, G4VEvaporationChannel,
    G4Evaporation
    removed Initialise method and use GetEmissionProbability method
    directly - minor performance improvement

These changes restructured how the fission probability is calculated and used within the de-excitation framework.

High-Precision Neutron Models and Bypassing the Issue

An important aspect to note is that when using the High-Precision (HP) neutron models (G4NeutronHP/G4ParticleHP) with evaluated data libraries like ENDF/B-VIII.0, the problematic theoretical calculation is often bypassed entirely. In these cases, fission fragment production is determined directly from experimental data rather than the theoretical model.

This explains why many users might not have encountered this issue before - the high-precision neutron packages provide an alternative pathway that circumvents the flawed physics calculation. However, this workaround is not available when:

  1. Using the standard physics lists without HP extensions

  2. Simulating isotopes not covered by evaluated data libraries

Working at energies beyond the range of existing evaluated libraries

Evidence from Simulation Output

My test simulations consistently show this problematic behavior:

ExEnergy: 4.9832 Epara=1.56227 Eex=6.54547 FissionBarrier=5.01935
In rare statistical fluctuations where the neutron energy is slightly higher, we see proper fission behavior:
ExEnergy: 7.96195 Epara=1.56227 Eex=9.52421 FissionBarrier=4.89883
This demonstrates that when the excitation energy is sufficiently high to overcome the artificially elevated barrier, fission does occur as expected.

Suggested Solution

The correct approach would be to use the full excitation energy when comparing to the fission barrier, as the pairing effects are already incorporated in the barrier calculation:
G4double exEnergy = fragment->GetExcitationEnergy(); // Without subtracting pairing correction
This would restore the proper physics where U-236’s excitation energy (6.545 MeV) exceeds the barrier (approximately 5.0 MeV), yielding a positive maxKineticEnergy and non-zero fission probability.

Testing Methodology

To validate this fix, I recommend testing with a simple setup:

  • Pure U-235 target (100% enrichment)

  • Thermal neutrons (0.0253 eV)

  • No HP physics processes enabled (to force use of the theoretical model)

  • Track fission fragment production

Before the fix, no fission fragments should be produced. After the fix, fission fragments should be generated with yields consistent with the known thermal neutron fission cross-section of U-235 (approximately 585 barns).

Conclusion

The current implementation of G4CompetitiveFission incorrectly calculates fission probabilities for thermal neutron-induced fission by double-counting the pairing correction effect. This is a fundamental physics error that affects the core functionality of Geant4 for nuclear applications. While high-precision neutron data can mask this issue in specific configurations, the underlying physics model remains flawed and should be corrected to maintain scientific integrity and ensure proper behavior across all use cases.

Thank you for your attention to this critical physics issue.

Best regards,
Liyinong

I am not a professional in conducting theoretical analysis of nuclear fission. If there are any errors in my above analysis, please forgive me.