Merging ROOT files containing TTree

When merging two (or more) ROOT files containing a TTree (with hadd) it creates two separate ROOT trees (or at least keys) in the output file: one containing all of the data, and another containing only the data from the first-listed root file (in the hadd argument). This can be very confusing when trying to browse a TTree’s contents in the TBrowser.

To demonstrate this I wrote a small script:

void TreeTest(string locFileName, double locNumber)
	TFile* locFile1 = new TFile(locFileName.c_str(), "RECREATE");
	TTree* locTree1 = new TTree("testtree", "testtree");
	double locValue1 = new double(locNumber);
	locTree1->Branch("Value", locValue1);

And executed it in ROOT by calling:

root [0] .L TreeTest.C 
root [1] TreeTest("test1.root", 1.0);
root [2] TreeTest("test2.root", 2.0);
root [3] .q

And merged the files with:

hadd test_merge.root test1.root test2.root

And you can load up test_merge.root in the TBrowser and you’ll see two TTree keys. Like I said, this is very confusing, and a user could easily view the wrong one. Please fix this bug. Thank you!

I guess I should clarify that I’m using version 5.30/00 of ROOT.

[url]Aux;1 aux;2 aux3;

Yes, it is the same. But it was never fixed. There shouldn’t be two keys in the new file in the first place, regardless of their cycle. There should only be one (unless there’s some really good reason for it that I’m missing) because it is misleading in it’s current format.

I can be wrong but they should be the ‘cycles’: in a TFile you can have several version of the very same object (an histogram or a tree) but taken at different times. Usually they are indicated like “h;1”, “h;2”, …

Are you sure that when you simply “click” on the TTree (via the TBrowser) you can really get the “wrong” one?
Retrieving the TTree from a macro or a program with TFile::Get(<name_of_the_tree>) will give you the last (the younger) tree and so, in your case, the correct one… I’m quite sure…


In the TBrowser there are two different objects: they have the same name but different cycles. Depending on which one you pick in the TBrowser you pick the contents are different: one contains all of the information, and one only contains the information from the first TTree. You can easily duplicate this with the above code.

Yes, calling TDirectoryFile::Get() in a macro you get the correct one, but in the TBrowser you can indeed choose the wrong one. It’s not a huge deal but it’s confusing to those who are unaware of the phenomenon, and I would like the extra,old object to be removed for clarity.

Is a little bit boring but you can delete the previous cycle

Or, otherwise you can “patch” the hadd (is very simple) and add the “kOverWrite” flag to the TFile::Write() method…


But what I am asking is that the ROOT developers “patch” hadd for a future release :slight_smile:

Yes I understood. But if you need today… :wink:


This should be already fixed, you’re just using an old root version.