Re: TTree::AutoSave()

From: Rene Brun <Rene.Brun_at_cern.ch>
Date: Wed, 30 May 2007 23:27:40 +0200


Two remarks:
 -You should not draw any conclusion from a gadget file less than one MByte, in particular

   considering the next point.
 -I do not understand why you need to have 17 ntuples in a G4 simulation. You have something wrong
  in your data model. Most simulation applications that I see produce one single Tree in output.
  This is simpler to handle and it is more efficient in space and time.

Rene Brun

Tom Roberts wrote:
> Rene Brun wrote:
>> It looks like your Tree has a small number of entries and all entries
>> fit in memory in the branch buffers,
>
> I don't know. The file without calls to AutoSave() is 326 kbytes, with
> a dozen calls is 589 kbytes -- clearly small enough to fit in memory.
> This is 1,000 events.
>
>
>> or more entries but with very large buffer sizes. I can tell you more
>> if you send the result of TTree::Print.
>
> Well, I'm removing the calls to AutoSave(), as in practice it's easier
> to re-run a crashed job than to deal with the hassle. My users are
> non-experts, and having two copies of every TNtuple is confusing.
>
>
>
> Is there really no way to "checkpoint" all of the TTree-s (or
> TNtuple-s) in a TFile so that if the program crashes the file can be
> opened and used up to the last checkpoint? Without keeping a second
> copy of all the data or a second version of each TTree.
>
>
>> Note that, in general, it is a very bad idea to have many Trees in
>> the same file. It is more efficient
>> to have one single Tree with more branches.
>
> This is a Geant4 simulation that was based on HistoScope (now
> defunct). It generates 17 different TNtuples, and they cannot be
> combined; we find it more convenient to have 1 root file than 17. I
> have written a Root macro that essentially performs the duties of the
> old "histo" program (i.e. easily and interactively generate histograms
> from TNtuples, with sliders for cuts). Efficiency is not a problem, as
> even a 250k event TNtuple can be re-scanned as I move a slider without
> undue delay (it's great to have such computing power in a laptop!).
>
>
> Tom Roberts
>
>
>>
>> Rene Brun
>>
>>
>> Tom Roberts wrote:
>>> When I use TTree::Autosave() on a tree in a TFile, I get two copies
>>> of the TTree as expected (different versions), but the file is
>>> roughly twice as large. As I am making files that are quite large,
>>> doubling their size is not acceptable. Note my TFile contains many
>>> TTree-s, and I call AutoSave() on all of them every N events
>>> (N=100000 by default).
>>>
>>> Is there any other way to "checkpoint" the output file so if the
>>> generating program crashes I can still recover most of the data that
>>> was written to the .root file, without doubling the size of the file?
>>>
>>> In a related question: how does TFile::Flush() relate to such
>>> "checkpoints"? My guess is that partly filled buffers of the TTree
>>> are not written to disk, and for consistency this really needs to
>>> happen at the TTree level, not the TFile level.
>>>
>>>
>>> Tom Roberts
>>
Received on Wed May 30 2007 - 23:27:47 CEST

This archive was generated by hypermail 2.2.0 : Thu May 31 2007 - 11:50:01 CEST