Run circuits according to `Circuit.wire_names`

[Edoardo-Pedicillo]

I would like to run a circuit specifying in which physical qubits it should be executed. The implementation can be done in different ways and on different levels, I am opening this issue to discuss.

I prefer to use Circuit.wire_names as a map and execute the circuit accordingly. One way to do it is to have a qubit setter in Gate and let the compiler change it, or we can let the compiler rules have the mapping as an input (like #864).

[alecandido]

Ops, I haven't seen this, and just replied in https://github.com/qiboteam/qibolab/pull/864#issuecomment-2036591416

In any case, I'd make the mapping part of the Circuit, such that it keeps the user-given names (arbitrary) and the actual names (0, 1, 2, ...). In the platforms, I would only use the integers. If there is any reason to associate different names at this level, the mapping could be documented (or kept as part of the Platform, but never used internally). We have the freedom of deciding names in Qibolab, since they are fully internal, so let's keep it simple.

Personally, I'd move this issue to Qibo.

[Edoardo-Pedicillo]

I understand your point, but I am not sure it is possible not to touch Qibolab, since the compiler create the sequences according to Gate.qubit(s), that are always in [0, circuit.nqubits], if we change it, I think we will brake Qibo.

In any case, I'd make the mapping part of the Circuit, such that it keeps the user-given names (arbitrary) and the actual names (0, 1, 2, ...).

So, you want a mapping int->int (we can use integers matrices instead of generic dictionary, to force it), we can do it, but still I think we are forced to use the mapping in Qibolab.

[Edoardo-Pedicillo]

Lets keep the conversation in the PR

[alecandido]

I understand your point, but I am not sure it is possible not to touch Qibolab, since the compiler create the sequences according to Gate.qubit(s), that are always in [0, circuit.nqubits], if we change it, I think we will brake Qibo.

This part is fine, and I'd keep it as it is.

As I said in https://github.com/qiboteam/qibolab/pull/864#issuecomment-2036679286, eventually you could do something like:

platform = PlatformView(original_platform, qubits=[1, 5, 17])
circuit = Circuit(3)
# ... define your circuit with 3 qubits ...
QibolabBackend(platform).execute_circuit(circuit)

However, for the time being, my suggestion would be to just do Circuit(18), and forget about the other qubits. It should not cause any relevant overhead (apart from screwing up the drawings). Morever, you should be able to concatenate a circuit with fewer qubits in one with more qubits. By doing on an empty one, you could define the circuit with just the qubits you need, and just increase the number of qubits after the creation.

[Edoardo-Pedicillo]

This part is fine, and I'd keep it as it is.

As I said in #864 (comment), eventually you could do something like:

platform = PlatformView(original_platform, qubits=[1, 5, 17])
circuit = Circuit(3)
# ... define your circuit with 3 qubits ...
QibolabBackend(platform).execute_circuit(circuit)

This is not a suitable solution, in RB we are using execute_circuits with a list of circuits running on different qubits, frequently the list can be quite huge, so this approach will slower the execution that now it is already too slow.

However, for the time being, my suggestion would be to just do Circuit(18), and forget about the other qubits. It should not cause any relevant overhead (apart from screwing up the drawings). Morever, you should be able to concatenate a circuit with fewer qubits in one with more qubits. By doing on an empty one, you could define the circuit with just the qubits you need, and just increase the number of qubits after the creation.

Now RB supports simulation with noise channels, I suppose create big circuits will increase consistently the execution time.

[alecandido]

This is not a suitable solution, in RB we are using execute_circuits with a list of circuits running on different qubits, frequently the list can be quite huge, so this approach will slower the execution that now it is already too slow.

I'm not sure why you're claiming that it would slow down the execution.

In any case, if you really want to run on a chip with N qubits, possibly using all of them, you should declare a circuit with all those qubits.

Only if you're sure you would only use a subset, during the whole execution, you should use a view. And that's just for convenience, because in the end it would only be a translation (so, apart from some negligible conversions during the invocation, it should perform exactly the same operations of using the whole platform).

Now RB supports simulation with noise channels, I suppose create big circuits will increase consistently the execution time.

That's a simulation problem, I don't see how it should affect Qibolab's behavior.