[Rivet] bug in polar angle?

[Jonathan Butterworth]

Hi Hendrik,

I agree this is a bug in the polar angle definition. I am not aware of 
any reason for this peculiar definition. And I guess the effect on 
anything using et will be serious.

Fortunately it seems that the pseudorapidity will be ok since it 
explicitly works around this:

inline double pseudorapidity(const Vector3& v) {
  	  double polarangle = polarAngle(v);
  	  if (polarangle < 0) polarangle += PI;
  	  return -log(tan( 0.5 * polarangle ));
  	}

Since Andy is away we won't get the full story now, I guess. But I 
suggest you do the following:

- submit a ticket with high priority and an appropriate cc list
- fix the polar angle definition
- leave the ticket open so we can check the consequences with Andy when 
he gets back.

But I would have thought that this would be garing in the analyses using 
jet algorithms since while newer papers tend to use pT and y, the old 
ones use ET and pseudorapidity..

Cheers,
Jon

Hendrik Hoeth wrote:
> 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
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Prof. Jonathan Butterworth,              http://www.hep.ucl.ac.uk/~jmb/ 

Physics and Astronomy Department                  Tel: +44 20 7679 3444
University College London                 Gower St, London WC1E 6BT, UK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~