Error budget pruning strategy in resource estimator core

[msoeken]

Resource estimation takes as input an error budget. This is a triplet of budget contribution to logical errors, rotation synthesis errors, and magic state distillation errors. The user can either specify each of these three values separately or provide a total value that is uniformly distributed among the three parts. So far, RE does not modify these provided values.

This PR implements a pruning strategy for the error budget that will decrease the budget for logical errors and rotation synthesis errors (without affecting the estimation), while increasing the budget for magic state distillation errors in order to reduce the resources required for factories.

For logical errors, we can reduce the budget by finding the largest value that still leads to the same code parameter (e.g., code distance). Similarly, for synthesis errors, we can reduce the budget by finding the largest value that still leads to the same number of magic states. The latter is layout dependent, and therefore a new function is added to the Overhead trait. The function has an empty default implementation, and therefore does not break existing layout implementations.

The strategy needs to be explicitly set for the resource estimation and only works for a resource estimation without any other constraints (e.g., maximum number of qubits or duration), and does not work for frontier based estimation. There is no job parameter yet to enable the behavior.

[billti]

I only see Rust updates here. Is this intended to be generally available functionality? (i.e. available via the Python API. I assume not for exposure in the simplified VS Code experience). If so, does it need Python (and docs) updates?

[msoeken]

I only see Rust updates here. Is this intended to be generally available functionality? (i.e. available via the Python API. I assume not for exposure in the simplified VS Code experience). If so, does it need Python (and docs) updates?

Eventually, this should be accessible via the Python API through job parameter configurations. But I'd like consider other PRs such as #1940, possibly #1689, and maybe other upcoming ones in designing how these configurations should look like rather than deciding ad-hoc for each feature. I suggest to then update Python (and docs) together with the PR that makes these capabilities accessible through job parameters.

[billti]

Thanks. Makes sense. I browsed the code and tested it with a bunch of our sample scripts and notebooks, all looks good. Approved!