CLHEP and ROOT - Request for Comments

From: Peter Malzacher (malzache@fnal.gov)
Date: Thu May 20 1999 - 21:40:02 MEST


Hi,

as one of my homeworks problem after the ROOT workshop at Fermilab
I "rootified" the Vector package of CLHEP. But I have doubts
whether it is useful to release them to public use.
 
At the workshop it was agreed to "rootify" CLHEP. But it was
not too clear what the main purpose of these "rootification"
should be:
  - Is it to incorporate functionality in ROOT which is not yet there?
  - Or to use the codes written with CLHEP classes in ROOT without 
    changes?
  - Or is it to use ROOT I/O for CLHEP objects?
 
What is the main objective: Ease of use for ROOT users or for
CLHEP users?

To use CLHEP functionality in ROOT one has at least the following
options:

1. Include some of the functionality of CLHEP in ROOT, i.e. take 
   ideas, algorithms etc from CLHEP to enhance ROOT.
   
2. Rootify CLHEP or parts of CLHEP
     Minimal changes:
     - generate LinkDef.h (to use CLHEP as is)
     - insert ClassDef/ClassImp and inherit from TObject or TNamed
       (to use ROOT I/O)
     Medium changes:
     - change types eg: HEPDouble -> Double_t ...
     - change class names eg: HepLorentzVector -> TLorentzVector
     - change math functions eg min/max/sqrt .. to TMath::Min/Max/Sqrt
       (to get rid of CLHEPs TemplateFunctions.h)
     Maximal changes:
     - move to ROOT naming conventions 
       eg for member functions:  setX() -> SetX(), x() -> GetX(), ...
     - Change the comments to the ROOT documentation standards
       eg move or copy the member function description from the 
       header file to the source file. 

3. Wrapper / Adapter / Mixing classes in ROOT which delegates the
   work to CLHEP

For option 1 it is important to know which packages are needed in ROOT,
which functionality is missing. Which of the packages:
Combination, Geometry, Matrix, Random, Units and Vector
(see the CLHEP homepage: http://wwwinfo.cern.ch/asd/lhc++/clhep/ )
are needed in ROOT. It would be a one-time
effort. I think it would be difficult to reimport changes
of the CLHEP after that first step.

With options 2 and 3 one has to decide whether it is useful to include 
the full (fat!) interface of CLHEP or whether it should be minimized:
e.g. the new HEPLorentzVector class has three different access methods
to its components Fortran-like v(0) C-like v[0] and v.x() (there are a 
lot of similar examples in the random classes).

Option 3 seems to me the promissing way. 
  - There could be a version problem but if it is possible to include
    in CLHEP a version number which could  be inquired at runtime it 
    could be implemented in a save way. 
  - It would be an example of one of the main objectives of object 
    orientation: using and extending existing programs without 
    modifiying them. 
  - The responsibilities and the credits of the ROOT and the CLHEP team
    would be clearly exposed.
  - It would be clear to users where to look for the documentation.
  - The most important point: the maintance of such a scheme could 
    easily be semi-automated.  

The ROOT team has agreed to incorporate a "rootified" version of
the Vector package into ROOT. However I am not convinced that a
simple "rootification" is justified. I see the following two
problems:  
1. A set of classes along the lines of option 2 with medium changes 
   is ready. It would be easy to move it to the full ROOT naming 
   scheme, but than it would be more difficult to use existing code 
   (if one changes only types - a set of typedefs is all needed, 
   but if one changes memberfunction names ...). 
2. Is it useful to put the full (for historical reasons) fat 
   interface into ROOT. A leaner version would be much better for
   the normal ROOT user. 

In short: my feeling is that the current version is halfway between
option 1 and 3 and therefore not too usefull for an experienced CLHEP
user (he has to change his code), but to difficult to overloaded
for somebody who will just use a LorentzVector class in ROOT.


Peter Malzacher  
FNAL and GSI

email: P.Malzacher@gsi.de



This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:33 MET