Implement the LEFT beta functions and their solutions

[jackypheno]

Implements solutions to LEFT RGEs using LEFT beta functions.

@jasonaebischerGIT @peterstangl at this stage you might upload the extracted beta functions.

@dvandyk this is just a draft, work in progress!

[jackypheno]

I think checks have failed because it needs the file betaleft.py (to be uploaded by @peterstangl @jasonaebischerGIT ).

[dvandyk]

I'm sorry, but I'm confused and seconding @DavidMStraub's comment from wcxf/wcxf-bases#8: What is the difference to what has been previously done in wilson? The current code uses the SMEFT <-> WET matching in the JMS basis. WET and LEFT are interchangeable names for the same effective field theory. LEFT implies using the JMS basis.

@jackypheno So what do you want to achieve with this PR?

[DavidMStraub]

It's about reimplementing RGEs based on San Diego rather than Bern, right?

In any case, WET should not be renamed to LEFT in the public facing API (WCxf etc.) as that would break things. For internal modules/methods it's fine.

[jackypheno]

@dvandyk The main goal of this PR would be:

Solve the WET/LEFT RGEs directly using the beta functions (for example #94) independently from the existing WET RGEs based on the ADMs. This independent solution to the WET RGEs hopefully will allow us to fix #54 .

The name LEFT is used for the Low energy effective field theory only for the internal modules unlike the initial idea of #8. In the current PR the key wet_method introduced that can take two values adms (default, i.e solve using existing implementation) or 'betafunctions' solve using #94. Thats why #8 has been abandoned.

Apart from this: there is plan to generalise the SMEFT class to an EFT class having SMEFT, LEFT, .. as child classes. For the moment there is not much in the EFT class, eventually all common methods of SMEFT, LEFT , .. will move to parent EFT class. This is currently work in progress!

[jackypheno]

@DavidMStraub Yes, I abandoned the stupid idea of adding new name for LEFT. In contrast the flag wet_method would allow the user to choose between the current or the new method of solving the RGEs. It would also allow us to add unittests comparing the two!

It would also be nice the fix #54 in the current implementation so that both methods can coexist.

[peterstangl]

Since the new wet_method would define a new option that is exposed to the user, I think we should think a bit about how we can extend the interface in a way that makes it possible to later combine the SMEFT and WET options without changing this interface again.

My suggestion would be to use a name for the option that can, at a later point, be used for both WET and SMEFT, e.g. something like rge_solution or rge_method instead of wet_method.

For the options themselves, I would stick to the names that are already used so far. I.e. instead of 'betafunctions' I would use 'integrate' (making it possible to also add a 'leadinglog' option that is based on the betafunctions as well). Since 'integrate' and 'leadinglog' specify the way the RGEs are solved rather than the way they are represented (in terms of either betafunctions or adms), I would suggest to use a name describing the solution by an evolution matrix instead of using 'adms'. Maybe we could use 'matrix' to keep it short, or 'evolutionmatrix' or 'evolution_matrix'.

Any comments on these suggestions and better ideas are also very welcome from @jasonaebischerGIT, @dvandyk, and @DavidMStraub.

[jackypheno]

@peterstangl sure we can invent better names, for the moment I just gave any tentative names, since the PR is currently work in progress. I have not even decided on the names etc and for the moment my focus is to just produce correct solutions to new beta functions #94.

I have already implemented leadinglog and integrate option for WET and will update it soon.

It would be great idea to go through it in details once the implementation is completed.