Unify experiment constuctor signature

[nkanazawa1989]

What is the expected behavior?

In #462 backend arg is added to the all experiment constructors. Thus now all experiments have qubits and backend as common arguments.

If all experiments have good initial experimental parameters, we should be able to run experiment with

data = Experiment([0, 1], my_backend).run()

This pattern can be often seen in Qiskit, for example

assemble(circuits, backend)
transpile(circuits, backend)
schedule(scheds, backend)

etc...

thus is would be great if all experiments can give default parameters except for qubits. Probably we can create a default configuration file to give default values to these experiments while keeping some flexibility. For example, superconducting qubits and spin qubits may have different T1 value, so default decays parameter (currently this is req'd arg) of T1 experiment may depend on target backend. I think giving reasonable (still configurable) default options will make the tool more user friendly because non-experienced user doesn't need to be annoyed from finding good parameters.

Note that backend is an optional argument because the backend object cannot be serialized and we cannot initialize experiment when we load it from db. When we load the experiment, we keep backend empty and later set it via the setter method.

[wshanks]

So it seems like this issue is more about providing a way to load inputs from a stored configuration than about unifying the signature?

Regarding unifying the signature, I have noticed that some experiments like T1 expect qubit: int instead of qubits: Sequence[int].

[wshanks]

I see that #431 addresses my second sentence above.

[chriseclectic]

@nkanazawa1989 I think this is a little restrictive to require for all experiments since there is no reason an experiment should only take qubits as its required arg. But for ones that can or a collections experiments that are very similar (ie characterization ones, or calibration ones) it is good to keep the args consistent between them whenever possible.

@wshanks The ExperimentConfig class can be used to store configuration for initializing an experiment, and is JSON serializable (it can only be properly round-tripped if all the args/kwargs are json serializable, which for the moment does not include schedules).

At minimum it can be used as:

config = ExperimentConfig(args=(arg1, arg2, ...), kwargs={...})
exp = SomeExperiment.from_config(config)

For saving config of an existing experiment you can either do:

# This should probably be moved to a more convenient import path, maybe qiskit_experiments.json
from qiskit_experiments.database_service.json import ExperimentEncoder
import json

json.dump(some_experiment.config, fp, cls=ExperimentEncoder)

Note you could JSON serialize the experiment directly (which basically converts it to its config to store), however if there are any class args which are not properly serializable the deserializing will likely fail when trying to initialize the reconstructed experiment. If you save the config instead you can still deserialize it and inspect the args that didn't serialize correctly (they will be left as a dict containing the original class name and module)

[wshanks]

Okay, I see. So the request is for

SomeExperiment([0, 1], my_backend)

to expand to something like

some_exp_config = __global_config__[SomeExperiment]
some_exp_config["qubits"] = [0, 1]
some_exp_config["backend"] = my_backend
SomeExperiment.from_config(some_exp_config)

where __global_config__ is a global dictionary the user has populated with default configurations for experiments.

The implicit loading of config values in __init__ seems tricky. An alternative might be to add methods like set_default_experiment_options. Then instead of a function to populate __global_config__ the user could have a function that calls the set_default methods on the experiment classes they want to change.

Some way of using from_config and changing qubit and backend values seems nice, though it could be problematic if there are experiments that do something with the qubits or backend in __init__ other than just storing them.