In simulating the interaction of muons with a material (C10H20), the use of the binary cascade model for pions (up to 1.5 GeV) causes crashes with "Segmentation fault". The problem seems to be caused by a block of code in G4PreCompoundModel.cc, in the beginning of the DeExcite method. When the fragment has an A<5 no de-excitation takes place. Instead, the particle table is accessed using the Z, A and excitation energy of the fragment (through the GetIon() method) in order to obtain its identity. But if Z=0, the method returns a null pointer causing the simulation to crash when the pre-compound creates a new G4ReactionProduct with it. An additional if...else to isolate neutron fragments and use its code to retrieve the pointer from the particle table seems to solve the problem. Alternatively, the GetIon() method of the particle table could be changed to accommodate this. This bug was seen on version 8.2.
The problem arises from the binary cascade. It is still in development for pions and passes an object which violates charge conservation to the PreCompound/De-excitation. I'm not sure the suggested fix with neutron selection can work, as otherwise the problem should be seen with incident neutrons and protons. Including the log file would help (to be sure of the diagnosis).
The use of the binary cascade already had a problem (this one not only with pions), but this is solved by suppressing abortion. Here's the output for one of these: "*** G4Exception : 007 issued by : G4HadronicProcess GeneralPostStepDoIt failed. *** Fatal Exception *** core dump *** *** G4Exception: Abortion suppressed *** *** No guarantee for further execution *** In /usr/local/geant4.8.2/source/processes/hadronic/models/util/include/G4Fragment.hh, line 264: ===> G4Fragment::SetNumberOfCharged: Number of charged particles can't be greater than number of particles G4HadronicProcess failed in ApplyYourself call for - Particle energy[GeV] = 0.02505144 - Material = C10H20 - Particle type = pi+ " But the problem here reported doesn't produce any output, and isn't directly connected with the above examples. Here's the output from gdb: "Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0000000c 0x0048d8fd in G4ReactionProduct::G4ReactionProduct () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 315 G4CountedObject<X>::aCountedObjectAllocator;" and here's the output from gdb backtrace: #0 0x0048d8fd in G4ReactionProduct::G4ReactionProduct () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 #1 0x000a4379 in G4PreCompoundModel::DeExcite () #2 0x000a4d2b in G4PreCompoundModel::ApplyYourself () #3 0x0007248d in G4BinaryCascade::ApplyYourself () #4 0x00304e95 in G4HadronicInteractionWrapper::ApplyInteraction (this=0xbfffea24, thePro=@0xbfffe954, targetNucleus=@0x493e494, theInteraction=0x48eca00) at src/G4HadronicInteractionWrapper.cc:36 #5 0x003025b1 in G4HadronicProcess::GeneralPostStepDoIt () #6 0x002fd1ed in G4HadronInelasticProcess::PostStepDoIt () #7 0x004de324 in G4SteppingManager::InvokePSDIP () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 #8 0x004de5ef in G4SteppingManager::InvokePostStepDoItProcs () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 #9 0x004db9a9 in G4SteppingManager::Stepping () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 #10 0x004d227e in G4TrackingManager::ProcessOneTrack () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 #11 0x004badec in G4EventManager::DoProcessing () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 #12 0x0048f6d1 in G4RunManager::DoEventLoop () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 #13 0x0048df9e in G4RunManager::BeamOn () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 #14 0x004937c2 in G4RunMessenger::SetNewValue () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 #15 0x006055cb in G4UIcommand::DoIt () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 #16 0x0060a479 in G4UImanager::ApplyCommand () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 #17 0x00614537 in G4UIbatch::SessionStart () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 #18 0x00608f2b in G4UImanager::ExecuteMacroFile () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 #19 0x00614c7a in G4UIcontrolMessenger::SetNewValue () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 #20 0x006055cb in G4UIcommand::DoIt () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 #21 0x0060a479 in G4UImanager::ApplyCommand () at /usr/local/geant4.8.2/source/global/management/include/G4ReferenceCountedHandle.hh:315 #22 0x0004884a in G4UIterminal::ExecuteCommand () #23 0x00049a86 in G4UIterminal::SessionStart () #24 0x0000248c in main ()
You mention that you have a problem with particles that are not pions, but the interacting particle (even if it's a secondary) in the output you provided is for a Pi+. If the problem occurs with other particles then please provide details. For now I would suggest not attaching the binary cascade to pions and instead using either the Bertini or LEP models.
