With the API enhancement (and possible transitioning) it becomes more relevant to accept external contributions, similarly to the actual plugins depicted in #508.
Applications
generating tables and plots could be useful beyond what is actually generated from the routines themselves
e.g. to collect in a single plot results coming from multiple available routines
eventually you'd like this information to be integrated in the final report
acquiring certain data at some stage of the whole experiment could also be practical
this has to be integrated in the execution, since in general scripts will not have a direct handle to the platform
even fitting together data from different routines might be useful
though this can happen fully outside the executor, it could be useful to register a fit on its own for
Updating the platform should mainly be done as a consequence of some actual routine (and a fit), to proper document the update and the motivations behind. But we could leave this consideration to the user, and expose even this.
Proposal
In order to ease the definition of partial routines, we could make specialized Routine constructors, restricted to individual components.
Despite we could follow this approach, I would mostly keep internal, or for more structured library extensions.
Instead, I'd expose a functional API to the user, similar to the following one:
from qibocal.routines import acquire, fit, plot, update
# Acquisition require a function, because it could depend on some parameters only known by
# the executor
def my_acquisition(platform, execution_parameters):
...
return acquired_data
acquire(my_acquisition)
# or, if it is fully independent on platform and parameters, just pass a sequence
my_sequence = ...
acquire(my_sequence)
# If the fit also needs to acquire, we need a proper routine, so the following function is
# only to store fit results in the history
fit_results = ...
fit(fit_results)
# As for fitting, if plotting requires access to a specific fit results, or certain acquired
# data, a proper routine is needed - while this function is only to register results for the
# report to show them
plots_and_tables = ...
plot(plots_and_tables)
# Update as well is subject to the same remark of fit and plot, and the function is just to
# give access to platforms modification
some_parameters_update = ...
update(some_parameters_update)
All the previous functions should also accept a name, and optionally further metadata, to use them as names of the folders and in the report.
Being Python, we have a certain introspection available, so we could otherwise extract the name from the name of the variable (in case of functions, we could even extract the docstring).
With the API enhancement (and possible transitioning) it becomes more relevant to accept external contributions, similarly to the actual plugins depicted in #508.
Applications
Updating the platform should mainly be done as a consequence of some actual routine (and a fit), to proper document the update and the motivations behind. But we could leave this consideration to the user, and expose even this.
Proposal
In order to ease the definition of partial routines, we could make specialized
Routineconstructors, restricted to individual components. Despite we could follow this approach, I would mostly keep internal, or for more structured library extensions. Instead, I'd expose a functional API to the user, similar to the following one:All the previous functions should also accept a name, and optionally further metadata, to use them as names of the folders and in the report. Being Python, we have a certain introspection available, so we could otherwise extract the name from the name of the variable (in case of functions, we could even extract the docstring).