[WIP] Functions to facilitate experiments on entire backends

[yaelbh]

We address a common use case, where a user wants to perform the same experiment in parallel on all the qubits. In the proposed API, all the user has to do is to define the experiment to run on individual qubits. Then the following happens automatically:

1. A parallel experiment, that applies the user's experiment for all the qubits in parallel, is constructed.
2. The experiment circuits are transpiled only once, for qubit 0; for the rest of the qubits, the circuits are copied, while modifying the qubit indices.

In fact, what's constructed is not a parallel experiment, but a batch experiment of parallel experiments, to ensure that neighboring qubits are tested in different circuits.

From the user's point of view, it looks like this:

"""
Demonstrates whole backend functionality for 1 and 2 qubits
"""

from qiskit import IBMQ

from qiskit_experiments.framework import BatchExperiment
from qiskit_experiments.library.characterization import T1
from qiskit_experiments.library.randomized_benchmarking import StandardRB

from partition import partition_qubits, partition_edges
from whole_backend import build_whole_backend_experiment


backend = IBMQ.load_account().backend.ibmq_quito


# Template experiment must act on the qubits `0, ..., num_qubits-1`
t1_template_exp = T1(0, [1e-6, 20e-6, 60e-6, 120e-6, 200e-6, 300e-6, 420e-6], backend=backend)

# The qubit/edge groups can be obtained from methods that calculate them from the coupling map
# (like `partition_qubits`) or manually given by the user
# qubit_groups = [[[0], [2], [3]], [[1], [4]]]
qubit_groups = partition_qubits(backend, 2)

t1_whole_backend_exp = build_whole_backend_experiment(t1_template_exp, qubit_groups)

rb_template_exp = StandardRB(
    [0, 1], [1, 20, 60, 120, 200, 300, 420], num_samples=1, backend=backend
)

edge_groups = partition_edges(backend, 2)

rb_whole_backend_exp = build_whole_backend_experiment(rb_template_exp, edge_groups)

exp = BatchExperiment(
    [t1_whole_backend_exp, rb_whole_backend_exp], flatten_results=True, backend=backend
)

expdata = exp.run().block_for_results()
expdata.save()

A couple of additional comments:

• For RB, all the qubits will have the same circuits, which I think is fine.
• Note that this is applicable only if transpile options don't depend on the actual qubit (as for example in the CR experiment).

[yaelbh]

This is fairly ready, up to tests and release notes

[coruscating]

I have a use case where I need to copy transpilation of multi-qubit circuits across different sets of qubits, for example doing mirror RB on three qubits across many disjoint sets of three qubits on a device, so it would be really useful if this can be extended to work for duplicating multi-qubit circuits in the scenario where all the qubit groups provided are the same length.

[coruscating]

Suggested change

	Basic atmoic experiment that mimics the template experiment,
	Basic atomic experiment that mimics the template experiment,

[coruscating]

__init.py__ needs to be formatted for generating API docs, and this docstring needs more information on how this works and how to use it. Including the example in your PR text would be helpful.

[wshanks]

Regarding extending this -- @thaddeus-pellegrini and I wrote an extension based on the code here for ZZ measurements where we also want to measure between pairs of disconnected qubits. We can let this PR finish review and then make another PR with that extension to match whatever final form this PR takes.

[yaelbh]

@coruscating I'm not sure if I understand correctly the request. Possibly it's already supported.

mirror_rb_template_exp = MirrorRB([0, 1, 2], ..., backend=backend)

#One parallel circuit, encompassing experiments for the triplets [1, 5, 3], [4, 2, 0], [6, 7, 8]
groups = [[[1, 5, 3], [4, 2, 0], [6, 7, 8]]]

mirror_rb_whole_backend_exp = build_whole_backend_experiment(mirror_rb_template_exp, groups)

[yaelbh]

I see that there's interest in moving this forward.
@chriseclectic In a team meeting you had reservations about the interface. Maybe also @nkanazawa1989.
Can you please read again the proposed interface and comment on it?

[coruscating]

@yaelbh Oh, I misunderstood you saying the experiment circuits are transpiled for only qubit 0 to mean that it wouldn't work for multiple qubit experiments like mirror RB. Then the framework should work for my use case as-is, thanks.

[yaelbh]

@coruscating Almost. The template experiment will be transpiled for qubits 0, 1, 2, taking into account the connectivity between them in the backend. For example, if qubits 0 and 2 are not connected, and you have a cnot gate between them, then the transpiled circuit will insert swap gates.
Now, if you provide in your groups a triplet of qubits with a different connectivity then you may get a bug. For example, if in your triplet the first and second qubits are not connected, while qubits 0 and 1 are connected, then the transpiled circuit may have 2q gates on the unconnected first and second qubits.

[chriseclectic]

My main disagreement with this is the API. I don't like to unnecessarily introduce new APIs to do things when we already have an existing API for building and running experiments which could be used to accomplish the same task, as this adds fragmentation to the module design, and increases burden for documentation and users.

It seems what you really want is a hybrid parallel+batch experiment that is initialized with a single experiment, rather than multiple, and tiles it across specific subsets of qubits. You should be able to accomplish this by creating an experiment subclass (maybe called TiledExperiment) to do this. Eg tiled_t1 = TiledExperiment(t1, qubit_groups). Along this lines the BasicExperiment class also seems unnecessary, as this functionality along with the functionality of build_whole_expeirment could be built into a single TiledExperiment class.

API aside, I think there will be some edge case issues/failures with this approach of transpiling once for logical qubits then remapping transpiled circuits to different qubits for experiments that use pulse instructions based on backend properties for specific qubits/channels, so we should have some validation or handling for those cases.

[yaelbh]

Thanks @chriseclectic. I'll try to design an API following these guidelines. Note that BasicExperiment is an internal class that's required for the implementation.

[yaelbh]

Closing because work continues elsewhere