Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ElePT opened this issue Aug 22, 2023 · 1 comment
Open

Comments

@ElePT
Copy link
Collaborator

ElePT commented Aug 22, 2023

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.

@ElePT
Copy link
Collaborator Author

ElePT commented Aug 22, 2023

Opened by @mrossinek
Original issue & discussion: Qiskit/qiskit#10194

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant