Created attachment 810 [details] Selected bits of code relevant to the issue I am trying to simulate neutron capture in a NaI detector for which I need to add new levels to the PhotonEvaporation files for Na24 and I128 as their current level schemes are not sufficient for this purpose. However, I have found that when I try to have more than 632 levels in a file and I run my simulations, no levels above level 632 are included in the simulations and GEANT4 will create gamma rays from the continuum to de-excite the residual nucleus, which I do not want it to do. I was looking through the source code for version 10.07.00 (which is the version I am using) and I found that when the function “G4PhotonEvaporation::InitializeLevelManager(G4int Z, G4int A)” is called, “const G4LevelManager* G4LevelReader::LevelManager(G4int Z, G4int A, G4int nlev, std::ifstream& infile)” is called where “nlev” is hardcoded to 0. It seems to me that with this condition, there is no way for the vectors that hold the level information being read in to be resized to the maximum number of levels in the file. I am not sure if this is a bug in the code or I have missed something about the way G4PhotonEvaporation I have included some information I hope will be helpful in illustrating the issue.
Hello, in the class G4LevelReader space for level data is initialized in the constructor using hard-coded numbers. This is done for more effective work with local memory. The size of allocated memory is defined from the size of existing data, provided in G4LEVELGAMMADATA. For the case of getting more levels in the code G4LevelReader lines 261-266 vector length is extended. So, the code should work for any number of levels in the data. Hardcoded numbers is only an optimisation. In theory, this should not prevent from extension of data files by users. This does not mean that we have no problem. Can you confirm that if you add extra lines inside the dataset then you have expected/non-expected results? VI
Hello, after looking in the code I start to agree with your concerns. The hardcoded limit was defined assuming that in existing files it significantly exceed the real number of levels. Now it is clear that there are limitations and we have to extend the limit. Fix will be available soon, I may send you updated code for private testing. VI
Hello, a simple fix is available: https://cernbox.cern.ch/s/9oLBpUh1D18Bdek For any case, also header file may be useful: https://cernbox.cern.ch/s/0AgHkxaUDUwQDn5 Please, try it out. In a mean time, the update will go via Geant4 validation procedure and be included into development branch in git. I am not sure if it will be available in the official patch to 10.7 and am not sure if such patch will be ever done, because of that I am sending the code privately. VI
Hello Vladimir, I tried compiling the code but I am encountering the following error: /mnt/misc/sw/x86_64/Debian/10/geant4/gnu/10.7.4-patched/geant4-v10.7.4/source/processes/hadronic/models/de_excitation/management/src/G4LevelReader.cc: In constructor ‘G4LevelReader::G4LevelReader(G4NuclearLevelData*)’: /mnt/misc/sw/x86_64/Debian/10/geant4/gnu/10.7.4-patched/geant4-v10.7.4/source/processes/hadronic/models/de_excitation/management/src/G4LevelReader.cc:60:27: error: ‘G4FindDataDir’ was not declared in this scope const char* directory = G4FindDataDir("G4LEVELGAMMADATA"); Perhaps there is a missing library reference to this variable, but I am not sure. Thank you, Mejdi
Hello Mejdi, I am sorry - my private variant was not coherent with the previous code. The problem should fixed in the new public versions 11.1.p02 and 11.2beta. Vladimir
Hello, Thank you for identification of the problem. It is fixed and will be available with new public release 11.2 (also 11.2beta). VI
