Problem 991 - issue with catching numerical errors in G4PhantomParameterisation
Summary: issue with catching numerical errors in G4PhantomParameterisation
Status: RESOLVED FIXED
Alias: None
Product: Geant4
Classification: Unclassified
Component: geometry/navigation (show other problems)
Version: 9.1
Hardware: All All
: P5 minor
Assignee: Pedro.Arce
URL:
Depends on:
Blocks:
 
Reported: 2008-01-03 21:00 CET by marcus.h.mendenhall
Modified: 2008-01-13 22:44 CET (History)
2 users (show)

See Also:


Attachments
patch file to make some reliability upgrades to G4PhantomParameterisation.cc (1.93 KB, patch)
2008-01-03 21:00 CET, marcus.h.mendenhall
Details | Diff

Note You need to log in before you can comment on or make changes to this problem.
Description marcus.h.mendenhall 2008-01-03 21:00:54 CET
Created attachment 12 [details]
patch file to make some reliability upgrades to G4PhantomParameterisation.cc

The logic in 

G4PhantomParameterisation::GetReplicaNo( const G4ThreeVector& localPoint, const G4ThreeVector& localDir )

has a minor error in its own error checking, which could result in wrong materials being assigned to voxels.  After doing all the computation of nx, ny, nz, the variable copyNo is set as follows:

  G4int copyNo = nx + fNoVoxelX*ny + fNoVoxelXY*nz;

and then a check is made to make sure the result is in bounds.  However, it will only end up out of bouds if the overflow was in the Z direction... overflows in X & Y will go undetected, but will cause a the vooxel to appear wrapped into the wrong row, column and layer.  Instead, each of nx, ny, nz should be individually checked and clipped.  Since all the calculations are biased in the same direciton by +kCarTolerance, the only roundoff error is positive, and one just needs to check the upper bound of each.  Then, all of the error checking code on copyNo can be eliminated outright.

I am attaching a diff -u patch file which makes the suggested changes. Note that the patch file deletes the now-unneeded error checking code with #if 0.  You might want to delete it rather than just flag it out this way.

Thanks.

Marcus Mendenhall
Comment 1 Pedro.Arce 2008-01-13 22:44:15 CET
I knew already of this problem, thanks to another user, but it was too late for release 9.1. As you realized, it is solved by deleting the line

if( copyNo < 0 || copyNo >= G4int(fNoVoxel) )

I do not agree with deleting the other checks, They, as you say, would be unnecessary, only if there were not pathological cases (that I did find in previous geant4 versions), where  the track is assigned to the voxels where it should be outside. That is why I put the "isOK" flag, because I want to send a warning at least, instead of just solving it with a std::min.