Re: [ROOT] TParticle, TMCParticle etc

From: Rene Brun (Rene.Brun@cern.ch)
Date: Wed Apr 18 2001 - 16:58:47 MEST


Hi Axel,

A remark about TParticle.
This class is heavily used by many applications.

Concerning your proposal about the PDG tables, did you investigate
the existing classes TParticlePDG, TDatabasePDG, TDecayChannel, etc ?

http://root.cern.ch/root/htmldoc/TDatabasePDG.html
http://root.cern.ch/root/htmldoc/TDecayChannel.html
http://root.cern.ch/root/htmldoc/TParticlePDG.html

Rene Brun

Axel Naumann wrote:
> 
> Hi,
> 
> first of all: If we should move this discussion to some other list please
> tell me.
> 
> So here's what I'd think of a general particle implementation:
> 
> TKinematicObject: member TLorentzVector. May have member methods like
> GetHelixParams(BField) etc.
> 
> TParticle: public: TKinemObj; member: particle ID, PDGData (I'll talk about
> this later), 2 links to vertices (parent, daughter).
> 
> TVertex members: TPoints3D, link to 1 incoming TParticle, list of links to
> outgoing particles.
> 
> Reason to have a seperate TKinematicObject: you could derive e.g. a TJet
> from that, just adding width, em/had ratio etc.
> 
> The point is we don't need a different TParticle for MonteCarlo and
> reconstructed particles: Both have the same properties, e.g. a mass
> calculated from the Lorentz vector, some quark-methods (does it contain a
> b?), etc. And the MC generator information should be stored as part of the
> event, not for each particle.
> 
> So where's the PDG data? Well, in my opionion you don't want to store that
> data as a particle: It has no track, no vertex etc. And it's not really part
> of the particle either; e.g. why should you substitute a particle's mass
> calculated from its Lorentz vector by the PDG mass?
> 
> So why not having a singleton TPDGBook, which acts as a database for
> particle data: You ask it for e.g. a mass, giving a particle ID. The data
> would come in classes of TPDGParticleData (I added the "Data" to viualize
> that this class does NOT derive from TParticle): public TObject, members are
> fMass with a corresponding GetMass() etc. You ask the TPDGBook for a link to
> a TPDGParticleData giving a particle ID. This can be stored by the TParticle
> and returned in GetPDGData. So you'd have both TParticle::GetMass() (from
> the Lorentz vector) and TParticle::GetPDGData().GetMass().
> 
> The PDGBook entries are a map <ID, TPDGParticleData> created automatically
> by parsing the PDG data sheet (I've heard there's a computer parsable list).
> As such it might be better to have TPDGBook2000, TPDGBook2001 etc, all
> deriving from one ABC TPDGBook (maybe with a TPDGManager with which the
> available TPDGBooks register so you can select one, so we can phase out old
> PDG versions independently whenever we want...)
> 
> Well, that's how I'd see the TParticle implementation. And I'm even willing
> to help with its implementation (I need it anyway...).
> 
> Regards, Axel.
> 
> PS: Now that I've had a look at TPoints3D - why does TABCPoint3D not derive
> from TPoint2D? And why are TPoint2D's members declared as pivate and not
> protected?
> 
> > -----Original Message-----
> > From: owner-roottalk@pcroot.cern.ch
> > [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Pasha Murat
> > (630)840-8237@169G
> > Sent: Monday, April 16, 2001 6:07 PM
> > To: Axel Naumann
> > Cc: roottalk@pcroot.cern.ch
> > Subject: Re: [ROOT] TParticle, TMCParticle etc
> >
> >
> > Axel Naumann wrote:
> > >
> > > Hi,
> > >
> > > I have some questions to the particle section of root:
> > >
> > > * Could the particles inherit from TLorentzVector instead of
> > having members
> > > like angles, momenta, etc?
> > >
> > > * TParticle is already a very specific implementation of a
> > generic particle
> > > class and due to its name it's blocking more general ones -
> > which should be
> > > called TParticle instead. I know I could make it "invisible"
> > for my classes
> > > or rename it - but I'd prefer if you could either rename it,
> > make it general
> > > (such that e.g. TMCParticle and TParticlePDG can inherit from
> > TParticle) or
> > > get rid of it. It doesn't look too much supported and developed
> > anyway (no
> > > accusation here, it might even be better to take it out of the
> > root package,
> > > I think it's too specific and too "applied")...
> > >
> >
> > Axel: the question of how the "right" HEP particle classes should
> > look like and
> > how they should be called is pretty delicate and sensitive, so
> > why don't we discuss
> > it as discussion could help somebody to implement the right
> > thing? To start the
> > discussion - could you describe how you see a generic particle class in a
> > little bit more detail? - I personally would like to see very
> > much how you combine
> > in one generic class 2 features mentioned above:
> >
> > a) it is a 4-momentum and
> > b) it could be a base class for TParticlePDG
> >
> > On the subject of one of the classes you mentioned: TParticle it
> > is a reasonably
> > well implemented and handy description of MCgenerator-level
> > particle. For this purpose
> > it is pretty generic. The fact that it is simple reflects nothing
> > but simplicity of MC
> > particle thing itself. For the moment there is no better
> > replacement for it, I
> > personally also don't see if it misses anything serious. We're
> > using it for quite
> > a while and are quite happy with it. Customized Streamer won't
> > hurt, but this is
> > already a detail. Anyway, until there is a better replacement,
> > I'd vote for TParticle
> > to stay as it is.
> >                                               best, Pasha
> >



This archive was generated by hypermail 2b29 : Fri Jun 08 2001 - 11:51:23 MEST