Unable to run SVM on Real Hardware about qiskit-ibm-runtime HOT 6 CLOSED

Hi @masternerdguy thanks for the detailed issue description. This is a known issue in some classes from qiskit-algorithms, and has been reported and is currently being discussed in qiskit-community/qiskit-algorithms#164. Until the issue is addressed in the corresponding repo, in this particular case, you may try to install qiskit-algorithms from source and manually run a transpilation step to convert the circuit to ISA inside ComputeUncompute.run() before the sampler is called. This will convert the unsupported instruction to the chosen backend's basis set.

from qiskit-ibm-runtime.

I think this was indeed my fault because I reran it with all of the circuits transpiled together in one pass, and the results look better:

It isn't quite what was expected based on the simulator, however this feels a lot better because setosa is zero and having both a zero and one prediction instead of both being zero seems like the computation is going better. I am going to assume the difference is basically a stochastic effect combined with the reduced training data.

Thank you @ElePT for the workaround! I would be curious to know if there really is a difference between doing the transpilation one-by-one as opposed to together. I don't have enough of a quota to experiment with that.

from qiskit-ibm-runtime.

Thank you very much @ElePT for the explanation! Using that information, I think I have a workaround. For anyone who finds this, here is a patch file of the quick-and-dirty changes I made that allowed my job to be submitted:

patch.txt

Note that submitting the entire iris data set turned out to be rather ambitious at 11175 (!) circuits, which would blow out my quota by orders of magnitude. So, I discarded ~88% of the data set to bring it down to an acceptable number.

As of writing, the job is still running - however once completed I would expect these results based on the reduced data set in the simulator:

Obviously discarding most of the data set significantly affects the predictions, however if the job completes on the real hardware with similar output that will still validate the workaround. Now I just need to wait and see.

from qiskit-ibm-runtime.

Well, this is probably my fault somehow but it didn't quite work -

The original job did complete

As did a second one that ran immediately after for the fit step (which I didn't expect but makes sense in hindsight)

Any ideas? Might this just be due to the randomness of the training and the significantly reduced data set?

from qiskit-ibm-runtime.

I'm glad it helped @masternerdguy :) Regarding one-by-one vs batch transpilation, there should be no significant differences, but there is some stochasticity in certain transpiler passes. You can try setting the seed_transpiler argument in transpile to ensure that both runs are equivalent if you need to do further tests.

from qiskit-ibm-runtime.

Closing this one here and referring to it from qiskit-algorithms as it is not a strictly a Qiskit Runtime issue (although, it is a consequence of a change in Qiskit Runtime)

from qiskit-ibm-runtime.