[ymzhang0]

Dependencies

This PR depends on #55 for explicit Eliashberg ports and #58 for RestartType.

Summary

• Remove low-level EPW flags from protocol YAML when they are managed by CalcJob ports or workflow restart stages.
• Configure SuperCon interpolation and final calculations through the orthogonal Eliashberg ports.
• Manage Prep, SuperCon, and mobility restart stages explicitly with RestartType.
• Preserve genuine user-facing protocol settings and direct CalcJob Wannierization semantics.
• Keep physical solver choices separate from restart staging.

Scope

The duplicated #57/#60 parser history and the large Pade fixtures have been removed. This PR contains no CalculationType and does not move parse_transport_matrices. Parser support from #57 and #60 is a downstream integration dependency, not part of this protocol diff.

Validation

• Full test suite: 130 passed, 2 skipped
• Pre-commit checks: passed

[LIU-Binbin]

Hi Yiming,
Is it necessary to define a new Restart type? For better integration to other Aiida plugins and easier maintenance, can we try to use Aiida native functionalities, eg the BaseRestartWorkChain, process handlers etc, to realize it?

[ymzhang0]

Hi Binbin,
Yes we can choose to make the code simple by not defining a RestartType but directly manipulate the parameters dictionary.

I define the RestartType only to encapsulate the relevant parameters into groups so that it is less error-prone because these restart-related parameters are not independent and should always be set consistently.

There is also this kind of behavior in aiida-quantumespresso (see https://github.com/aiidateam/aiida-quantumespresso/blob/e90b9ad8d1a857421a1dcf742597bcb48a8ac991/src/aiida_quantumespresso/common/types.py#L36).

I think RestartWorkChain can not help with this case. It can only help us to restart the workchain without any modification of the parameters only in cases of system crashes.

In the error handling functions, yes we can deal with the parameters control. But as I said, defining a RestartType is only for controlling the parameters into independent groups. It should make the error handling functions more concise (hopefully so). It will not replace the error handling functions.