[from qiskit] Add a `filter_limit` option on `NumPy(Minimum)Eigensolver`

[ElePT]

What should we add?

What should we add?

The Problem

When prototyping or debugging non-quantum parts of the stack I often find myself getting back to the NumPy(Minimum)Eigensolver classes. However, in less trivial chemistry applications, the naive lowest eigenvalue is oftentimes not a physical one, so I need to rely on adding a filter_criterion to find a physically meaningful eigenvalue.

Unfortunately, the code currently hard-codes k when a filter_criterion is supplied: https://github.com/Qiskit/qiskit-terra/blob/332bd9fe0bea82c0fdf7329cea3da115d86e3fc2/qiskit/algorithms/eigensolvers/numpy_eigensolver.py#L257-L259

This means that ALL eigenvalues will be computed, which can take a VERY long time. The reason for doing this is well motivated though, because one cannot know a priori what value to pick for k.

My proposed solution

I would like to propose that we support setting k and filter_criterion simultaneously. Since as an end-user I have written the filter_criterion myself, I do have more knowledge about the problem that I am trying to solve. Thus, I may also be able to make an educated guess for k. And even if that fails, I may be willing to try setting k to 100, then 200, then 300 and so on , rather than having to wait for say 2**10=1024 eigenvalues to be computed regardless of whether my value of interest might have been in the first 10% or so.

I think the prototyping and debugging speed that could be gained here is quite significant.

So in summary:

• the defaults should remain as they are right now
• but it should be possible for an end-user to manually set k while also setting a filter_criterion

---

I would work on this myself, but in the recent months where I thought of doing this I have not found the time to come up with a clean code solution. Thus, I am opening this issue to see if someone else might find this interesting and has the time to do this. I will gladly review a PR once time has come. Otherwise I might get back to this once I have a bit more time on my hands in the (potentially far) future.