Allow list of optimizers+initial points in VQD

[ariannacrippa]

Summary

During my research, I needed to be more flexible with the VQD algorithm, e.g. I wanted to be able to choose an arbitrary initial point for my set of eigenstates. Especially when I already have knowledge of the system that I am simulating. In addition, I found it helpful to have the possibility to decide which optimizer to use for each kth eigenvalue and be able to define the number of iterations for every kth step. For example, in some cases, I needed more iteration for excited states than the ground state.
For these reasons, I have added the following:
-input for initial point: single or list. If single, the kth excited state is computed from the previous optimal point (already implemented). If list, every kth eigenvalue is computed starting from the initial points in the list.
-input for optimizer: single or list: If single, already implemented. If list, every kth eigenvalue is computed with kth optimizer.

Details and comments

I tried the code with NFT and COBYLA optimizers. However, when I tried with SPSA I obtained an error.

[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.

[woodsp-ibm]

Supporting initial point being a list is something we recognized was lacking when these were recently refactored to primitives. This implements VariationalAlgorithm which defines the property and that interface is used elsewhere. We had discussed perhaps a separate interface for ground versus excited state eigensolvers use. When plotting dissociation curves in Nature adjusting the molecule a little, the prior solution point often is better than a random start point, so setting them all is highly desirable.

Now separate optimizers - that seems more complicate for a user to deal with - do you have some specific use case - maybe its the same optimizer class but parameterized differently? What do you find that set differently?

@ElePT as you have done some work with the VQD can I assign you to this.

[Cryoris]

Thanks for the contribution @ariannacrippa! I have one question below, and otherwise some minor comments 🙂

[Cryoris]

If I understood VQD correctly, our cost function for parameters x, an ansatz phi is

L(x) = <phi(x)|H|phi(x)> + penalty * ( |<phi(groundstate)|phi(x)>|^2 + |<phi(1st_excited)|phi(x)>|^2 + ...)

where groundstate are the parameters for the ground state and 1st_excited for the first excited etc. So the prev_states variable here I think should always be the optimal points.

The initial points in Qiskit are usually understood as starting points for the optimizations, so at iteration k of the VQD for the k-th excited state, element k of the initial_points list should be the initial point of the optimization. Instead here, I think you are implementing

L(x) = <phi(x)|H|phi(x)> + penalty * ( |<phi(initial_points[0])|phi(x)>|^2 + |<phi(initial_points[1])|phi(x)>|^2 + ...)

or maybe I misunderstood the code 🤔

If you indeed need the latter, then we can also discuss adding that, but I think the initial_points should only act as starting points for the optimization and not be part of the loss function.

[ariannacrippa]

Thanks for the comment. Yes you are right, what I want to do is use the previous set of parameters as in L(x) = <phi(x)|H|phi(x)> + penalty * ( |<phi(groundstate)|phi(x)>|^2 + |<phi(1st_excited)|phi(x)>|^2 + ...) but put in x a given set of parameters from the list of the initial points and then do the optimization. The local file that I was working on was slightly different from the version that I then modified and uploaded. I have to check better on this.

[ElePT]

Hi @ariannacrippa! It looks like a few unit tests are failing in the CI (automatic test), in particular: test_aux_operators_std_dev and test_callback.

The first test fails because in line 63 you are checking len(point) and if point is a float, it has no length. (see line 17471 here: https://dev.azure.com/qiskit-ci/qiskit-terra/_build/results?buildId=41666&view=logs&j=e4ea27c2-3a16-5b32-7be8-0bf30fe9e828&t=793d4f07-8490-552a-798f-6a5657042d16).

The second test fails for an assertion error, it looks like the values don't match the expected results anymore (see line 17516 from link above).

[JoelHBierman]

I was considering working on and opening a similar pull request, but since this one already exists I have one suggestion to add (Unless someone thinks this would merit a separate pull request):

The current VQD implementation appears to require that the same ansatz is used for all excited states. However, there is nothing in the VQD formulation that requires this to be the case. The ground state ansatz could be UCCSD and the first excited state could be RealAmplitudes and that would still be valid. (Although I would find this particular choice a little strange.)

A couple of more realistic examples of how allowing the ansatz to be different across different excited states could be useful (In addition to allowing the initial parameters to be different):

1. Use the same ansatz circuit, but prepend them with different physically-motivated initial states. (e.g. Hartree Fock for the ground state and some other Slater determinants or perturbed Hartree Fock states for the excited states)
2. Reason on physical grounds that the most important cluster operators will differ across the different ground and excited states and supply custom UCC-style ansatzes for the various states.

[coveralls]

Pull Request Test Coverage Report for Build 4699380082

• 18 of 19 (94.74%) changed or added relevant lines in 1 file are covered.
• 12 unchanged lines in 4 files lost coverage.
• Overall coverage increased (+0.004%) to 85.795%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/algorithms/eigensolvers/vqd.py	18	19	94.74%

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/expr.rs	1	93.76%
qiskit/transpiler/passes/synthesis/unitary_synthesis.py	1	95.14%
crates/qasm2/src/lex.rs	4	90.13%
crates/qasm2/src/parse.rs	6	97.58%

Totals
Change from base Build 4694883008:	0.004%
Covered Lines:	70410
Relevant Lines:	82068

---

💛 - Coveralls

[Cryoris]

This change looks good to me, thanks @ariannacrippa! Could you add a releasnote and a test?

@JoelHBierman sounds like a good idea, let's do that in a follow-up!

[ElePT]

Hi Arianna!!
It looks like your release note is in qiskit-terra.qiskit.algorithms.eigensolvers.releasenotes.notes, but it should be in the top directory. Can you please move it to qiskit-terra.releasenotes.notes? (and delete the releasenotes folder you created inside eigensolvers?)

[ElePT]

Hello again, I left some typehint-related suggestions, but apart from that, the code looks good to me. All that's missing to approve this PR is adding a test for multiple optimizers to the VQD unit test, you can find the file here. If you have any question about how to write a unit test, you know where to find me :)

[ElePT]

LGTM, but @Cryoris, could you take a final look?

[Cryoris]

Just one small note on the reno, otherwise LGTM, thanks for bringin it over the finish line!