Added V2 and ISA support #197
Conversation
|
|
|
FYI. I merged a PR that fixed CI with the main branch and changes that will going into the shortly to be released 1.2.0 so that CI now passes fully here and does not fail with the two jobs that check things out against qiskit main, and updated the branch here so this now completely passes. I think this is fine. I must admit though I had wondered, given that I think we only ever need something that has a run() method, that takes circuits and gives transpiled circuits back whether, something could be done around a type that was more targeted along those lines. The pass manager has a number of methods that I do not think we would call, and the AI Transpiler Service which has a run method could be used too but is not a passmanager - i,e, so that a Passmanager instance or the AI transpiler could be used - or anything else that had a run method that did the transpilation. I know Optimization went for BassPassManager too as the type and maybe thats ok. Whatever is done I think we might want to note in the docstring for this that's its optional and that passing in None results in the circuit not being transpiled. Maybe for some algos like VQE one can already pass a circuit (ansatz) that is transpiled for a given backend so the note there might be a little different to accommodate that - for PE they build their own circuits of course so that aspect does not apply. One minor comment I might have is that the |
Hey @woodsp-ibm, sorry for the time without news! I think it's up to you! As things currently are, We also intended to fix the issues in the Monitoring Qiskit workflow, but there are still some issues that are not fixed, even though it seems PR are on their way. All in all, it probably depends on whether you intend to release a new version of Concerning the monitoring, AFAIK this PR will work with Qiskit up to version 2.1, and maybe an issue could be opened to tackle this? |
The Monitoring task was done to just give us a heads up on what was happening as far as Qiskit was concerned by installing/testing against their main branch. As its work in progress there can be issues that arise that cause things to fail here - and we have given feedback in the past when things were more active here in case the issue we saw was unknown.
In looking at
Things can be coordinated around a release - if its felt more needs doing, can be done, before a release then that's fine. This PR has been going for some time I am sure a bit longer is ok. And in terms of some issues, like changing to circuit library functions, as their removal from deprecation seems to have been moved out to Qiskit 3.0 it appears there is more time to look at things like that. |
|
With 2.1.1 (and presumably same with 2.1.0) this looks akin to the failures that are occurring on main, in the monitor main task, though the reasons for stopping seems clearer with main - complaint about empty operator and non-complex coeffs when doing a conversion. |
|
I raised an issue on Qiskit and linked this PR so the Qiskit issue shows up linked above. Hopefully we can get the failures under 2.1 figured. |
Nope, I'd just forgot that we put this pin here, I somehow convinced myself that things were fine on 2.1.X, that's on me!
If I'm not mistaken, there are already issues on Qiskit about this (concerning the particular problems though, without linking to this PR that gather them all). As far as I can tell, there are three issues at hand with Qiskit 2.1.X:
All in all, we have to tackle the case of nil observables manually and it should be fine. If the last PR makes it to the next Qiskit release, then it means that we'd only have to "forbid" Qiskit 2.1.0 and 2.1.1. Also, thinking about it, I think I've found a way to include transpiling to
And then we could probably merge this PR with the monitoring tests (and thus, hopefully by then, the next Qiskit release), passing. Would that work for you? |
If that's the case, you can reduce the number of shots (You need to take care the precision when you compare the results). |
Ah you had raised more specific issues. 14714 was merged last night and in the issue I raised I was asked to retry. This is how I responded
Do you think the tests should be passing - in looking at the operators we create n say the VQD std dev test I thought they were ok. Now I believe they get converted to some other type in the estimator - since you have the code locally does it look like the observables passed to the estimator at least are ok? But yes you might like to add the pin back again to requirements-dev - we can remove it once things seem to pass for main and a newer version of qiskit has been released that fixes things (assuming things are all ok on the algs side of course) |
|
So, by modifying If I'm not mistaken, the remaining three are due to the fact that we directly use the This may however cause some problems. For instance, in the job = self._estimator.run(pubs)
try:
results = job.result()
except AlgorithmError as exc:
raise AlgorithmError("Estimator job failed.") from excby results = [
estimate_observables(
self._estimator,
quantum_state,
[observable],
parameters_values,
threshold=-float("inf")
)[0][0]
for (quantum_state, observable, parameters_values) in pubs
]However, a direct consequence of doing it like this is that it not only launches multiple jobs, but also waits for each job to end before launching the next one, which of course results in a large overhead. The solution would be to modify |
A different method like that seems more promising I agree. With the usage being inside algorithms calling this and result, instead of directly on an estimator seems reasonable enough, if that's what it takes, |
|
@woodsp-ibm As seen here, it seems that the only remaining tests are failing because Qiskit/qiskit#14611 han't been merged yet, but they should pass once that's done. So I think it's ready to be merged now! |
There was a problem hiding this comment.
@tnemoz Thanks so much for doing this. It was a lot of work no doubt and thanks too for raising and sorting out the issues here with the latest Qiskit release. The monitor main should once again pass, as you say, when the last of those issues around the complex coeffs is fixed in 2.1.2. Tremendous piece of work, thanks once again.
Thanks! It was fun (mostly, I now hate the Sampler gradients) working on this 😄 And thank you for the reactivity on answering my questions! I'll probably try to continue contributing on other issues now that I have a good vision of the codebase :) By the way, I don't think I have the rights to merge the PR by myself, even now that you've approved it! |
|
Just an FYI. It seems the CI actions that were run following the merge failed copyright check on 3 files that look like they were last changed in 2024. So while the PR passed against the branch being done from after merging the dates got updated. The above linked PR has more info. |
|
Well, this PR did take a year to complete, but that's a funny bug 😄 |
Summary
This PR's goal is to adapt the whole code base to support V2 primitives and ISA circuits. Will fix #136, fix #164, fix #165, fix #194, fix #204, fix #213, fix #220, fix #224, and fix #229.
What's working
eigensolversgradientsminimum_eigensolversoptimizersstate_fidelitiestime_evolversutilsamplitude_estimatorsgroverphase_estimatorsvalidation