[WIP] Add Subspace Search Variational Quantum Eigensolver (SSVQE)

[JoelHBierman]

Summary

The SSVQE algorithm (https://arxiv.org/abs/1810.09434) is a straightforward generalization of VQE to find low-lying eigenstates of a hermitian operator. Specifically, this pull request implements the version of SSVQE that carries out one optimization procedure using weights. Whereas VQE minimizes the expectation value of an operator with respect to a parameterized ansatz state, SSVQE takes a set of mutually orthogonal initial states, applies the same parameterized ansatz circuit to all of them, then minimizes a weighted sum of the expectation values of the operator with respect to this state. Because inner products of states are invariant under unitary transformations, the set of states remains orthogonal under ideal conditions and thus the global minimum corresponds to the low-lying eigenstates.

Details and comments

Because of its similarity to VQE in structure, the code for SSVQE is mostly duplicate code from VQE. It is essentially VQE code that has been modified to handle lists of QuantumCircuits (and other objects such as CircuitSamplers) where it is necessary in order to calculate the weighted sum objective function. Tests have been added for this class which are mostly duplicate from the tests for VQD. These two methods are both low-lying eigensolvers, so they should be required to pass similar tests. The code is essentially finished, but I have added the WIP tag for any changes that may arise from feedback. Example of how a user may use this class:

from qiskit import QuantumCircuit
from qiskit.opflow import Z
from qiskit.circuit.library import RealAmplitudes
from qiskit.utils import QuantumInstance
from qiskit.providers.aer import AerSimulator
from qiskit.algorithms.optimizers import SPSA
from ssvqe import SSVQE

operator = Z^Z
input_states = [QuantumCircuit(2), QuantumCircuit(2)]
input_states[0].x(0)
input_states[1].x(1)
quantum_instance = QuantumInstance(backend=AerSimulator())

ssvqe_instance = SSVQE(num_states=2,
                          optimizer=SPSA(),
                          ansatz=RealAmplitudes(2),
                          initial_states=input_states,
                          quantum_instance=quantum_instance)

result = ssvqe_instance.compute_eigenvalues(operator)

As far as code content that may need to be adjusted, one thing that comes to my mind in particular is how the user input for the orthogonal set of input states should be handled. Right now it is user responsibility to make sure that these are orthogonal and there are no warnings if they are not. The reason for this is that it may not be desirable to make mandatory the overhead calculation of all the pairs of inner products of a set of 2^N-dimensional vectors. Although this could be remedied with an optional boolean argument. (i.e. check_orthogonal = False as default that can be set to True by user.) If no input is given for the set of initial states, then SSVQE sets them to be a set of computational basis states. This choice is also possibly not ideal since for certain problems such as those in chemistry, these states may not lay in the desired particle number or spin magnetization subspace. If a particle or spin-preserving ansatz is used, using this default may return incorrect results which could be confusing to a new user. Any other physically-motivated choice of states would however make assumptions about the kind of system the user is applying the algorithm towards, which may not be ideal either.

This is my first Qiskit pull request, so any feedback is welcome and please let me know if I have forgotten anything for the pull request process.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ JoelHBierman
❌ Joel Bierman

---

Joel Bierman seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[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

[woodsp-ibm]

Hi. At present there is significant refactoring going on for algorithms moving them over to use primitives.. This affects all algorithms, including the (minimum_)eigen_solvers which are being reworked in different folders (minimum_)eigensolvers (no underscore now between eigen and solvers. The existing algorithms are now pending deprecation for this upcoming release and will be deprecated and eventually removed thereafter.

Would you like to take a look at this ongoing refactoring and see how this impacts your contribution. We would be wanting any additional algorithms using primitives going forwards.

The refactored VQE is being done here #8702 and VQD (like SSE being and eigensolver) is here #8640 (FYI deprecations of existing algo are #8703 and #8651). The refactor work is scheduled for the next release which has a current planned RC1 date of Sep 29th so these PRs will end up being merged soon but final adjustments are still ongoing before being merged. So for now you really caught us mid-change - hopefully you are interested in making appropriate adjustments to what you have done so far to align/use primitives for this.

[JoelHBierman]

Yes, I would be glad to refactor the code so that it is compatible with future releases. I will take a look at the other algorithm refactoring to see what should be done here. Should I close this PR and re-open a new (refactored SSVQE) PR once more progress has been made on that? Or should I modify this existing PR?

[woodsp-ibm]

I think having this PR open is ok. If you prefer to do a separate PR later, which maybe is easier, this can be closed off at that point. For now if you had any questions its a place to at least ask questions should you have any. You could though instead raise an issue regarding adding SSE, with perhaps some of the text above as content, that can be assigned to you. This could then be closed off now. As you prefer.

[woodsp-ibm]

BTW The CLA issue and avoiding it going forwards - either ensure the email in your git config is one of the ones known in your github account, or add that email to the github account. It looks like some commits the email is not known (cannot be matched to a github account( and its picking your user name from them).

[JoelHBierman]

I have noticed that the branch that I forked to work on this PR has an outdated versions of primitives. For example, there does not seem to be gradient primitives and the estimators lack the run() method which both seem to be key to the refactored VQE implementation The PRs for VQE and VQD do seem to be more up to date. Is there a particular branch I should sync this fork with? The goal here is just to make local testing and eventual merging with a more up to date branch easier.

[woodsp-ibm]

The main branch here should be the one - that is what the refactored VQE and VQD are using/based off. You can see the changes in these and if its out-of-date with main branch meaning more commits have been done on main than in the fork. In the stable/released version of Terra it does not have gradients (these are under algorithms now in main) and the primitives interface is not the same as it is now. In looking at your branch the estimator there has run() - its a method in the base estimator which calls _run() which is overridden in derived classes - gradients are there under algorithms too (gradients use primitives i.e sampler or estimator and are in algorithms rather than being in with primitives - they do look more like primitives in terms of their look/usage - quasi-primitives if you like)

[JoelHBierman]

Ah I see now, thanks!

[JoelHBierman]

Closed for now- will reopen soon with refactored code. Syncing fork with most up-to-date main branch seemed to result in circular import issues from non-ssvqe code. It seems easier to just add the SSVQE code back into a fresh git clone rather than track down where the fork syncing went wrong.

[woodsp-ibm]

Sure, once #8640 gets merged, which should be soon, that new location is where I would expect an SSVQE to be. This folder does not yet exist in main, that PR will add it, (very similar name but no underscore in eigensolvers like there is with current algos. It maybe we have to tweak things for imports if we end up with circular imports - I had to earlier when we added some new code.