Strange "overwriting" behavior of hadd in merging

Hello,

I just met a strange problem in merging root files with hadd. I noticed that the value of one variable (runNumber) become the same after the merging. You could see that the runNumber is 191301 in Tuple_1.root, 187901 in Tuple_2.root, but after merging, they all become 191301. It is quite strange, and I still don’t know whether there is such problem for the other variables. It is a big trouble.

The root files were generated with ROOT 5.18.00d on a 64-bit machine (SLC4).
/afs/cern.ch/sw/lcg/external/root/5.18.00d/slc4_amd64_gcc34/root/

There is such problem with hadd in the same version ROOT (Tuple_5.18.root) or 5.20.00 (Tuple_5.20.root). All the root files were attached for your reference. Could you please give me some hints where the problem is from? Thank you very much for your kind help.
Tuple_5.20.root (33.4 KB)
Tuple_5.18.root (17.7 KB)
Tuple_2.root (16.7 KB)
Tuple_1.root (17.5 KB)

I can reproduce the problem. We are going to investigate the cause and will let you know.
Meanwhile you can merge correctly your files by doing

hadd -f3 result.root Tuple_1.root Tuple_2.root
Rene

Hi,

I can also reproduce the problem, however I noticed that only 1/2 of the branches are in common between the 2 files. Is it really what you expect?

When merging these files, the branch that are in the first file but not in the others, will be filled either not be filled for those entries and filled with the value of the last entry of the last file where they were defined.

The issue in the ROOT code that it does not gracefully handle this type of discrepancies between the files …

Cheers,
Philippe.

Hi,

The problem has been fixed in the head of the SVN repository as well as in the patch branch for 5.18 and 5.20.

However, please note that the fix mean that the branches that are in both of your file will now be correctly filled in the output BUT the branches that are only the first file will not be correctly filled (since their is no information about them in the 2nd tree).

Cheers,
Philippe

Hi, Philippe,

[quote=“pcanal”]
I can also reproduce the problem, however I noticed that only 1/2 of the branches are in common between the 2 files. Is it really what you expect?[/quote]

Thank you very much for pointing out this.

I am a little (but not very) surprised to hear that the branches are different. Actually, I also suspected that there was some discrepancies between them and used “diff” to compare their header files. But I overlooked them. You know, the branch 0 in Tuple_1.root is the branch 1 in Tuple_2.root and vice verse… The discrepancies are more obvious by using “vim -d” (maybe you have more powerful tool?). So, these root files have the same branches, but the branches are not in the same sequence. I will try to dig out the problem in the tuple filling algorithm.

Just two more questions, in this case there would be (potential) problem even with TChain, right? And “hadd -f3” will not work, either?

Cheers, Jibo

Hello,

Thank you so much for your reply in the weekend.

Sorry, just a stupid question, how could I let the ROOT on our cluster be patched?

And I just noticed that the sequence of the branches are not the same. Could you please point out the branches that are only in the first file? You know, it is very helpful for our debugging of the tuple filling algorithm.

Cheers, Jibo

Hi,

[quote] So, these root files have the same branches, but the branches are not in the same sequence.[/quote]Actually, no. I only noticed that the sequence of branches was different and i had not noticed that they were actually the same set of branches in a different order.

So with the fix, all your branches should be correctly filled.

Without the fix, they would be correctly filled if they were in the same order in each file.

Cheers,
Philippe.