| Summary: | G4ErrorFreeTrajState incorrect angle calculation | ||
|---|---|---|---|
| Product: | Geant4 | Reporter: | James Mott <jmott> |
| Component: | error_propagation | Assignee: | 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 | ||
Solved, thanks for spotting this |
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.