A call to G4EmProcessOptions SetMaxEnergy that worked fine in Geant4.9.6 causes a crash in Geant4.10.00.p2. The crash is triggered by the following lines in my modular physics list's SetCuts method: G4EmProcessOptions opt; opt.SetMinEnergy(0.); opt.SetMaxEnergy(500.); Specifically, if I just call SetMinEnergy, it works fine. But if I call SetMaxEnergy, I get a crash. I was able to reproduce this in example B3 by just copying those three lines into the end of B3PhysicsList::SetCuts(), so that the complete method is then: void B3PhysicsList::SetCuts() { G4VUserPhysicsList::SetCuts(); G4EmProcessOptions opt; opt.SetMinEnergy(0.); opt.SetMaxEnergy(500.); } Here is the traceback from my B3 running on Mac OSX10.8 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff85128d46 __kill + 10 1 libsystem_c.dylib 0x00007fff804c2f83 abort + 177 2 libc++abi.dylib 0x00007fff8a7b79eb abort_message + 257 3 libc++abi.dylib 0x00007fff8a7b539a default_terminate() + 28 4 libobjc.A.dylib 0x00007fff82c63887 _objc_terminate() + 111 5 libc++abi.dylib 0x00007fff8a7b53c9 safe_handler_caller(void (*)()) + 8 6 libc++abi.dylib 0x00007fff8a7b5424 std::terminate() + 16 7 libc++abi.dylib 0x00007fff8a7b658b __cxa_throw + 111 8 libstdc++.6.dylib 0x00007fff8a3e137e std::__throw_length_error(char const*) + 85 9 libG4analysis.dylib 0x0000000107a2afb8 std::vector<double, std::allocator<double> >::_M_fill_insert(__gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >, unsigned long, double const&) + 536 10 libG4global.dylib 0x00000001095b4758 G4Physics2DVector::PrepareVectors() + 152 11 libG4global.dylib 0x00000001095b45b7 G4Physics2DVector::G4Physics2DVector(unsigned long, unsigned long) + 119 12 libG4processes.dylib 0x0000000107f055ac G4MuPairProductionModel::MakeSamplingTables() + 716 13 libG4processes.dylib 0x0000000107f0529a G4MuPairProductionModel::Initialise(G4ParticleDefinition const*, G4DataVector const&) + 650 14 libG4processes.dylib 0x0000000107fb4fcf G4EmModelManager::Initialise(G4ParticleDefinition const*, G4ParticleDefinition const*, double, int) + 4959 15 libG4processes.dylib 0x0000000107fd3714 G4VEnergyLossProcess::PreparePhysicsTable(G4ParticleDefinition const&) + 2916 16 libG4run.dylib 0x0000000107c89ce2 G4VUserPhysicsList::PreparePhysicsTable(G4ParticleDefinition*) + 146 17 libG4run.dylib 0x0000000107c8969a G4VUserPhysicsList::BuildPhysicsTable() + 106 18 libG4run.dylib 0x0000000107c765cc G4RunManagerKernel::BuildPhysicsTables(bool) + 124 19 libG4run.dylib 0x0000000107c763e9 G4RunManagerKernel::RunInitialization(bool) + 265 20 libG4run.dylib 0x0000000107c6a554 G4RunManager::RunInitialization() + 36 21 libG4run.dylib 0x0000000107c6a2b7 G4RunManager::BeamOn(int, char const*, int) + 71 22 libG4run.dylib 0x0000000107c6f150 G4MTRunManager::Initialize() + 32
Hi Joseph, Thanks for detail description of the problem. The crash is happen due to small value 500 MeV - mu-pair production model of Geant4 is capable to work above 1 GeV. It is the bug of mu-pair production model initialisation. Before the fix is provided this upper limit should be above 1 GeV. VI
I've tried raising the limit to 2 GeV but this did not resolve the problem in my test with example B3. Are you sure setting a higher limit fixed the problem in your test?
Hi Joseph, The problem of the muon models has been fixed and fix will be available in the next reference version of Geant4. The problem was connected with the contradiction: muons models are applicable and have non-zero cross sections above 1 GeV but low-limit was set as 500 MeV. During study of this problem a new one has been discovered: the same call G4EmProcessOptions::SetMaxEnergy(G4double) inside G4VModularPhysicsList::SetCuts() provide stable crash in MT mode independently on what value of the max energy is set. This is connected with the recent updates of the kernel for MT and this is valid for other calls inside SetCuts. From my point of view, it is another bug. The fix require substantial change of G4EmProcessOptions and EM initialization, which indeed was planned for this year. We may keep this bug report for the second problem. For today, there is an alternative: if inside your application it is possible to use UI commands, they are working: /process/eLoss/maxKinEnergy 500 MeV is OK, EM tables are really built up to 500 MeV only. By the way, it is not recommended to set low-energy limit to 0. In standard and DNA it can be not smaller than 10 eV, in low-energy - 100 eV. Vladimir
Hello Joseph, The problem is fully fixed, the fix is included into development version, and will be available with the next version of Geant4 in December. Fix is not trivial to be included into any patch. Vladimir
