Linear Collider Forum



Home » Software Tools » LCIO » Proposal for 4-Vectors in LCIO
Proposal for 4-Vectors in LCIO [message #35] Wed, 17 March 2004 02:56
gaede
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
As has been discussed it would be desirable to provide support for 4-vectors in LCIO. For C++ the HepLorentzVector from CLHEP offers a lot of features in particular the Lortentz transforms.

The initial attempt to inherit MCParticle and Reconstructed particle from HepLorentzVector creates a number of problems:
  1. LCIO will depend on CLHEP
  2. MCParticle already has internal data for (P,E) that is of type float whereas HepLorentzVector has doubles. One could of course change the internal representation but then accessing the data via the LCIO API involves copying or one has to have two synchronized internal representations. Both options are not very efficient.
  3. Inheriting from HepLorentzVector undermines our mechanism for READ_ONLY and UPDATE mode. The user can change the 4Vector part even when the object is readonly (No way to prevent that, except for changing back to the 'const' objects in C++)
  4. After applying Lorentz transforms to the object the original data (from the generator or reconstruction) is lost. If you think of a modular analysis where one computes event shape variables in one module and then uses the transient LCEvent in another module the kinematics is screwed up. Analyses should be done in READ_ONLY mode and add only new collections to the event !


There is a simple solution to the problem: use an LCFourVector that inherits from HepLorentzVector and holds a reference to the
original LCObject. See the simplified UML diagram:
http://www.desy.de/~gaede/tmp/FourVector.png


This approach has several advantages:

  1. On instantiation the 4Vector data is copied once and can then be modified (transformed) independent of the original data.
  2. Then new object offers access to all methods of the original object, i.e. it can be used for all further analysis, no need to handle two objects. For C++ overloading the -> operator even allows to replace a pointer to an MCParticle with an LCFourVector object in existing code ! For example on has:
    typedef LCFourVector<MCParticle> MCParticle4V ;
    // ....
    //
    for(  int index = 0 ; index < nParticles ; index++){
      
    // 'old' LCIO code:
    // MCParticle* part =  dynamic_cast<MCParticle*>( col->getElementAt( index ) ) ;
    
    // new code with LCFourVector object:
      MCParticle4V part( col->getElementAt( index ) ) ;
    
      cout <<  " LCIO mass: "  << part->getMass()         
    	   <<  " LCIO E:    "  << part->getEnergy()      
    	   << "  4vec mass; "  << part.m()
    	   << "  4vec E:    "  << part.e() << endl ;
    
    }
    
    
    This even simplifies the lengthy dynamic_cast<> syntax for the user. For Java one would have one additional method returning the LCIO object, e.g.
       MCParticle4V part = MCParticle4V( col[i] ) ;   
       System.out.println(" LCIO mass: " + part.lcObj().getMass() 
                         +" 4Vec mass: " + part.m()  ) ;
    
  3. The READ_ONLY/UPDATE mechanism is preserved
  4. We can make the dependence on CLHEP (+Java version) optional, i.e. plain LCIO does not depend on anything. Only when users want the 4vector functionality they compile with CLHEP !



So I would propose to go ahead with this approach as it offers all the functionality that we need by avoiding the dependence on an additional library which was the main objection against introducing 4vectors.


Please comment !

-Frank.
 
Read Message
Previous Topic:MCParticle Tree Viewer
Next Topic:MCParticle-Hit-Assignment
Goto Forum:
  


Current Time: Thu Dec 12 08:43:39 Pacific Standard Time 2019
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.1.
Copyright ©2001-2010 FUDforum Bulletin Board Software