Refactor PTO to order as in EKO?

[felixhekhorn]

• @giacomomagni mirrored in N3LO light coefficients #145 the theory card refactor from eko and introduced the order field
• I wonder whether instead we should call eko.compatibility inside and then act further (note that we need the eko settings for Couplings.from_dict
• as far as yadism is concerned the second element of order is never relevant (since QED corrections are out of scope, as discussed), instead the tuple (PTODIS, PTO) is relevant

[alecandido]

I would keep compatibility:

1. we can make order to be a tuple (same theory for EKO and yadism)
2. or we can make order just an integer

I prefer 2., since EKO and yadism theories don't have to be the same and they won't be compatible (it should be possible to generate them from a single one, so in this sense they will be compatible, but you won't be able to use exact same runcard).
For sure, we should not use the same name for things that are conceptually different.

So my favorite scheme would be:

# EKO
order: ["QCD", "QED"]
# yadism
order: "QCD"
evolution_order: "QCD"  # open to: `["QCD", "QED"]`

I'm also open to use evolution_order also for EKO (but also order is good enough, since it is clear from the scope). Or also dglap_order, to point out that it is (more or less) resummation, and not FO.

[felixhekhorn]

We need some compatibility between eko and yadism, since they share some settings and, more relevant, some code: Couplings (which explicitly depends on QED) - that's why I suggested to build on top of eko.compatibility

[alecandido]

We need some compatibility between eko and yadism, since they share some settings and, more relevant, some code: Couplings (which explicitly depends on QED) - that's why I suggested to build on top of eko.compatibility

Not that sure: I'd like runcards to be independent, because there are a lot of theory parameters that are DIS only and Evolution only, and they should not enter each other cards (since we are not sensitive to it, they should not be provided).
Moreover, yadism is performing a different job than eko, the dependency is just an implementation detail (to save us some duplication), but should be kept internal: from the point of view of the user, they are separate and that's it.

Also consider that compatibility is a temporary layer, going to vanish as soon as possible. If we need compatibility with database, it should be dealt at the database interface level - i.e. in pineko (that will produce theories for a wide range of providers, including MadGraph and so on). The other option is to keep also pineko theory agnostic (just sensitive to the ID), or semi-agnostic (just producing theory for eko only), and delegate the rest to pinefarm (that is a sensible choice, since it is already aware of providers, so we can keep provider integration only here, instead of spreading over the whole pineline).

[giacomomagni]

I'm happy with this solution:

# EKO
order: ["QCD", "QED"]
# yadism
order: "QCD"
evolution_order:`["QCD", "QED"]`

apart that "QCD" values will not have the same meaning, since we have a +1 for eko ...

[alecandido]

apart that "QCD" values will not have the same meaning, since we have a +1 for eko ...

Yes, you're right wrt the pre-QED status. But after QED modification, they should be the exact same, i.e. the number of powers of $\frac{\alpha_s}{4\pi}$ (since we needed also the case with no QCD, and pure QED, i.e. [0, 1]).