Enforce default for matching order at post-init time

[alecandido]

Hot fix for matching order setting.

It should be properly tested, but if merging this is urgent we can postpone it.

[alecandido]

It should be properly tested, but if merging this is urgent we can postpone it.

I take it back: thanks to @felixhekhorn is already tested. And the behavior was different from the one I imagined.

Actually, this would not work with the polarized settings @RoyStegeman forwarded (the default would not reproduce those settings, but you should keep manually specifying it).

theorycard = TheoryCard.from_dict(
    {
        "order": [2, 0],
        ...
        "matching_order": [2, 0],
    }
)

(and instead it will be "matching_order": [1, 0], by default)
However, before fine-tuning for polarized, I'd like to understand why polarized should be different from unpolarized. @Radonirinaunimi

[RoyStegeman]

if merging this is urgent we can postpone it

It's not urgent since I can just set the matching orders manually. Nevertheless, I think this can be merged once @Radonirinaunimi is able to confirm if this is also correct for polarized.

[felixhekhorn]

• I'm slightly worried about unintended side effects (i.e. please wait and check the benchmarks)
• we should drop these lines

  eko/src/eko/runner/parts.py

  Lines 93 to 94 in 0c4bf11

  	if tcard.matching_order is not None
  	else (tcard.order[0] - 1, 0),

  to avoid double acounting
• it is fine to keep this one

  eko/src/eko/io/runcards.py

  Line 223 in 0c4bf11

  new["matching_order"] = old.get("PTO_matching", [old["PTO"], 0])

  since we may have PTO_matching (although in real life, I think, this never happens ...)

[giacomomagni]

• we should drop these lines

  eko/src/eko/runner/parts.py

  Lines 93 to 94 in 0c4bf11

  	if tcard.matching_order is not None
  	else (tcard.order[0] - 1, 0),

  
  to avoid double acounting

I thought the same, but one should be to evolve ekos without that key and the other one for reading ekos without that key no?

[felixhekhorn]

I thought the same, but one should be to evolve ekos without that key and the other one for reading ekos without that key no?

Mmm not really, I think - either case would create a TheoryCard object and after calling the constructor you're done

[alecandido]

Indeed, @felixhekhorn is right: they are acting both at the level of the TheoryCard, so they are doubled.
The new one is for reading and writing, since acting directly on TheoryCard, the old one only for writing, since enforced during computation.

[felixhekhorn]

Can this be merged?

[alecandido]

For me, it was ready. If you and @giacomomagni agree, then I'll merge.