You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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 afilter_criterion
to find a physically meaningful eigenvalue.Unfortunately, the code currently hard-codes
k
when afilter_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
andfilter_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 fork
.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 say2**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:
k
while also setting afilter_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.
The text was updated successfully, but these errors were encountered: