|
[Rivet] bug in polar angle?Hendrik Hoeth hendrik.hoeth at cern.chMon Jun 23 17:39:30 BST 2008
Hi, I want to access the transverse energy ET of particles. So I ask the particle for its momentum and the momentum for its Et(): p->getMomentum().Et() (p is a ParticleVector::const_iterator over the particles() of a FinalState projection) To my great surprise the Et() is negative in about half of the cases. So let's check the definition of Et(): inline double Et(const FourMomentum& lv) { return sin(lv.polarAngle()) * lv.E(); } Okay, doesn't look unreasonable. And E() is always positive, so I looked at the values of p->getMomentum().polarAngle() -- the polar angle is calculated in the range [-pi/2 .. pi/2], see Vector3.hh: /// Calculate polar angle of a 3-vector. inline double polarAngle(const Vector3& v) { return atan( polarRadius(v) / v.z() ); } Now one could assume that this is a simple bug, since I don't see any situation where you want a polar angle definition like this. But directly after this strange definition of polarAngle() I see this: /// Calculate pseudorapidity of a 3-vector. inline double pseudorapidity(const Vector3& v) { double polarangle = polarAngle(v); if (polarangle < 0) polarangle += PI; return -log(tan( 0.5 * polarangle )); } Whoever wrote this code has been well aware of the fact that polarAngle() can give negative results. Therefore I have some questions: - Is there a reason for defining polarAngle() as it is now? - Do you see anything we would break by fixing this? - How much might be broken at the moment? Cheers, Hendrik -- Those who give up essential liberties for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin
More information about the Rivet mailing list |