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 : Tue Jan 01 2002 - 17:50:43 MET