eko.runner package

Manage steps to DGLAP solution, and operator creation.

eko.runner.solve(theory_card: Dict[str, Any] | TheoryCard, operators_card: Dict[str, Any] | OperatorCard, path: PathLike)

Solve DGLAP equations in terms of evolution kernel operators (EKO).

The EKO \(\mathbf E_{k,j}(a_s^1\leftarrow a_s^0)\) is determined in order to fullfill the following evolution

\[\mathbf f(x_k,a_s^1) = \mathbf E_{k,j}(a_s^1\leftarrow a_s^0) \mathbf f(x_j,a_s^0)\]

The configuration is split between the theory settings, representing Standard Model parameters and other defining features of the theory calculation, and the operator settings, those that are more closely related to the solution of the DGLAP equation itself, and determine the resulting operator features.

Note

For further information about EKO inputs and output see Input & Output

Submodules

eko.runner.commons module

Runners common utilities.

eko.runner.commons.interpolator(operator: OperatorCard) → InterpolatorDispatcher

Create interpolator from runcards.

eko.runner.commons.atlas(theory: TheoryCard, operator: OperatorCard) → Atlas

Create thresholds atlas from runcards.

eko.runner.commons.couplings(theory: TheoryCard, operator: OperatorCard) → Couplings

Create couplings from runcards.

eko.runner.legacy module

Main application class of eko.

class eko.runner.legacy.Runner(theory_card: Dict[str, Any] | TheoryCard, operators_card: Dict[str, Any] | OperatorCard, path: PathLike)

Bases: object

Represents a single input configuration.

For details about the configuration, see here

setup

input configurations

Type:

dict

banner = '\noooooooooooo oooo    oooo  \\\\ .oooooo.\n`888\'     `8 `888   .8P\'  //////    `Y8b\n 888          888  d8\'   \\\\o\\/////    888\n 888oooo8     88888     \\\\\\\\/8/////   888\n 888    "     888`88b.      888 ///   888\n 888       o  888  `88b.    `88b //  d88\'\no888ooooood8 o888o  o888o     `Y8bood8P\'\n'

compute()

Run evolution and generate output operator.

Two steps are applied sequentially:

1. evolution is performed, computing the evolution operator in an internal flavor and x-space basis

2. bases manipulations specified in the runcard are applied

eko.runner.managed module

Fully managed runner.

This is an automated runner, mainly suggested for small EKOs computations.

The primitives used here to compute the various pieces are part of the public interface, and should be directly used to manage a more complex run for a considebaly large operator.

Thus, parallelization and multi-node execution is possible using EKO primitives, but not automatically performed.

eko.runner.managed.solve(theory: TheoryCard, operator: OperatorCard, path: Path)

Solve DGLAP equations in terms of evolution kernel operators (EKO).

eko.runner.operators module

Combine parts into operators.

eko.runner.operators.retrieve(headers: List[Evolution | Matching], parts: Inventory, parts_matching: Inventory) → List[Operator]

Retrieve parts to be joined.

eko.runner.operators.dot4(op1: ndarray[Any, dtype[_ScalarType_co]], op2: ndarray[Any, dtype[_ScalarType_co]]) → ndarray[Any, dtype[_ScalarType_co]]

Dot product between rank 4 objects.

The product is performed considering them as matrices indexed by pairs, so linearizing the indices in pairs.

eko.runner.operators.dotop(op1: Operator, op2: Operator) → Operator

Dot product between two operators.

Essentially a wrapper of dot4(), applying linear error propagation, if applicable.

Note

Linear error propagation requires matrices to be positive before taking the product.

Indeed, for a simple product of two variables \(a \cdot b\), the error is propagated in the following way:

\[\max_{\sgn_{da}, \sgn{db}} (a + da)(b + db) - ab = \max_{\sgn_{da}, \sgn{db}} da \cdot b + a \cdot db + \mathcal{O}(d^2) = |da \cdot b| + |a \cdot db| + \mathcal{O}(d^2) = |da | \cdot |b| + |a| \cdot |db| + \mathcal{O}(d^2)\]

Where the second step is a consequence of being able to vary the two variations independently, and last just a trivial property of the product.

But in a matrix multiplication, each element of the two matrices has an independent variation associated. Thus:

\[\max_{\sgn_{da_i}, \sgn{db_i}} (a_i + da_i)(b_i + db_i) - a_i b_i = \max_{\sgn_{da_i}, \sgn{db_i}} da_i \cdot b_i + a_i \cdot db_i + \mathcal{O}(d^2) = |da_i| \cdot |b_i| + |a_i| \cdot |db_i| + \mathcal{O}(d^2)\]

eko.runner.operators.join(elements: List[Operator]) → Operator

Join the elements into the final operator.

Note

Since the matrices composing the path have to be multiplied from the destination to the origin, the input order, coming from path (which is instead origin -> target), is being reversed.

Todo

consider if reversing the path…

eko.runner.parts module

Compute operator components.

Todo

This is the only part of the new runner making use of the global context through the EKO object.

After #242, the goal is to update Operator and OperatorMatrixElement to simplify the computation and passing down parameters.

eko.runner.parts.managers(eko: EKO) → dict

Collect managers for operator computation.

Todo

Legacy interface, avoid managers usage.

eko.runner.parts.blowup_info(eko: EKO) → dict

Prepare common information to blow up to flavor basis.

Note

intrinsic_range is a fully deprecated feature, here and anywhere else, since a full range is already always used for backward evolution, and it is not harmful to use it also for forward.

Indeed, the only feature of non-intrinsic evolution is to absorb a non-trivial boundary condition when an intrinsic PDF is defined. But to achieve this, is sufficient to not specify any intrinsic boundary condition at all, while if something is there, it is intuitive enough that it will be consistently evolved.

Moreover, since two different behavior are applied for the forward and backward evolution, the intrinsic range is a “non-local” function, since it does not depend only on the evolution segment, but also on the previous evolution history (to determine if evolution is backward in flavor, irrespectively of happening for an increasing or decreasing interval in scale at fixed flavor).

eko.runner.parts.evolve_configs(eko: EKO) → dict

Create configs for Operator.

Todo

Legacy interface, make use of a dedicated object.

eko.runner.parts.evolve(eko: EKO, recipe: Evolution) → Operator

Compute evolution in isolation.

eko.runner.parts.matching_configs(eko: EKO) → dict

Create configs for OperatorMatrixElement.

Todo

Legacy interface, make use of a dedicated object.

eko.runner.parts.match(eko: EKO, recipe: Matching) → Operator

Compute matching in isolation.

Note

Compared to the old prescription, a dedicated rotation to a different intrinsic basis is not needed any longer.

All the operators are blown up to flavor basis, and they are saved and joined in that unique basis. So, the only rotation used is towards that basis, and encoded in the blowing up prescription.

eko.runner.recipes module

Recipes containing instructions for atomic computations.

eko.runner.recipes.elements(ep: Tuple[float, int], atlas: Atlas) → List[Evolution | Matching]

Determine recipes to compute a given operator.

eko.runner.recipes.create(evolgrid: List[Tuple[float, int]], atlas: Atlas) → List[Evolution | Matching]

Create all associated recipes.