This PR covers changes intended to improve reporting support for two scenarios:
Report generation when using a CircuitListsDesign (addressing #320)
Report generation when performing GST without using gauge optimization. (addressing #412)
For item 1, previously it was the case that many plots, especially those related to model violation summarization had the assumption that the design has a PlaquetteGridStructure format hardcoded in. This of course makes sense for the model violation and TVD plaquette plots, but is an unnecessary assumption for the per-circuit histogram plots and other model violation statistics plots which would fail to generate. With the changes in this PR we can now generate all of the model violation plots that don't explicitly require this structure.
For item 2, this is in response to the bug report from @pcwysoc in #412. As reported there, when performing GST without gauge optimization the report generation would not create plots/tables related to gauge-variant quantities including distance metric tables, error generator plots, etc... This report reminded me that I ran into this exact same issue over a year ago in the context of generating reports for ModelTest protocols and fixed it on this branch (where I allowed it to subsequently languish after getting distracted). So I've now ported the fix I made for ModelTest over to the GateSetTomography protocol (and pre-emptively LinearGateSetTomography since this would have the same issue if anyone were to use it this w/o gauge optimization).
In the process of working on item 2 I originally implemented some changes to deprecate 'none' as an option, before reverting these changes upon the realization that the utility of having this option (beyond what is available using an empty GSTGaugeOptSuite) is that it allows for including no gauge optimization as an option among other gauge optimization suites (including multiple gauge optimizations in an estimate isn't something we do super often, but is fully supported). In going through this back and forth, however, it occurred to me (spurred on by the intuition about how the code worked that I'd gained from the other bugfixes) that there was going to be an edge case when using multiple gauge optimization suites when including 'none' as one of them wherein this would be skipped/not included in the report. Some subsequent testing confirmed this was indeed the case, with reports produced including all of the selected suites except for None. TLDR, I knew if I didn't fix this now I may never have done so, so I figured out a patch and that fix is included in this PR as well.
Unrelated change: While going through the gst protocol module I happened to noticed that the LinearGateSetTomography protocol was missing the auxfile specifications needed for directory-based serialization of the sort we have for GateSetTomography and StandardGST. So I added those (pattern matching off of the other two), which means that this protocol should be serializable now. Probably not a big deal either way, since I don't think many folks use this with any regularity, but figured I'd do it now since while it was fresh. I also added some new unit tests for all three of these protocols testing the directory-based serialization for each them.
This PR covers changes intended to improve reporting support for two scenarios:
For item 1, previously it was the case that many plots, especially those related to model violation summarization had the assumption that the design has a PlaquetteGridStructure format hardcoded in. This of course makes sense for the model violation and TVD plaquette plots, but is an unnecessary assumption for the per-circuit histogram plots and other model violation statistics plots which would fail to generate. With the changes in this PR we can now generate all of the model violation plots that don't explicitly require this structure.
For item 2, this is in response to the bug report from @pcwysoc in #412. As reported there, when performing GST without gauge optimization the report generation would not create plots/tables related to gauge-variant quantities including distance metric tables, error generator plots, etc... This report reminded me that I ran into this exact same issue over a year ago in the context of generating reports for ModelTest protocols and fixed it on this branch (where I allowed it to subsequently languish after getting distracted). So I've now ported the fix I made for ModelTest over to the GateSetTomography protocol (and pre-emptively LinearGateSetTomography since this would have the same issue if anyone were to use it this w/o gauge optimization).
In the process of working on item 2 I originally implemented some changes to deprecate 'none' as an option, before reverting these changes upon the realization that the utility of having this option (beyond what is available using an empty GSTGaugeOptSuite) is that it allows for including no gauge optimization as an option among other gauge optimization suites (including multiple gauge optimizations in an estimate isn't something we do super often, but is fully supported). In going through this back and forth, however, it occurred to me (spurred on by the intuition about how the code worked that I'd gained from the other bugfixes) that there was going to be an edge case when using multiple gauge optimization suites when including 'none' as one of them wherein this would be skipped/not included in the report. Some subsequent testing confirmed this was indeed the case, with reports produced including all of the selected suites except for None. TLDR, I knew if I didn't fix this now I may never have done so, so I figured out a patch and that fix is included in this PR as well.
Unrelated change: While going through the gst protocol module I happened to noticed that the LinearGateSetTomography protocol was missing the auxfile specifications needed for directory-based serialization of the sort we have for GateSetTomography and StandardGST. So I added those (pattern matching off of the other two), which means that this protocol should be serializable now. Probably not a big deal either way, since I don't think many folks use this with any regularity, but figured I'd do it now since while it was fresh. I also added some new unit tests for all three of these protocols testing the directory-based serialization for each them.