-
Notifications
You must be signed in to change notification settings - Fork 97
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
Feature/mrhs solvers #1489
base: develop
Are you sure you want to change the base?
Feature/mrhs solvers #1489
Conversation
… size to use when generating null-space vectors. This is the parameter used to enable MRHS null space generation. Updated the null-space generation to work on vectors of this width
…-> scalar cast operator explicit instead of implicit
…ch - will be needed for batched CG
… issues at compile time, the scalar -> vector<scalar> cast operator is now explicit. Apply necessary changes to ensure that stuff doesn't break with this change
…of invertQuda to new function solve which is MRHS aware
… also now called by the invertMultiSrcQuda interface
@@ -1426,8 +1426,9 @@ void qudaInvertMsrc(int external_precision, int quda_precision, double mass, Qud | |||
|
|||
// return the number of iterations taken by the inverter | |||
*num_iters = invertParam.iter; |
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.
I believe MILC expects the aggregate number of iterations as if it wasn't a batch/block solve, but I forget. I'll also scope out how it expects the residuals as part of the work I'm doing on the MILC side and sort this out
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.
Note to self, can confirm that is the case: https://github.com/lattice/milc_qcd/blob/develop/generic_ks/d_congrad5_fn_milc.c#L409-L417
… have single implementations of these, which use a solver factor to call the correct CG method
|
||
// break-out check if we have reached the limit of the precision | ||
if (r2 > r2_old) { | ||
resIncrease++; | ||
resIncreaseTotal++; | ||
warningQuda( | ||
"CA-CG: new reliable residual norm %e is greater than previous reliable residual norm %e (total #inc %i)", | ||
sqrt(r2), sqrt(r2_old), resIncreaseTotal); | ||
sqrt(r2[0]), sqrt(r2_old[9]), resIncreaseTotal); |
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.
r2_old[0]
not r2_old[9]
:)
return true; | ||
} | ||
|
||
bool Solver::convergenceHQ(double, double hq2, double, double hq_tol) | ||
bool Solver::convergenceHQ(cvector<double> &hq2, cvector<double> &hq_tol) |
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.
There's a big "gotcha" that happens here: in, for example, inv_cg_quda.cpp
, this routine is called as:
convergenceHQ(hq_res, param.tol_hq)
Where param.tol_hq
is just a double. Within convergenceHQ
(and elsewhere), this is blindly converted to a cvector<double>
where the 0th element is param.tol_hq
and then the rest are uninitialized. This gives garbage for the other values, messing up convergence.
I think the only way to catch this is to make a conversion from a type T
to cvector<T>
require an explicit cast, which I think you've imposed on other types as well.
This is PR is a biggie:
QudaMultigridParam::n_vec_batch
invertMultiSrcQuda
interfaceQudaInvertParam::true_res
andQudaInvertParam::true_res_hq
are now arraysDirac::prepare
andDirac::reconstruct
functions are now MRHS optimizedcvector<T>
toT
is now explicit instead of implicitDslashCoarse
is now robust to underflowMPI_THREAD_FUNNELED
Things left to do