Preparation of the Setup

Runcards

Since both eko/ and yadism/ work with runcards, the outcome shoud be fully specified by specifing the respective runcards. Both programs consume as a first dependency a unique theory runcard (Note that also this is subject to be changed in future versions), that mainly defines the physical setup, e.g. reference value of the strong coupling \(\alpha_s(Q_{ref})\). In addition, they consume a second runcard that is one of the main differences between the two codes: eko consumes an operator runcard, that e.g. defines the target evolution scales, and yadism consumes a observable runcard, that e.g. defines the kinematic points of the structure functions. Henceforth, we will refer to the respective cards uniquely as [o-card] as we can actually abstract some logic here in banana.

Specifing the Desired Setup

Each table comes with a default runcard from which one can extend. Hence, one needs to specify only the key-value pairs that one wants to change. The typical benchmark run will look like this: runner.run(theory_updates,ocard_updates,pdfs)

I/O databases’ structure

Input database will consist of the tables:

• theories: each entry of this table will represent a physical theory, i.e. it will specify a set of parameters involved in QFT computations; the following entries are expected:

  • PTO: perturbative order

  • XIF, XIR:

  • mc. Qmc, mb, Qmb, mt, Qmt:

  • etc.

• observables: each entry of this table will represent a set of DIS observables, and also some parameters involved in the computation of the observables themselves; the following entries are expected:

  • xgrid: the grid on which the interpolation is evaluated

  • etc.

• cache: to keep a cache of the external output. Since it is stable there is no need of rerunning it multiple times to compute the same observables (while rerunning is needed for yadism during its development, of course…)

• logs: keep a log of the comparisons between yadism and the external program