<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div> Daniel,<div class=""><br class=""></div><div class=""> Thanks for the update. We can patch the release version of PETSc (normally we don't have a way to patch previous release versions)</div><div class=""><br class=""></div><div class=""> There is no direct option to always use the _N version. (For smaller blocks using _N is very slow).</div><div class=""><br class=""></div><div class=""> Barry</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 21, 2021, at 9:51 AM, Daniel Stone <<a href="mailto:daniel.stone@opengosim.com" class="">daniel.stone@opengosim.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I seem to have confirmed that making the change suggested by Lawrence fixes things in our <div class="">case. Some alternate runs by a colleague that result in a blocksize 12 matrix also work</div><div class="">fine - I think in that case MAtMultAdd_SeqBAIJ_N must be being used as I can't find</div><div class="">a blocksize 12 analogue.</div><div class=""><br class=""></div><div class="">Is there by any chance a setting somewhere that can tell petsc to override the use of </div><div class="">blocksize specific routines like this and always go to, e.g., MatMultAdd_SeqBAIJ_N</div><div class="">etc? Might be useful as a short term fix.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">Daniel</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 21, 2021 at 11:50 AM Lawrence Mitchell <<a href="mailto:wence@gmx.li" class="">wence@gmx.li</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Daniel,<br class="">
<br class="">
> On 21 Sep 2021, at 11:19, Daniel Stone <<a href="mailto:daniel.stone@opengosim.com" target="_blank" class="">daniel.stone@opengosim.com</a>> wrote:<br class="">
> <br class="">
> Hello,<br class="">
> <br class="">
> If we look at lines 2330-2331 in file baij2.c, it looks like there are some <br class="">
> mistakes in assigning the `sum..` variables to the z array, causing<br class="">
> the function MatMultAdd_SeqBAIJ_11() to not produce the correct<br class="">
> answer.<br class="">
> <br class="">
> I don't have a good example program to demonstrate this yet - it's<br class="">
> currently causing problems in a dev branch of pflotan_ogs that<br class="">
> can produce blocksize 11 matrices. When in parallel, a standard<br class="">
> matrix-vector multiplication calls MatMultAdd for the off-proc<br class="">
> contributions, and the result is wrong when this is redirected<br class="">
> to MatMultAdd_SeqBAIJ_11. Seems to be the root cause of<br class="">
> several solvers failing such as fgmres.<br class="">
> <br class="">
> Can anyone confirm that these two lines seem incorrect?<br class="">
<br class="">
Looks wrong to me, I guess this patch is correct?<br class="">
<br class="">
diff --git a/src/mat/impls/baij/seq/baij2.c b/src/mat/impls/baij/seq/baij2.c<br class="">
index 2849ef9051..65513c8989 100644<br class="">
--- a/src/mat/impls/baij/seq/baij2.c<br class="">
+++ b/src/mat/impls/baij/seq/baij2.c<br class="">
@@ -2328,7 +2328,7 @@ PetscErrorCode MatMultAdd_SeqBAIJ_11(Mat A,Vec xx,Vec yy,Vec zz)<br class="">
v += 121;<br class="">
}<br class="">
z[0] = sum1; z[1] = sum2; z[2] = sum3; z[3] = sum4; z[4] = sum5; z[5] = sum6; z[6] = sum7;<br class="">
- z[7] = sum6; z[8] = sum7; z[9] = sum8; z[10] = sum9; z[11] = sum10;<br class="">
+ z[7] = sum8; z[8] = sum9; z[9] = sum10; z[10] = sum11;<br class="">
if (!usecprow) {<br class="">
z += 11; y += 11;<br class="">
}<br class="">
<br class="">
<br class="">
Lawrence</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>