Open cpviolator opened 7 years ago
Apologies for the aeonic response time. To answer your questions
Cleaning up this should be high in our priorities. Moreover, I'm not entirely sure why the ColorSpinorField class should know or care about what the twist_flavor
is. This has some rather unintended side effects, such as linear algebra being retuned when changing flavour but having all other meta data constant.
@alexstrel can you remind me what the motivation is for each field knowing what twist_flavor it is be applied to?
I noticed that in the
setMultigridParams()
function in the test function, the twist flavour is passed to the MG routines (default is MINUS.) Does this mean that in order to perform a calculation with both PLUS and MINUS twists, one needs two separate MG preconditioners for each type? In my code, I have a loop over spin and colour for a given source, and within that spin-colour loop I calculate both up and down type correlation functions. I have found that I get errors when I call the solver indicating that "Twist flavours do not match" if the MG preconditioner is created with MINUS and I then try to change to PLUS inside my calculations.I can get around this my declaring two new preconditioner pointers in
invert_quda.h
andquda.h
thus:and then running the MG setup twice, once with
QUDA_TWIST_PLUS
passed tosetMultigridParams()
and once withQUDA_TWIST_MINUS
:Inside the spin color loop, when I wish to change flavour, I write
The creation of Dirac operators and such (
d, dPre, dSloppy, m, mPre, mSloppy
) are done before the iteration over spin/colour. I have some questions about this procedure:d, dPre, dSloppy, m, mPre, mSloppy
objects, or is it sufficient to call:param->twist_flavor = QUDA_TWIST_MINUS;
orparam->twist_flavor = QUDA_TWIST_PLUS;
as required before creating aSolverParam
object and calling the solver?