-
Notifications
You must be signed in to change notification settings - Fork 102
Final charged lepton polarization #434
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Final charged lepton polarization #434
Conversation
…KFF to more common LwlynSmithIsoFFCC for isoscalar target and make related with it changes
…precated [-Wdeprecated-copy]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some comments about the changes to GHepParticle polarization representation
TLorentzVector * fX4; ///< position 4-vector (in the target nucleus coordinate system / x,y,z in fm / t from the moment of the primary interaction in ys(yocto second = 10^-24 s) | ||
double fPolzTheta; ///< polar polarization angle (rad) | ||
double fPolzPhi; ///< azimuthal polarization angle (rad) | ||
TVector3 fPolarization; ///< polarization vector of final lepton |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change in the representation of the polarization would make files incompatible across GENIE versions. This might or might not be a problem, and possibly can be mitigated using a ROOT I/O rule for converting from one representation to the other, but it needs consideration.
A less intrusive, but less satisfying, alternative might be to add a magnitude data member.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While adding a magnitude member might seem like a less intrusive modification, does introducing an additional double really create fewer compatibility issues than replacing the existing members with a TVector3? Either way, older versions would lack the new parameter, leading to incompatibility. If backward compatibility is a major concern, perhaps a ROOT I/O rule could be explored to facilitate the transition smoothly.
…polarization with magnitude greater than 1
…update configs according to this
All current work.