Not only in qubit spectroscopy, but very often the *Data classes built by the acquisition functions are exceedingly complex, and they involve the usage of these .register_qubit methods.
For the qubit spectroscopy, half of the work was done in #1607, by storing raw data in the *Data object, and start sourcing the parameters to be propagated from the *Parameters class, instead of the computed values for each and every qubit.
However, much of the existing information-passing mechanisms have not been cleaned up, and the protocol now contains operations which are a bit redundant.
In general, we would like the fitting functions to have access to the parameters that have been passed (or a relevant subset of it) and to a convenient slice of the Parameters and Calibration.
Possibly, we want to still avoid to give full access from these functions to the whole some of *Parameters and the Platform content, to make it more isolated, and therefore easier to test/invoke independently.
However, we may make a method of the *Data class, to generate it from the larger subset, such that it is also is to populate it having the larger collections at hand.
Something that instead we should preserve is the independence from the platform. If propagated upwards, and made optional for FIT mode, we could avoid what is being done in #1624
Not only in qubit spectroscopy, but very often the
*Dataclasses built by the acquisition functions are exceedingly complex, and they involve the usage of these.register_qubitmethods.For the qubit spectroscopy, half of the work was done in #1607, by storing raw data in the
*Dataobject, and start sourcing the parameters to be propagated from the*Parametersclass, instead of the computed values for each and every qubit.However, much of the existing information-passing mechanisms have not been cleaned up, and the protocol now contains operations which are a bit redundant.
In general, we would like the fitting functions to have access to the parameters that have been passed (or a relevant subset of it) and to a convenient slice of the
ParametersandCalibration.Possibly, we want to still avoid to give full access from these functions to the whole some of
*Parametersand thePlatformcontent, to make it more isolated, and therefore easier to test/invoke independently.However, we may make a method of the
*Dataclass, to generate it from the larger subset, such that it is also is to populate it having the larger collections at hand.Something that instead we should preserve is the independence from the platform. If propagated upwards, and made optional for
FITmode, we could avoid what is being done in #1624