Adding nuSMEFT and its RG Running.

[jackypheno]

A new EFT, nuSMEFT, is added to Wilson, which allows performing renormalization group running within nuSMEFT based on the anomalous dimensions computed in the two papers: https://arxiv.org/abs/2010.12109 and https://arxiv.org/abs/2103.04441.

The major change is the generalization of the SMEFT class to an EFTevolve class, which allows RG running in SMEFT, nuSMEFT as well as in WET. The WET part is not updated but can be done in the future.

In addition, we also introduced yukawa_scale_in and gauge_higgs_scale_in as new options of set_option() which allow the user to input the Yukawa, gauge, and Higgs couplings at Lambda, for the RG running. For nuSMEFT, it is necessary to input the 'G_n' because it is internally not computed by wilson. Its default value is set to zero. For SMEFT, these new options allow us to study the individual effects of gauge and Yukawa running.

Jason Aebischer, Tejhas Kapoor, Jacky Kumar

[peterstangl]

Hi @jackypheno! That's really great that you're adding the nuSMEFT! I have few general comments:

• I think if there is a major change in some of the classes of wilson (introducing the EFTevolve class), it might be good to do this in a separate PR, independent of adding the nuSMEFT beta functions.

• Your current PR is undoing the changes implemented in wilson v2.4. It seems that your new code is based on an older version of wilson. Please apply your changes on top of the current master branch. This could e.g. be done by doing a proper rebasing on the master branch. As a general suggestion, it is always good to use "feature branches" also on your forked repository such that the master branch there can be updated to the one in the main repository.

• Concerning yukawa_scale_in and gauge_higgs_scale_in, please take a look at issue SMEFT running with user-defined SM parameters #38. Does your new implementation fully address this issue?

[jackypheno]

Hi @jackypheno! That's really great that you're adding the nuSMEFT! I have few general comments:

• I think if there is a major change in some of the classes of wilson (introducing the EFTevolve class), it might be good to do this in a separate PR, independent of adding the nuSMEFT beta functions.

Well, I do not see a clear point here. As written, the SMEFT can not solve nuSMEFT beta functions. We have rewritten it so that it is now general and can work for all three EFTs (SMEFT, WET, nuSMEFT), even though we are not using it for WET at the moment. Most of the functions of SMEFT have been generalized to accommodate nuSMEFT -- not for an independent reason. But I agree, that since some of the methods have been revised/deleted/added, there might be an issue of backward compatibility. On the other hand, at the top level, Wilson class all functions work exactly like before. So how important is backward compatibility with internal functions -- which are not meant to be directly used-- I am not sure @jasonaebischerGIT @DavidMStraub what's your view on that?

• Your current PR is undoing the changes implemented in wilson v2.4. It seems that your new code is based on an older version of wilson. Please apply your changes on top of the current master branch. This could e.g. be done by doing a proper rebasing on the master branch. As a general suggestion, it is always good to use "feature branches" also on your forked repository such that the master branch there can be updated to the one in the main repository.

I noticed that. Will fix it, we missed v2.4

• Concerning yukawa_scale_in and gauge_higgs_scale_in, please take a look at issue SMEFT running with user-defined SM parameters #38. Does your new implementation fully address this issue?

I think so, now one can supply their own SM parameters at the NP scale. As you have noticed correctly in #38, the parameters options just go to matching without affecting running. Again, our original motivation was solely to be able to provide G_n for nuSMEFT as an input since its a new physics parameter.

I have created another version of PR #114, where nuSMEFT is handled independently of the previous SMEFT class. This should be backward compatible. But I believe #114 way of implementing the code is better than #115.