Could not import architecture: Unable to cast Python instance to C++ type

[cda-tum]

Could not import architecture: Unable to cast Python instance to C++ type

[burgholzer]

Hey there,

Thanks for your interest in our project.
The compile function expects the path to the corresponding file. So instead of

qmap.compile(circ,file1)

you should call it with

qmap.compile(circ,file_name)

Also make sure that your file is formatted according to the expected specification of a coupling map, e.g.,

5
0 1
1 0
1 2
2 1
1 3
3 1
3 4
4 3

where the first number indicates the total number of qubits and all following pairs indicated the coupling map's edges.
At the moment, the tool does not accept JSON-formatted files. However, if there is demand for it, we can certainly implement it.

I hope this helps to get you started.

[Mushkan-Sureka]

hey!
I converted file_name as a txt file, however as I implement the compile function, my session crashes and a warning comes as

WARNING:root:kernel bc957a7b-2b6f-497d-a03a-5d3cf0d1abe2 restarted

[burgholzer]

Could you post the whole script you are trying to execute (including the circuit you are trying to compile and the coupling map)?
It's hard to make something from the error you posted.

[Mushkan-Sureka]

sure!
https://colab.research.google.com/drive/1Pvo8IO7753G7Gck5ST0IsJSHL1ZJmzM4?usp=sharing
this is the link of the programme and the my file_name is a .txt file of
5
0 1
1 0
1 2
2 1
1 3
3 1
3 4
4 3

[burgholzer]

Thanks for sharing.
Unfortunately, I won't have access to my computer until tomorrow. I will look into it then and get back to you!

[Mushkan-Sureka]

okay sure! thankyou so much

[Mushkan-Sureka]

Hey! How would I convert a json file to Qiskit circuit? like the mapped one

[hillmich]

Lukas, I hope you don't me checking in as well.

The python process dies with SIGILL, indicating some illegal instruction or jump target.

Could you try to force a source (re-)installation of qmap with

pip install --force-reinstall --ignore-installed --no-binary :all: jkq.qmap

and report if this solves your problem?

[Mushkan-Sureka]

It solves the problem. I got a JSON output, my other doubt is that how can I convert the given JSON output in Qiskit circuit or QASM?

[hillmich]

If you pass save_mapped_circuit=True to qmap.compile, you get the resulting circuit as part of the return value and can use the OpenQASM code in the dict under mapped_circuit / qasm.

In this case:

print(qmap.compile(circ, file_name, save_mapped_circuit=True))

{'circuit': {'cnots': 1,
             'layers': 2,
             'n_gates': 2,
             'n_qubits': 2,
             'name': '',
             'singlequbitgates': 1},
 'mapped_circuit': {'cnots': 1,
                    'direction_reverse': 0,
                    'n_gates': 2,
                    'n_qubits': 5,
                    'name': '_mapped',
                    'qasm': '// i 0 1 2 3 4\n'
                            '// o 0 1 2 3 4\n'
                            'OPENQASM 2.0;\n'
                            'include "qelib1.inc";\n'
                            'qreg q[5];\n'
                            'h q[0];\n'
                            'cx q[0], q[1];\n',
                    'singlequbitgates': 1,
                    'swaps': 0}}

[Mushkan-Sureka]

hey sorry to disturb but could you send me the coupling map of IBM QX3 and QX5 according to the expected specification of a coupling map? I tried IBM QX3 coupling map as:-
16
0 1
1 2
2 3
3 14
4 3
4 5
6 11
6 7
7 10
8 7
9 8
9 10
11 10
12 5
12 11
12 13
13 4
13 14
15 0
15 14

However, I am getting a tad bit different result for the circuit in the paper.

For the circuit:-

OPENQASM 2.0;
include "qelib1.inc";
qreg q0[6];
creg c0[6];
cx q0[2],q0[3];
cx q0[1],q0[0];
cx q0[1],q0[4];
cx q0[5],q0[3];
cx q0[2],q0[3];

The proposed optimised mapped circuit I am getting is:-

OPENQASM 2.0;
include "qelib1.inc";
qreg q[16];
cx q[0], q[1];
cx q[2], q[3];
swap q[2], q[3];
cx q[3], q[14];
swap q[4], q[3];
swap q[2], q[3];
h q[1];
h q[2];
cx q[1], q[2];
h q[2];
h q[1];
cx q[0], q[1];

which is different from that in the paper of Effective Mapping

[burgholzer]

Hi there,

Your coupling map seems to be a bit mixed up. I attached the two coupling map files as from this paper:
ibm_qx3.txt
ibm_qx5.txt

I hope this helps.

[Mushkan-Sureka]

Thank you! the resulting map I got is (mapping to IBMQX3)

OPENQASM 2.0;
include "qelib1.inc";
qreg q[16];
cx q[1], q[0];
cx q[2], q[3];
swap q[2], q[3];
cx q[3], q[14];
cx q[15], q[0];
cx q[1], q[0];

however, I am not sure it is right since the paper has some other mapping solution. Also as per your coupling map, CNOT is from 1 to 0 in QX3 however isn't the opposite right? (according to your "An Efficient Methodology for Mapping
Quantum Circuits to the IBM QX Architectures" paper coupling map diagram)

Also, any way to know which qubit got mapped to which of the 16 qubits?

[burgholzer]

You are right. The "An Efficient Methodology for Mapping
Quantum Circuits to the IBM QX Architectures" paper shows a different coupling map for IBM QX3 than the "Improved Mapping of
Quantum Circuits to IBM QX Architectures" paper. These coupling maps frequently changed in the past due to IBM experimenting with their devices and trying to figure things out.

The coupling map you posted above is the one from the first paper and should be correct. Over the years, the way we select device qubits during the mapping improved. This should yield better results in general. Some of the details are outlined in the paper "Evaluating the Flexibility of A* for Mapping Quantum Circuits".
In addition, the tool per default does not group the gates of the circuit into layers anymore as this was shown to yield sub-optimal results in some cases in the paper "Mapping Quantum Circuits to IBM QX Architectures Using the Minimal Number of SWAP and H Operations". Allowing a change of the mapping in front of every gate allows for more flexibility.

As to knowing how the qubits were mapped: The resulting QASM string of our tool contains two comments at the very top which indicate how the circuits logical qubits are initially (// i ...) assigned to the devices physical qubits and where to expect the logical qubits at the end of the circuit (// o ...).

If I take the circuit and the coupling map from your comment above, I obtain the following circuit (*):

// i 1 0 2 3 15 14 6 7 8 9 10 11 12 13 5 4
// o 1 0 2 3 15 14
OPENQASM 2.0;
include "qelib1.inc";
qreg q[16];
cx q[0], q[1];
cx q[2], q[3];
h q[15];
h q[0];
cx q[15], q[0];
h q[0];
h q[15];
h q[3];
h q[14];
cx q[3], q[14];
h q[14];
h q[3];
cx q[2], q[3];

The first comment // i 1 0 2 3 15 14 6 7 8 9 10 11 12 13 5 4 indicates that logical qubit q0 is mapped to physical qubit Q1, q1 to Q0, q2 to Q2, q3 to Q3, q4 to Q15, q5 to Q14, etc.
The second comment // o 1 0 2 3 15 14 indicated that, at the end of the computation, q0 can be obtained from Q1, q1 from Q0, q2 from Q2, q3 from Q3, q4 from Q15 and q5 from Q14.
As you can see, no SWAP is required at all. Only two direction reverses using 4 Hadamard's each.

(*) I am currently working on a new PyPI release that addresses the main problem of this issue (our Python wheels are compiled with --march=native which causes incompatibility with different platforms) and that fixes two additional issues. The circuit you obtain currently might not match the circuit shown above until it is released. It should be ready later today.

[Mushkan-Sureka]

Okay, sure! let me know when the error is fixed and apologies for incessant mailing.

[burgholzer]

"Later today" maybe was a bit optimistic. But the new version (1.2.1) should be online in the next 30min.
You should now see the same behavior as in the comment above (and should now be able to just use pip install jkq.qmap instead of doing a source install as described by Stefan earlier).

[Mushkan-Sureka]

Haha I did check it out, however for circuit

OPENQASM 2.0;
include "qelib1.inc";
qreg q1[6];
creg c1[6];
cx q1[2],q1[3];
cx q1[1],q1[0];
cx q1[1],q1[4];
cx q1[5],q1[3];
cx q1[2],q1[3];

the mapped one I am getting is:-

OPENQASM 2.0;
include "qelib1.inc";
qreg q[16];
cx q[0], q[1];
cx q[2], q[3];
swap q[2], q[3];
cx q[3], q[14];
swap q[4], q[3];
swap q[2], q[3];
h q[1];
h q[2];
cx q[1], q[2];
h q[2];
h q[1];
cx q[0], q[1];

which is not the same as yours.

[burgholzer]

I copied your coupling map and circuit from above into a script:

from jkq import qmap
from qiskit import QuantumCircuit
import os

if __name__ == '__main__':
    
    f = open("./ibm_qx3.arch", "w")
    f.write(
        "16\n"
        "0 1\n"
        "1 2\n"
        "2 3\n"
        "3 14\n"
        "4 3\n"
        "4 5\n"
        "6 11\n"
        "6 7\n"
        "7 10\n"
        "8 7\n"
        "9 8\n"
        "9 10\n"
        "11 10\n"
        "12 5\n"
        "12 11\n"
        "12 13\n"
        "13 4\n"
        "13 14\n"
        "15 0\n"
        "15 14\n")
    f.close()

    qc = QuantumCircuit.from_qasm_str(
        "OPENQASM 2.0;"
        "include \"qelib1.inc\";"
        "qreg q1[6];"
        "creg c1[6];"
        "cx q1[2],q1[3];"
        "cx q1[1],q1[0];"
        "cx q1[1],q1[4];"
        "cx q1[5],q1[3];"
        "cx q1[2],q1[3];")
    result = qmap.compile(qc, "./ibm_qx3.arch", save_mapped_circuit=True)
    print(result['mapped_circuit']['qasm'])

    os.remove('./ibm_qx3.arch')

Executing it yields

// i 1 0 2 3 15 14 6 7 8 9 10 11 12 13 5 4
// o 1 0 2 3 15 14
OPENQASM 2.0;
include "qelib1.inc";
qreg q[16];
cx q[0], q[1];
cx q[2], q[3];
h q[15];
h q[0];
cx q[15], q[0];
h q[0];
h q[15];
h q[3];
h q[14];
cx q[3], q[14];
h q[14];
h q[3];
cx q[2], q[3];

There should be no source of randomness in the mapper, so I would expect this to produce the same on your end.

[Mushkan-Sureka]

Ah okay! I finally got it, thank you so much for your help and so sorry for so many queries.

[burgholzer]

No worries. Glad I could help!
I am closing this for now.
Feel free to reach out again in case of further questions 👍🏼