"TChain" for histograms? and hadd problems

Hi,

I have a simple question, is there a class that chains histograms like TChain chains trees? I am more after the nice feature that I just can “Add” files and I don’t have to get the pointer to each file’s tree.

The real reason is that I am having trouble with hadd, for some reason it suddenly doesn’t add my files anymore. I just added one tree and some histograms in my root file and now hadd always crashes with

SysError in <TFile::WriteBuffer>: error writing to file /tmp/test.all.root (-1) (Invalid argument)

And I get this error even if I only “merge” one file. If I open this file manually or if I use TChain to chain the trees there are no problems.

I tried 5.14.00 and also the latest 5.19.04.

Duc

What do you mean by “chaining histograms” ?
What is the problem with hadd? Could you post 2 files in a public area?

Rene

Hi,

of course “chaining” histogram makes no sense (it should be adding histograms across files), but I found the feature of TChain nice that I just can add the files and TChain takes care about the tree inside the file.

I put the two files, the working one and the faulty one in my public on AFS /afs/cern.ch/user/d/dta/public/

The files are named TopTuples.doMCUT.00001.root (working one) and TopTuples.test.00001.root (not working).

Thanks,
Duc

Hi,

I can reproduce your problem which are due to a couple of issues with the fast TTree Cloner when dealing with in-memory TTree (in the case where the TTree was filled before/without being attached to a file). To workaround those issue, you need to disable it by selecting of compression factor for the output file that is different from your input file. For example, do hadd -f2 output.root input.root

Cheers,
Philippe.

Hi,

thanks for the hint! I continued with my code today after I reported this to the forum and I actually had a message saying that there is a problem with the in-memory tree. I didn’t think that it has to do with this hadd problem and it only showed up after I added another variable to the tree in question.

I changed the order of tree and file creation for this particular tree (it is called infoTree which is separate to my tree that contains the analysis data, that is why it was created so early) and I will check the result.

Cheers
Duc

[quote]I changed the order of tree and file creation for this particular tree (it is called infoTree which is separate to my tree that contains the analysis data, that is why it was created so early) and I will check the result. [/quote]Changing the order of creation (or more exactly the order of writing) of the TTree will indeed work-around one of the issue. However the in-memory tree will still not be copyable by the fast cloner (you can work around this issue by making the TTree disk resident instead :slight_smile: ).

Cheers,
Philippe

Hi,

The problem has been completely solved in the svn head (and hence in the upcoming v5.20 production release).

Cheers,
Philippe.