Next runcards update

[alecandido]

At the moment we want to keep compatibility with the runcard format defined by #220

However, while reworking the internals for numerical FONLL I just defined the concept of the "evolution point", that (apart from the name) is a clean abstraction suitable for the runcard as well.

For this reason, I start here a list of desiderata for the next runcard update, without any idea about its schedule.

• evolution points in the runcard
• drop intrinsic range
• drop integration cores
• drop max nf configurations

And related:

• drop runcards.update()

Evolution points

Move num_flavs_init:

eko/src/eko/quantities/heavy_quarks.py

Lines 106 to 111 in 0224739

	num_flavs_init: FlavorsNumber
	r"""Number of active flavors at fitting scale.
	I.e. :math:`n_{f,\text{ref}}(\mu^2_0)`, formerly called ``nf0``.
	"""

to mu0:

eko/src/eko/io/runcards.py

Lines 95 to 96 in 0224739

	mu0: float
	"""Initial scale."""

Also the couplings reference should be an evolution point (scale, num_flavs_ref):

eko/src/eko/quantities/couplings.py

Lines 23 to 25 in 0224739

	scale: LinearScale
	max_num_flavs: FlavorsNumber
	num_flavs_ref: Optional[FlavorsNumber]

Intrinsic range

eko/src/eko/runner/parts.py

Lines 45 to 62 in 0224739

	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/src/eko/quantities/heavy_quarks.py

Lines 114 to 115 in 0224739

	intrinsic_flavors: IntrinsicFlavors
	"""List of intrinsic quark PDFs."""

Integration cores

After #242 we should not need any longer, and parallelism in Python has poor support, better avoiding it, and apply at some different level (dispatch multiple jobs, use parallel primitives).

eko/src/eko/io/runcards.py

Lines 87 to 88 in 0224739

	n_integration_cores: int = 1
	"""Number of cores used to parallelize integration."""

Max nf

Drop both MaxNfPdf and MaxNfAs because redundant with the matchings mechanism.

Actually, the first one is fully redundant, while the second is only redundant if equal to the first, but there is no evidence that it makes sense using it separately during an evolution run (and since EKO is a library, like APFEL, if you want just to evolve $\alpha_s$ you can pass your matchings to the Couplings class)

Runcards update

It will be up to the user to use the new nested runcards.

We will move the update() function to ekomark, for its internal uses.