Open peterstangl opened 4 years ago
Related to this, I noticed that there are two sets of default SM parameters:
M_Z
:
https://github.com/wilson-eft/wilson/blob/b410f11fbeb6d089f36a83e7ad92f83074f5eb3c/wilson/run/smeft/smpar.py#L13-L35m_t
):
https://github.com/wilson-eft/wilson/blob/b410f11fbeb6d089f36a83e7ad92f83074f5eb3c/wilson/parameters.py#L1-L22The 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?
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.
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
instancew
usingthese 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: https://github.com/wilson-eft/wilson/blob/b410f11fbeb6d089f36a83e7ad92f83074f5eb3c/wilson/classes.py#L212-L214In principle it is possible to use the
wilson.run.smeft.SMEFT
class directly for the above problem. But while this class has an argumentget_smpar
, setting this argument toFalse
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 attributeC_in
using the SM parameters, therun
method can be used without producing an error. I think that ifget_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 thewilson.Wilson
class.I would like to rewrite
wilson.run.smeft.SMEFT
andwilson.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 thewilson.util.smeftutil.add_missing
function called bywilson.util.smeftutil.wcxf2arrays_symmetrized
https://github.com/wilson-eft/wilson/blob/b410f11fbeb6d089f36a83e7ad92f83074f5eb3c/wilson/run/smeft/classes.py#L65-L72 )