wilson-eft/wilson

SMEFT matching @ 1-loop: problem with dG

Closed this issue · 11 comments

dvandyk commented

When comparing with Sebastian Bruggisser (@tarendo) for a joint project, we noticed the following peculiarity in the wilson code for SMEFT(Warsaw up) on WET(JMS) matching:

C['dG'] = ... + (g3bar*mW**2*einsum("pr,p",C["phid"],md))/(36.*mZ**2*pi**2)

I would claim that this is incorrect for the following reason:

  • the left-hand side is a 3x3 matrix with indices p and r
  • the term on the right-hand side is a 3 vector with index r

Unfortunately, this does not produce an error, since a rank-two numpy array 'a' and a rank-one numpy array 'b' can be added, yielding a rank-two numpy array with 'b[r]' added to each column in row 'r'.

A quick grep shows that his seem to only affect 'dG' and 'dGamma':

$ grep 'einsum("pr,p"' wilson/match/smeft_loop.py | awk -F'=' '{print $1}'
c['dgamma'] 
c['dG']

The problem can be fixed in the following way:

einsum("pa,ar->pr",np.diag(md),C["phid"])

@DavidMStraub @jasonaebischerGIT @peterstangl Please confirm. If confirmed, I will provide a patch.

DavidMStraub commented

Could be, but did you check the corresponding Mathematica expression from D & S to be sure?

dvandyk commented

Could be, but did you check the corresponding Mathematica expression from D & S to be sure?

The corresponding Mathematica expression in D&S is a 3x3 matrix, since 'p' and 'r' are external indices, which are not summed over.

We found this while investigating some oddities with respect to phiq1_pr, but first wanted to discuss the simplest case.

DavidMStraub commented

Is there any way this can be checked or shall it just be merged as-is?

dvandyk commented

Please do not merge yet. We have identified further problems while attempting to create a unit test, matching the D/S results to wilson's. We think that in the translation from the Mathematica code to Python code terms that involve kd[pi, ri] md[pi] have been mistranslated. The D/S term is a diagonal matrix with the down-type masses on the diagonal. The Wilson code reads:

einsum("p,r",one,md)

which is non-diagonal. This error affects the SM contributions, but also terms involving scalar SMEFT coefficients, e.g, phiD. Together with the errors we pointed out above, this means that the majority (if not all) terms in dG and dgamma involving factors of md have been mistranslated.

We further suspect that such a problem also appears in uG and ugamma, in which we find similarly:

einsum("p,r",one,mu)

which is not the intended (diagonal) mass matrix.

We have updated the commit fixing dG and dgamma. However, given the large number of terms that need fixing, it would probably be a good idea to fix the translation script that was originally used, and re-translate the D/S expressions for these four LEFT coefficients. We would also offer to audit the translation script, if you are interested.

peterstangl commented

@DavidMStraub do you still have the script for translating the Mathematica expressions into Python code? I would also take a look at this issue and the translation script would be very helpful.

DavidMStraub commented

Unfortunately not. AFAIR, this was done with regexes in an editor and using the existing tree-level matching implementation as a unit test (which does not guard against errors in the 1-loop terms obviously).

The notation of D & S for masses is really stupid unfortunate.

dvandyk commented

Unfortunately not. AFAIR, this was done with regexes in an editor and using the existing tree-level matching implementation as a unit test (which does not guard against errors in the 1-loop terms obviously).

Understood! I have adjusted my commit in dvandyk/wilson#issue50. I have also added test cases for
phid, phiq1 and phiq3.

The notation of D & S for masses is really stupid unfortunate.
Well, we have to deal with it now as it is.

@tarendo Would you please check that my test cases coincide with your version of the D/S notebook?
I'd like to have an independent test, in case I messed this up.

tarendo commented

@dvandyk I agree with your tests. Except for the small O(1e-22) imaginary parts. They seem to be numerical artefacts though and I would not worry about them (given that the leading real part is orders of magnitudes larger).

dvandyk commented

@DavidMStraub @peterstangl @jasonaebischerGIT I have updated the commit with further test cases.
Please merge. Thanks to @tarendo for doing the brunt of the work!

DavidMStraub commented

This should be merged by a professional.