Hi Rene,
Thanks for the update on the status of the new TTree branching
mechanism, and I'm glad to hear that good progress is being made
on Root version 3.01.
I have downloaded the most recent CVS version of ROOT to test
out some of the new features that you advertised. I find that I
can now successfully use the TTree::Draw method on TTree's
created with TTree::Bronch, and that the problem that I reported
using version 3.00.06:
http://root.cern.ch/root/roottalk/roottalk01/1264.html
does not occur with this developmental version. Thanks!
One thing that I am still unable to do with the CVS version I
downloaded today is to successfully implement the Simple example:
http://root.cern.ch/root/roottalk/roottalk00/1572.html
although you indicate in your most recent reply that this should
now be possible using TTree::Bronch. I am wondering if this is
because the features that will support this have not yet been
committed to CVS (still in your private version of ROOT), or
if it's an indication that I am doing something wrong?
-Sue
Rene Brun wrote:
> Hi Sue,
>
> We are not making good progress with the implementation of the
> new Tree branching mechanism (TTree::Bronch).
> Our development version (3.01/00) includes several enhancements,
> including support for pointers to abstract classes in split mode.
> I tested that your example works correctly with our development version.
>
> To facilitate the migration to the new branches, I have added a new
> function TTree::SetBranchStyle(Int_t style=1) (a static function).
>
> To use the new branching mechanism, do TTree::SetBranchStyle(1);
> This will become the default very soon in the development version.
>
> With this new function, you can keep the calls to TTree::Branch.
> TTree::Branch will automatically call the new branches (TBronch)
> or the old TBranch depending on the branching style.
>
> In the development version, it is now possible to use TTree::Draw
> and the TTreeViewer.
>
> Our goal is to release this version in time for the ROOT workshop in June.
>
> Rene Brun
>
>
>
> On Thu, 12 Apr 2001, Susan Kasahara wrote:
>
> >
> > Hi Rooter's,
> > I have another TTree::Bronch question. Some time ago I posted
> > a message on ROOT talk digest:
> > http://root.cern.ch/root/roottalk/roottalk00/1572.html
> > regarding the capabilities of TTree::Branch to store objects
> > of my class "Simple" on a ROOT TTree in splitmode, where
> > this Simple class included a data member:
> > TShape* fShape;
> > that is actually the base class of the objects to be stored
> > on the TTree. The answer at the time was that TTree::Branch
> > could not support this situation, but that it would
> > be considered for future versions of ROOT.
> > I am wondering if it is expected that TTree::Bronch will support
> > this scenario? I am not able to get it to work in my tests
> > (using the same driver code and classes as posted on
> > http://root.cern.ch/root/roottalk/roottalk00/1572.html
> > but substituting:
> > simpletree -> Bronch("Simple","Simple",&simple,16000,1);
> > for
> > simpletree -> Branch("Simple","Simple",&simple,16000,1);
> > in the driver code),
> > but I notice that it fails now in the fill of objects to the tree and
> > not the read as before.
> > I am optimistic that it is at least a possibility, since TBranchElement
> > does not require the derived ClassName of the object to be stored there
> > as an argument (as did TBranchObject). I am using ROOT v 3.00.06
> > and gcc 2.95.2 on Linux.
> > -Sue
> >
> >
> > Rene Brun wrote:
> >
> > > Hi Sue,
> > >
> > > As I said in my previous mail, the split mode supported by the current
> > > TTree::Branch has many restrictions, including the one you mention
> > > about the TObjArray. The new split mode supported by TTree::Bronch
> > > has no limitations compared to the non-split mode. Bronch supports correctly
> > > the two cases: TObjArray and TObjArray*.
> > > With Bronch, the splitlevel can be used to control the depth of splitting.
> > > Try for example:
> > >
> > > tree -> Bronch("Validity","VldContext",&valid,32000,9);
> > >
> > > I encourage people to start playing with TTree::Bronch instead of TTree::Branch.
> > > However, note that, as indicated in the documentation of this function,
> > > one cannot use TTree::Draw or the TreeViewer with Trees created with
> > > TTree::Bronch in the production version 3.00/06.
> > > This already works in my development version (not yet in CVS).
> > >
> > > Rene Brun
> > >
> > > Susan Kasahara wrote:
> > > >
> > > > Hi Rene and Pasha,
> > > > Thank you both for your advice. I tried the TTree::Bronch method
> > > > as you suggested and it did successfully write out the enumerated
> > > > fDetector data member. I did notice that when I switched to the
> > > > TTree::Bronch method, i.e. from
> > > > tree -> Branch("Validity","VldContext",&valid,32000,1);
> > > > to
> > > > tree -> Bronch("Validity","VldContext",&valid,32000,1);
> > > > that the TObject base class of VldContext was not longer split
> > > > into two separate branches for the fUniqueId and fBits data members
> > > > as it was using TTree::Branch.
> > > > Is this to be expected?
> > > >
> > > > I have another TTree splitting question. I've noticed that when
> > > > I attempt to store a class in split mode that has a TObjArray data member , e.g.
> > > > class Event {
> > > > public:
> > > > ...
> > > > private:
> > > > TObjArray fData;
> > > > Int_t fEvtNumber;
> > > > };
> > > >
> > > > And store it on a tree in split mode:
> > > > TTree* tree = new TTree("TestTree","test tree");
> > > > Event* event = 0;
> > > > tree -> Branch("EventBranch","Event",&event,32000,1);
> > > >
> > > > That ROOT will attempt to split the TObjArray (to 7 branches), and since the
> > > > data member of the TObjArray which contains the array's data has been "!" out, ROOT will
> > > > not write the actual data of the TObjArray to the TTree.
> > > > On the other hand, storing the TObjArray by pointer as a data member of the
> > > > Event class, e.g.
> > > > class Event {
> > > > public:
> > > > ...
> > > > private:
> > > > TObjArray* fData;
> > > > Int_t fEvtNumber;
> > > > };
> > > > does seem to work since the customized Streamer of the TObjArray is invoked
> > > > to stream the TObjArray data out to a single ROOT TBranch.
> > > > I guess what I'd like is to preserve the Event structure of the first case (with
> > > > the fData TObjArray stored by value), but have the Event splitting results of the
> > > > second case, with the TObjArray data streamed out to a single ROOT TBranch.
> > > > Is this possible?
> > > > Thanks again,
> > > > -Sue
> > > >
> > > > Rene Brun wrote:
> > > >
> > > > > Hi Sue, Pasha,
> > > > >
> > > > > enums are not recognized by TTree::Branch in split mode.
> > > > > They are supported by TTree::Bronch in 3.00/06. You can make a test
> > > > > by replacing the line:
> > > > > tree -> Branch("Validity","VldContext",&valid,32000,1);
> > > > > by:
> > > > > tree -> Bronch("Validity","VldContext",&valid,32000,1);
> > > > >
> > > > > Read TTree::Bronch for more info.
> > > > > I am now finishing the implementation of the new split mode. The new split
> > > > > mode (Bronch) has no limitation compared to the non-split mode.
> > > > > With the next major release 3.01 scheduled for early June, Bronch will
> > > > > be renamed Branch. The new split/no-split mode in Trees will have several
> > > > > new features. In addition to the extended C++ support described
> > > > > at http://root.cern.ch/root/SchemaEvolution.html , the new Trees will also
> > > > > be connected with the TFolder structure. Trees can be generated automatically
> > > > > from an existing TFolder hierarchy and vice-versa a TFolder hierarchy
> > > > > automatically generated from a Tree structure.
> > > > > This new functionality will be included in the first development releases
> > > > > of 3.01 in 2 or 3 weeks.
> > > > >
> > > > > Rene Brun
> > > > >
> > > > > Susan Kasahara wrote:
> > > > > >
> > > > > > Hi rooters,
> > > > > > I am having a problem with the ROOT tree splitting method.
> > > > > > I have a simple class "VldContext" with just two data members:
> > > > > >
> > > > > > DetectorType::Detector_t fDetector;
> > > > > > Int_t fTimeStamp;
> > > > > >
> > > > > > The first data member is of an enumerated type Detector_t defined
> > > > > > in a separate class DetectorType. What I would like is to have these
> > > > > > two data members, fDetector and fTimeStamp, be stored on two separate
> > > > > > subbranches of the same TTree.
> > > > > >
> > > > > > I set up a tree with one main branch to hold these VldContext objects
> > > > > > in split mode (split level = 1), using the form:
> > > > > >
> > > > > > TTree* tree = new TTree("TestTree","test tree");
> > > > > > VldContext* valid = 0;
> > > > > > tree -> Branch("Validity","VldContext",&valid,32000,1);
> > > > > >
> > > > > > And have noticed that although a subbranch is created for the fTimeStamp
> > > > > > data member as expected, no subbranch is created for the fDetector
> > > > > > data member. I am assuming the problem has something to do with
> > > > > > fDetector's specialized enumerated data type that is somehow not being
> > > > > > recognized by ROOT.
> > > > > >
> > > > > > I am attaching the code for the test driver program, the VldContext
> > > > > > class, and the DetectorType class. These tests are being run on a
> > > > > > RH Linux system using gcc 2.95.2 and ROOT version 3.00.04.
> > > > > >
> > > > > > Any ideas as to how to fix this?
> > > > > >
> > > > > > Thanks,
> > > > > > Sue Kasahara
> > > > > >
> > > > > > **************** The test driver program **********************************
> > > > > > #include <iostream.h>
> > > > > > #include "TROOT.h"
> > > > > > #include "TFile.h"
> > > > > > #include "TTree.h"
> > > > > > #include "VldContext.h"
> > > > > >
> > > > > > TROOT root("TestWrt","MINOS Persistency Package Test Write");
> > > > > >
> > > > > > int main() {
> > > > > >
> > > > > > TFile* file = TFile::Open("test.root","RECREATE","test file");
> > > > > > TTree* tree = new TTree("TestTree","test tree");
> > > > > >
> > > > > > VldContext* valid = 0;
> > > > > > tree -> Branch("Validity","VldContext",&valid,32000,1);
> > > > > >
> > > > > > // Begin entry loop
> > > > > > Int_t nent = 100;
> > > > > > for (Int_t ient=0; ient < nent; ient++) {
> > > > > > DetectorType::Detector_t dtype = DetectorType::kCalib; // detector type
> > > > > > Int_t tstamp = 100;
> > > > > > VldContext* valid = new VldContext(dtype,tstamp);
> > > > > > if (valid) {
> > > > > > tree -> Fill();
> > > > > > }
> > > > > > delete valid; // clean up validity object
> > > > > > }
> > > > > >
> > > > > > tree -> Write();
> > > > > > tree -> Print();
> > > > > > file -> Close();
> > > > > >
> > > > > > return 0;
> > > > > >
> > > > > > }
> > > > > >
> > > > > > **************** The VldContext class **********************************
> > > > > >
> > > > > > #include "TObject.h"
> > > > > > #include "DetectorType.h"
> > > > > >
> > > > > > class VldContext : public TObject {
> > > > > >
> > > > > > public:
> > > > > >
> > > > > > VldContext();
> > > > > > VldContext(const DetectorType::Detector_t &detector,
> > > > > > const Int_t &time);
> > > > > > virtual ~VldContext();
> > > > > >
> > > > > > protected:
> > > > > >
> > > > > > DetectorType::Detector_t fDetector;
> > > > > > Int_t fTimeStamp;
> > > > > >
> > > > > > private:
> > > > > >
> > > > > > ClassDef(VldContext,1) // VldContext version 1
> > > > > > };
> > > > > >
> > > > > > #include "VldContext.h"
> > > > > >
> > > > > > ClassImp(VldContext)
> > > > > >
> > > > > > VldContext::VldContext()
> > > > > > {
> > > > > > // Default constructor
> > > > > > }
> > > > > >
> > > > > > VldContext::VldContext(const DetectorType::Detector_t &detector,
> > > > > > const Int_t &tstamp)
> > > > > > : fDetector(detector), fTimeStamp(tstamp)
> > > > > > {
> > > > > > // normal constructor
> > > > > > }
> > > > > >
> > > > > > VldContext::~VldContext()
> > > > > > {
> > > > > > // delete all the owned sub-objects
> > > > > >
> > > > > > }
> > > > > >
> > > > > > ********************The DetectorType class**********************************
> > > > > >
> > > > > > #include "Rtypes.h"
> > > > > >
> > > > > > class DetectorType {
> > > > > > public:
> > > > > > typedef enum EDetectorType {
> > > > > > kNear = 0x01,
> > > > > > kFar = 0x02,
> > > > > > kCalib = 0x04,
> > > > > > kTestStand = 0x08,
> > > > > > kMapper = 0x10
> > > > > > } Detector_t;
> > > > > >
> > > > > > // no ctor or dtor's - this class consists of only static members
> > > > > >
> > > > > > // Translation from enum to character strings
> > > > > >
> > > > > > static char *AsString(Detector_t detector) {
> > > > > > switch (detector) {
> > > > > > case kNear: return "Near"; break;
> > > > > > case kFar: return "Far"; break;
> > > > > > case kCalib: return "Calib"; break;
> > > > > > case kTestStand: return "TestStand"; break;
> > > > > > case kMapper: return "Mapper"; break;
> > > > > > default: return "Unknown"; break;
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > ClassDef(DetectorType,1)
> > > > > >
> > > > > > };
> > > > > >
> > > > > > #include "DetectorType.h"
> > > > > >
> > > > > > ClassImp(DetectorType)
> >
> >
> >
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:41 MET