Problem 2010 - G4ErrorFreeTrajState incorrect angle calculation
Summary: G4ErrorFreeTrajState incorrect angle calculation
Status: RESOLVED FIXED
Alias: None
Product: Geant4
Classification: Unclassified
Component: error_propagation (show other problems)
Version: 10.3
Hardware: All All
: P4 minor
Assignee: Pedro.Arce
URL:
Depends on:
Blocks:
 
Reported: 2017-11-08 19:39 CET by James Mott
Modified: 2017-11-10 12:58 CET (History)
1 user (show)

See Also:


Attachments
Chi2 for the same tracks rotated around the y-axis with and without this fix (394.32 KB, application/pdf)
2017-11-08 19:39 CET, James Mott
Details

Note You need to log in before you can comment on or make changes to this problem.
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