Weird combination of AddFriend/Project causing a bug?!

Hello there,

Not sure this is the right place. I have a combination of TChain, addFriend, Project that seems to reveal what it looks like a bug, but maybe I am just wrongly using the tools. I am using ROOT 6.32.06.
I prepare some TChains :

TChain* mu_000 = new TChain("nt");
TChain* mu_140 = new TChain("nt");
TChain* mu_200 = new TChain("nt");

mu_000->Add("AOD.41864953._00*01.root");
mu_140->Add("AOD.41929789._00*01.root");
mu_200->Add("AOD.41929979._00*01.root");

Then I put then all together in a single TTree :

TTree *nt = new TTree();;
nt->AddFriend(mu_000,"mu_000");
nt->AddFriend(mu_140,"mu_140");
nt->AddFriend(mu_200,"mu_200");

And project into histograms :

TH2F* resolution_vs_pt_000 = new TH2F("res_pt_000","res_pt_000",100,0,100,100,-20,20);
TH2F* resolution_vs_pt_140 = new TH2F("res_pt_140","res_pt_140",100,0,100,100,-20,20);
TH2F* resolution_vs_pt_200 = new TH2F("res_pt_200","res_pt_200",100,0,100,100,-20,20);
TH2F* resolution2_vs_pt_000 = new TH2F("res2_pt_000","res_pt_000",100,0,100,100,-20,20);
TH2F* resolution2_vs_pt_140 = new TH2F("res2_pt_140","res_pt_140",100,0,100,100,-20,20);
TH2F* resolution2_vs_pt_200 = new TH2F("res2_pt_200","res_pt_200",100,0,100,100,-20,20);

mu_000->Project("res_pt_000","100.0*(offelpt-truthpt)/truthpt:truthpt*1e-3","truthpt>1e3");
mu_140->Project("res_pt_140","100.0*(offelpt-truthpt)/truthpt:truthpt*1e-3","truthpt>1e3");
mu_200->Project("res_pt_200","100.0*(offelpt-truthpt)/truthpt:truthpt*1e-3","truthpt>1e3");

nt->Project("res2_pt_000","100.0*(mu_000.offelpt-mu_000.truthpt)/mu_000.truthpt:mu_000.truthpt*1e-3","mu_000.truthpt>1e3");
nt->Project("res2_pt_140","100.0*(mu_140.offelpt-mu_140.truthpt)/mu_140.truthpt:mu_140.truthpt*1e-3","mu_140.truthpt>1e3");
nt->Project("res2_pt_200","100.0*(mu_200.offelpt-mu_200.truthpt)/mu_200.truthpt:mu_200.truthpt*1e-3","mu_200.truthpt>1e3");

When plotting, I can easily see that the results are similar, but one point in each histogram seems to blow up completely.

Also, I would like to change the coordinate of the Stat box when displaying some of the histograms created in a similar way a bit ahead :

resolution_000->Draw();
resolution_140->Draw("sames");
resolution_200->Draw("sames");
gPad->Update();

TPaveStats* pav000 = (TPaveStats *) resolution_000->FindObject("stats");
TPaveStats* pav140 = (TPaveStats *) resolution_140->FindObject("stats");
TPaveStats* pav200 = (TPaveStats *) resolution_200->FindObject("stats");
std::cout << "PAVs : " << pav000 << " " << pav140 << " " << pav200 << std::endl;

pav000->SetY1NDC(0.3);
pav000->SetY2NDC(0.5);
pav140->SetY1NDC(0.5);
pav140->SetY2NDC(0.7);
pav200->SetY1NDC(0.7);
pav200->SetY2NDC(0.9);
gPad->Update();

I put the three input files and the code (compareMu.C) in ~damazio/public/ in lxplus. Please, let me know if you need anything else to reproduce this.

I should have said : for the projection made with the nt (the Tree with the friend branches)

Hello @damazio!

If I understand correctly, you were surprised by the Tree with friends giving different results compared to the single trees alone?
In that case, you could maybe first inspect the branches using nt->Scan("*") (see more about Scan here). Maybe there is something odd happening such as one variable missing from a tree, or the number of entries being different. Give this a try to see which one is causing the difference.

Regarding the stat box, what exactly is the problem? The code you posted looks reasonable on first look.

About the TPaveStats. Nothing moves. I see all boxes when above the other…
As for the Scan… I can see that it seems to “create” some repeated entries for one of the entries in the friends ttree…

The TTree Scan gives something weird :

root [3] nt->Scan("*")
************
*    Row   *
************
*        0 *
*        1 *
*        2 *
*        3 *
*        4 *
*        5 *
*        6 *
*        7 *
*        8 *
*        9 *
*       10 *

But the number of entries is really different :

root [4] mu_000->GetEntries**()**
(long long) 557
root [5] mu_140->GetEntries()
(long long) 251
root [6] mu_200->GetEntries()
(long long) 108

All of them should have some indication of how to align, but it looks to me that this would be impossible to handle anyway… Right?! Thanks…

About the TPaveStats. Nothing moves. I see all boxes when above the other…

I see. You are doing it correctly, but instead of gPad->Update(), use gPad->Draw() to redraw.

But the number of entries is really different

Oh yes, this is a problem. If you check AddFriend(), you will see that:

The number of entries in the friend must be equal or greater to the number of entries of the original tree. If the friend tree has fewer entries a warning is given and the missing entries are not included in the histogram.

I guess in your case the warning and stopping part doesn’t hold, because you have an empty “main tree”. You could try to make the one with most entries the main one, and add the other two as friends:

- TTree *nt = new TTree();;
- nt->AddFriend(mu_000,"mu_000");
- nt->AddFriend(mu_140,"mu_140");
- nt->AddFriend(mu_200,"mu_200");
+ mu_000->AddFriend(mu_140,"mu_140");
+ mu_000->AddFriend(mu_200,"mu_200");

Oh, I realise one thing now:
The three input files seem to be from different runs. If you want to process all runs, you should put them in a chain. This is a “vertical join”.

If you add them as friends, you are horizontally joining them, so event 1 of run 1 will be joined with events 1 of run 2 and event 1 of run 3. This likely doesn’t make sense, as these events are statistically independent, so they shouldn’t be correlated with each other. This would also explain why your chains have different sizes.

Ok! The gPad->Draw() was a perfect solution. Thanks a lot. I was missing that.
The TTree problem, however, is not as simple. Actually, the three root files have the same events but reconstructed with different conditions. So… Not all events (or particles, actually) appear in the same event. I will have to adopt a not as fancy solution of addFriends, but rather by making matches by the Event Number ID and the truth content of the particles which are, indeed, “matchable”… Thanks for raising the really relevant points which I had not understood.