0.2 update

[stavros11]

As promised in #990, this provides a template on how routine updates should be upgraded to the qibolab 0.2 interface. I have fixed the updates associated to the resonator spectroscopy, Rabi amplitude and length and single shot, which are also the upgraded routines in #990 and confirmed they work as expected on hardware and dumps the updated platform parameters successfully.

@alecandido let me know if you agree with the approach used. It is not very nice in terms of code, as I am finding a mutable object (dict or list) nested in qibolab's frozen objects and abuse its mutability to perform the update, but it's probably the simplest and quickest solution. Once we agree, we can merge this and start propagating to other routines as we are also upgrading the acquisition part.

Note that that I have also the updates associated to some parameters that are no longer in the qibolab Platform. As mentioned in #990, my plan is completely ignore them for the time being, since they are already stored within the report results, so it is not necessary to also have them somewhere else.

[alecandido]

@alecandido let me know if you agree with the approach used. It is not very nice in terms of code, as I am finding a mutable object (dict or list) nested in qibolab's frozen objects and abuse its mutability to perform the update, but it's probably the simplest and quickest solution. Once we agree, we can merge this and start propagating to other routines as we are also upgrading the acquisition part.

So, my plan was to change approach concerning updates, in both Qibolab and Qibocal.
Concerning Qibocal, this means a deeper change than what you're doing here, and finally pursuing #910.

My plan is to:

1. define a suitable update function in Qibolab for 0.2.1, that will take care of applying an update from a plain update dictionary similar to

   {
     "native_gates.single_qubit.0.RX[0][1].duration": pi_pulse_duration,
     ...
   }

2. copy-paste the function in the current Qibocal upgrade, to make it available even when using with 0.2.0 (then replace as soon as 0.2.1 will be released)
3. stop producing directly updated platforms' parameters, but rather just produce the update dictionaries - possibly adding the parameters' file generation as a feature in qq update

However, transitionally you may even use the approach in this PR, in case you want to make sure to be able to update the parameters.
But I would discourage you to put too much effort in propagating it to all the routines, unless you disagree with the plan above.

Note that that I have also the updates associated to some parameters that are no longer in the qibolab Platform. As mentioned in #990, my plan is completely ignore them for the time being, since they are already stored within the report results, so it is not necessary to also have them somewhere else.

Concerning this, I perfectly agree. We will need a strategy to treat (store and report) these parameters as data, beyond showing them in the reports.
But that's a separate problem, and we can open a dedicated issue for it.

[stavros11]

1. define a suitable update function in Qibolab for 0.2.1, that will take care of applying an update from a plain update dictionary similar to

   {
     "native_gates.single_qubit.0.RX[0][1].duration": pi_pulse_duration,
     ...
   }

2. copy-paste the function in the current Qibocal upgrade, to make it available even when using with 0.2.0 (then replace as soon as 0.2.1 will be released)

These are both fine with me, as long as we can write this function without making it very ugly. However, it is probably better than the current approach, since the weird manipulations required to update the Platform will be concentrated to this function only and not spread all over the update methods.

3. stop producing directly updated platforms' parameters, but rather just produce the update dictionaries - possibly adding the parameters' file generation as a feature in qq update

I also agree with this. Then I guess there will be no new_platform/parameters.json inside the report folder anymore, just a json dump of the updates dict.

However, transitionally you may even use the approach in this PR, in case you want to make sure to be able to update the parameters. But I would discourage you to put too much effort in propagating it to all the routines, unless you disagree with the plan above.

I would say that the proposed plan seems relatively simple to implement quickly, so I would prefer to go ahead with that directly. I don't think it is worth spending time with another approach, if we are eventually planning to change it and the change can happen pretty soon. The only question is whether there is already a plan to do it and someone is looking into it, or should I do it directly in this PR?

Concerning this, I perfectly agree. We will need a strategy to treat (store and report) these parameters as data, beyond showing them in the reports. But that's a separate problem, and we can open a dedicated issue for it.

Yes, this would be ideal, however according to @andrea-pasquale and @Edoardo-Pedicillo, some of these parameters are used for fitting. I did not encounter this problem yet, as I have not touched any of the routines that this happens. However, if that is the case, we cannot just ignore them and we should try to come up with a solution during the qibolab 0.2 update (even though I initially hope we didn't have to). The main issue is that when you do qq fit you only have access to parameters in the Platform and the current report, so you cannot use parameters foud in a previous report/routine, unless these are also in the Platform, which is not the case for all parameters anymore.

[Edoardo-Pedicillo]

Yes, this would be ideal, however according to @andrea-pasquale and @Edoardo-Pedicillo, some of these parameters are used for fitting.

In theory, not only for fitting, for example, when we run a resonator spectroscopy we sweep around the readout frequency, but we know that this could not be the resonator peak one (even if it is close). It could be better to store the resonator value somewhere (it is not in the 0.1 Platform, so probably not even in the 0.2 one) and use it in the acquisition.
Maybe the example is not too meaningful, but I hope it passes the message.

I don't know too much about Qibolab 0.2, but if we have a Qibocal Platform object inheriting the Qibolab one adding the extra information and feature, we should be able to solve the problem.

[alecandido]

Ok, thanks @stavros11 and @Edoardo-Pedicillo to make me aware of the issue. I agree with you we need an earlier solution.

But maybe I'm not yet fully understanding the problem.
Could you make an even more explicit example where you need to update a Platform?

In principle, we could solve the problem just by adding extra arguments (with None defaults), in order to accept them from outside.
There would be still a problem with runcards, since there would be no clear way of accessing parameters from previous steps, but it would be easily solved in scripts.

---

Concerning runcards, we could even solve the problem there, but it's a bit more convoluted: we could allow specifying the parameters for the fit in the runcard, using some kind of convention for placeholders, like

actions:
  - id: routine1
    ...
  - id: routine2
    ...
    parameters:
      ...
    fit:
      arg1: 42
      arg2: =res1@other_routine

[Edoardo-Pedicillo]

But maybe I'm not yet fully understanding the problem.
Could you make an even more explicit example where you need to update a Platform?

Another example is in the resonator flux dependency: in the fit function we need to access the bare resonator frequency

qibocal/src/qibocal/protocols/flux_dependence/resonator_flux_dependence.py

Line 202 in c77f563

[0, data.bare_resonator_frequency[qubit] * HZ_TO_GHZ - 0.2],

this parameter is in the Platform (Qibolab 0.1). Without it, the fit will fail.

Concerning runcards, we could even solve the problem there, but it's a bit more convoluted: we could allow specifying >the parameters for the fit in the runcard, using some kind of convention for placeholders, like

I think this is not a solution, since it makes the calibration less user-friendly with higher chances of errors.

[alecandido]

I think this is not a solution, since it makes the calibration less user-friendly with higher chances of errors.

User-friendliness is arguable, I agree (though it may be up to a specification).
About the higher chances of errors instead, I would argue that this is the current case, not the proposed one. Now, the order in which routines are executed implicitly affects the results, if the update is set to True (which it is, by default), by changing values in the platform that are not necessarily clear to the user (and may even change over time, by protocols developers' choice). While in the proposed alternative, the causal relation can only be explicit - which should lead to fewer unexpected behavior (though you're losing the default connection between protocols, which could make it simpler for inexperienced users' - but only in the case in which they are running multiple routines in the same runcard).

We could even make the current behavior explicit, with a further feature:

actions:
  - id: routine1
    ...
  - id: routine2
    ...
  - id: routine3
    ...
    parameters:
      ...
    fit:
      inherit: [routine1]

in which there is an automated look-up (matching fit parameters, with specified routines' results, by name). Of course, the same could be done for parameters as well.

However, though it's all possible, we're touching the point where I'd like to invest as little as possible in runcards, and getting more and more inclined to just deprecate them. I.e. keep them for what they could do, and strip features that are complex to support.
Moreover, in my experience most of runcards' users were running one single protocol at a time, and when running multiple ones it has also been suggested to apply --no-update just to make the behavior simpler and more intuitive.

Declined for the current option, a solution could be removing the update key from runcards, with the assumed behavior of update=False, and just keep the update feature for scripts.

[Edoardo-Pedicillo]

@alecandido Your idea could be fine if this information is coming only from the protocols in the same runcard, but it does not cover the case in which the user wants to consume knowledge coming from past calibrations, i.e., the bare resonator frequency should not oscillate too much, so I should not be forced to add every time an high power spectroscopy in the runcard to compute it.

Moreover, in my experience most of runcards' users were running one single protocol at a time, and when running multiple ones it has also been suggested to apply --no-update just to make the behavior simpler and more intuitive.

Personally, this depends on the purpose: for protocol testing it is correct, but for the chip calibration the update is needed and usually, we run multiple protocols in the runcard.

[alecandido]

Ok, to cut the long story short, and simplify maintenance and implementation, my proposal is:

1. avoid new features for runcards (anything which is not trivial to implement - ✅ fit parameters ❌ syntax for connecting to previous parameters) - and in case give up on old features
2. following previous point, I would propose to actually give up on update with runcards, keeping them for simple calibrations, removing the update parameter and act as if update=False always
3. point 2. should make it possible to avoid all automated updates everywhere in qibocal.auto
4. update explicitly Platform.parameters in scripts (the API will be provided by Parameters updater [extended syntax] qibolab#1061), and pass explicitly protocols' results to further routines' arguments (acquisition and fit), where relevant
5. establish a calibration.json, with a corresponding Calibration object (similar to the parameters.json/Parameters pair), and store these files in the platforms' folders - Qibolab will be unaware of their presence, but the existence of a platform folder is part of the interface, and, if not yet exposed, we should make it possible to retrieve a platform path given its name (the Platform object instead, once loaded, has to be kept independent of the path generating it)
6. change API to the Routine.update operations, to return two update dictionaries (according to the Parameters updater [extended syntax] qibolab#1061 syntax), one to update Parameters, the other targeting Calibration
7. add fit parameters to the protocol interface

These points should not be implemented all here, but they are related, and by now coupled to the Qibolab 0.2 upgrade (well, point 7. could be applied even in main...). Once we'll have agreed about the plan, we could split to further issues and PRs.
If you have further related points unaddressed by this list, or comments about the proposal, please feel free to provide any kind of feedback :)

[stavros11]

Closing this as outdated. We have merged a new interface for doing qibolab updates implemented in qiboteam/qibolab#1086. We should start using this on top of #1036 to implement all the updates.