I have a script that reads in 3 data files and creates a TChain out of the 3 data files. I then perform simple selections on the tree w/ a TCut. I noticed that the results from the selections were wrong so I test each individual tree in the files and saw that the sum of the individual selections did not match the chained selections. I have an example tar ball here:
/afs/cern.ch/user/g/griffith/public/tree.tgz
The idea of the script is to load in the three files as a chain of tree w/ name ‘VisMassCycleTree’ and to simultaneously fill a vector<TTree*> so that i can compare the selections on the Trees vs the Chain. I assume the problem is with one of the files having the branches written in a different order than the other two trees. If I do TTree::Print on the three trees I see this:
I don’t see how this should matter though since the selection is defined for each tree in each file and further each tree has the same branches with the same types albeit in a slight different order. And it is certainly this middle Tree that is causing all the grief.
I Mean GetEntries and not Draw. Also I had commented out 3 vital lines in my script. I have fixed that in my afs public now. Finally I run the script w/ aclic
*Br 26 :VIS_MASS_1 : generic_pad31/B *
*Entries : 16736 : Total Size= 17589 bytes File Size = 1736 *
*Baskets : 4 : Basket Size= 32000 bytes Compression= 9.85 *
*............................................................................*
*Br 27 :VIS_MASS_2 : generic_pad32/B *
*Entries : 16736 : Total Size= 17589 bytes File Size = 4253 *
*Baskets : 4 : Basket Size= 32000 bytes Compression= 4.02 *
....
*............................................................................*
*Br 71 :VIS_MASS : generic_pad72/B *
*Entries : 16736 : Total Size= 17599 bytes File Size = 571 *
*Baskets : 4 : Basket Size= 32000 bytes Compression= 29.95 *
where the issue is not the ordering but the name of the leafs (padXY). When a TTree is created using the leaflist technique, since each branch might contain more than one leaf, the branchname is only a ‘convenience’ alias to the full leaf name (based on the first TTree in the chain). So when you refer
to ‘VIS_MASS’ depending which file you might be refering to VIS_MASS.generic_pad72 or VIS_MASS.generic_pad31 … whichever alias is picked is used throughout the whole chain (hence those entries exist in only 1 or 2 of the 3 files …
You best bet is to always use the same name for the branched and for the leaves when creating them.
Thanks for looking into this. So if I change the name of the branch in the middle of a tree fill, is it possible to change every needed parameter? As of now I do:
br->SetName(blah);
should I add:
br->GetLeaf()->SetName(blah)?
Also curiously if I just use hadd on the files, the combined tree works exactly as I’d expect.
[quote]So if I change the name of the branch in the middle of a tree fill, is it possible to change every needed parameter?[/quote]Even-though you might be able to pull this off, you really should not. Instead you should make sure the branchname/leafname are consistent when you first create/add them to the TTree.
[quote]Also curiously if I just use hadd on the files, the combined tree works exactly as I’d expect.
[/quote]Indeed, hadd match the branchname and ignore the fact that the underlying leafname are different…
Right I thought that there was some technical reason w/ my personal code that prevented me from naming the branches properly from the outset, but there really never was a reason.