Mods to allow copy in/out of full QDP-JIT spinors

[bjoo]

Mods to allow copy-in of full (both parities) of QDP-JIT fields. This should allow the use of unpreconditioned actions from Chroma (allowing QUDA to take care of source creation and reconstruction on device).

[bjoo]

I have tested this with Chroma using CG and BiCGStab. In the end I went with an inline function to compute the parities. This way I don't need to flip them in the constructor body (which would involve changing a 'const int`). Rather the constructor can call the helper function to set the parities. This avoids having to check, e.g. a 'flipInputParity' flag in the actual accessor every time we access.

I ran git clang-format as well to clang-format the changes. Hope it is OK.

[bjoo]

Removed Kate from the reviewer list since I think she is already part of the quda_core.

[bjoo]

So, the way checkerboarding works in Chroma at the moment, is that we always use the Odd Subset for preconditioned solves. However it may be worth bullet proofing, in case someone wants to call an even-even solve for whatever reason. Can we get that info? (A reference to the solver params) from the ColorSpinor fields? If so, the ‘computeParity()’ function is a good place to put that I guess.

Best, B

From: maddyscientist @.> Date: Wednesday, October 16, 2024 at 2:02 PM To: lattice/quda @.> Cc: Balint Joo @.>, Author @.> Subject: Re: [lattice/quda] Mods to allow copy in/out of full QDP-JIT spinors (PR #1504)

@maddyscientist commented on this pull request.

---

In include/kernels/copy_color_spinor.cuhhttps://github.com/lattice/quda/pull/1504#discussion_r1803573417:

@@ -16,6 +16,21 @@ namespace quda

using namespace colorspinor;

• /* Helper function for parity computation /

• inline int computeParity(const ColorSpinorField &f)

• {

• // Account for odd-even vs. even-odd site orders

• int ret_val = f.SiteOrder() == QUDA_ODD_EVEN_SITE_ORDER ? 1 : 0;

• // Account for potential parity flip to access single parity subset QDP-JIT fields

• if (f.FieldOrder() == QUDA_QDPJIT_FIELD_ORDER && f.SiteSubset() == QUDA_PARITY_SITE_SUBSET) {

Thinking out loud: I guess this parity flip here should really be predicated on the solve being an odd-odd solve, and not an even-even solve. If Chroma asked for an even-even solve we'd grab the wrong parity. Is this something we should support?

— Reply to this email directly, view it on GitHubhttps://github.com/lattice/quda/pull/1504#pullrequestreview-2373276378, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAEPL2AMY5KCXBF5IFFTRKDZ32S2BAVCNFSM6AAAAABQBTZS2SVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGNZTGI3TMMZXHA. You are receiving this because you authored the thread.Message ID: @.***>

[maddyscientist]

So, the way checkerboarding works in Chroma at the moment, is that we always use the Odd Subset for preconditioned solves. However it may be worth bullet proofing, in case someone wants to call an even-even solve for whatever reason. Can we get that info? (A reference to the solver params) from the ColorSpinor fields? If so, the ‘computeParity()’ function is a good place to put that I guess.

Yes, that information is available. When the fields are set up, the preconditioning type for the solver (even-even, odd-odd, even-even-asymmetric, etc.) is used to store the "suggested" parity for the field. The function to query is ColorSpinorField::SuggestedParity().

[bjoo]

Resolved Evan's comment with: commit 25cfeed

[bjoo]

Fixed @param f[in] -> @param[in] f in 76947a3

[bjoo]

OK. Looks like comments are resolved, and PR is approved so here goes...