-
Notifications
You must be signed in to change notification settings - Fork 47
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
Interface for eigensolver on QUDA #561
Conversation
… interface, added timing and more comments
I tested this on a 32c64 lattice and it seems to work correctly as far as I can tell. However, I think the time to solution for the lowest eigenvalue can be reduced significantly. On the machine in question (single quad-A100 node), the solver takes around My guess is that appropriate settings for |
No poly accel:
smallest: 457 seconds TOTAL: 462 seconds (compared to over 1000 seconds on the CPU for this particular ensemble and machine) untuned poly accel:(note that poly acceleration exchanges SR <-> LR)
It seems that with the chosen settings
that the solve for the largest eigenvalue does not work. Likely one needs to disable poly accel for that. (since the solve time is super short, that's perfectly fine)
The timing reflects this fact: smallest: 77 seconds TOTAL: 154 seconds Proposal for default
and we might need some new parameters to make the degree,
smallest: 77 seconds TOTAL: 82 seconds I'm pretty sure that this can be improved further by lowering the polynomial degree and optimising |
If you have some time, maybe you can take a look at / merge #564 and try to make the parameters user-configurable and/or test around with some production ensembles at various lattice spacings if the hard-coded defaults are okay for now. We can certainly live with 80ish seconds for the eigensolver in the HMC. |
first stab at using polynomial acceleration for the ND eigensolver
…urb global inv_param when changing precision, adjust indentation in one place
|
||
eig_param.invert_param = &inv_param; | ||
|
||
// need our own QudaInvertParam for passing the operator properties |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aniketsen note that I've added this just now because the change of precision is performed in the global inv_param
, which might have unforeseen consequences in certain situations
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this way, the global inv_param
is never touched via the pointer
…tings user input for poly acc settings
…in order to allow all requested eigenvalues to be returned, if desired
@aniketsen slowly getting back into finalizing this and other things As far as I can tell there is currently no way to actually build
If you want we can just leave
you don't actually set any of the global parameters based on the monomial and instead immediately call If you look at something like
where
|
yes, I did not push the changes in the build system. I had added all the monomials, for a more general approach, but yes,
yes, this is a mistake. For some reason I thought You can just leave this script out. I agree that this does not really perform a very useful function at the moment, other than just calling the eigensolver for different monomials. But you can also easily get the same job done by setting |
This reverts commit a46c4c6.
eigsolveQuda
acts as interface for calling the eigensolver on QUDA. Inphmc.c
, this interface is called based on input parameterUseExternalEigSolver
which is stored inmonomial
parameterexternal_eigsolver
. The interface also initializes QUDA and initializes the two flavor solver.