PhysicsVectors Package and CLHEP Vector Package -- Problem Tracking CURRENT OPEN PROBLEMS 015: Wrong test for improper momentum in rapidity() Initial Bug Report 4/20/04 ------------------ Version 2.2.2 / CLHEP 1.9.8 Burkard Reisert (of CDF) reports that the rapidity() method of LorentzVector does not catch (and behave properly in) the case where the z component of momentum is equal to the energy. Problem Reproduced 4/21/04 ------------------ Resert's analysis is correct: The problem lies in LorentzVectorK.cc, where tests compating fabs(ee) to z ought instead to be comparing ee to fabs(z). Problem Rectified 4/21/04 ----------------- Fix made and tested. Checked in to cvs and also to CERN cvs in 3 places (!) Will be released as version 2.2.3 / CLHEP 1.9.9 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = PAST (CLOSED) PROBLEMS (Note -- there are many versions listed in this log as 1.9.x. Although all versioning up to 1.8 matched the CERN versioning of CLHEP, past 1.8 it does not -- we thought they were at 1.9 when they were not. Point releases under 1.9 at CLHEP are separately declared.) 014: Incorrect isNear for Boost agains general LorentzRotation Initial Bug Report 8/27/03 ------------------ Version 2.2 / CLHEP 1.9.2 John Marafino, in checkong PhysicsVectors tests, notes the same sort of error in HepBoost::isNear(HepLorentzRotation) as was made in problem 009. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 8/27/03 ----------------- Checked in to cvs. Will be in CLHEP 1.9.3. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 013: Incorrect Boost*LeorentzVector Initial Bug Report 8/22/03 ------------------ Version 2.2 / CLHEP 1.9.2 The method HepBoost::VectorMultiplication(LorentzVector) has typos leading potentially to incorrect results. The Z and T components contain contributions from the xz terms in the boost matrix, where the contributions should use the yz terms instead. This method appears in Boost.icc - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bug Reproduced 8/27/03 -------------- The Z component contains Mzx*y instead of Mzy*y. The T component contains Mtx*y and Mtx*z instead of Mty*y and Mtz*z. As long as the boost is largely in the Z direction, the effect will be very small, but it is a real error. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 8/27/03 ----------------- Problem has been rectified and fix checed in to cvs. Will be in CLHEP 1.9.3. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Root Cause Analysis 8/27/03 ------------------- This appears to have crept in about the time that E. T. backed out many of the merge changes M. F. had made, and mf had to repair a number of gotchas that were now preventing compilation on FNAL platforms. At about that time, several features and definitions were changed over to the CLHEP way of defining them (rather than the definitions in ZOOM PhysicsVectors). This had the unfortunate effect of causing some of the super-extensive PhysicsVectors tests to produce many bogus problem reports. We never had the time to check through each of these till now. One of the probelm reports was NOT bogus, and was catching this error. Per check of D0 code browser (8/27/03), no D0 code uses the HepBoost class in this (or any other non-boilerplate) way, so the error has not affected them. Per check of CDF code browser (8/27/03), no CDF code uses the HepBoost class in this (or any other) way, so the error has not affected them. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 8/27/03 ----------------- Problem has been rectified and fix checed in to cvs. In CLHEP 1.9.3. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 012: False azimAngle problem in deltaPhi test Initial Bug Report 7/15/03 ------------------ Version 2.2 / CLHEP 1.9.2 The test deltaPhi reports that some azimAngles are wrong. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bug Reproduced 7/18/02 -------------- Turns out that the problem is non-existant; the test was comparing two doubles for equality. There is a subltety in that APPARENTLY te two doubles were to be produced in the same manner, but obviously the compiler did something tricky. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 7/19/03 ----------------- Will be in CLHEP 1.9.3. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 011: Incorrect ranging for d_phi used in LorentzVector deltaR() Initial Bug Report 7/15/03 ------------------ Version 2.2 / CLHEP 1.9.2 The test deltaPhi reports that w2.deltaR(w1) is wrong. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bug Reproduced 7/18/02 -------------- Turns out that for LorentzVector, deltaR() was doing a direct phi subtraction rather than using pp.deltaPhi. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 7/19/03 ----------------- Will be in CLHEP 1.9.3. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 010: Missing operator* and decompose methods Initial Bug Report 7/14/03 ------------------ Version 2.2 / CLHEP 1.9.2 Scott Synder reports that "There are a number of declarations with no definitions i can find. In some cases, it looks like the definition is really missing; in others, it looks like the declaration wasn't meant to be there in the first place." In LorentzVector.h: inline HepLorentzVector & operator *= (const HepRotation &); In LorentzRotation.h: HepLorentzRotation operator * (const HepRotationX & r, const HepLorentzRotation & lt); HepLorentzRotation operator * (const HepRotationY & r, const HepLorentzRotation & lt); HepLorentzRotation operator * (const HepRotationZ & r, const HepLorentzRotation & lt); In RotationY.h: void decompose (HepRotation & rotation, HepBoost & boost) const; void decompose (HepBoost & boost, HepRotation & rotation) const; inline HepRotation operator * (const Hep3RotationInterface & r) const; In RotationZ.h: void decompose (HepRotation & rotation, HepBoost & boost) const; void decompose (HepBoost & boost, HepRotation & rotation) const; inline HepRotation operator * (const Hep3RotationInterface & r) const; In LorentzRotation.h: inline friend HepLorentzRotation inverseOf ( const Hep4RotationInterface & lt ); - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bug Reproduced 7/14/02 -------------- These problems crept in in the last big quake having to do with the CLHEP merge, when the reliance on the interface classes Hep4RotationInterface and Hep3RotationInterface was excised. inline HepLorentzVector & operator *= (const HepRotation &); This appears in LorentzVector.icc but is excised by #ifdef TESTOUT There is a subtlety involving transform() vs operator *= (our original PhysicsVectors package omitted this *= for this very reason). The definition **insisted** on by CLHEP is identical to that of transform; the natural C++ definition is v = v*R instead of v = R*v. We intended to conform to this CLHEP definition, as is evidenced by the ThreeVector case, in which we have in ThreeVectorR.cc Hep3Vector & Hep3Vector::operator *= (const HepRotation & m) { return *this = m * (*this); } To minimize the chance of anything going wrong, or of somebody staring at the code and STILL thinking that v *= R will somehow do v = v*R, I'm removing the ifdef but using the IDENTICAL code to transform -- pp.transform(m). HepLorentzRotation operator * (const HepRotationX & r, const HepLorentzRotation & lt); It is unclear as to whether I intended to excise these "second-order" combinations or not (once HepNRotationInface was gutted, they no longer worked automatically, and there are MANY combinations -- eg HepRotationX * HepBoostZ). But as long as these are present in the header, I might as well code them. While visiting LorentzRotation.cc, I noted some significant inefficiency in operator* ( const HepRotation & r, const HepLorentzRotation & lt): It was ignoring the fact that much of r is known to be 0 or 1, and was taking (but never using!) rep4x4 of each. Also, the form of using accessors can be INCREDIBLY inefficient if a debug option causes the inlining to be missed; I have rectified this as originally intended, by using those rep3x3 and rep4x4. for RotationY and RotationZ void decompose (HepRotation & rotation, HepBoost & boost) const; void decompose (HepBoost & boost, HepRotation & rotation) const; These were simply missing from the RotationY.cc and .icc files (and similarly for Z); they are there for X. It was easy to reproduce them as needed. inline HepRotation operator * (const Hep3RotationInterface & r) const; This was meant to be excised; it is also missing for RotationX, but was excised from its header long ago. I am taking this out of these headers. In LorentzRotation.h: inline friend HepLorentzRotation inverseOf ( const Hep4RotationInterface & lt ); This was meant to be excised. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ 7/15 -- Fixed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 7/18/03 ----------------- Checked in to cvs. Will be in CLHEP 1.9.3. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 009: Incorrect isNear for specialized axial boosts, against general Lorentz Rotations Initial Bug Report 7/14/03 ------------------ Version 2.2 / CLHEP 1.9.2 Scott Synder reports that in HepBoostX::isNear(const HepLorentzRotation & r) the answer is jumbled du to incorrect ordering of operations. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bug Reproduced 7/14/02 -------------- MF notes that Scott's analysis is correct. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ Fixing immediately. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 7/15/03 ----------------- Checked in to cvs. Will be in CLHEP 1.9.3. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 008: Incorrect RotationZ*Rotation Initial Bug Report 7/14/03 ------------------ Version 2.2 / CLHEP 1.9.2 Scott Synder reports that in operator * (const HepRotationZ & rz, const HepRotation & r) the zz matrix element is wrong. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bug Reproduced 7/14/02 -------------- MF notes that Scott's analysis is correct, this is a typo in the trivial last element. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ Fixing immediately. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 7/15/03 ----------------- Checked in to cvs. Will be in CLHEP 1.9.3. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 007: Euler Angle inaccuracy Initial Bug Report 4/22/03 ------------------ Version 2.2 / CLHEP 1.8.3 Alexander Skiba reported that the eulerAngles() method of HepRotation produces badly flawed results in certain circmstances when the rotation matrix has strayed from perfect orthogonality. Although the example sent explictly introduces such devations, he further claims that deviations due to normal roundoff have been seen to lead to this problem, in which HepRotation R; // R is not perfect HepEulerAngles e = R.eulerAngles(); HepRotation R2 (e); // At this point, R2 can be significantly different from R! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bug Reproduced 4/24/02 -------------- MF notes that this results from division of a quantity in the Z row or column, by sin(theta). When the rotation is very nearly about the Z axis, both the numerator and denominator will be quite small; thus the result is numerically unstable against accumulated roundoff error from early computations. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ The fix is to use an expression in which the quantities which become small when sin(theta) is small appear identically in the numerator and denominator (and thus cancel). This only be done by computing the combinations phi+psi and phi-psi from values of Rxx, Rxy, Ryx, Ryy. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 4/30/03 ----------------- version 2.2 / CLHEP 1.8.4 Checked in to cvs. Will be in CLHEP 1.8.4. The mathmatical details of the problem and the numerically stable algorithm can be found in eulerAngleComputation.ps. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 006: Build cleanup needed Initial Bug Report 3/03/03 ------------------ Version 2.1.2 Due to CLEHP not using ISOcxx and thus Exceptions being mocked up, various PhysicsVectors tests that depend on sophisticated use of the package now fail. Also, the effects ofthe merge invalidate some things the tests are doing. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ This requires trickery to allow ZMexceptions to work in a situation where (for CDF) excpetions may be disabled without the right DEFECT set. The trickery is in the ZOOM_SRT GCC.mk and KCC.mk files. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 3/18/03 ----------------- version 2.1.2 Checked in to cvs. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 005: Possible range problem in theta() Initial Bug Report 5/16/02 ------------------ Version 2.1 Jim Kowalkowsi points out that if you take a Rotation where due to roundoff rzz > 1 by a tiny amount, then take thetaZ() of that Rotation, you are taking acos(rzz) which bombs. The key point is that the Geometry3D package IS capable of producing such an ill-formed Rotation, so this problem affects CDF. Bug Reproduced 5/16/02 -------------- MF notes that this will be an easy fix; a simple check and pin gives the correct result. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ Will make this change, and also check other places where acos is not protected by checks and ZMthrowC's. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 5/16/02 ----------------- version 2.1.1 Checked in to cvs. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 004: Non-initialized base class Initial Bug Report 11/23/01 ------------------ Version 2.0.3 Pere Mato at CERN points out that the copy constructor for HepRotation does not explicitly initialy the (pure virtual) base class Hep3RotationInterface. This leads to a compiler warning in some cases. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bug Reproduced 11/26/01 -------------- MF notes that this will be an easy fix, as the base class involved is pure stateless interface so the default constructor can just be used (before any data member initialization). It will be necessary to check on ALL the various ctors; for example, HepLorentzRotation almost certainly has the same issue. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ Will go thru the code and add interface ctor() as needed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified 11/27/01 ----------------- version 2.1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ================================================================== 003: polarAngle negative Initial Bug Report 11/21/01 ------------------ Version 2.0.3 S. Snyder points out that contrary to documentation, v1.polarAngle(v2) gives negative results if v1.theta() ------------------ Version 2.x.x - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bug Reproduced -------------- MF sees the problem and has discussed it with PC for a solution. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Repair Plans ------------ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of repair ---------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of repair ---------------- * * (in long-running problems might need more than one) * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Problem Rectified ----------------- version x.z - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Ongoing Caveats --------------- * * * ==================================================================