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