If you have a Git clone, you can make a temporary merge to see if it works.
On October 9, 2014 10:06:44 AM MDT, Eric Chamberland <[email protected]> wrote: >Hi Jed, > >I do not have a petsc/dev or petsc/next compiled (I just use petsc >3.5.2), but Patrick have one for sure. He should be able to try the >patch sooner than I. > >Patrick, would you give it a try please? > >Thanks, > >Eric > >On 10/09/2014 11:41 AM, Jed Brown wrote: >> Hi, Eric. Fabian reported this a couple days ago (all, petsc-users >is >> preferred so that people can see recent discussion). >> >> Thanks for linking to Patrick's report. I have extended it to >simplify >> the code a bit and reduce synchronization, but I don't have a test >case >> handy and I'm about to board a plane. Could you try 'next' (or >> 'placasse/VecGetSubVector' in petsc.git, which has my follow-up >commits) >> to let me know if it works for you. >> >> >https://bitbucket.org/petsc/petsc/issue/75/vecrestoresubvector-silently-ignores-non >> >> Eric Chamberland <[email protected]> writes: >> >>> Hi, >>> >>> I noticed it because I got a strange behavior when computing y=Ax >with >>> (a wrongly) non-contiguous stride in parallel. Normally, the >>> VecRestoreSubVector should have exited with an error ("Unhandled >case, >>> values have been changed and need to be copied back into X) but >didn't, >>> resulting in a silently wrong result (ouch). >>> >>> I corrected my code to define a contiguous stride, which "bypass" >the >>> bug in VecRestoreSubVector and now I hopefully compute the correct >result. >>> >>> You may be interested by: >>> >>> >>> >https://bitbucket.org/placasse/petsc/commits/4e4323587ad9148c29ba9101e5030629f073700c >>> >>> By the way, if I have no local unknowns on a process, shall the >stride >>> *always* be considered locally contiguous? (this is my initial error >on >>> how to define a stride when no unknowns are locally owned). >>> >>> Thanks, >>> >>> Eric
