Hello, Simulating photons of 2 MeV impinging on a LaBr3 box using the (Livermore) low-energy EM-package resulted in Geant4 getting caught in an endless loop which did occur in 9.1. Doing some debugging I found out that the endless loop is in G4eIonisationSpectrum::SampleEnergy(). The direct cause is a devision by zero in G4eIonisationSpectrum::Function(...), where in the endless loop case x==0. The data of "x" set in SampleEnergy(...) originates from a call to G4eIonisationParameters::Parameter(...). For La problem seems to only appear in case SampleEnergy(..) is called with shell=0 and thus Parameter(...) is called with shellIndex=0. In this case the data of the according EMDataSet seem to contain large negative values causing Parameter(...) to return the value 0. The large negative values are already present in the data file ion-sp-57.dat (=La). But also other data files such as ion-sp-56.dat are affected. My guess is that the data tables are defective. However, since almost everything seems to be unchanged, I am not sure why this problem appears now and not in previous versions of Geant4. Thus four things have to be done: 1. In G4eIonisationParameters::LoadData(), check the data set during reading for errors, i.e. values need to be positive, otherwise print warning message and try to fix data by interpolation or skipping these data points? 2. Protect G4eIonisationSpectrum::Function(...) against divisions by zero 3. Fix the input data sets 4. Figure out what's different between the current and previous versions causing the problem to appear now and not earlier. Regards, Andreas Zoglauer
Just a clarification: The problem does NOT happen with 9.1-p01 but with 9.2. And in my simulations setup (large Lanthan-box capable of stopping all photons) I had to start on average 25.000 2-MeV photons until I hit the endless-loop.
Ciao, a question concerning your last point: are you saying that the problems happens with Geant4 9.2 but NOT with Geant4 9.1? If so, could you please specify which version of the G4LEDATA database do you use in the two cases? The code looks unchanged. Luciano
Dear Luciano, Correct: 9.1-p01 runs without problems and 9.2 ends up in an infinite loop. I always use the G4EMLow version which comes with Geant4, i.e. for 9.2 I use 6.2 and with 9.1 I use 5.1. I also recognized that the code as well as the data is unchanged. Thus the difference must originate from someplace else. Do you agree that the large negative numbers in the data file must be incorrect? Ciao, Andreas
Dear Andreas, > Correct: 9.1-p01 runs without problems and 9.2 ends up in an infinite loop. > I also recognized that the code as well as the data is unchanged. Thus the > difference must originate from someplace else. this is somewhat puzzling and makes more complicated to understand where the problem may come from. >Do you agree that the large negative numbers in the data file must be >incorrect? I agree that one should correct the database for the negative values (well, I have to check more in detail the database and the numbers it contains for ionisation: I am not fully familiar with G4LowEnergyIonisation) and protect against division by zero. Question: did you change anything else between the two runs? E.g. the compiler? Which versions of CLHEP are you using in the two cases? Thanks, Luciano
Dear Luciano, I used the same compiler (gcc 4.2.1). Concerning clhep I always use the version suggested on the webpage, i.e. for 9.2 I use 2.0.4.2 and for 9.1 I use 2.0.3.2 Ciao, Andreas
reassigned to Luciano who has fixed the bug
Dear Andreas, thanks for reporting the bug and for your analysis. Your diagnosis indeed turned out to be complete and correct. Corrupted data were found in Z=38 (Sr), Z=56 (Ba) and Z=57 (La). The database files have been fixed; this will be available in the next release with G4EMLOW version 6.4. The next Geant4 release will also include the protection in G4eIonisationSpectrum. I have run 1e6 2-MeV e- in La, without any endless loop. Before the fix, the endless loop showed up before event 20000. Thanks again for your report, Luciano
