I have encountered a strange behavior using G4NeutronHPThermalScattering: after scattering, neutron momenta mostly stay in the same plane as if randomization is not performed in Phi direction. I have prepared a simple demonstrator at https://github.com/andrmor/TSmin The world is made of G4_POLYETHYLENE (or TS_Aluminium_Metal, see DetectorConstruction) Neutron physics is set using a QGSP_BIC_HP physics list and TS is activated using the approach described in the Hadr04 example A given number of neutrons is generated at (0,0,0) with (1,0,0) direction and a fixed energy The code reports the momentum direction after the first neutron interaction and kills the neutron At the end the mean free path is reported If the neutron energy is set above 4 eV, everything works as expected in terms of scattering direction and MFP. When energy is below 4 eV (TS model range), the MFP changes and the value is realistic, but the momentum direction after scatter lays in the Z = 0 plane with just a few exceptions When neutron killing is disabled, the result show that the direction mostly is kept to the same plane even after consequent scatterings. Note that neutron momentum vector not only keeps to the same plane, but changes always "to the left" as would be if the theta angle is applied (range 0 - 180 degrees), but randomization around Phi angle is not performed. The tests were performed with the newest Geant4 version (10.6.2) at Ubuntu 18.04 Note that this problem was already reported before (Problem Id 1856) but was closed since it was reported for an old version of Geant4. I have performed tests at the newest version (and 10.6.1 too).
see also user forum : https://geant4-forum.web.cern.ch/t/neutronhpthermalscattering-strange-angular-behaviour/3796/2
Hello, The bug in final state rotation is fixed and the fix will be available in the new release and in the 1st patch to 10.7. It would be good to check if this fix resolve the problem. Because the fix is limited, I can send fixed class privately. VI
Hello Vladimir, Please send me the fixed class, I will check. An important issue: how about the issue 1856? Was it the same bug? My test was that: a high-energy neutron slows down in paraffin and as soon as its energy is in the range of the TS model, the Z component of the momentum is 0 after the first scattering event. Since the original direction of the neutron is random, it looks like a separate bug (not just the missing randomization around the axis – in that test the axis should have non-zero Z component itself). I think if it is not the same bug, it will not be possible for me to check that issue mentioned above after your fix: due to randomization of the phi angle, the Z component will not be zero anymore. Regards, Andrey
It appears that this is the same bug as in 1856. That report however, was for Geant4 9.1 which is quite old.
It looks like I bumped into the same issue: https://bugzilla-geant4.kek.jp/show_bug.cgi?id=2307 Vladimir, I patched the code myself and verified that it fixes the issue. I suspect that my patch and the current fix are the same, but you might want to double check.
I am not sure this is the same error that was reported in #1856, since this worked fine in 10.5. I guess we'll never know...
Hello Sergio, would you show how you fix the problem? For example, in attachment or copy lines of code, which you introduced? Vladimir
Sure, I attached the patch to the other thread, that is what I meant. I will upload it here as well.
Created attachment 659 [details] Fix patch
Hello Sergio, thank you for the patch. It is type of solution we had in past and what we do not want to have anymore - forced rotation of final state at the level of the elastic process. The update introduced two years ago was introduced in order to remove final state rotation from the process class and left rotation in each model class. The reasons: - any model level test requires correct kinematics, so phi should be randomly sampled inside each model in order to be tested; - external models integrated to Geant4 should already have final state rotation implemented; - model may depend on spin direction, which cannot work in past, because forced rotation kills such model. Problem was that when I made this migration thermal scattering model was overlooked - all other models were fine. Now the bug in the thermal model is fixed. Vladimir
Aaah, I see! Thank you for the thorough explanation. So my "fix" addressed thermal elastic scattering but broke everything else (or best case uselessly re-randomized around Z), nice ;-) Indeed your explanation makes sense, since the only issues we observed were with the thermal neutron fluences. Looking forward to 10.7.1 then!
There is nothing wrong in your fix - small overhead will have invisible effect on CPU. But for the long term we want another solution. Cheers, Vladimir
Hello, the bug was fixed and the fix is already inside 10.7p01. Vladimir
Problem has been fixed and is now part of Geant4 10.7 patch01.
