Upperlimits after Merging HypoTestInverterResults

Hi,

I am writing a script to merge multiple hypotestinverterresults. I found that the merge result’s upperlimit doesn’t actually change. The codes posted below seems to output the same upperlimit before and after the Add(). The expected limit changed so the merge did do something.
========Output=========
UL/Err 3 +/- 0.861151 expUL 3
UL/Err 2.5 +/- 1.11676 expUL 2.5
[#1] INFO:Eval – HypoTestInverterResult::Add - merging result from result_nNr in result_nNr
[#1] INFO:Eval – HypoTestInverterResult::Add - new toys/point is 40
UL/Err 3 +/- 0.861151 expUL 2.81667
=========Code==========
TFile f1(“result1.root”);
RooStats::HypoTestInverterResult * res = f1.Get(“result_nNr”);
cout<<"UL/Err “<<” “<UpperLimit()
<<” +/- “<UpperLimitEstimatedError()
<<” expUL "<GetExpectedUpperLimit()<<endl;
TFile f2(“result2.root”);
RooStats::HypoTestInverterResult * res2 = f2.Get(“result_nNr”);
cout<<"UL/Err “<<” “<UpperLimit()
<<” +/- “<UpperLimitEstimatedError()
<<” expUL "<GetExpectedUpperLimit()<<endl;
res->Add(*res2);
cout<<"UL/Err “<<” “<UpperLimit()
<<” +/- “<UpperLimitEstimatedError()
<<” expUL "<GetExpectedUpperLimit()<<endl;

Hi,

Can you please post also the root files with the two result objects so I can check why the merging does not work as expected

Best Regards

Lorenzo

Hi Lorenzo,

Here are two output files you can test.

I am running “5.34/20”.

Wing
Freq_Clsb_grid_ts2_result_00050.0GeV_1.root (205 KB)
Freq_Clsb_grid_ts2_result_00050.0GeV_0.root (206 KB)

Hi,

Thank you for the filer. I can produce the problem. As a workaround, you would need to add the line, after the merge (res->Add(*res2)) :

res->FindInterpolatedLimit(1.-res->ConfidenceLevel(),true);

I will anyway fix in ROOT to make the computation automatically after the merge.

Thank you for reporting this problem.
Best Regards

Lorenzo

That’s an easy fix you posted. Thanks.

Wing

Hi Lorenzo,

I think there might be a problem with producing the TestStatDist also. I added these lines after the fixed you posted.

RooStats::HypoTestInverterPlot * Plot = new HypoTestInverterPlot(r);
TCanvas * c0 = new TCanvas("c0","c0",500,400);
Plot->Draw("");
TCanvas * c1 = new TCanvas("c1","c1",500,400);
RooStats::SamplingDistPlot * pl = Plot->MakeTestStatPlot(1,1);
pl->SetLogYaxis(true);
pl->Draw();

The first plots comes out fine as the p values of the inverter results. The second plot (c1) is suppose to give the TestStat plot for nSignal = 1, and type = 1 only null (S+B).

This is coming out as a blank canvas so far. If you still have my files, can you check if this is the case?

Thanks,

Wing

Hi,
The plot is blank because the underlying histogram is attached to the current file directory which is deleted at the end of your macro.
A simple fix in your code is doing instead of

TFile f1("result1.root");
TFile f2("result2.root");
TFile * f1 = TFile::Open("result1.root");
TFile * f2 = TFile::Open("result2.root");

I will fix also this in the code, to have the histograms not being deleted

Best Regards

Lorenzo

Hi Lorenzo,

i’ve question here, i’m using 5.34/14 and i’ve done toys for a given mu scan but also splitting the toys for the same mu point in different jobs of 1000 toys each to speed-up. For each job i change the seed calling

RooRandom::randomGenerator()->SetSeed(i)

where i=1,…,njobs. Note that the same seed is used for different mu values…is this actually ok? I was assuming this would be the default if one would do one job per mu value.

Then i need to sum-up the HypoTestInverterResults and i do it sorting the single job results per mu value,
so that i add them in order of increasing mu. Like:

Res_mu0_job0.root
Res_mu0_job1.root
Res_mu0_job2.root

Res_mu0_job10.root
Res_mu1_job0.root
Res_mu1_job1.root
Res_mu1_job2.root

Res_mu1_job10.root

Is this the correct procedure? Because i’ve noticed that if i add them without sorting in mu i get weird results,
like if different mu values are mixed up.

Finally do i also need to apply the fix you mentioned above? But how? Should i instead add the results in this order?

Res_mu0_job0.root
Res_mu1_job0.root
Res_mu2_job0.root

Res_muN_job0.root
—> call the fix
Res_mu0_job1.root
Res_mu1_job1.root
Res_mu2_job1.root

Res_muN_job1.root
—> call the fix

best,
Max

Dear Lorenzo

  • would this issue has been fixed in all the version after 5.34/20 ?
  • would you clarify a bit the question about the adding sequence from bellomo ?

Thanks!
Javier