"Interpolating" Efficiencies

[A-A-Abdelhamid]

I accessed the ROOT file of the efficiency graph:

And I tried to use the Interpolate() function to match a muon with a given pt and d0 to its reconstruction efficiency. The graph has data points for a few d0's and pt's with interval/gap between them. The issue is when we have a point that does not exactly match a data point's pt or d0, the interpolate function returns zero:

For pt = 150 GeV and d0 = 50 mm, the interpolated efficiency is 0.5208171428571429.

For pt = 100 GeV and d0 = 25 mm, the interpolated efficiency is 0.54118.

For pt = 90 GeV and d0 = 25 mm, the interpolated efficiency is 0.0.

For pt = 105 GeV and d0 = 25 mm, the interpolated efficiency is 0.0.

There are two ways I suggest to get such efficiencies:

1) The easiest route is to locate the closest data point in the graph to the given pt and d0, i.e.

In this case, for example, we give the muon with pt and do the efficiency of point A. Distances here is the Eucleadean distance in the x-y plane, which is the pt-d0 plane.

2) Probably more accurate and consnsitent way to do it is to manually interpolate the efficiency as a function of pt and d0.

Here I'm assuming that pt, d0 and efficiency are approximately linear the space between A and B. Pt and d0 in green are our given particle's, eff1 is the efficiency of point A at d0_1 and pt_1

Please let me know what you think, thanks! @trholmes

[trholmes]

Glad you're thinking about these details! In fact what we do is significantly simpler than what you're describing. The bin itself is built on the values in the full range (not just the leading edge) so in principle this is taken care of by construction. You can just use the value returned by the FindBin() function.

Of course there are small issues this can create if your distribution within a bin is dramatically different between the sample this was measured on vs. the sample you're applying it to, but we try to make the bins small enough that this is not an issue.

[A-A-Abdelhamid]

@trholmes Thanks!

This makes sense, but there is an issue with that function. The graph/plot in the ROOT file is not a histogram object, it is a "TGraph2DErrors" object

It does not have a FindBin()method and gives this error when I try to use it:

AttributeError: 'TGraph2DErrors' object has no attribute 'FindBin'

Here is the ROOT files contents:

command _file0->ls() output:

TFile**     HEPData-ins1831504-v2-pt-d0_muon_efficiency.root    
 TFile*     HEPData-ins1831504-v2-pt-d0_muon_efficiency.root    
  KEY: TDirectoryFile   pt-d0 muon efficiency;1 pt-d0 muon efficiency

command:

_file0->cd("pt-d0 muon efficiency");
_file0->ls();

output:

TFile**     HEPData-ins1831504-v2-pt-d0_muon_efficiency.root    
 TFile*     HEPData-ins1831504-v2-pt-d0_muon_efficiency.root    
  TDirectoryFile*       pt-d0 muon efficiency   pt-d0 muon efficiency
   KEY: TGraph2DErrors  Graph2D_y1;1    doi:10.17182/hepdata.98796.v2/t15
  KEY: TDirectoryFile   pt-d0 muon efficiency;1 pt-d0 muon efficiency

One way to get around this is to extract the x,y,z values and plotting it as a histogram (TH2), (or maybe in this case it might be easier to use one of the suggestions I mentioned earlier.)

What do you think?

[trholmes]

I see, that's interesting. TGraph2DError inherits from TGraph2D, so you should have access to this function: https://root.cern.ch/doc/master/classTGraph2D.html#a50396cad8c1615df3e977a7ecd007b23

In general you're typically able to convert a TGraph to a histogram with a built-in function. See if it works!

On Tue, Aug 15, 2023 at 3:28 PM Alaa Abdelhamid @.***> wrote:

Thanks!

This makes sense, but there is an issue with that function. The graph/plot in the ROOT file https://www.hepdata.net/download/table/ins1831504/pt-d0%20muon%20efficiency/2/root is not a histogram object, it is a "TGraph2DErrors" https://root.cern.ch/doc/master/classTGraph2DErrors.html object

It does not have a FindBin() method and gives this error when I try to use it:

AttributeError: 'TGraph2DErrors' object has no attribute 'FindBin'

Here is the ROOT files contents:

command _file0->ls() output:

TFile* HEPData-ins1831504-v2-pt-d0_muon_efficiency.root
TFile HEPData-ins1831504-v2-pt-d0_muon_efficiency.root
KEY: TDirectoryFile pt-d0 muon efficiency;1 pt-d0 muon efficiency

command:

_file0->cd("pt-d0 muon efficiency"); _file0->ls();

output:

TFile* HEPData-ins1831504-v2-pt-d0_muon_efficiency.root
TFile HEPData-ins1831504-v2-pt-d0_muon_efficiency.root
TDirectoryFile* pt-d0 muon efficiency pt-d0 muon efficiency KEY: TGraph2DErrors Graph2D_y1;1 doi:10.17182/hepdata.98796.v2/t15 KEY: TDirectoryFile pt-d0 muon efficiency;1 pt-d0 muon efficiency

One way to get around this is to extract the x,y,z values and plotting it as a histogram (TH2), (or maybe in this case it might be easier to use one of the suggestions I mentioned earlier.)

What do you think?

— Reply to this email directly, view it on GitHub https://github.com/A-A-Abdelhamid/LLP_Sleptons_RPV_SUSY/issues/8#issuecomment-1679480857, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6DBBLJOYE56K5IKAB27ILXVPEVJANCNFSM6AAAAAA3RNOON4 . You are receiving this because you were mentioned.Message ID: @.***>

[A-A-Abdelhamid]

I used the GetHistogram() function: I simply typed hist=_ graph.GetHistogram() , and it works as expected. According to the function's documentation:

 "If fHistogram doesn't exist, books the 2D histogram fHistogram with a margin around the hull. Calls TGraphDelaunay::Interpolate at each bin centre to build up an interpolated 2D histogram."

I plotted it to see how it looks and compared it to the original plot.

The binning here is different compared to the histogram in the paper. Here, instead of having one bin for 100GeV to 170 GeV as the original plot, it creates 5 bins centered at "107.875, 123.625, 139.375, 155.125, 170.875" GeV.

Same with the 25mm-75mm bin, which is now 7 bins centered at "28.125, 34.375, 40.625, 46.875, 53.125, 59.375, 65.625, 71.875" mm, the efficiencies for these new bins are interpolated. 

A muon with 100-170 GeV and 25-75mm d0 has an efficiency of 0.54118 then it jumps to 0.4164 at 75mm in the original plot. Now efficiency for bin centered at (107.875 GeV, 28.125 mm) is 0.540038875, for bin centered at 139.375, 46.875  mm ) is 0.519581875, for bin centered at (170.875 GeV, 71.875 mm) is 0.49807787500000006 and for bin centered at (170.875 GeV, 78.125 mm) is 0.468099125

I am not sure why it chose to change the binning, but I believe this is perfectly fine (probably even better now), but I wanted to let you know just in case.

Thanks! @trholmes

[trholmes]

Hmm given that there aren't huge jumps in this plot I think it should be OK -- we can decide if we're worried about it based on how your efficiency comes out compared to the paper's efficiency.

On Wed, Aug 16, 2023 at 2:08 PM Alaa Abdelhamid @.***> wrote:

I used the GetHistogram() function, and it works as expected. According to the function's documentation:

"If fHistogram doesn't exist, books the 2D histogram fHistogram with a margin around the hull. Calls TGraphDelaunay::Interpolate at each bin centre to build up an interpolated 2D histogram."

I plotted it to see how it looks and compared it to the original plot. [image: hist] https://user-images.githubusercontent.com/130788379/261092859-646b773b-1bac-4357-bc50-cb6a80e5f9ad.png

The binning here is different compared to the histogram in the paper. Here, instead of having one bin for 100GeV to 170 GeV as the original plot, it creates 5 bins centered at "107.875, 123.625, 139.375, 155.125, 170.875" GeV.

Same with the 25mm-75mm bin, which is now 7 bins centered at "28.125, 34.375, 40.625, 46.875, 53.125, 59.375, 65.625, 71.875" mm, the efficiencies for these new bins are interpolated.

A muon with 100-170 GeV and 25-75mm d0 has an efficiency of 0.54118 then it jumps to 0.4164 at 75mm in the original plot. Now efficiency for bin centered at (107.875 GeV, 28.125 mm) is 0.540038875, for bin centered at 139.375, 46.875 mm ) is 0.519581875, for bin centered at (170.875 GeV, 71.875 mm) is 0.49807787500000006 and for bin centered at (170.875 GeV, 78.125 mm) is 0.468099125

I believe this should be fine (probably even better now) and I should be good to go from here, but I wanted to check it with you first.

Thanks! @trholmes https://github.com/trholmes

— Reply to this email directly, view it on GitHub https://github.com/A-A-Abdelhamid/LLP_Sleptons_RPV_SUSY/issues/8#issuecomment-1681063855, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6DBBK7DFUOGH35T74JIBDXVUECPANCNFSM6AAAAAA3RNOON4 . You are receiving this because you were mentioned.Message ID: @.***>