SMEFT running with user-defined SM parameters

[peterstangl]

I would like to run SMEFT Wilson coefficients together with user-defined SM parameters, i.e. I don't want to use iteratively determined SM parameters but provide them myself at the high new physics scale. However, if one provides user-defined SM parameters to a Wilson instance w using

w.set_option('parameters',{...})

these parameters will only be used for translating to another SMEFT basis (where the CKM elements are used) or for matching to the WET. But the wilson.run.smeft.SMEFT instance that is created for the running seems to never see these user-defined parameters:

wilson/wilson/classes.py

Lines 212 to 214 in b410f11

	smeft = SMEFT(self.wc.translate('Warsaw', sectors=translate_sectors, parameters=self.parameters))
	# if input and output EFT ist SMEFT, just run.
	wc_out = smeft.run(scale, accuracy=smeft_accuracy).translate(basis)

In principle it is possible to use the wilson.run.smeft.SMEFT class directly for the above problem. But while this class has an argument get_smpar, setting this argument to False can easily lead to an error since in this case the SM parameters are not set at all. Only after updating the dictionary in the attribute C_in using the SM parameters, the run method can be used without producing an error. I think that if get_smpar=False is used, the SM parameters should be provided on instantiation.
But all of this seems to be unnecessarily complicated and error-prone and I think that it should be possible to do the same using the wilson.Wilson class.

I would like to rewrite wilson.run.smeft.SMEFT and wilson.Wilson a bit, but before doing so I though it might be good to get some comments on this from @DavidMStraub @jasonaebischerGIT @jackypheno.

(And maybe the wilson.run.smeft.SMEFT class needs some further rewriting. E.g. the following lines seem to be redundant and lines 66-72 seem to be unnecessary since the same is done by the wilson.util.smeftutil.add_missing function called by wilson.util.smeftutil.wcxf2arrays_symmetrized

wilson/wilson/run/smeft/classes.py

Lines 65 to 72 in b410f11

	C = wilson.util.smeftutil.wcxf2arrays_symmetrized(wc.dict)
	# fill in zeros for missing WCs
	for k, s in smeftutil.C_keys_shape.items():
	if k not in C and k not in smeftutil.SM_keys:
	if s == 1:
	C[k] = 0
	else:
	C[k] = np.zeros(s)

)

[peterstangl]

Related to this, I noticed that there are two sets of default SM parameters:

• Parameters defined at M_Z:
  

  wilson/wilson/run/smeft/smpar.py

  Lines 13 to 35 in b410f11

  	# Default values for SM parameters: MSbar parameters at M_Z (except GF)
  	p = {}
  	p['GF'] = 1.1663787e-5
  	p['alpha_e'] = 1 / 127.9
  	p['alpha_s'] = 0.1185
  	p['Vus'] = 0.2243
  	p['Vub'] = 3.62e-3
  	p['Vcb'] = 4.221e-2
  	p['delta'] = 1.27
  	p['m_e'] = 0.000511
  	p['m_mu'] = 0.1057
  	p['m_tau'] = 1.777
  	p['m_u'] = 0.00127 # mu(2 GeV)=0.0022
  	p['m_c'] = 0.635 # mc(mc)=1.28
  	p['m_d'] = 0.00270 # md(2 GeV)=0.0047
  	p['m_s'] = 0.0551 # ms(2 GeV)=0.095
  	p['m_b'] = 2.85 # mb(mb)=4.18
  	# MSbar running masses at MZ computed with "mr"
  	# https://github.com/apik/mr, https://arxiv.org/abs/1601.08143
  	p['m_t'] = 169.0
  	p['m_W'] = 80.20
  	p['m_Z'] = 91.46
  	p['m_h'] = 130.6

• "Physical" parameters defined at various scales (missing m_t):
  

  wilson/wilson/parameters.py

  Lines 1 to 22 in b410f11

  	"""Standard Model parameter values."""
  	p = {}
  	p['m_W'] = 80.385
  	p['m_Z'] = 91.1876
  	p['m_h'] = 125.
  	p['GF'] = 1.1663787e-5
  	p['alpha_e'] = 1/127.9
  	p['alpha_s'] = 0.1185
  	p['Vus'] = 0.2243
  	p['Vub'] = 3.62e-3
  	p['Vcb'] = 4.221e-2
  	p['delta'] = 1.27
  	p['m_b'] = 4.18
  	p['m_s'] = 0.095
  	p['m_c'] = 1.28
  	p['m_u'] = 0.0022
  	p['m_d'] = 0.0047
  	p['m_e'] = 0.0005109989461
  	p['m_mu'] = 0.1056583745
  	p['m_tau'] = 1.77686

The first set of parameters is used for iteratively extracting the SM parameters at the high new physics scale. The second set of parameters is used by default for translating between different bases and for matching. I don't understand why two different sets of parameters are used and why e.g. translating between bases is not done with the SM parameters at the scale where this basis translation is performed. For many cases the difference might be negligible. But it might make a difference e.g. if a basis change is performed far above the electroweak scale, right?

[DavidMStraub]

Yes, indeed you are touching on some of the problems of wilson.

The historic reason for most of this mess is that it started out as several different packages (python-dsixtools, python-wetrunner, ...) which after the merger were only partially harmonized; and most of this was written even before the advent of WCxf.

So, indeed the main problem here I think are the two different sets of parameters used by run.smeft vs all the other modules. The reason is that, for the SMEFT running, we require the SM MSbar parameters at the EW scale, in particular for W, Z, t, h, which were calculated with the mr package for the SMEFT running.

To make the confusion even larger, note that my new implementation of the SMEFT-WET matching also uses the parameters from run.smeft, since the one-loop calculation is performed in the MSbar scheme, so it was not consistent to use pole masses for W, Z, t, h (at tree-level this was irrelevant as the scheme dependence is of higher order).

So, to solve this mess (which I created), the cleanest solution is to merge the two parameter.py into a single one. Maybe the scheme for the heavy EW states could be added as a switch. (By the way, a warning: the functions from rundec-python cannot be used to translate between pole and MSbar scheme since this only includes QCD corrections, not EW ones! One has to use mr, which has no Python version.) This would then also allow to consistently modify the parameters everywhere needed in Wilson.

By the way: the reason I didn't care too much about the setting of SM parameters in run.smeft is that the impact on the running of dimension-6 WCs is really tiny; after all, these parameters cannot deviate much from the values we know. I think this really only matters if you look at the running of the SM parameters themselves (which is probably what you want, but not the focus wilson.Wilson as of now). The difference is also certainly smaller than the error introduced by the iterative determination (which you probably don't want to use).

I don't understand why two different sets of parameters are used and why e.g. translating between bases is not done with the SM parameters at the scale where this basis translation is performed.

For WET, this is actually done:
https://github.com/wilson-eft/wilson/blob/master/wilson/translate/wet.py#L1569-L1591
However it would certainly be more elegant to merge this into a unified parameter module.