-
Notifications
You must be signed in to change notification settings - Fork 102
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
Mods to allow copy in/out of full QDP-JIT spinors #1504
Conversation
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. |
Removed Kate from the reviewer list since I think she is already part of the quda_core. |
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.cuh<#1504 (comment)>:
@@ -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 GitHub<#1504 (review)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAEPL2AMY5KCXBF5IFFTRKDZ32S2BAVCNFSM6AAAAABQBTZS2SVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGNZTGI3TMMZXHA>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
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 |
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 has my approval pending the doxygen request! I confirmed offline that this was clang-format
'd.
Resolved Evan's comment with: commit 25cfeed |
OK. Looks like comments are resolved, and PR is approved so here goes... |
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).