PennyLaneAI / qml

Introductions to key concepts in quantum programming, as well as tutorials and implementations from cutting-edge quantum computing research.
https://pennylane.ai/qml
Apache License 2.0
527 stars 185 forks source link

[BUG] Quantum transfer learning on IBM backend #426

Closed AlexanderGeng closed 2 years ago

AlexanderGeng commented 2 years ago

Issue description

Hello,

first thanks for the wonderful notebook "Quantum transfer learning". It is really amazing. I tried it and it works quite fine, when using dev = qml.device('default.qubit', wires=n_qubits) as device.

However, if I test it on an actual IBM machine (e.g. ibm_cairo) it does not work or runs for days. The queue time is not the problem maybe rather some other issues. I also tested it on some of the other IBM backends. But the result was all the same.

When calling the train_model command quite at the end of the notebook, it arises the following UserWarning:

Resynthesized 

<qiskit.circuit.library.standard_gates.rz.RZGate object at 0x7f971b2d50d0>
<qiskit.circuit.library.standard_gates.sx.SXGate object at 0x7f971b2d5310>
<qiskit.circuit.library.standard_gates.rz.RZGate object at 0x7f9730849fd0>
<qiskit.circuit.library.standard_gates.sx.SXGate object at 0x7f971b327fd0>

and got

<qiskit.circuit.library.standard_gates.rz.RZGate object at 0x7f971b327690>
<qiskit.circuit.library.standard_gates.sx.SXGate object at 0x7f971b327410>
<qiskit.circuit.library.standard_gates.rz.RZGate object at 0x7f971b327e50>
<qiskit.circuit.library.standard_gates.sx.SXGate object at 0x7f971b327610>
<qiskit.circuit.library.standard_gates.rz.RZGate object at 0x7f971b3276d0>

but the original was native (for ['id', 'rz', 'sx', 'x', 'cx', 'reset']) and the new value is longer.  This indicates an efficiency bug in synthesis.  Please report it by opening an issue here: https://github.com/Qiskit/qiskit-terra/issues/new/choose
  new_dag = pass_.run(dag)

Maybe this is in some sense the reason for it, but I do not know.

I want to get something similar to the paper Transfer learning in hybrid classical-quantum neural networks, where they showed it with the ibmqx4 backend and a execution time of 26 seconds for the full dataset.

Has somebody an idea how to fix this problem?

My system information:

Qiskit Software Version
qiskit-terra 0.18.3
qiskit-aer 0.9.0
qiskit-ignis 0.6.0
qiskit-ibmq-provider 0.16.0
qiskit-aqua 0.9.5
qiskit 0.30.1
Python 3.7.11 (default, Jul 27 2021, 14:32:16) [GCC 7.5.0]
OS Linux
CPUs 12
Memory (Gb) 62.85524368286133

Fri Feb 18 18:53:45 2022 CET

CatalinaAlbornoz commented 2 years ago

Hi @Alex-259, at a first glance this looks like a problem with Qiskit. See how at the end of your error message they say: "This indicates an efficiency bug in synthesis. Please report it by opening an issue here: https://github.com/Qiskit/qiskit-terra/issues/new/choose ".

Some workaround for now could be using a Mock backend. In this error mitigation demo, in the Mitigating noisy circuits in quantum chemistry section, you will see that we use the "FakeLima" device to simulate a noisy device.

Please let me know if this helps solve your problem!

AlexanderGeng commented 2 years ago

Hi @CatalinaAlbornoz, thanks for the reply.

Everything works fine on the qasm_simulator or on the fake backends. The fake backends are good to see that in theory, it works even with errors. However, I am mostly interested in the results of the real backends. I just thought that maybe someone here has already encountered the same problem.

I will also post the question at qiskit and keep you here up to date, on how the problem can be circumvented

PCesteban commented 2 years ago

Hi @CatalinaAlbornoz, thanks for the reply.

Everything works fine on the qasm_simulator or on the fake backends. The fake backends are good to see that in theory, it works even with errors. However, I am mostly interested in the results of the real backends. I just thought that maybe someone here has already encountered the same problem.

I will also post the question at qiskit and keep you here up to date, on how the problem can be circumvented

Hi @Alex-259, I faced a similar problem running my experiments on a real backend, and indeed it took a ridiculously amount of time to finish the task, however at the end the results were returned. I also think that that's an issue that needs to be addressed.

josh146 commented 2 years ago

Thanks @Alex-259 and @PCesteban for reporting this! We will investigate and see what the cause could be. One quick question: when you are submitting the jobs for execution, do you see them in the job queue using the IBMQ web interface? If so, what is the status of these jobs?

AlexanderGeng commented 2 years ago

Hello,

yes, I see the jobs in the queue. First, I have the error messages from above two times in the notebook even before the job runs on the real backend (I think the error messages come from the transpiler step). Then, I see my job in the queue as normal. I receive the results as far as I see (jobs are completed) and then for the next job the same procedure again.

I have executed over 300 jobs this way on the real backend (e.g. ibm_cairo), but I didn't even get an update on the iteration like Phase: train Epoch: 1/... Iter: 1/... Batch time: .... Only a lot of error messages.

I don't know if this helps, but for example, the id of one job on ibm_cairo was for example 62128d6161cbfc9d5162e026

rmoyard commented 2 years ago

Hi @Alex-259, I suggest that you use the following small example for tracking the different times

from pennylane_qiskit import IBMQDevice

dev = IBMQDevice(wires=n_wires, backend="ibmq_cairo", shots=1024)
dev.tracker.active = True

@qml.qnode(dev)
    def circuit():
        qml.PauliX(wires=0)
        return qml.probs(wires=0)
circuit()

print(dev.tracker.history["job_time"])

where you can check the time dictionary dev.tracker.history["job_time"] by accessing with the keys creating, validating, queued and running. I don't think it is a problem on PennyLane side but that the Cairo quantum computer is busy and that your job is queued for a long time. Let me know what is the breakdown between the different times.

AlexanderGeng commented 2 years ago

Hi @rmoyard,

I tested what you mentioned. That is what I get. So, only execution and shots as an outcome result

When I look at the IBM website https://quantum-computing.ibm.com/jobs/ I see the following for the job: result2 Thus, a quite low validating and queue time, but a quite large running time for this simple example

rmoyard commented 2 years ago

What are your PennyLane and PennyLane-Qiskit version?

Thank you for sharing the different times number, in my opinion this issue is on Qiskit/Hardware side. PennyLane-Qiskit is just a way to translate the original PennyLane circuit to a Qiskit circuit. When the translation is done, we do not control what happens on the hardware side. What you can do on PennyLane side is changing the circuit, reducing the number of shots or give some transpiler configuration that can eventually optimized your circuit.

AlexanderGeng commented 2 years ago

Hi @rmoyard,

thanks for the answer. Both are now on the current version 0.21.0. (Now also the job_time is visible :+1: )

Ok interesting: Before I had 0.18.0 with all the bugs and errors mentioned above. With 0.21.0 it now works fine and also the times for the simple example are different result4

I have not found directly which change in one of the new releases solves this problem but at least it works now. So, never forget to have the newest version :+1:

The only remaining problem is the many computations on the real backend, which cause a long runtime for the Quantum Transfer Learning notebook on the real backend. But this problem is due to the algorithm itself and has nothing to do with Pennylane or Qiskit.

So thanks @CatalinaAlbornoz , @PCesteban, @josh146 , and @rmoyard for helping me solving my problem