Neutron Absorption in G4-AIR seems to high

Hello, I am very new to using Geant4 and encountered a problem I can’t wrap my hand around. In my setup, I shoot neutron with an energy of 5.5 MeV at a detector. The whole setup is located in a box with air and therefore I used the Geant4 Material G4_AIR. With this setup, the neutrons lose all their energy after about 1cm, which is not realistic.

To understand the problem I build “air” from the ground up with the exact material proportions as G4_AIR should be consist of. (I used https://geant4.web.cern.ch/sites/geant4.web.cern.ch/files/geant4/collaboration/working_groups/geometry/training/D1-Materials.pdf page 18 for that). My code for this looks like this:

With this material, the neutrons lose their energy after around 4.2 cm, which is the expected value. So I am a little bit confused about why this divergence occurs and I would like to understand it.

Yes it is definitely too high, but I do not think it is the material definition. There is no way that 5.5 MeV neutrons should lose all their energy in 4.2 cm or 1 cm of air. In fact, it should hardly lose any energy. Can you show a picture of your geometry? How are you measuring energy loss of the neutron?

I am so sorry! I meant alpha-particles the whole way. I do’t know why I wrote neutrons everywhere instead of alpha-particles. (But I think I can’t change the title anymore)
My setup is just a box filled with air and at some distance a detector (diamond) and the absorbed energy in the detector is measured. So when the alpha source is 4.2 cm away there should be no measured energy left.

  1. So you are measuring energy loss of the alpha as 5.5MeV minus the energy deposited in the detector?

  2. The two materials should give the same result for the range of the alpha and I agree that ~4.5cm is the correct value.

  3. Is there any material in front of the diamond detector?

  4. Have you tried changing the detector-source separation and incident alpha energy to see if the range and stopping power agrees with established values like those of SRIM?

  5. Have you changed anything else between the two material cases? In other words, if you took the code you have right now, commented out the material definition portion and replaced it with the other material then reran the code, would you get a different result?

  1. Yes exactly, I just look for the energy deposition in the detector as a quick way to look for the reason for this discrepancy.

  2. No there is no material. In both cases, the alpha particles are shoot through the air directly at the diamond

  3. For the mixture of air I have created the stopping power agrees.

  4. The code for using G4_AIR is:
    auto *defaultMaterial = nist->FindOrBuildMaterial(“G4_AIR”);

which results in this:

when I comment out this line and add my air mixture:
G4Element* elN = new G4Element(“Nitrogen”, “N”,7.,14.01g/mole);
G4Element
elO = new G4Element(“Oxygen”,“O”,8.,16.00g/mole);
G4Element
elC = new G4Element(“Carbon”,“C”,6.,12.011g/mole);
G4Element
elAr = new G4Element(“Argon”,“Ar”,18.,39.948g/mole);
G4Material
Air = new G4Material(“Air”, 1.20479mg/cm3, 4);
Air->AddElement(elN, 75.5268
perCent);
Air->AddElement(elO, 23.1781perCent);
Air->AddElement(elC, 0.0124
perCent);
Air->AddElement(elAr, 1.2827*perCent);

auto *defaultMaterial = nist->FindOrBuildMaterial(“Air”);

With this, only very small energy can be measured and the beam ends just before the diamond, and not as early as in the previous picture.

In both cases, the exact same particle beam is used, with a distance of exactly 43mm to the surface of the diamond.

Here the picture of the beam/ detector combination for “my” air material (as a new user I can just post one picture at a time)

To confirm your suspicions, here a macro for example TestEm0, its output and the result of nist-Astar calculation (AstarData.txt).
In short : CSDA range of alpha, 5.5 MeV, in air :
nist-Astar = 4.19 cm; TestEm0 (Air) = 2.06 cm; TestEm0 (G4_AIR) = 0.753 cm
These 3 values are mutually not compatible.
Such discrepancies did not happen with older versions of Geant4 : TestEm0 (Air) = TestEm0 (G4_AIR) = 3.93 cm.
Something goes wrong in Geant4 ? …
julian.mac.txt (309 Bytes)
julian.out.txt (5.8 KB)
AstarData.txt (279 Bytes)

Just to add to the confusion, I ran TestEm0 using Geant4 10.7.2. I ran it “as is” with julian.mac as input and then modified to make the material Air match the density and composition of G4_AIR (they are close but not the same in the orginal DetectorConstruction.cc).

The results are that the range for Air (3.93544 cm) and G4_AIR (3.93341 cm) are virtually the same. I’ve attached the input macro (which is identical to julian.mac) and the output.
julian.mac.txt (309 Bytes)
myjulian.out.txt (19.6 KB)

So Michel has the range for G4_AIR and Air differing for Geant4 version Name: geant4-10-07-ref-08 (30-September-2021) and I have them the same for Geant4 version Name: geant4-10-07-patch-02 (11-June-2021). What version of Geant is Julian using?

I guess it is 11.0-beta

Just for confirmation, a plot of alpha track length from TestEm1 simulation.
julian.mac.txt (348 Bytes)

This is getting interesting and more confusing. Again I am running Geant4 10.7.2.

I ran TestEm1 with Michel’s macro. I get a range of 3.923cm with the original Air composition (Air_Original) of the DetectorConstruction.cc module and 4.193cm with the Air composition which matches that of G4_Air. I get a range of 0.9291cm for G4_AIR. See attached plots of alpha track length for Original Air, Air and G4_AIR respectively.

Air_Original
Air
G4_AIR

So my range results from TestEm0 roughly agree with my TestEm1 range results for Air but are very different from each other for G4_AIR. The G4_AIR range is less than 1cm for TestEm1 but is roughly equal to the range for Air in TestEm0.

Sorry for not replying for so long. as I have read the problem is not only apparent for my geant4 simulation.
I am currently using geant4 version 10.7.2, so no beta.

I think I have unraveled the discrepencies between TestEm0 and TestEm1. They relate to which EM physics list is used. I have attached two tables of ranges, one for TestEm0 and the other for TestEm1 for the geometry under discussion for the available EM physics choices: emstandard_opt0,1,2,3,4, empenelope and emlivermore. All roughly agree with the range from SRIM except for opt3, opt4 for G4_AIR. I am using Geant4 10.7.2.
TestEM0_myjulian_range_results_summary.txt (1.0 KB)
TestEM1_myjulian_range_results_summary.txt (1.0 KB)

Recently, @civanch has been working on this question.
With his latest corrections, the range has approximately same value with all physics constructors, for Air and G4_AIR as well.
Unfortunately this value is ~0.753 cm (TestEm0) or ~0.957 cm (TestEm1).

I looked up the range of 5.5 MeV alphas in air, just in case there was an (incredibly unlikely) error in SRIM. For air at 15 degrees C temperature, 760 mm Hg pressure, equivalent to a density of 1.225 mg/cm3, the range is ~4.05 cm. (The data is from the Radiological Health Handbook, US Dept of Health, Education and Welfare, 1970, but is widely found in many publications.) So yes, ~.753 cm or ~0.957 cm are unfortunate results. But it’s good that all the physics constructors now agree.

Of course, previous versions of Geant4 do not suffer of this problem …
alpha.out.txt (4.6 KB)

Would you know what is the latest version of Geant4 for which the results are correct? (I suppose I could download older versions, compile them and figure it out myself, but if someone has ready access to the earlier versions, it would be nice.) I am particularly interested if any version since 10.7.0 gives correct results.

Also, has a bug report been filed (or is that necessary)?

Please do it. Describe the situation as you see it in 10.7.2

I I have created Bugzilla problem 2439 ‘Alpha Particle Range in G4_AIR Differs Significantly for Different EM Physics Lists’. I will keep you posted as to the outcome.

It didn’t take long to get a solution! The following reply came for Bug Report 2439.

"The problem was reported in 2414, it is fixed and the fix will be available with the next public release and the next patch to 10.7. In a mean time disable ICRU90 flag in your applications:

/process/eLoss/UseICRU90 false