Hi all,
Ok, I'm back with more silly stuff. I'll present a few recommendations
on Event formats in the hope that this may spark some debate on this.
Event Formats (revisited):
--------------------------
I've been looking a bit more into the class BrEvent and TTree, and
their siblings, following the recent discussion on the list, and have
learned a bit more. Let my try to summarize:
First of, I agree with Flemming and Kris, that the BrEvent format is
_very_ general and applicable in almost any circumstances. Also, it is
very flexible, and supports nice dynamic expansion etc., altogether
nice features for such a scheme.
However, I do not agree that the BrEvent scheme is much faster then
the one provided by TTree. In fact, the BrEvent scheme is likely to
have many more calls to new/delete (heavy methods) then the TTree
one, because of the internal use of TObjArray in BrDataTable and
BrEventNode.
Also, once the data is written to disk, using TTree and TClonesArray
makes for a much more user-friendly, not to say memory-friendly,
interface then BrEvent does. After all, reading even the tiniest bit
of a BrEvent, requires you to load all of the BrEvent object into
memory (if I'm wrong, please tell me so). This can be avoided by using
TTree and TClonesArray. The user-friendliness comes from the high
degree of granuliarity avaliable in TTree, by using TClonesArray's and
many TBranches.
The possibility of chaining many files with a TTree into one `file' is
also a nice feature of class TTree, that isn't directly supported in
the BrEvent class. Using TTree it's also possible to write different
parts (TBranch's) to seperate files on disk, thereby circumventing the
2GB file limit on Linux for example.
Using BrEventIO to write the BrEvent object to disk, it's possible to
make chains however. Because of the internal use of TObjArray (rather
then TClonesArray) in BrDataTable, and the way BrEventIO write a
BrEvent to disk, it's not possible to split a specific parts of a
BrEvent onto seperate files, as is the case for TTree.
However, the TTree class isn't all that flexible as the BrEvent class
is. It requires a fairly good knowledge of the data structure you want
to store on for it to work really good, at least at write time. (I'm
not completly sure of this point, but it's my ipression anyway.)
Also, in BrEvent objects, it's possible to go to any desired nesting
depth, via the BrEventNode class. In the case of Raw data, the current
BRAT uses a nesting level of 5:
BrEvent->BrEventNode->BrEventNode->BrDataTable->BrDataObject
"Event" "FS" "FFS" "T1" "TPCSequence"
In a TTree it's only possible to go to a nesting level of 4:
TTree->TBranchObject->TBranchClones->TBranch
However, all of these levels will be visible in the ROOT Browser,
which isn't the case for BrEvent, where only the BrEvent objects will
shown.
In conclussion: While the flexibility of BrEvent is what is needed in
the step from Raw/Geant data to Reconstructed data, a think much could
be gained at later stages using the TTree class, where the data
structure is pretty well known. In short, using BrEvent for Raw/Geant
data is fine, but after reconstruction I recommend switching to TTree
and TClonesArray with a high level of granularity.
BrEventIO:
----------
It's seems that an object of class BrEventIO is written to disk when
using this object to write a BrEvent to disk. This object is given the
key "BRAHMS ROOT I/O File". This is a rather unfortunate name, since
the method "TFile::Get(const Char_t*)" interprets the '/' as a
directory seperator, rather then a part of the name of the BrEvnetIO
object on disk:
root [2] file->Get("BRAHMS ROOT I/O File")
Error in <TFile::cd>: Unknown directory BRAHMS ROOT I
(class TObject*)0x0
Ofcourse it's still possible to get the object with:
root[3] file->cd();
root[4] TList* list = gDirectory->GetListOfKeys();
root[5] TObject *iofile = list->FindObject("BRAHMS ROOT I/O File");
but not so slick as the above method. I suggest renanming this object
to "BRAHMS ROOT IO File".
As with the table names in BrRawDataInput, I think that such names
should really be "#define"s, static data members, or global
variables. In fact, _all_ literal strings (except things like "READ",
"UPDATE", and "RECREATE") could be one of the three above. I'm not
saying these things should have been changed yesterday, rather I
recommend having this in mind when making new classes or updating
existing ones, as I gives users access to such names when ever and
where ever, needed, without looking through a number of source files.
I hope some of this will be of some use.
Cheers,
Christian -----------------------------------------------------------
Holm Christensen Phone: (+45) 35 35 96 91
Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305
DK-2200 Copenhagen N Web: www.nbi.dk/~cholm
Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Mon Mar 13 2000 - 13:51:50 EST