Difference in SMEFT-WET matching between v2 and v1

[MJKirk]

I've found a change in the matching results wilson gives between v1.8 and v2.0 (I think the v1 results are correct, and v2 is wrong).
In wilson v1.8:
Setting the initial conditions phiq3_12 = 1e-8 @ 100 GeV, then matching to the WET (in the flavio basis, at the same scale) gives CVLL_ucuc = -2.47e-12.
In wilson v2.0:
The same thing gives a result of CVLL_ucuc = -1.77e-19, so 10^7 smaller!
The phiq3 operator (after symmetry breaking) affects the W and Z couplings, so phiq3_12 gives a LH Z-u-c vertex, and then the matching is relatively straightforward. Doing it by hand I agree with the larger result from v1.8.

I see similar differences in the matching of phiu_12 (which gives a RH Z-u-c, 10^11 smaller in v2), and phiq3_11 (gives LH Z-u-c after CKM rotation, smaller by 10^7).
The flavour diagonal matching (phiq3_11 -> CVLL_uuuu) is the basically same between versions though.

Similar effects in the down sector:

• phid_12 -> CVRR_sdsd is 10^13 smaller
• phiq3_12 -> CVLL_sdsd (only) 10^3 smaller
• phiq3_11 is tiny in both, which it should be since we work in the basis with all the CKM rotation in the up sector.

I haven't had a change to check the Mathematica notebook from the new source paper to see what happens there, or whether it is just a bug in the conversion to Python.

[DavidMStraub]

Did you switch off 2-loop contributions in v2?

[MJKirk]

I assume you mean 1-loop (unless wilson is secretly much better than announced!).
I believe the default is tree matching, but I have explicitly called wilson.Wilson.set_default_option('smeft_matching_order', 0)
at the beginning to make sure and the results are the same.

[jackypheno]

@MJKirk

I believe @DavidMStraub meant 1-loop SMEFT-WET matching only.

What SMEFT basis did you use for matching CVLL_ucuc?

I think this matching (12 psi^2phi^2 D type SMEFT WCs in the Warsaw-down basis to sdsd WCs in WET) requires two insertions of SMEFT operators which I do not think is implemented in wilson. But the non-zero result that you are getting might be due to the running of SMEFT Wilson coefficients from 100 GeV (your input scale) to 91.1876 GeV (default matching scale in the wilson). To see this try setting scale= 91.1876 GeV instead of 100 GeV in your initial condition.

Still, the origin of the difference between the two versions should be investigated.

[MJKirk]

What SMEFT basis did you use for matching CVLL_ucuc?

I am matching from SMEFT Warsaw to WET flavio

But the non-zero result that you are getting might be due to the running of SMEFT Wilson coefficients from 100 GeV (your input scale) to 91.1876 GeV (default matching scale in the wilson). To see this try setting scale= 91.1876 GeV instead of 100 GeV in your initial condition.

Ah good point, for some reason (that reason being I didn't check carefully), I assumed just setting the scales equal would be enough to prevent running.
Setting the scale to MZ to avoid this, the ucuc coefficients are exactly 0 in v2, while phiq3_12 gives a non-zero but tiny (10^-23) value for sdsd.

I think this matching (12 psi^2phi^2 D type SMEFT WCs in the Warsaw-down basis to sdsd WCs in WET) requires two insertions of SMEFT operators which I do not think is implemented in wilson.
Still, the origin of the difference between the two versions should be investigated.

Reading both papers, at the end of Sec 4 of 1709.04486, they comment about these sorts of double insertions and say that "the last term, from the product of two dimension-six corrections to the gauge coupling should formally be dropped as it is of higher order in the power counting". However, looking at the old code:

wilson/wilson/match/_smeft_old.py

Line 92 in 1686d08

c["VuuLL"] = C["qq1"]+C["qq3"]-gzb**2/(2*p["m_Z"]**2)*np.einsum('pr,st',zul,zul)

it seems these were included in v1 which would explain the result.
Whereas in the new code

wilson/wilson/match/smeft_tree.py

Line 98 in 1686d08

c['VuuLL'] = ((18*C["qq1"] + 18*C["qq3"] + 18*einsum("stpr",C["qq1"]) + 18*einsum("stpr",C["qq3"]) + ((-4*mW**2 + mZ**2)*((8*mW**2 - 2*mZ**2 + vT**2*((4*mW**2 + mZ**2)*C["phiD"] + 8*g1bar*mW*vT*C["phiWB"]))*kdkd + 6*mZ**2*vT**2*(-einsum("pr,st",C["phiq1"],kd) + einsum("pr,st",C["phiq3"],kd) - einsum("st,pr",C["phiq1"],kd) + einsum("st,pr",C["phiq3"],kd))))/(mZ**4*vT**2))/36.)

it seems these quadratic terms are correctly dropped.

So I think that clears up my narrow problem at least - these terms should not have been included originally, and as of v2 are not.

[MJKirk]

And I see now that in the test David wrote when he updated the matching:

wilson/wilson/match/test_smeft_tree_new.py

Lines 46 to 54 in 1686d08

	def test_quadratic(self):
	"""For WCs entering also quadratically, agreement should be good
	up to the size of quadratic terms"""
	C = wilson.util.smeftutil.wcxf2arrays_symmetrized(wc_quadratic.dict)
	c_old = wilson.match._smeft_old.match_all_array(C, p)
	c_new = wilson.match.smeft_tree.match_all_array(C, p)
	for k in c_old:
	npt.assert_almost_equal(c_old[k], c_new[k], decimal=10,
	err_msg=f"Failed for {k}")

the different treatment of quadratic terms was allowed for, so I think it is safe to say this is resolved.

[dvandyk]

@MJKirk thanks for such an in-depth check! I would argue that, in general, the quadratic terms must be dropped.
The power counting is not the right argument, though. Much more importantly, double insertions of dim-6 SMEFT operators are in general not finite, and you will need dim-8 counter terms. While in specific cases this might be avoidable, e.g., when you cannot write down a dim-8 term for some reason, in general it is not. Hence, you cannot have a consistent treatment of double insertions of dim-6 operators without also taking dim-8 operators into account, regardless of the power-counting argument.