Computing error generators and downstream quantities in reports

[rileyjmurray]

Our report generation code computes error generators from process matrices. That entails computing something like $\log(A B^{-1})$ or $\log(A^{-1}B)$ for process matrices $(A, B)$.

In the practically-universal case when the argument to the matrix log isn't Hermitian positive definite, issues with branch cuts of the log extended to all of ℝ can lead to violating $\exp(\log( M)) = M$. This results in warnings and invalidates the meaning of certain parts of the report. It's also possible for report generation to fail outright (i.e., an exception is raised but never caught) in the rare situations when $M$ ends up being singular.

The numerical computation of matrix logs can be avoided when a model is already parameterized in terms of error generators. Since error generators are one of our most common ways of parameterizing models it makes sense that report generation should try and take advantage of this fact.

I expect it will be difficult to make these changes in a comprehensive way. So I'm opening this issue rather than making a PR right away.

[coreyostrove]

The numerical computation of matrix logs can be avoided when a model is already parameterized in terms of error generators. Since error generators are one of our most common ways of parameterizing models it makes sense that report generation should try and take advantage of this fact.

The issue here is that in the normal GST workflow one performs gauge-optimization as a final step, and that process currently only works using a process matrix representation (so one can do the requisite similarity transformations). So there currently isn't a way to avoid shifting back and forth between representations when doing gauge-optimization on error generator models.