Here is my first post in the new series on codes, even though WCxf is more about conventions than about code.

First off, it’s true, WCxf is not a very catchy name. On the other hand, it’s definitely googlable and was still available as organization name on Github!

So what is it, actually? In short, it’s two things:

- a way to specify and define unambiguous conventions for operators bases in effective field theories (EFTs),
- a data format to exchange numerical values of Wilson coefficients of these operators (in one of these conventions) between different programs.

WCxf is supported by ten public codes and was described in detail in a paper. Below I give a brief version of how it works and list some caveats about its usage.

## Motivation: exchanging BSM WCs

The original motivation was to have an unambiguous way to exchange values of beyond-the-Standard-Model Wilson coefficients between different public codes, for instance those that compute them in specific new physics models, those that perform RG evolution, and those that compute observables. There is already the FLHA format that partly addresses this problem, but we (initially mostly the developers of flavio and EOS) found it not to entirely suit our needs, e.g. because

- different public codes used different normalizations (which are not fixed by FLHA), such that it is not actually an unambiguous exchange format in practice,
- the format does not fix a non-redundant basis of operators, which is not inconsistent, but can lead to ambiguities (the famous symmetry factors of 2) unless each code specifies exactly how redundancies are dealt with,
- the format is limited to the weak effective theory below the electroweak scale and is not meant for SMEFT, which however becomes more and more important,
- while the FLHA file format is similar to other *LHA formats used in HEP, it is not a format that can be easily parsed by all programming languages (unlike industry standards like YAML or JSON).

But in fact the new format we came up with is not meant as a replacement for FLHA – FLHA has a much wider scope, allowing also to exchange SM Wilson coefficient values and even hadronic parameters etc.

Next, let me describe some of the basic concepts of WCxf.

## EFTs

At the most basic level, WCxf allows to define different *EFTs*. An EFT is defined by having a set of *operators* that can optionally be split into *sectors*, that is groups of operators that close under renormalization. This can be convenient for codes performing RG evolution or basis translation, as this can be done on a sector-by-sector basis.

A new EFT is defined by submitted an EFT file to a public repository. At the moment, the EFTs defined are: `SMEFT`

(the dimension-6 extension of the SM above the electroweak scale), `WET`

(the weak effective theory below the EW scale), as well as`WET-4`

and `WET-3`

corresponding to the WET with reduced number of quark flavours (appropriate for low-energy processes below the b or c quark scale).

## Bases

A *basis* in WCxf is defined as a set of non-redundant (but not necessarily complete) operators for a given EFT. For `SMEFT`

, the most well-known basis is the `Warsaw`

basis. On the WCxf web site, you can access PDF files with lists of all operators in a given basis.

Note that the term basis is used slightly differently than in parts of the literature here: it is not sufficient to choose a non-redundant set of operators, but one also needs to define to define the weak basis for the fields and their relations to the mass basis! For WET, this is not so relevant because one is free to work in the mass basis for all fields at all times (even though it might be more convenient to work in the flavour basis for neutrinos), but for SMEFT it is non-trivial: First, because it is not possible to work in the mass basis for both left-handed up-type and down-type quarks. Second, because the RG evolution is flavour dependent, such that definitions involving diagonality of mass matrices are only valid at a single scale.

## Wilson Coefficients

Once EFTs and bases have been defined, they can be used to exchange numerical values of BSM Wilson coefficients. WCxf fixes the *data format*, which is programming language agnostic, and by default provides two different *file formats*: JSON or YAML. But programs can also exchange data structures directly, without the detour over a file.

## Translators & matchers

Since WCxf allows using different basis for a given EFT, it can be used together with *basis translators* that translate a set of WCs from one basis to another. Since it allows also using different EFTs, it can also be used together with *matchers* to match WCs from a high-energy EFT (e.g. SMEFT) to a lower-energy one (i.e. WET). Such translators and matchers are provided by the `wilson`

package that I will discuss in the next post.

## Caveats

After a little more than a year of using WCxf, a few subtleties and caveats have emerged that are worth stressing.

- As already mentioned above, for an unambiguous exchange format, in SMEFT the weak basis needs to be fixed. 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. - The bases must be non-redundant also with respect to flavour indices. This is necessary to ensure an unambiguous and consistent data exchange. However, flavour-redundant bases are actually more convenient in some contexts, e.g. matching or RG evolution, leading to symmetry factors with respect to the flavour non-redundant WCxf conventions. This is discussed in detail in appendix A.2 of this paper.

## Code

There is a Python utility called `wcxf`

that allows to manipulate WCxf files on the command line and can be used as a library for Python packages built on the WCxf format. See its documentation for details. For translation, matching, and RG evolution, the `wilson`

package, that will be discussed in the next post, is a more powerful layer on top of `wcxf`

.