Problem 602

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