VQE implementation with estimator primitive

[declanmillar]

Summary

Adds a standard VQE implementation using an Estimator primitive. Closes #8471.

A SamplingVQE implementation that takes a Sampler primitive is introduced in PR #8669.

Details and comments

This fresh implementation lives in qiskit/algorithms/minimum_eigensolvers. The prior implementation may still be found in qiskit/algorithms/minimum_eigen_solvers.

The following elements have been removed:

• The final "eigenstate". To reproduce this one may use a Sampler and the optimal point from VQE outside the algorithm.
• The callback from the energy evaluation. Instead the callback should be attached to the optimizer which can allow to additionally evaluate the energy at the current point. After discussing with @woodsp-ibm, I decided to add back the callback on VQE as this may be simpler for users. Callbacks are not universally supplied by all optimizers.
• The setting property and print_settings method. No other algorithm has these.
• All trivial getters and setters, just use public attributes instead (expect for initial_point, which requires it for the VariationalAlgorithm interface.
• expectation and include_custom. These are not required anymore when using an Estimator.

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the the following people are requested to review this:

• @Qiskit/terra-core
• @manoelmarques
• @woodsp-ibm

[CLAassistant]

All committers have signed the CLA.

[Cryoris]

The overall structure LGTM! I left some
brief comments below 🙂

[coveralls]

Pull Request Test Coverage Report for Build 3135497477

• 257 of 266 (96.62%) changed or added relevant lines in 11 files are covered.
• 9 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+0.08%) to 84.451%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/algorithms/minimum_eigensolvers/minimum_eigensolver.py	31	32	96.88%
qiskit/algorithms/minimum_eigensolvers/numpy_minimum_eigensolver.py	42	45	93.33%
qiskit/algorithms/minimum_eigensolvers/vqe.py	110	115	95.65%

Files with Coverage Reduction	New Missed Lines	%
qiskit/extensions/quantum_initializer/squ.py	2	79.78%
qiskit/algorithms/optimizers/qnspsa.py	7	87.3%

Totals
Change from base Build 3132502212:	0.08%
Covered Lines:	59852
Relevant Lines:	70872

---

💛 - Coveralls

[mrossinek]

Just some minor comments/questions from my side 👍

[declanmillar]

I note that estimate_observables now returns the variances and shots if obtained from metadata (and sets these to 0.0 otherwise). Should I add this for the main eigenvalue too? It seems odd to have this data for the aux operators and not the main one. I guess there are three ways of doing this:

1. Make eigenvalue: tuple[complex, tuple[complex, int]], which will require a lot of downstream changes.
2. Add a metadata property to the result class with the metadata pulled straight from the job.
3. Add shots and variance properties to the result class.
   Any thoughts on this @woodsp-ibm, @mrossinek, @Cryoris?

[woodsp-ibm]

I note that estimate_observables now returns the variances and shots if obtained from metadata (and sets these to 0.0 otherwise). Should I add this for the main eigenvalue too?

It seems sensible/consistent to have access to other information for the main operator too. I had suggested in the estimate_observables passing back the whole metadata #8683 (comment) while perhaps keeping the extracted variance as a first class field.

#8105 may change things up.

[ElePT]

I note that estimate_observables now returns the variances and shots if obtained from metadata (and sets these to 0.0 otherwise). Should I add this for the main eigenvalue too? It seems odd to have this data for the aux operators and not the main one. I guess there are three ways of doing this:

1. Make eigenvalue: tuple[complex, tuple[complex, int]], which will require a lot of downstream changes.
2. Add a metadata property to the result class with the metadata pulled straight from the job.
3. Add shots and variance properties to the result class.
   Any thoughts on this @woodsp-ibm, @mrossinek, @Cryoris?

I think that adding the metadata property (option 2) sounds like the most consistent option. I am not sure about the usefulness of also including the variance as a first class field, I think it would complicate things. Or @woodsp-ibm, were you referring to the aux_ops_eigenvalues that already return the variance?? I think it would make sense for them to mirror the main eigenvalues, and also return the auxiliary variance/shots as a metadata entry.

About #8105, it looks like the discussion hasn't progressee in a while, so it might change things in the future, but I don't think we should worry about it for this release.

[woodsp-ibm]

were you referring to the aux_ops_eigenvalues that already return the variance??

Yes, there the variance is already taken out of the metadata - the resultant tuple of (variance, shots) is always present with either defaulting to 0 if its not in the metadata. All I meant by first class field was extracting it out of the metadata like the estimate observables does. It would be nice to see some of what is in the metdata more directly as fields estimator result etc you can know what is in the result, IDE auto-completion and so on. Having it "hidden" in metadata seems less ideal which is an aspects #8105 was seeking to address too I think.

[ElePT]

Thanks so much Declan and Steve for all the effort, especially over the past day. My approval is not very powerful, but I believe all the comments have been addressed and it looks good to me. If @t-imamichi or @ikkoham could approve it, it would unblock our workflow for the PRs that depend on VQE :)

[t-imamichi]

Is it related to VQE?

[ElePT]

It's related to the compute_eigenvalues method that is also used in VQE. We changed the signature to take optional parameters instead of bound circuits so that the estimator cache does not think it's a different circuit every time (for efficiency). In trotter QRTE the circuits are not parametrized so we had to add this None in the parameters field.

[woodsp-ibm]

It would have been possible too to change some of the parameters in the call to using keywords, particularly threshold at the end, That way the None for parameters could have been left as the default value - the call as it stood would have to have been changed either way.

[t-imamichi]

I'm not sure whether it requires | None?

Suggested change

	] = None,
	] | None = None,

[woodsp-ibm]

The prior signature was

   filter_criterion: Callable[[Union[List, np.ndarray], float, Optional[ListOrDict[float]]], bool] = None,

I imagine this is saying that the filter criteria is applied to the aux ops result which may be None. I would have thought the filter would not have needed to be called in this case but this is how it has been.

[declanmillar]

Change made in the commit that addresses your comment below.

[t-imamichi]

It looks good overall though I wrote some minor comments.

[ikkoham]

Great! lgtm. I left some minor comments.

[woodsp-ibm]

@declanmillar @ElePT Thanks for the effort to get this done!