PhysicsVectors Package and CLHEP Vector Package -- Feature Log Enhancement 006: Addition of key info to exception classes Statement of suggested enhancement 10/10/03 ---------------------------------- version 2.2.2 Bill Tanenbaum requests information in the various thrown exception classes. For example, ZMxTachyonic could provide the offending vector. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Technical Information --------------------- This is a fair amount of work, for four reasons: 1) We have to instrument each place where the ZMthrow occurs, to add an argument with the desired info. 2) We have to indiviually provide headers for each class instead of relying on a single macro. And we have to provide explicitly the ctors for each; also if the new info is to be obtained via an accessor, those methods need to be written. 3) Since now the ctors are supplied with an additional argument, we have to decide how the ZOOM exception classes will be modified to accomodate them. If they all have exactly one extra argument this may be OK; otherwise the class macros will become useless and we may need to individualize classes. The ZOOM Exceptions package was designed with this in mind, but it is not at all a trivial step to take en masse. 4) Testing for this sort of stuff involves a bit of thought, becuae we need to be able to generate each type of exception. There are about 20 types of exceptions, and they appear in about 50 places. The full enhancement could take 1 day to get the ZOOM approach right, then 5 minutes times 50 instances, then 15+ minutes times 20 classes times 2 for ZOOM exceptions and CLHEP version for implementation; then 50 cases times about 20+ minutes for testing; with contingency, my estimate would be 6 days. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Decision -------- We should wait a while; if any particular type of exception could benefit hugely from adding a piece of info, we could perhaps do it on a one-at-a-time basis. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Plans and Priority ------------------ Priority is low, unless and until CMS or another user really has a situation whehre they could use specific information. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of implementation ------------------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Enhancement Done ---------------- ================================================================== Enhancement 005: Removal of exit() in favor of exceptions in CLHEP line Statement of suggested enhancement 10/7/03 ---------------------------------- version 2.2.1 The CMS crowd points out (I heard this from Bill Tanenbaum, but people all the way up to Innocente were concerned) that it is not nice to exit() when some problem crops up -- in their case, a tachyonic vector supplied to a boost. The package should instead throw an exception, which they could then catch and move to the next event. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Technical Information --------------------- The tachyonic vector was being produced in a routine of Geant4, due to a minor peculiarity of Pythia or another event generator. If the ZOOM version was in use, they could set the code to handle the situation, or they could catch the exception. The CLHEP version exit() was harder to recover from. It should be possible to modify the ZMthrowA macro to throw instead of exiting. Fortunately, the changes are localized to ZMxpv.h and .cc; the pseudo-throws in code are already of the proper form. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Decision -------- This has considerable profile, and will be implementated and checked in to both FNAL and CERN ASAP. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Plans and Priority ------------------ I will create a base class, derived from std::exception, called CLHEP_vector_exception. I will substitute for the defines for each exception type, defines that sets up (in ZMxpv.h and ZMxpv.cc) a class which is contructed taking a message string and has methods what() and name() to access the message. The decisions as to which proplems warrent abortion and which could be continued are completely separate from this matter and will be left unchanged. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of implementation ------------------------- 10/9/03 Work started 10/10/03 WOrk completed, tested, checked in. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Enhancement Done ---------------- Will appear in CLHEP 1.8.0.2 and PhysicsVectors 2.2.2 ================================================================== Enhancement 004: Removal of virtuals in operations involving Rotations Statement of suggested enhancement 1/29/02 ---------------------------------- version 2.1 Evgenyi points out, after investigating a slowdown in Geant4 using CLHEP 1.7 noticed by Makoto Asia: The operations R*v and R*R are musch slower (factor of 3.5 and 2.3) in CLHEP 1.7 than they were in 1.6. This is contributing to a factor of 1.2 slowdown in Geant4. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Technical Information --------------------- The reason is that the function (actually operator()(v) is virtual and the calling overhead is large relative to the work, which was inlined in CLHEP 1.6. If we can inline this method the unfavorable difference will go away. Unfortunately, the function is virtual in Hep3RotationInterface precisely to allow polymorphic use of rotations of various kinds. The reasoning behind that dates back to the original committee design, but is based on efficiency arguments. But now floating point is so fast and pipeline breaking is so expensive that these arguments actually work in reverse! Fortunately, neither CDF nor D0 ever use the base classes, or use Rotations in a polymorphic manner. Removing this ability will greatly simplify the code and may speed up Run II executables as well. We could try to have our cake and eat it by doing inline virtual. The consensus among MF, MP, WB is that this is not best because (1) compilers will still miss the optimization; (2) the simplification in removing the unwanted interface structure is considerable. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Decision -------- I will (pending approval by D0; CDF has already said OK) strip out the inheritance structure and inline all methods where this is remotely sensible. The interface classes will remain present for solid documentation of what every Raotion-like class can do, but these will no longer have a v-table at all, and nothing will inherit from them. NO methods will be inherited in the rotation classes. Actually, the rotation classes will call a method of the interface classes to get and set things like default tolerance. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Plans and Priority ------------------ This is a goodly amount of work; fortunately most is straightforward and in fact simplifies the package. I will start on it right away, since CLHEP users would like the improvement sooner rather than later. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of implementation ------------------------- 1/30/02 Work started 2/11/02 Changes made, compilation and testing started 2/21/02 Code works but there is a mystery in that full speedup was not achieved 2/28/02 Code works with mystery resolved 3/05/02 Final fix and check in. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Enhancement Done ---------------- Will appear in CLHEP 1.7.7 and PhysicsVectors 2.2 ================================================================== Enhancement 003: Matching operator>> to operator<< output Statement of suggested enhancement 11/13/01 ---------------------------------- version 2.0.3 Scott snyder points out: One's first expectation, absent good reason to the contrary, is that operator<< and operator>> should be inverses; that is, what you write out with operator<< you should be able to read back in with operator>>. However, that's not so for some of the Vector classes. For example, the HepEulerAngles class puts out is output like this (phi, theta, psi) but expects to read input in the form phi theta psi (no punctuation). ... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Technical Information --------------------- Scott is right. Fortunately the fix can be made WITHOUT affecting the behavior of existing correct programs: It is "just" a matter of increasing the flexibility of operator>>. This will take some work, along with some testing, but it is straightforward. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Decision -------- I will provide the improved operator>>. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Plans and Priority ------------------ A fairly extensive set of CLHEP mods having to do with HepPDT and gcc 3.0.1 are currently being worked on. These improved operator>>'s in CLHEP/Vector will be done and checked in after that major work is complete, and will be in that cut release. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of implementation 11/26/01 ------------------------- Done and tested for Hep3Vector, HepAxisAngle, HepEulerAngles, Hep2Vector. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Enhancement Done 11/27/01 ---------------- Turns out that HepLorentzVector already had this property, and that the Rotaion and LorentzRotation classes did not have operaor>>. ================================================================== Enhancement 002: Range of delta phi in deltaR() and azimAngle() Statement of suggested enhancement 11/12/01 ---------------------------------- version 2.0.3 Petar Maksimovic, speaking for a CDF group, points out that w1.deltaR(w2), as it stands, is not the useful quantitiy it is meant to be. The problem is that if v1.phi() is PI-epsilon, and v2.phi() is -PI+epsilon, then the delta phi used to compute deltaR() should be small, not almost 2*PI. Also, when told about aximAngle, PM stated that it was hard to see that this function was available; deltaPhi() would be a better name. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Technical Information --------------------- The problem is genuine and should be rectified. This problem, of course, is not restricted to LorentzVector::deltaPhi(). SpaceVector::deltaPhi() has the same behavior, and also the azimAngle() method without a reference direction has the same flaw. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Decision -------- I will fix the situation as follows: * v1.azimAngle(v2) will be modified to return an angle in (-PI,PI]. * v1.azimangle(v2) will also be given an alias of v1.deltaPhi(v2). * deltaR() for Hep3Vector will utilize deltaPhi(). * deltaR() for LorentzVector will return deltaR() of its 3-vector part. * Appropriate documentation changes will reflect these range normalizations. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Plans and Priority ------------------ A fairly extensive set of CLHEP mods having to do with HepPDT and gcc 3.0.1 are currently being worked on. These changes in CLHEP/Vector will be done and checked in before that major work is complete, but will not be cut as a release till afterward. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of implementation 11/13/01 ------------------------- v1.azimAngle(v2) has been fixed. deltaR() has been fixed (both cases) but is not using azimAngle(). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Enhancement Done 11/14/01 ---------------- Will be in version 2.1 ================================================================== Enhancement 001: eta(0) Statement of suggested enhancement 8/22/01 ---------------------------------- version 2.0.3 Gustaaf Brooijmans has code which occasionally takes eta() of a zero vector. He would find it more convenient if the value returned were 0 instead of 1.0E72. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Technical Information --------------------- The code, inherited from ThreeVector, is HepDouble Hep3Vector::pseudoRapidity() const { HepDouble m = mag(); if ( m== z() ) return 1.0E72; if ( m== -z() ) return -1.0E72; return 0.5*log( (m+z())/(m-z()) ); } This is mathematically proper. For a zero vector, however, it does make some sense to return 0, in the following sense: 1) If the vector is looked at as a vector with 0 z component and perhaps a tiny transverse component, then the answer would be zero. 2) If the vector is looked at as a vector along the Z axis, then the answer is infinite but with the same sign as z. For z=0, zero makes more sense than plus or minus a large number. I would recommend adding the line if (m==0) return 0.0; However, this does change a behavior in a CLHEP class, and I don't know how well the CLHEP people would like this. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Decision 11/15/00 -------- Given no objections in three months now, we will do it. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Enhancement Done 11/15/00 ---------------- Version 2.1 ================================================================== Enhancement xxx: brief name Statement of suggested enhancement DATE ---------------------------------- version x.y.z X. Y. requests ... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Technical Information --------------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Decision -------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Plans and Priority ------------------ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Status of implementation ------------------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Enhancement Done x/xx/xx ---------------- ==================================================================