James, The fix is pushed to petsc-maint (release) https://bitbucket.org/petsc/petsc/commits/c974faeda5a26542265b90934a889773ab380866
Thanks for your report! Hong On Mon, Sep 15, 2014 at 5:05 PM, Hong <[email protected]> wrote: > James : > I'm fixing it in branch > hzhang/matmatmult-bugfix > https://bitbucket.org/petsc/petsc/commits/a7c7454dd425191f4a23aa5860b8c6bac03cfd7b > > Once it is further cleaned, and other routines are checked, I will > patch petsc-release. > > Hong > >> Hi Barry, >> >> Thanks for the response. You're right, it (both ex70 and my own code) >> doesn't give those valgrind errors when I run it in parallel. Changing the >> type to MATAIJ also fixes the issue. >> >> Thanks for the help, I appreciate it. >> >> James >> >> >> >> >> >>> -----Original Message----- >>> From: Hong [mailto:[email protected]] >>> Sent: Friday, September 12, 2014 4:29 PM >>> To: Dominic Meiser >>> Cc: Barry Smith; James Balasalle; Zhang, Hong; [email protected] >>> Subject: Re: [petsc-users] Valgrind Errors >>> >>> I'll check it. >>> Hong >>> >>> On Fri, Sep 12, 2014 at 3:40 PM, Dominic Meiser <[email protected]> >>> wrote: >>> > On 09/12/2014 02:11 PM, Barry Smith wrote: >>> >> >>> >> James (and Hong), >>> >> >>> >> Do you ever see this problem in parallel runs? >>> >> >>> >> You are not doing anything wrong. >>> >> >>> >> Here is what is happening. >>> >> >>> >> MatGetBrowsOfAoCols_MPIAIJ() which is used by >>> >> MatMatMult_MPIAIJ_MPIAIJ() assumes that the VecScatters for the >>> >> matrix-vector products are >>> >> >>> >> gen_to = (VecScatter_MPI_General*)ctx->todata; >>> >> gen_from = (VecScatter_MPI_General*)ctx->from data; >>> >> >>> >> but when run on one process the scatters are not of that form; hence >>> >> the code accesses values in what it thinks is one struct but is >>> >> actually a different one. Hence the valgrind errors. >>> >> >>> >> But since the matrix only lives on one process there is actually >>> >> nothing to move between processors hence no error happens in the >>> >> computation. You can avoid the issue completely by using MATAIJ >>> >> matrix for the type instead of MATMPIAIJ and then on one process it >>> automatically uses MATSEQAIJ. >>> >> >>> >> I don’t think the bug has anything in particular to do with the >>> >> MatTranspose. >>> >> >>> >> Hong, >>> >> >>> >> Can you please fix this code? Essentially you can by pass parts >>> >> of the code when the Mat is on only one process. (Maybe this also >>> >> happens for MPIBAIJ matrices?) Send a response letting me know you >>> saw this. >>> >> >>> >> Thanks >>> >> >>> >> Barry >>> > >>> > I had to fix a few issues similar to this a while back. The method >>> > VecScatterGetTypes_Private introduced in pull request 176 might be >>> > useful in this context. >>> > >>> > Cheers, >>> > Dominic >>> > >> >> >> >> >> >> >> >> >> This electronic communication and any attachments may contain confidential >> and proprietary >> information of DigitalGlobe, Inc. If you are not the intended recipient, or >> an agent or employee >> responsible for delivering this communication to the intended recipient, or >> if you have received >> this communication in error, please do not print, copy, retransmit, >> disseminate or >> otherwise use the information. Please indicate to the sender that you have >> received this >> communication in error, and delete the copy you received. DigitalGlobe >> reserves the >> right to monitor any electronic communication sent or received by its >> employees, agents >> or representatives. >>
