Device status Reporting

[elrama-]

Just discussed a proposal from @leodicarlo for a specific unit of the code that keeps the latest calibrated status of the device. Key points follow:

• To distinguish latest calibrated value from latest value. The former to be qubit.T2_star (for example).
• To keep track of a timestamp for every change we do to these calibrated quantities (I think it would be good to create a Parameter type that does this).
• To have accesible functions that prints a summary.
• To have accesible functions that allow live-connection with the GBT.

curuious to know how you conceived this in your mind @AdriaanRol .

[AdriaanRol]

@elrama- , oeh this looks intereting. I have indeed already put some though in this. I'll try to get back to this in my software chapter of the thesis. In the meantime I'll use this issue to bounce some ideas off of you guys.

In the meantime there is a few things that should already be helpful.

• the parameter class includes an attribute that notes that last change to a parameter. You can use this to know when it got updated (and identify corresponding datasets)
• Most things belong in the device object at some point.
• There is a point where we need more complex data structures than individual parameters, Ideally something portable like a YAML or JSON dictionary. There is a technical aspect
• The printing of a summary is something that I think should be like the device summary figures I made. They also include data structures for this kind of stuff. I have also discussed some preliminary things here with Berend.

Lots of thoughts, no structure yet. I'll put this on as one of the subjects for my Software chapter.

[elrama-]

Code meeting 2020-02-04: Agree with Adriaan on the fact that we have lot of thoughts but no structure yet.

In the spirit of enforcing structure, the following statements pop up:

Berend is working on the Analysis part of it, by reading values out of an HDF5, and triggering the analysis mechanism. That is only one part. How to store, in which structure and what parameters is not clear. There's not even a definite list of parameters available. (probably there's some from some report?) Not sure whether the data should be read of an HDF5 file or live. Hani's strategy for design: think from the gbt backwards.

[jorgemfm27]

After code meeting (04-02-2020) the following structure for logging was conceived: GBT goes through 3 main stages and generates a report after each of them.

Resonators ----------------< LOG resonator specs Qubit spec ----------------< LOG Qubit specs Coherence ----------------< LOG Coherence metrics data

Next meeting @hasali92 and @jorgemfm27 should get a printed version of GBT graph to further iterate this idea.

[elrama-]

Notes from discussion: 12/02/2020

[Summary by Hani]

report is part of the analysis. Recalls things from qubit object. As of now, you wait until all calibrations are finished, then recall the report class and it reports. Right now you do not report from each individual (partial) node. Storage is handled as a big dictionary with qubit names as keys, and inside sub-dictionaries with parameters. This is casted into a pandas dataframe. This inherits from ma2, sharing all our standard flow. Difficulties with coping with partial stuff Does not separate the notion of "calibrated value" and "current value" Report is not connected to GBT

Ideas:

GBT should have a reporting feature for every node. Save a timestamp (associated with a certain node calibration). Both ideas could be merged into a dictionary per node. Purposes still get confused. Use-case declaration?

---

Realizations:

Only focus on use-case of "Daily calibration" Focus on reporting Specifications agreed-upon:

• Calibrated frequencies onto S7 layout.
• Coherence-times table.
• Gate fidelities onto S7 layout.
• Leakage onto S7 layout.
• RO fidelities onto S7 layout.
• Residual excitations onto S7 layout.

[MiguelSMoreira]

According to @jorgemfm27 functionality was tested in demo on Ferrari, but changes should be migrated from notebook and integrated into graph-based tuneup code. To the attention of @elrama- @hasali92