Problem 2010

Summary: G4ErrorFreeTrajState incorrect angle calculation
Product: Geant4 Reporter: James Mott <jmott>
Component: error_propagationAssignee: Pedro.Arce
Status: RESOLVED FIXED    
Severity: minor CC: resnegfk
Priority: P4    
Version: 10.3   
Hardware: All   
OS: All   
Attachments: Chi2 for the same tracks rotated around the y-axis with and without this fix

Description James Mott 2017-11-08 19:39:53 CET
Created attachment 473 [details]
Chi2 for the same tracks rotated around the y-axis with and without this fix

In the muon g-2 experiment, we made the (non-judicious) choice of placing our detector planes close to the z-axis.  This highlighted a bug that doesn't show up if they're in x or y (as is presumably the case for most collider geometry with the beam along z).

The mistake is in error_propagation/src/G4ErrorFreeTrajState.cc. Line 255 reads:
  G4double sinpPostInv = 1./std::sin( vpPreNorm.theta() );
whereas I think it should be:
  G4double sinpPostInv = 1./std::sin( vpPostNorm.theta() );

It looks like this is a simple typo (given the variable name).

To verify that this is indeed correct, I took the a set of tracks and "measurements" in a vacuum world and rotated them around the y-axis - this should be invariant in terms of the chi2 of my fit track.  The attached plots show the chi2 rising close to the z-axis (my phi_z is theta) in the pre-fix version and uniform in the post-fix version.

In addition, one other small fix to the same file is to add in:
  if( 1. - std::fabs(vpPreNorm.z()) < kCarTolerance ) return 4;
alongside line 252:
  if( 1. - std::fabs(vpPostNorm.z()) < kCarTolerance ) return 4;
In tracking calculations, an inverse is normally taken and when sinpPre is tiny, this can cause big precision problems.  Given we're already not able to track along a postStep of Z, it doesn't seem a big deal to catch the preStep too.
Comment 1 Pedro.Arce 2017-11-10 12:58:07 CET
Solved, thanks for spotting this