HTML Report Requests

[pcwysoc]

Responding to @coreyostrove's call for HTML report requests.

• [x] Gauge Dependent Error Metrics: Raw Estimates: The basis in which the SPAM operators are reported as matrices is extremely confusing and not explained. Perhaps we should just report them as Pauli (co-)vectors? Alternate suggestion: Make upper triangle the real part and lower triangle imaginary part (or vice-versa)? Even if no changes made, documentation should make how to interpret these maps clear.
• [ ] Quantum instrument scale: Quantum instruments usually have a maximum element value of 0.5, but this varies. Currently, all process matrices (including QIs) are scaled the same which impacts visibility. The plot of the quantum instrument elements should take the maximum value in any of the estimates and Target to set the colorbar. However, this should be symmetric and the scale should be the same for all instrument elements.
• [x] Hover label in per sequence detail: this sometimes covers the entire plaquette making navigation hard (particularly problematic for many-outcome circuits, i.e. PC GST or long-sequence QILGST).
• • [x] It would be nice if the information contained in the tooltip box was more cleanly presented. Two ideas to that end:
• • • [x] Displaying no more than, say, 3 significant figures for any float.
• • • [x] Turning the outcomes/p/f/counts data into a table. Ideally it would have borders (like a spreadsheet table) but given plotly restrictions, a tab-delimited table (for example) would still be great.
• • [ ] Germ labels for 2Q GST sometimes get truncated on the color box plots' y axes. It would be nice if we can fix this.
• [ ] Gauge invariant Error Metrics Table 1: This table appears to be (almost always?) broken now (RB error metrics).
• [ ] Gauge invariant Error Metrics Table 5: For 2Q GST, does not always (ever?) properly compute this table (Gauge-robust gate metrics).
• [ ] Error bars missing from following tables:
• • [ ] Gauge Invariant Error Metrics: Overview: Tables 3, 4, 5, 7
• • [ ] Gauge Invariant Error Metrics: Germs Detail: Table 1
• • [ ] Gauge Variant Error Metrics: Germs Detail: Tables 3, 4
• • [x] Gauge Dependent Error Metrics: Raw Estimates: Tables 1, 2. (Table 2 displays CI half-width in column 4 but would be nice if it was displayed via mouseover as well.)
• • [ ] Gauge Dependent Error Metrics: Gate Decompositions: Tables 1, 2.
• [ ] Scale of confidence regions for raw estimates: It would be helpful to a) be able to find out the errorbars on a particular process matrix element by hovering over it (like is done for error generators currently) and b) be able to tell the scale of the errorbars at a glance (perhaps adding a colorbar).
• [ ] Consistent sizing of plots: the auto-scaling to the size of figure size with the window means that some plots are tiny and some overlap. I know this could be hard to fix. Another thing that could allow larger plots is moving the color bar along the bottom.
• [x] Juan's point: about adding something like "click for more info" on the titles of plots
• [ ] Downloading a plot as png: rarely works, usually gives an empty plot
• [ ] The colorscale on raw estimates: often we get such good results now that it can be hard to visually see how the estimates differ from the target. Maybe a log scale or something?
• [ ] More report generation feedback/warnings: so as to more easily identify what is going wrong, this also aligns nicely with the goal of making the report more modular to allow more experiment designs (e.g. warn if something is skipped)

I know some of these are probably more fixable than others, but I wanted to report everything just in case!

[coreyostrove]

Juan's point: about adding something like "click for more info" on the titles of plots

This was added by @sserita in 0.9.12.2, so this can be checked off.

[coreyostrove]

Question:

Predicted RB number in Gauge Invariant Estimates: this never calculates correctly

By this do you mean that it doesn't show up, or that the value returned is wrong?

[pcwysoc]

The returned value is -1 always.

[pcwysoc]

Added another point about report generation.

[pcwysoc]

@kmrudin and I added another 10 points.

[coreyostrove]

(Joking aside, thanks for the detailed updates!)

[coreyostrove]

Predicted RB number in Gauge Invariant Estimates: this never calculates correctly The returned value is -1 always.

Whelp, I can explain this one (stumbled onto this serendipitously): https://github.com/sandialabs/pyGSTi/blob/ee2158575f4a6a9cffa7465983054be13772e0f8/pygsti/report/reportables.py#L2218C66-L2218C67

@jordanh6 has kindly agreed to look into this and try to restore this functionality.

[coreyostrove]

Gauge Dependent Error Metrics: Raw Estimates: The basis in which the SPAM operators are reported as matrices is extremely confusing and not explained. Perhaps we should just report them as Pauli (co-)vectors? Alternate suggestion: Make upper triangle the real part and lower triangle imaginary part (or vice-versa)? Even if no changes made, documentation should make how to interpret these maps clear.

Funny enough, after an investigation of the code it turns out that your alternate suggestion, making the upper triangle correspond to the real part and lower the imaginary part is exactly what is being done currently (it just isn't stated anywhere in the report). I'm not sure why it was thought to be in a strange basis (I recall hearing this too), but it looks like it is just the standard basis (with unexpected convention).

It also turns out support for including the HS vector was already implemented, it just had the flag for including it set to False elsewhere in the reporting code.

With that I think there are three options (in addition to including the HS vector, which I see no downside to doing by default).

1. lean into the current approach for SPAM and add additional labeling to indicate which triangle is which (analogous to what I did with the C/A error generator projections.
2. Split this into two subfigures, one each for real and imaginary.
3. Drop the whole box plot thing for SPAM and just report this as a matrix with complex entries.

I'm leaning toward 2, but open to being convinced otherwise.

[coreyostrove]

Here is my first attempt at reworking the spam plot from raw estimates. I want to re-work the hilbert schmidt vector some more (giving this as a vector in this format is the original behavior still).

[coreyostrove]

Here is my next iteration on this table/plots: