Composite Output - distributed computation

[alecandido]

Follow up of #105

• add runcards subfolder and move there runcards (0.theory.yaml, 0.operator.yaml)
• create recipes subfolder and dump instructions
• create recipes' runner, dump into parts subfolder
• create parts' merger

UI:

• orchestrate eko run through CLI commands (run subcommand)

Further:

• write runcards types (eko.runcards) and use them in eko.output.struct.EKO
• rename output subpackage in something more appropriate (like compute or orchestration)
• runcard dump broken: Q0 and Qref are NumPy scalars in both theory and operators card
• functions that play with q2 should always act on existing element retrieved with a given precision (parameter of the object): if multiple object are found in the range, raise
  • __getitem__
  • __setitem__
  • __contains__
• rename output/manipulate.py to output/rotation.py
• move Rotation from output/struct.py to output/rotation.py
• move Operator from output/struct.py to output/operator.py
• move DictLike from output/struct.py to output/utils.py

Plan

Let's break all these over multiple PR:

Recipe

• establish recipe format
  • self contained instruction to compute a part
  • do not repeat global information (like Configs and Debug) since they are always accessible for the full operator
• with dedicated in-memory struct
• provide recipe computer (from runcard-like input)

Parts

• start splitting operator.grid instructions to compute parts from recipes
• provide a part struct
• benchmark with FFNS

Operators

• compute full operators as well (merging separate parts)
• move operator struct
• benchmark with VFNS

Runner replacement

• replace default runner, with a runner using recipes-parts-operators
• benchmark new runner against old one, over a wide range of conditions
• drop operator.grid

Move to Ekobox

Since at this point the runner won't be our default way to compute an EKO, and Ekobox is sufficiently good, we can move the one-line runner to Ekobox (it will actually be there for user convenience, so makes sense to be part of the UI-oriented package).

In particular, we can also include as part of the EKO CLI, i.e.:

eko run thcard.yaml ocard.yaml [output-file]

Layout

Following, the proposed layout backing the new mode:

runner.py
output/
  |-- legacy.py
  |-- struct.py
  |-- rotation.py
  |-- recipe.py
  |-- part.py
  |-- operator.py

• runner.py: it will eventually contain a runner performing the same task of the current one, but based on recipe-part-operator rather than operator.grid
• legacy.py: contains methods to load and dump old style EKO files (dump methods are going to be deprecated as soon as it is possible to compute a new one, load later on)
• struct.py: contains the EKO class and simplest methods
  • for some time will also host Debug and Config
  • Config has also to be renamed, too generic
• rotation.py: contains the Rotation class and rotation functions (xgrid, flavor, and to evolution wrapper)
• recipe.py: contains the Recipe class and functions to compute it from runcard-like info
• part.py: contains the Part class and functions to compute part from recipe
• operator.py: contains the Operator class, and functions to compute operator from parts

[alecandido]

@felixhekhorn whenever you open a new PR, list it (the #xx tag) in the corresponding section of the Plan