> Christoph Borgmeier wrote: > > Hello Rene, > > I sent you a lengthy description of my event and track classes on Friday. > Now it looks like I already understand a little bit more: > > If I store a pointer to an entry of a TClonesArray, the entry seems to be > serialized independently of the TClonesArray. So the data of the pointer > exists twice in the file. In my current work, this is acceptable, because > the major part of analyses will be done only on the trigger particles. > You must distinguish between the split and no-split method. In the no-split method, if the object you are written out is a hierarchy of other objects, these objects, in turn, pointing anywhere, thus creating a graph structure, ROOT will serialize all the referenced objects in the output buffer, taking care that objects referenced multiple times are written only once. When you will read back the buffer, the super object will be rebuilt in memory with all pointers correctly set. If now, you use the automatic split method, when you create your branches of a TTree, you must be more careful. You may end up in the situation that you describe where an object is going to be saved in multiple branches. This is essentially why we use the wording "TTree" to reflect the hierarchical nature of this facility. To use the split method, you must effectively ensure that your branches do not have pointers to branches other than daughter branches. For this reason, it is sometimes more appropriate (and also less expensive) to use small integers as a reference to a track number (in a list) rather than a direct pointer to the track. > But I found out, that I still have a design problem. I was used to have > the CLHEP classes Hep3Vector, HepPoint3D, and HepLorentzVector, which > allowed to treat tracks as geometrical objects and simplified distance > calculations and projections. Then I noticed that these ideas are not > present in the root examples, that the Event/Track example and also > ATLFAST contain only `flat' classes, which are mainly collections of > scalar entries. Will there be a kind of common three dimensional geometry > in ROOT? > You can perfectly make a Track class using all the 3 classes quoted above. By the way, the next version of Root will include this kind of classes as well as Matrix classes. More news about this soon. > Now I still run into a concetional problem. A simply class to describe a > straight Monte-Carlo track might look like this: > > class MC_Track: public TObject > { > ... > ... > private: > MC_Vertex* fCreationVertex; > MC_Track* fMotherParticle; > MC_Track* fDaughterParticle; > ThreeVector fMomentum; > Float_t fLength; > }; > > Now I would not want to store the daughter particle, because it is > redundant, and because just reading the trigger particles would result in > reading effectively the entire event. > > Do I understand it right, that I have to write my own Streamer function > with a line like > > if( fMotherParticle!=0 ) fMotherParticle->fDaughterParticle = this; > > and that I must not use any splitting of MC_Track to have the Streamer > function called? What you should do is to create a TClonesArray of tracks as shown in root/test/Event. Instead of your class structure above, simply have: class MC_Track: public TObject { ... ... private: Short_t fCreationVertex; Short_t fMotherParticle; Short_t fDaughterParticle; ThreeVector fMomentum; Float_t fLength; }; > > Is there the possibility to just read one Object (not one `column') of a > TClonesArray? > Not in a TTree unless you have a fixed number of tracks and amke one branch for each track. > If you think, these things are interesting enough, would you please reply > via the mailing list? > done Rene Brun
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:26:22 MET