Skip to content

Conversation

@bryates
Copy link
Contributor

@bryates bryates commented Oct 1, 2025

This PR updates the basis rotations so that the SMEFTsim WC names become the POIs and any dim6top names are only used internally. There is also a caveat added to the fitting README about glados having issues making a workspace with expr in scalings.json. It works fine on lxplus, and the resulting root file can be used on `glados.

Here's an example of an (incomplete) 2D scan of ctBRe vs ctWRe (rotating ctZ and ctW). The correlations are much smaller than in TOP-22-006 when using dim6top.
image

@bryates bryates requested review from Andrew42 and sscruz October 1, 2025 18:50
@bryates bryates self-assigned this Oct 1, 2025
@codecov
Copy link

codecov bot commented Oct 1, 2025

Codecov Report

❌ Patch coverage is 80.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 24.65%. Comparing base (d1a60cd) to head (fd75fc8).
⚠️ Report is 186 commits behind head on master.

Files with missing lines Patch % Lines
topeft/modules/datacard_tools.py 80.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #495      +/-   ##
==========================================
+ Coverage   24.58%   24.65%   +0.07%     
==========================================
  Files          36       36              
  Lines        5516     5520       +4     
==========================================
+ Hits         1356     1361       +5     
+ Misses       4160     4159       -1     
Flag Coverage Δ
unittests 24.65% <80.00%> (+0.07%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

anpicci added a commit that referenced this pull request Nov 12, 2025
…er-and-tools

Add coverage for canonical process names across data-driven utilities
@bryates
Copy link
Contributor Author

bryates commented Nov 24, 2025

I've now fully validated this PR including the simple renames. The summary plot shows identical results for all the ones that are renames, modulo the ones that become correlated like cpQM = cHQ1 - cHQ3.
image

Updated warning message regarding EFT basis rotation and combine limit scans.
@Andrew42
Copy link
Contributor

I'm trying to figure out whether or not it's expected that the limits for some of the WCs are different, but I'm still working out some toy examples to try and wrap my head around what this rotation actually means.

The basic idea here is that we want to compute the limits for a set of WCs: x1, x2, and x3, however, the yield dependence for some of our samples is given based on WCs: x1, x2, and x4. We also having the following mapping that takes x4 <-> x2 - x3. Now lets say we're doing a 1D frozen scan in x3. For the SMEFTsim samples, combine will need to plug in x4 = 0 - x3 to get the relevant yields. Clearly there's a relative minus sign between the parameterization for the dim6top samples and the SMEFTsim samples, but my assumption would be that the structure constants for the SMEFTsim samples would differ in precisely the correct way so as to ensure you get the same final yield as what you get from the dim6top parameterization.

As an explicit concrete example:

let f(x1,x2,x3) be dim6Top parameterization
let g(x1,x2,x4) be SMEFTsim parameterization
let x4 = x2 - x3

Then the structure constants of f() and g() should be such that
f( 0, 0,x3) = g(0 , 0,-x3)
f( 0,x2, 0) = g(0 ,x2, x2)
f(x1, 0, 0) = g(x1, 0,  0)

    and in general
    
f(x1,x2,x3) = g(x1,x2,x2 - x3)

With the point being that if the two parameterizations are correct and you've made sure that combine substitutes in the correct values for the "rotated" WC, then you should get the exact same yields and therefore the exact same limits. So I'm a bit uneasy that we're seeing different limits between the 2 approaches.

@bryates
Copy link
Contributor Author

bryates commented Dec 12, 2025

I'm trying to figure out whether or not it's expected that the limits for some of the WCs are different, but I'm still working out some toy examples to try and wrap my head around what this rotation actually means.

The basic idea here is that we want to compute the limits for a set of WCs: x1, x2, and x3, however, the yield dependence for some of our samples is given based on WCs: x1, x2, and x4. We also having the following mapping that takes x4 <-> x2 - x3. Now lets say we're doing a 1D frozen scan in x3. For the SMEFTsim samples, combine will need to plug in x4 = 0 - x3 to get the relevant yields. Clearly there's a relative minus sign between the parameterization for the dim6top samples and the SMEFTsim samples, but my assumption would be that the structure constants for the SMEFTsim samples would differ in precisely the correct way so as to ensure you get the same final yield as what you get from the dim6top parameterization.

As an explicit concrete example:

let f(x1,x2,x3) be dim6Top parameterization
let g(x1,x2,x4) be SMEFTsim parameterization
let x4 = x2 - x3

Then the structure constants of f() and g() should be such that
f( 0, 0,x3) = g(0 , 0,-x3)
f( 0,x2, 0) = g(0 ,x2, x2)
f(x1, 0, 0) = g(x1, 0,  0)

    and in general
    
f(x1,x2,x3) = g(x1,x2,x2 - x3)

With the point being that if the two parameterizations are correct and you've made sure that combine substitutes in the correct values for the "rotated" WC, then you should get the exact same yields and therefore the exact same limits. So I'm a bit uneasy that we're seeing different limits between the 2 approaches.

I believe that is what it is doing. The figure above is not really a fair comparison for the rotated cases. In TOP-22-006 we fit cpQM but for this rotated case I'm comparing that to cHQ1, not cHQ1 - cHQ3. So the plot is only useful for the simple renaming WCs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants