Superfluous rotation?

[jackypheno]

In SMEFT class, the attribute self.C_in is already https://github.com/wilson-eft/wilson/blob/fb2cf94aab283edd1868500b4bf22e8d24c69d07/wilson/run/smeft/classes.py#L62 in the 'wcxf warsaw basis' .

Now, after the running(say down), why another rotation is made here https://github.com/wilson-eft/wilson/blob/fb2cf94aab283edd1868500b4bf22e8d24c69d07/wilson/run/smeft/classes.py#L214 ?

[DavidMStraub]

Hi,

which rotation are you referring to? The function _to_wcxf takes a dictionary of arrays (Cout) and takes it to a flat dictionary of numbers. Is there an erroneous rotation somewhere?

[jackypheno]

Yes, but _to_wcxf also makes a rotation https://github.com/wilson-eft/wilson/blob/fb2cf94aab283edd1868500b4bf22e8d24c69d07/wilson/run/smeft/classes.py#L86.

So when it is called here https://github.com/wilson-eft/wilson/blob/fb2cf94aab283edd1868500b4bf22e8d24c69d07/wilson/run/smeft/classes.py#L214, it rotates C_out which I do not understand, because C_out here is already in the wcxf Warsaw basis.

[DavidMStraub]

Oh, very good point. I think this is correct because the RG running can make a re-rotation necessary, see e.g. here:

In the WCxf Warsaw basis, the convention is that the running down-type quark and charged lepton mass matrices are diagonal at the scale of the exchange. Since the RG evolution is flavour dependent, this means that a code performing this RG evolution must use a slightly different weak basis for input and output in order to adhere to this convention

Let me know in case you still think there is a problem (could be).

[jackypheno]

Hi David,

Yes, I think it make sense to rotate it back after running to WCxf basis to get the output in this basis.

Also, to match it to WET at the electroweak scale, the weak basis of SMEFT has to be specified. So again a rotation is required.

Still, I am making few numerical checks, so please keep the issue open if possible.

While checking this I notice that for a solution to the RGEs in the leading-log approximation the scale dependent SM couplings are used, see e.g https://github.com/wilson-eft/wilson/blob/fb2cf94aab283edd1868500b4bf22e8d24c69d07/wilson/run/smeft/classes.py#L113

But as far as I understand in the leading-log approximation the anomalous dimension for the SMEFT Wilson coefficients are assumed to be scale independent, i.e the beta-function of SM parameters are set to zero. Do you agree?

[DavidMStraub]

But as far as I understand in the leading-log approximation the anomalous dimension for the SMEFT Wilson coefficients are assumed to be scale independent, i.e the beta-function of SM parameters are set to zero. Do you agree?

I think I agree in the sense that the choice of the scale where the SM parameters are evaluated is an effect beyond the leading-log approximation. So taking them at the high scale or the low scale I guess is both equally justified. But what the function _run_sm_scale_in does (apart from running the SM parameters) is also calculating the shifts in the SM parameters due to dimension 6 contributions, which I think are a separate issue. Even neglecting the running these effects would be present. Is this what you mean?

[jackypheno]

But as far as I understand in the leading-log approximation the anomalous dimension for the SMEFT Wilson coefficients are assumed to be scale independent, i.e the beta-function of SM parameters are set to zero. Do you agree?

I think I agree in the sense that the choice of the scale where the SM parameters are evaluated is an effect beyond the leading-log approximation. So taking them at the high scale or the low scale I guess is both equally justified.

I agree that we can use the SM parameters at high or low scale as long as they are in the correct basis.

So, I am Ok with the _run_sm_scale_in and even _get_sm_scale_in. As the later function provides us the SM parameters (ignoring the running of wilson coefficients) at the input scale in the Warsaw-down basis. This is perfect. But, when we use the run function, it runs both the SM parameters and wilson coefficients even in the leading log approximation. In this step the SM parameters , the Yukawas for example can be modified due to running and since we are using _to_wcxf https://github.com/wilson-eft/wilson/blob/fb2cf94aab283edd1868500b4bf22e8d24c69d07/wilson/run/smeft/classes.py#L214 which rotates back and this rotation affects the SMEFT wilson coefficients which is entirely caused by the running of SM parameters. But the SM parameters should not run in the leading log approximation and can be treated as a constant estimate for all scale, in my opinion.

[jackypheno]

I think the SM keys should be excluded in the loop here

https://github.com/wilson-eft/wilson/blob/fb2cf94aab283edd1868500b4bf22e8d24c69d07/wilson/run/smeft/rge.py#L18

[DavidMStraub]

which rotates back and this rotation affects the SMEFT wilson coefficients which is entirely caused by the running of SM parameters.

Is that the case? The rotation also becomes necessary in case of leading-log contributions induced in any of the "psi^2 phi^3" type operators that enter in the mass matrices, right?

[jackypheno]

which rotates back and this rotation affects the SMEFT wilson coefficients which is entirely caused by the running of SM parameters.

Is that the case? The rotation also becomes necessary in case of leading-log contributions induced in any of the "psi^2 phi^3" type operators that enter in the mass matrices, right?

Ah.. you are right. But what if psi^2 phi^3 wilson coefficients are zero. In that case the running is entirely due to the SM right?

[DavidMStraub]

In that case the re-rotation (if any) is due to leading-log contributions to SM Yukawas. But this is something else than SM Yukawa contributions to the running of dim-6 WCs.

Your above statement

SM parameters should not run in the leading log approximation and can be treated as a constant

is correct I think, in the sense that the change of SM parameters is not taken into accuont in the beta functions of WCs. Similarly, the WCs themselves are treated as constant in the running in a sense, namely in the beta functions of other WCs. However, I don't the actual leading-log contributions to the SM Yukawas themselves should be discarded.

[peterstangl]

Your above statement

SM parameters should not run in the leading log approximation and can be treated as a constant

is correct I think, in the sense that the change of SM parameters is not taken into accuont in the beta functions of WCs. Similarly, the WCs themselves are treated as constant in the running in a sense, namely in the beta functions of other WCs. However, I don't the actual leading-log contributions to the SM Yukawas themselves should be discarded.

@jackypheno, I remember we discussed this and agreed that the current implementation is fine, right? So can this issue be closed or is there still a problem?

[jackypheno]

@peterstangl @DavidMStraub

Yes, I am closing the issue.