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
At the moment spectra solvers are sort of black-boxes, which return an enum at the end which signals convergence or failure.
This is sufficient for problems that do not take long to compute. For larger problems that take hours or days to run, more information about the internal state of the solver would be nice. users could benchmark there code better and it would also be useful for debugging.
I have two different ideas how to do this, but a lot more feedback is appreciated and probably better ideas as well.
a) Add a virtual class Log which can be set via setLogger(*log) and has to be implemented by the user. If no logger is set, no logging output is produced. The derived class has to implement a log(const& Data) method.
I am not sure what should be in the Data, probably iteration count, residues, current eigenvalues, for davidson maybe subspace size, number_of_converged eigenvalues().
b) The second choice would be to have a bool iterateOneStep() function, which would be called.
and the user would have to put this into a loop him/herself until the system is converged, in the meantime we would expose most of the solver internals via get() functions. So the user can write the iteration stuff him/herself.
I am not sure which method is better, I favour the first one. Instead of a setLogger method we can also pass an additional argument to the constructor.
The text was updated successfully, but these errors were encountered:
Is anyone working on this? I have been finding that I would like this more and more. I am very much in favor of (a) the virtual class. If no one is working on this I could probably take a crack at it after 7/24.
At the moment spectra solvers are sort of black-boxes, which return an enum at the end which signals convergence or failure.
This is sufficient for problems that do not take long to compute. For larger problems that take hours or days to run, more information about the internal state of the solver would be nice. users could benchmark there code better and it would also be useful for debugging.
I have two different ideas how to do this, but a lot more feedback is appreciated and probably better ideas as well.
a) Add a virtual class
Log
which can be set viasetLogger(*log)
and has to be implemented by the user. If no logger is set, no logging output is produced. The derived class has to implement alog(const& Data)
method.I am not sure what should be in the
Data
, probably iteration count, residues, current eigenvalues, for davidson maybe subspace size, number_of_converged eigenvalues().b) The second choice would be to have a
bool iterateOneStep()
function, which would be called.and the user would have to put this into a loop him/herself until the system is converged, in the meantime we would expose most of the solver internals via
get()
functions. So the user can write the iteration stuff him/herself.I am not sure which method is better, I favour the first one. Instead of a
setLogger
method we can also pass an additional argument to the constructor.The text was updated successfully, but these errors were encountered: