Loss of precision when using /remoll/thcommax and /remoll/thcommin

[rahmans1]

Environment:

• Release Version: remoll-2.0.0
• System:
  

Steps to reproduce: (give a step by step account of how to trigger the bug)

1. Insert a debug statement in remollGenMoller.cc to print out value of fThCom_max used.
   
2. Run 1000 events with seed value 123456 and /remoll/thcommin and /remoll/thcommax commented out in runexample.mac.
   
3. Run time output and radial distribution in moller ring with messenger commands commented out:
   
   
4. Run 1000 events with seed value 123456 and messenger commands uncommented.
5. Run time output and radial distribution in moller ring with messenger commands in runexample.mac:
   
   

Expected Result: (what do you expect when you execute the steps above)

Would expect the same radial distribution since the value of fThCom_min and fThCom_max set by the messenger commands is identical to the default values set in remollGenMoller.cc constructor. The sims are run with the same seed.

Actual Result: (what do you get when you execute the steps above)

There is a loss of precision on the values of fThCom_min and fThCom_max when set by messenger commands. Is this causing the change in radial distribution?
Rate Integral in Moller Ring (No messenger commands): 159 GHz
Rate Integral in Moller Ring (With messenger commands): 145 GHz

[wdconinc]

While strange that the double precision does not transfer correctly (I'm looking into that), I do not think this could affect the rate (I'm looking into that too). Are you basing the rate calculation on only 1000 events?

[wdconinc]

It does indeed affect the rate when using a limited number of events since some events will have angles that are different in the least significant digits.

*       23 *        0 * 0.0057065 * 962557187 *
*       23 *        1 * 0.0197978 * 962557187 *

vs.

*       23 *        0 * 0.0057065 * 962556980 *
*       23 *        1 * 0.0197978 * 962556980 *

which is a 2e-7 effect. I assume it's a larger effect for very forward events with higher cross section... So yeah, this is a real effect due to the systematic one-directional effect of cutting the least significant digits and therefore decreasing the angle.

[wdconinc]

This is an upstream bug. Demonstrated on Geant4 example B1 at https://github.com/wdconinc/geant4-messenger-double-precision/.

[wdconinc]

Reported upstream: https://bugzilla-geant4.kek.jp/show_bug.cgi?id=2070

No workaround known at this point. I'd say we should be aware of this issue. Does it affect calculated rates at much larger number of events?

[rahmans1]

I based the rate calculations on the thousand events just to check that the bug exists. In all my previous high statistic runs, I had the messenger commands in my macro. I will run a batch with the messenger commands commented out. That will give me an idea whether this is an issue at larger statistics as well. It will be wise to not use the messenger commands for moller(thcommin, thcommax) and elastic(thmin, thmax, Emin) generator since the exact effects are not clear. Better just change the default values if needed in the generator constructors and recompile.

[wdconinc]

Actually, if there's no effect (and there shouldn't for large statistics) then there's no need to recompile.

[wdconinc]

Upstream resolved as of geant4.10.03-p01 by setting G4UImanager::UseDoublePrecisionStr(true). Include in branch bugfix-issue-130 b9ab80c. Could you please test and let me know if that resolves the issue (with a geant4 version >= 4.10.03-p01)?

[wdconinc]

Ok, I had to explicitly include G4Version.hh. Now I get the same output on 1000 events when setting thcommax explicitly as when I don't set it explicitly. I'll consider this solved, at least for Geant4 > 4.10.03-p01.