I cannot reproduce either of these problems in Geant4 10.6.
Please migrate to that release and let us know what happens.

Hi. Thank you for the response. Today I ran a case that previously gave the problem (primary gamma ray energy 11.668 MeV) using Geant4 10.5-patch01. In confirmation of previous results, I got many, many errors of the form:

-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : had012
      issued by : G4HadronicProcess:CheckResult()
Warning: Bad energy non-conservation detected, will re-sample the interaction
 Process / Model: photonNuclear / LENDorBERTModel
 Primary: gamma (22),  E= 11.668, target nucleus (7, 14)
 E(initial - final) = -12108.5 MeV.

*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------

Then I migrated to 10.6-patch-01 and reran the same case. I still get the same errors.

I will do a long run at 16.107 MeV to see if I can duplicate the second problem (the segmentation fault).

Hi. I have just run a case under Geant4 10.6.1 that has thrown a segment fault like it did in 10.5.1. As before, it seems that the seg fault arises in G4HadronicProcess::CheckResult.

The traceback from the seg fault follows:

Thread 4 "exampleB4a" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffed9b4700 (LWP 17733)]
0x00007ffff24f0b1c in G4HadronicProcess::CheckResult(G4HadProjectile const&, G4Nucleus const&, G4HadFinalState*) ()
   from /home/jmcfee/geant4/geant4.10.6.p01-install/lib64/libG4processes.so
Missing separate debuginfos, use: dnf debuginfo-install bzip2-libs-1.0.6-29.fc30.x86_64 expat-2.2.8-1.fc30.x86_64 freetype-2.9.1-7.fc30.x86_64 glib2-2.60.7-2.fc30.x86_64 graphite2-1.3.13-1.fc30.x86_64 harfbuzz-2.6.1-2.fc30.x86_64 libICE-1.0.9-15.fc30.x86_64 libSM-1.2.3-2.fc30.x86_64 libX11-1.6.7-1.fc30.x86_64 libXau-1.0.9-1.fc30.x86_64 libXext-1.3.3-11.fc30.x86_64 libXmu-1.1.2-13.fc30.x86_64 libXt-1.1.5-11.20190424gitba4ec9376.fc30.x86_64 libgcc-9.2.1-1.fc30.x86_64 libgcrypt-1.8.5-1.fc30.x86_64 libglvnd-glx-1.1.0-4.gitf92208b.fc30.x86_64 libgpg-error-1.33-2.fc30.x86_64 libicu-63.2-2.fc30.x86_64 libpng-1.6.36-1.fc30.x86_64 libstdc++-9.2.1-1.fc30.x86_64 libuuid-2.33.2-2.fc30.x86_64 libxcb-1.13.1-2.fc30.x86_64 lz4-libs-1.9.1-1.fc30.x86_64 mesa-libGLU-9.0.0-17.fc30.x86_64 qt5-qtbase-5.12.5-2.fc30.x86_64 qt5-qtbase-gui-5.12.5-2.fc30.x86_64 xz-libs-5.2.4-5.fc30.x86_64
(gdb) backtrace
#0  0x00007ffff24f0b1c in G4HadronicProcess::CheckResult(G4HadProjectile const&, G4Nucleus const&, G4HadFinalState*) ()
   from /home/jmcfee/geant4/geant4.10.6.p01-install/lib64/libG4processes.so
#1  0x00007ffff24f28b7 in G4HadronicProcess::PostStepDoIt(G4Track const&, G4Step const&) ()
   from /home/jmcfee/geant4/geant4.10.6.p01-install/lib64/libG4processes.so
#2  0x00007ffff620b29e in G4SteppingManager::InvokePSDIP(unsigned long) ()
   from /home/jmcfee/geant4/geant4.10.6.p01-install/lib64/libG4tracking.so
#3  0x00007ffff620ba0b in G4SteppingManager::InvokePostStepDoItProcs() ()
   from /home/jmcfee/geant4/geant4.10.6.p01-install/lib64/libG4tracking.so
#4  0x00007ffff6208aff in G4SteppingManager::Stepping() () from /home/jmcfee/geant4/geant4.10.6.p01-install/lib64/libG4tracking.so
#5  0x00007ffff62140ec in G4TrackingManager::ProcessOneTrack(G4Track*) ()
   from /home/jmcfee/geant4/geant4.10.6.p01-install/lib64/libG4tracking.so
#6  0x00007ffff624fb16 in G4EventManager::DoProcessing(G4Event*) () from /home/jmcfee/geant4/geant4.10.6.p01-install/lib64/libG4event.so
#7  0x00007ffff62fad9c in G4WorkerRunManager::DoEventLoop(int, char const*, int) ()
   from /home/jmcfee/geant4/geant4.10.6.p01-install/lib64/libG4run.so
#8  0x00007ffff62ef1be in G4RunManager::BeamOn(int, char const*, int) () from /home/jmcfee/geant4/geant4.10.6.p01-install/lib64/libG4run.so
#9  0x00007ffff62fc5ec in G4WorkerRunManager::DoWork() () from /home/jmcfee/geant4/geant4.10.6.p01-install/lib64/libG4run.so
#10 0x00007ffff6305bba in G4MTRunManagerKernel::StartThread(G4WorkerThread*) ()
   from /home/jmcfee/geant4/geant4.10.6.p01-install/lib64/libG4run.so
#11 0x00007ffff0e1d6f4 in ?? () from /lib64/libstdc++.so.6
#12 0x00007ffff0bcb4c0 in start_thread () from /lib64/libpthread.so.0
#13 0x00007ffff0af9163 in clone () from /lib64/libc.so.6

OK, re-opening bug report.

I have reproduced this result, and now understand the cause.  The G4LEND models get their data from the GIDI database which stores and provides most of its data in terms of spectra such as, for example, final state particle multiplicity vs. incident particle energy.  GIDI provides all final state products which satisfy the sampling criteria and does not stop if, say, baryon number conservation is violated.  This most accurately reproduces the measured spectra, which would be distorted if conservation rules were enforced.

Because most Geant4 users demand conservation, an attempt was made to provide it in the LEND models.  Unfortunately, the cases where large nuclear fragments are concerned were not accounted for, hence mass differences of anywhere from A = 4 to
A = 14 in your example.  The higher-level Geant4 caught this and sent the warnings.

I am now rewriting G4LENDInelastic.cc which tries to apply the conservation.   I think it will be possible to ensure baryon number conservation without distorting too much the reproduction of measured spectra, but there will still be charge and energy non-conservation of the order of a few percent.  There are several reasons for the latter, but, due to the nature of the GIDI data, this cannot be helped.

I'll let you know when the code is ready.

That is great. Thank you.

Created attachment 620 [details]
CS_Au196

Will the solution be available in the next patch?
And I have another question: will it be possible to use LENDorBERTModel for energies above 20 MeV? For instance if i set:

G4LENDorBERTModel* lend = new G4LENDorBERTModel(G4Gamma::Gamma());
lend->SetMaxEnergy(80*MeV);
process->RegisterMe(lend);
G4LENDCombinedCrossSection lendXS = new G4LENDCombinedCrossSection(G4Gamma::Gamma());
process->AddDataSet(lendXS);

Because actually there are data for cross sections in LEND library for energies above 20 MeV, and when I try to get the value of cross section for Au196 (see attached image), I get some, but before segmentation fault (core dump) for 23.3 MeV incident gamma, and ofcourse there are a lot of exception like it was mentiond above. Will this segmentation fault be fixed in this code?

As it was a bug fix, this will likely be in the next patch.

In principle LEND can handle energies above 20 MeV as long as there is data in GND.
However, in working on the problems mentioned for this model, I see a lot of the trouble comes from the GIDI layer of code beneath Geant4.  I'm not an expert on this, so I've asked for help from the author at Livermore; so far no response.