Bug Report: Energy Deposition Discrepancy Between G4beamline 3.06 and 3.08

[M lng]

Dear Muons Inc. Support Team,

I am writing to report a significant simulation discrepancy I have observed between G4beamline versions 3.06 and 3.08. I hope this detailed report will assist your development team in identifying and resolving the issue.

Problem Summary: When running identical input files, version 3.06 correctly simulates complete energy deposition of a heavy ion beam (Uranium-238 with 17 MeV/u) in copper detectors at approximately z=70 mm, which matches theoretical expectations. However, version 3.08 shows the beam completely penetrating all detectors with virtually no energy loss, contradicting both theoretical predictions and the previous version's results.

Simulation Setup:

• Physics List: QGSP_BIC (also tested with QGSP_BERT)
• Beam: Uranium-238 ions, 17 MeV/u kinetic energy
• Detector Array: 200 copper detectors (D1) placed sequentially with 0.001 mm spacing
• Energy: ~4 GeV total kinetic energy
• Statistics: 1000 events

Key Observations:

1. Version 3.06: Correct energy deposition profile showing complete stopping at z≈70 mm
2. Version 3.08: Beam penetrates entire 200-detector array with minimal energy loss
3. NTuple Analysis: Version 3.08 shows abrupt drop in particle counts after z=73 (from 992 to 91 entries), suggesting particles are being lost rather than depositing energy
4. Impact: This discrepancy significantly affects the reliability of heavy ion transport simulations, particularly for applications requiring accurate energy deposition calculations such as detector design, radiation shielding, and medical physics applications.

   Request:

   1. Could you please verify if this is a known issue in version 3.08?
   2. Are there any recommended workarounds or parameter adjustments?
   3. Is there a timeline for a fix in upcoming releases?

   Additional Information:

   • Operating System: win11
   • Geant4 Version: same 11.0.2

   I would be happy to provide additional simulation data, input files, or assist with testing potential solutions. Thank you for your attention to this matter, and I look forward to your response.

   Best regards,

   Ning Li 2026/1/12

   Attached is the original code.

   #物理列表
   physics QGSP_BIC
   #minRangeCut=1
   param minStep=0.0001
   
   
   #束流
   #~~~~能量转动量~~~~~~~~~~~~~~~~~~~~~~~~~~~
   param beamloss=1000922380
   param -unset nucleaP=92 nucleaZ=238 KEu=17
   param KE=$KEu*$nucleaZ
   #param MeV=MeV
   #param histoFile=$KEu$MeV$nucleaP$nucleaZ
   
   param Mp=938.272 Mn=939.565
   param nucleaN=$nucleaZ-$nucleaP
   param M=$Mp*$nucleaP+$Mn*$nucleaN
   param P=sqrt(($M+$KE)*($M+$KE)-$M*$M)
   #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   
   beam gaussian  nEvents=1000 particle=$beamloss z=-10 P=$P sigmaX=2.7 sigmaY=1.33
   
   detector D1 radius=20 length=0.001 color=0,1,1,0.1 material=Cu
   do n 1 200
   place D1 front=1 z=0+$n*0.001 rename=z$n
   enddo

[Eremey Valetov]

Hello Ning Li,

Try setting a global maxStep parameter and progressively reducing it. The default is 100 mm, which may be too coarse for your detector spacing. According to the G4beamline manual: "The maximum physics step permitted to be taken. Note this is a limit on the physics step; integrating the equations of motion will take multiple 'integration steps' within this. Can be overridden in each element."

If adjusting maxStep doesn't resolve the issue, you might systematically vary other geometric and physics parameters (e.g., detector length) to see whether any changes cause the anomaly to disappear. This could provide additional insight into the underlying problem.

Debugging directly with the G4beamline source code might also reveal where the particle tracking or energy deposition calculation diverges between versions.

Cheers,
Eremey

[M lng]

Dear Ereme,

Thank you for your previous suggestion regarding adjusting the maxStep parameter. I have followed your advice and conducted further systematic tests, but the issue persists. Below is a summary of my findings:

1. Adjusting the maxStep parameter:

   • In version 3.08, I progressively reduced maxStep from its default value to 0.001 mm. However, the particle penetration behavior remained unchanged—particles continued to pass through all 200 detectors.

   • When maxStep was further reduced to 0.0001 mm, no particles reached the detectors, which is inconsistent with expectations.

   • In contrast, version 3.06 correctly simulated energy deposition with the default maxStep value, with particles penetrating only up to the 73rd detector (consistent with the theoretical range of 73 μm).

2. Cross-version environment testing:

   • I installed both version 3.06 and 3.08 source codes on Ubuntu and ran simulations using g4blmpi 48 filename.g4bl. The results matched those observed on Windows 11.

3. Database cross-referencing:

   • To rule out potential discrepancies due to database differences, I conducted a systematic test using both the default and swapped database configurations. The swap was implemented by renaming the database directories/files to make each version load the other's data:

     • First, each version was run with its own corresponding Geant4Data database.

     • Then, a cross-test was performed: by renaming the data directories, version 3.08 was forced to use the database from version 3.06, and vice versa.

     In all cases, version 3.08 consistently failed to simulate the correct energy deposition, while version 3.06 performed as expected across both configurations. This indicates that the observed issue is unlikely to be caused by database discrepancies,

Based on these results, the issue appears unrelated to the maxStep parameter and may instead stem from underlying differences in particle tracking or energy deposition calculations between the two versions. I am prepared to conduct more in-depth debugging of the source codes for both versions. If you have any further insights or suggestions—such as other critical parameters or physical models that may have changed between versions—I would greatly appreciate your input.

Please let me know if you need me to provide test scripts, detailed output logs, or specific code snippets for further analysis. I look forward to your reply.

Best regards,
Ning Li