I belive that there is a fairly serious logical error in G4hLowEnergyLoss:: BuildDEDXTable(). The following line numbers refer to the version 4.6-p01 G4hLowEnergyLoss.cc source file. I found this issue when experimenting with a simple structure whose geometry can be changed from the command line, with a corresponding change in the number of entries in the couple table. However, it isn't necessary to have the user code to see the issue. It is obvious in the source file that something is wrong. At line 244 of G4hLowEnergyLoss.cc, theDEDXTable is set to either theDEDXpTable or theDEDXpbarTable. The latter two pointers are initialized to 0 when the class is first instantiated, but are not null thereafter. At line 247 there is an if() statement that uses the fact that theDEDXTable is zero initially, to prevent code from being unnecessarily repeated as various particles are processed. However, there is a problem with this, made obvious by the code within the if() clause at line 261 and again at line 275. At these locations checks are done for theDEDXpTable and theDEDXpbarTable being non-null. However, these clauses are superfluous and will never be executed, since one can only arrive at these locations if the pointers are null in the first place because of the if() at line 247. Obviously, the cases that lead to the need for the code at lines 261 and 275 are not being properly passed thorugh the test at line 247. The effect of this problem is that any change in the geometry of the detector that causes numOfCouples to change, requires tables to be recomputed, but they can't be if an earlier run has initialized them already. If one simply removes the check for the null pointer at line 247 and executes the code in the if() clause (lines 250-337) for all particles letting the deletions at 263 and 277 and recreations at 264 and 278 go forward without regard to efficiency, my program works, apparently correctly. Certainly, it does not crash. If, however, I create additional flags in the G4hLowEnergyLoss class to also track changes in numOfCouples in addition to the null pointer checks (being careful to handle Charge > 0. and Charge < 0. separately) I still get program aborts when I change the geometry in such a way that numOfCouples changes. As a result, I am suspicious that the scope of the if() statement beginning at line 247 is also wrong. I believe, in other words, that there is code in the if() statement that needs to be executed for each particle even though the tables only need to be built once. Could the closing brace of this clause be at the wrong location? I judge this to be a fairly serious error, the full scope and implications of which I have not attempted to evaluate. I will be travelling some in the next few weeks. If you try to communicate with me by email and don't get a reply, please contact my collaborator Marcus Mendenhall (marcus.h.mendenhall@vanderbilt.edu). He is also familiar with the issue. Regards, Bob Weller Vanderbilt University
The problem is reassigned to the developer responsible for Geant4 Low Energy hadron ionisation. Best wishes, Maria Grazia Pia
The problem may exist. We would sujest for the time being to use standard EM package for work with geometry which is changed during one session. The problem will be addressed in the work which is carried out now to redesign energy loss processes in lowenergy package.
