<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 23 Sep 2019, at 4:16 AM, <a href="mailto:hong@aspiritech.org" class="">hong@aspiritech.org</a> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Now I understand why the latest changes in MatMatMult_MPIAIJ_MPIDense() cause errors in your application (likely for slepc as well). <div class="">I always assume "MAT_REUSE_MATRIX requires that the C matrix has come from a previous call with MAT_INITIAL_MATRIX" for all matrix products in petsc. I noticed </div><div class=""><br class=""></div><div class="">/*<br class=""> This is a "dummy function" that handles the case where matrix C was created as a dense matrix<br class=""> directly by the user and passed to MatMatMult() with the MAT_REUSE_MATRIX option<br class=""><br class=""> It is the same as MatMatMultSymbolic_MPIAIJ_MPIDense() except does not create C<br class="">*/<br class="">PetscErrorCode MatMatMultNumeric_MPIDense(Mat A,Mat B,Mat C)<br class=""></div><div class=""><br class=""></div><div class="">but I do not see this routine is being used by any petsc routines or tests, thus I thought it might be a dead routine, </div></div></div></blockquote><div><br class=""></div><div>It sure isn’t: <a href="https://www.mcs.anl.gov/petsc/petsc-current/src/mat/impls/dense/mpi/mpidense.c.html#line1192" class="">https://www.mcs.anl.gov/petsc/petsc-current/src/mat/impls/dense/mpi/mpidense.c.html#line1192</a></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">and planned to remove it after a careful investigation.</div><div class="">The name of this routine is misleading as well.</div></div></div></blockquote><div><br class=""></div><div>I agree.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">I prefer a uniformed and clean design for all matrix products, i.e., do not allow "REUSE" without previous call with "INITIAL". Almost all products include internal data structures for various reasons. </div><div class="">In latest MatMatMult_MPIAIJ_MPIDense(), we added internal data structures and obtained an impressive improvement in memory usage.</div></div></div></blockquote><div><br class=""></div><div>As I said to Barry, the change in behavior will likely result in worse memory usage for all applications that currently use this “feature”.</div><div>The previous symbolic phase was also basically a no-op, I’ve not yet benchmarked the new implementation, but I’m betting this will be slightly costlier.</div><div>Codes which previously didn’t cache the Mat C and relied once again on this feature will also have to pay the prize of doing multiple symbolic phases (assuming the rest remains as is and is not changed to cache C).</div><div><br class=""></div><div>Thanks,</div><div>Pierre</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Hong</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 22, 2019 at 4:38 PM Pierre Jolivet via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov" class="">petsc-dev@mcs.anl.gov</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"><div style="overflow-wrap: break-word;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 22 Sep 2019, at 8:32 PM, Smith, Barry F. <<a href="mailto:bsmith@mcs.anl.gov" target="_blank" class="">bsmith@mcs.anl.gov</a>> wrote:</div><br class="gmail-m_-3873696193683309536Apple-interchange-newline"><div class=""><div class=""><br class=""> Since this a common used feature we will need to support it in the release or it will break a variety of codes.<br class=""><br class=""> I am not sure how to "deprecate it" in a useful way. How would the code actively tell the user that the approach is deprecated and they should update their code before the next release? Having it print warnings while it is running if they never used the INITIAL is too intrusive but what else could be done? Save the message and print it when the program ends? I guess we could do that. Is that too intrusive? Will it break other peoples tests? Do we want it to break other people's tests with this message?<br class=""><br class=""> Suggestions? For sure this feature will be removed at some point, how to give users useful warning (reading a document doesn't work).<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I believe that if you deprecate this behavior, it should mean that you deprecate MatMatMultNumeric_MPIDense as well.</div><div class="">Which means that there are tests that are becoming pretty meaningless, e.g., <a href="https://www.mcs.anl.gov/petsc/petsc-dev/src/mat/impls/aij/mpi/mpimatmatmult.c.html#line606" target="_blank" class="">https://www.mcs.anl.gov/petsc/petsc-dev/src/mat/impls/aij/mpi/mpimatmatmult.c.html#line606</a> unless there is a memory corruption of some sort, but then the user has bigger concerns.</div><div class="">They could instead be replaced by a check for the presence of the correct stuff (MPI_Datatype and whatnot) introduced by the new MR, and if not, do what you suggest (error message at the end, PetscInfo, whatever…) + go back to the symbolic phase to avoid any kind of segfault like I’m getting right now?</div><div class="">Just my two cents…</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Pierre</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> Barry<br class=""><br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Sep 22, 2019, at 1:16 PM, Pierre Jolivet <<a href="mailto:pierre.jolivet@enseeiht.fr" target="_blank" class="">pierre.jolivet@enseeiht.fr</a>> wrote:<br class=""><br class="">Just to be sure: can we expect this "feature" to be fixed for the upcoming release and deprecated later on, or will you get rid of this for good for the release?<br class=""><br class="">Thanks,<br class="">Pierre<br class=""><br class="">On Sep 22, 2019, at 7:11 PM, "Smith, Barry F." <<a href="mailto:bsmith@mcs.anl.gov" target="_blank" class="">bsmith@mcs.anl.gov</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><br class=""> Jose,<br class=""><br class=""> Thanks for the pointer. <br class=""><br class=""> Will this change dramatically affect the organization of SLEPc? As noted in my previous email eventually we need to switch to a new API where the REUSE with a different matrix is even more problematic.<br class=""><br class=""> If you folks have use cases that fundamentally require reusing a previous matrix instead of destroying and getting a new one created we will need to think about additional features in the API that would allow this reusing of an array. But it seems to me that destroying the old matrix and using the initial call to create the matrix should be ok and just require relatively minor changes to your codes?<br class=""><br class="">Barry<br class=""><br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Sep 22, 2019, at 11:55 AM, Jose E. Roman <<a href="mailto:jroman@dsic.upv.es" target="_blank" class="">jroman@dsic.upv.es</a>> wrote:<br class=""><br class="">The man page of MatMatMult says:<br class="">"In the special case where matrix B (and hence C) are dense you can create the correctly sized matrix C yourself and then call this routine with MAT_REUSE_MATRIX, rather than first having MatMatMult() create it for you."<br class=""><br class="">If you are going to change the usage, don't forget to remove this sentence. This use case is what we use in SLEPc and is now causing trouble.<br class="">Jose<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">El 22 sept 2019, a las 18:49, Pierre Jolivet via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov" target="_blank" class="">petsc-dev@mcs.anl.gov</a>> escribió:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On 22 Sep 2019, at 6:33 PM, Smith, Barry F. <<a href="mailto:bsmith@mcs.anl.gov" target="_blank" class="">bsmith@mcs.anl.gov</a>> wrote:<br class=""><br class=""><br class="">Ok. So we definitely need better error checking and to clean up the code, comments and docs <br class=""><br class="">As the approaches for these computations of products get more complicated it becomes a bit harder to support the use of a raw product matrix so I don't think we want to add all the code needed to call the symbolic part (after the fact) when the matrix is raw.<br class=""></blockquote><br class="">To the best of my knowledge, there is only a single method (not taking MR 2069 into account) that uses a MPIDense B and for which these approaches are necessary, so it’s not like there is a hundred of code paths to fix, but I understand your point.<br class=""><br class=""><blockquote type="cite" class="">Would that make things terribly difficult for you not being able to use a raw matrix?<br class=""></blockquote><br class="">Definitely not, but that would require some more memory + one copy after the MatMatMult (depending on the size of your block Krylov space, that can be quite large, and that defeats the purpose of MR 2032 of being more memory efficient).<br class="">(BTW, I now remember that I’ve been using this “feature” since our SC16 paper on block Krylov methods)<br class=""><br class=""><blockquote type="cite" class="">I suspect that the dense case was just lucky that using a raw matrix worked.<br class=""></blockquote><br class="">I don’t think so, this is clearly the intent of MatMatMultNumeric_MPIDense (vs. MatMatMultNumeric_MPIAIJ_MPIDense).<br class=""><br class=""><blockquote type="cite" class="">The removal of the de facto support for REUSE on the raw matrix should be added to the changes document.<br class=""><br class="">Sorry for the difficulties. We have trouble testing all the combinations of possible usage, even a coverage tool would not have indicated a problems the lack of lda support.<br class=""></blockquote><br class="">No problem!<br class=""><br class="">Thank you,<br class="">Pierre<br class=""><br class=""><blockquote type="cite" class="">Hong,<br class=""><br class="">Can you take a look at these things on Monday and maybe get a clean into a MR so it gets into the release?<br class=""><br class="">Thanks<br class=""><br class=""><br class="">Barry<br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Sep 22, 2019, at 11:12 AM, Pierre Jolivet <<a href="mailto:pierre.jolivet@enseeiht.fr" target="_blank" class="">pierre.jolivet@enseeiht.fr</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On 22 Sep 2019, at 6:03 PM, Smith, Barry F. <<a href="mailto:bsmith@mcs.anl.gov" target="_blank" class="">bsmith@mcs.anl.gov</a>> wrote:<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Sep 22, 2019, at 10:14 AM, Pierre Jolivet via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov" target="_blank" class="">petsc-dev@mcs.anl.gov</a>> wrote:<br class=""><br class="">FWIW, I’ve fixed MatMatMult and MatTransposeMatMult here <a href="https://gitlab.com/petsc/petsc/commit/93d7d1d6d29b0d66b5629a261178b832a925de80" target="_blank" class="">https://gitlab.com/petsc/petsc/commit/93d7d1d6d29b0d66b5629a261178b832a925de80</a> (with MAT_INITIAL_MATRIX).<br class="">I believe there is something not right in your MR (2032) with MAT_REUSE_MATRIX (without having called MAT_INITIAL_MATRIX first), cf. <a href="https://gitlab.com/petsc/petsc/merge_requests/2069#note_220269898" target="_blank" class="">https://gitlab.com/petsc/petsc/merge_requests/2069#note_220269898</a>.<br class="">Of course, I’d love to be proved wrong!<br class=""></blockquote><br class="">I don't understand the context.<br class=""><br class="">MAT_REUSE_MATRIX requires that the C matrix has come from a previous call with MAT_INITIAL_MATRIX, you cannot just put any matrix in the C location.<br class=""></blockquote><br class="">1) It was not the case before the MR, I’ve used that “feature” (which may be specific for MatMatMult_MPIAIJ_MPIDense) for as long as I can remember<br class="">2) If it is not the case anymore, I think it should be mentioned somewhere (and not only in the git log, because I don’t think all users will go through that)<br class="">3) This comment should be removed from the code as well: <a href="https://www.mcs.anl.gov/petsc/petsc-dev/src/mat/impls/aij/mpi/mpimatmatmult.c.html#line398" target="_blank" class="">https://www.mcs.anl.gov/petsc/petsc-dev/src/mat/impls/aij/mpi/mpimatmatmult.c.html#line398</a><br class=""><br class=""><blockquote type="cite" class="">This is documented in the manual page. We should have better error checking that this is the case so the code doesn't crash at memory access but instead produces a very useful error message if the matrix was not obtained with MAT_INITIAL_MATRIX. <br class=""><br class="">Is this the issue or do I not understand?<br class=""></blockquote><br class="">This is exactly the issue.<br class=""><br class=""><blockquote type="cite" class="">Barry<br class=""><br class="">BTW: yes MAT_REUSE_MATRIX has different meanings for different matrix operations in terms of where the matrix came from, this is suppose to be all documented in each methods manual page but some may be missing or incomplete, and error checking is probably not complete for all cases. Perhaps the code should be changed to have multiple different names for each reuse case for clarity to user?<br class=""></blockquote><br class="">Definitely, cf. above.<br class=""><br class="">Thanks,<br class="">Pierre<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">Thanks,<br class="">Pierre<br class=""><br class=""><blockquote type="cite" class="">On 22 Sep 2019, at 5:04 PM, Zhang, Hong <<a href="mailto:hzhang@mcs.anl.gov" target="_blank" class="">hzhang@mcs.anl.gov</a>> wrote:<br class=""><br class="">I'll check it tomorrow.<br class="">Hong<br class=""><br class="">On Sun, Sep 22, 2019 at 1:04 AM Pierre Jolivet via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov" target="_blank" class="">petsc-dev@mcs.anl.gov</a>> wrote:<br class="">Jed,<br class="">I’m not sure how easy it is to put more than a few lines of code on GitLab, so I’ll just send the (tiny) source here, as a follow-up of our discussion <a href="https://gitlab.com/petsc/petsc/merge_requests/2069#note_220229648" target="_blank" class="">https://gitlab.com/petsc/petsc/merge_requests/2069#note_220229648</a>.<br class="">Please find attached a .cpp showing the brokenness of C=A*B with A of type MPIAIJ and B of type MPIDense when the LDA of B is not equal to its number of local rows.<br class="">It does [[1,1];[1,1]] * [[0,1,2,3];[0,1,2,3]]<br class="">C should be equal to 2*B, but it’s not, unless lda = m (= 1).<br class="">Mat Object: 2 MPI processes<br class="">type: mpidense<br class="">0.0000000000000000e+00 1.0000000000000000e+00 2.0000000000000000e+00 3.0000000000000000e+00<br class="">0.0000000000000000e+00 1.0000000000000000e+00 2.0000000000000000e+00 3.0000000000000000e+00<br class=""><br class="">If you change Bm here <a href="https://www.mcs.anl.gov/petsc/petsc-dev/src/mat/impls/aij/mpi/mpimatmatmult.c.html#line549" target="_blank" class="">https://www.mcs.anl.gov/petsc/petsc-dev/src/mat/impls/aij/mpi/mpimatmatmult.c.html#line549</a> to the LDA of B, you’ll get the correct result.<br class="">Mat Object: 2 MPI processes<br class="">type: mpidense<br class="">0.0000000000000000e+00 2.0000000000000000e+00 4.0000000000000000e+00 6.0000000000000000e+00<br class="">0.0000000000000000e+00 2.0000000000000000e+00 4.0000000000000000e+00 6.0000000000000000e+00<br class=""><br class="">Unfortunately, w.r.t. MR 2069, I still don’t get the same results with a plain view LDA > m (KO) and a view + duplicate LDA = m (OK).<br class="">So there might be something else to fix (or this might not even be a correct fix), but the only reproducer I have right now is the full solver.<br class=""><br class="">Thanks,<br class="">Pierre<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><br class=""></blockquote></blockquote><br class=""></div></div></blockquote></div><br class=""></div></blockquote></div>
</div></blockquote></div><br class=""></body></html>