[Rivet] bug in polar angle?

Hendrik Hoeth hendrik.hoeth at cern.ch
Mon 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