[ROOT] TTree and R__zip: source buffer too big

From: Mike Kordosky (kordosky@mail.hep.utexas.edu)
Date: Thu Apr 05 2001 - 22:10:18 MEST


Hi,

I am using TTree to basically reorgaize some prexisting data collected in
a PMT testing station (for MINOS).  The basic testing entity is known as a
Run.  Each run contains some meta information (run number, testing mode,
temperatures, etc) as well as a couple of hundred TH1F (data is binned on
the fly by an automated DAQ).  My strategy has been to store the
histograms in a TObjArray (TClonesArray is not possible, even with no
splitting, correct?).  I also construct an associated TClonesArray in
parallel with the TObjArray of histograms.  Each entry of the clonesarray
is an object HistRef which encapsulates information about an associated
entry of the TObjArray.  HistRef contains an integer index which acts as a
psuedo pointer between the two.

My questions are the following:

(1) People who use TTrees: Does this sound reasonable?  The TObjArray can
be rather long (600+ TH1F).  If I want to access 1 histogram, I basically
have to load the whole array in from the TTree, right?  If I could use
TClonesArray would that still be the case? I could split up the TObjArray
into a few different branches, based on histogram type.  The problem with
that is (a) for some runs, not all branches would be filled. (b) Adding
new histogram types would require adding more branches.  Analysis code
would probably break in this case. I am not sure how serious (a) is?

(2) When filling this tree, I periodically get the following error:

R__zip: source buffer too big

This error doesn't happen for every run (TTree entry) and doesn't
correlate with the size of the run in any noticable way.  How can I
understand and deal with this message.  My tree filling program doesn't
terminate when this happens.

I am running ROOTv3.00/06 on a Compaq AlphaStation xP900 running RedHat
6.2 with egcs-2.91.66.

Sorry for being so long winded!
Thanks,

Mike Kordosky



This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:41 MET