-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CouplingMap.distance does not support "partial" coupling maps #2314
Comments
To the best of my knowledge nothing supports partial coupling maps. The example map you provided above breaks the transpiler: TranspilerError: 'Not enough qubits in CouplingGraph' I am also not sure what the equivalent qasm would be in this case for a three qubit circuit that starts indexing at 10. What is the use case for this feature? |
Yes I'm not sure we want to support non-zero-based coupling maps. |
Okey... I will try to put in words my itching feeling about The goal is to run the following circuit in the qubits 11 and 12 ( q = QuantumRegister(2)
c = ClassicalRegister(2)
qc = QuantumCircuit(q, c)
qc.h(q[0])
qc.cx(q[0], q[1])
qc.measure(q, c); The problem with the Standard transpilation is, if I understand correctly, the visualization of the fully padded circuit (Cell [16]). That could be solved by having a visualization option to disable the printing of empty wires. The tutorial, instead, does some juggling. First, "reduces" the coupling map to obtain
Notice that translation and execution are working with different assumptions. In particular, the layout for the transpilation is With A way that I see to simplify this full thing is by having non-zero-based coupling maps. The example from the tutorial would be quite straight forward:
Notice that So, in summary:
Now, change my view :) (tagging this as discussion) PS1: In the tutorial, it seems that there is an understanding that running PS2: The tutorial says that CouplingMap([[0,1], [1,2], [2,3], [2,4], [2,5], [2,6]]).reduce([2,3,4,5,6]))
|
So, the main focus of the Also the proposed solution for the "ugly" visualization is a bad one. We should not implicitly be truncating circuits in the visualizations. This leads to things like circuits whose actual widths do not match the width shown to the user, thus leading to confusion. Indeed, transpilation might be strongly related to hardware. This is something that needs to be worked on. Perhaps a reduced coupling_map knowing where it came from. I am not sure why one wants to include edges in a sub-graph that do not point to a qubit in the subgraph. The whole point is that when run on the device the reduced map plus mapping gives the same thing. I am not sure about PS2. The example does what is expected. In the end, all of this reduction business is because the transpiler expands the qubit count of a circuit to the full number supported by the device. Personally, I am not in favor of this, as it leads to work arounds like those discussed here. Indeed, I believe Aer already works around this by reducing some problems down to the original circuit width. Instead, it would be nice if the transpiler kept the circuit the same width (perhaps enlarging only if the swap mapper needed it), and added meta data to the returned circuits indicating things like layouts, targeted backend, etc. The circuits could then be padded to full size upon execute (if executing on a real device). I know @ajavadia is against this, but I think it is the route we will have to go as the devices become larger. |
I agree the transpilation process should be backend-independent. The two options I see are:
Do we agree that |
If the transpiler does not expand circuits, then much of the use of reduce goes away. However, it still has some worth for returning subgraphs that the user would otherwise have to implement by hand. I still do not like your solution for the fact that it is more backend specific, and qasm code (which we still use to store and retrieve circuits) does not support this. |
I will also point out that if you build a width 50 bell circuit using qubits 48, 49, then the transpiler outputs a smaller, reduced circuit, that uses qubits 0 and 1 only when |
Partial coupling maps should not be needed now with the layout fixes that were done and the decisions on layout/coupling map made there. For visualization purposes |
Dropping the assumption that coupling maps always start with 0 would help to have a cleaner support for defective qubits |
One can also just map to a reduced sub-graph and back. |
This is currently working:
So, closing. |
The following code does not work:
I think is because it was assumed that the coupling map was always "complete", with the practical consequence that starts in 0. But, from after #2225, my reading is that we want to move away from that assumption. Is my reading correct @ajavadia ?
It seems the issue was introduced in #1544
The text was updated successfully, but these errors were encountered: