<p>Where is the update to every KSP (at least the CGs, but I think all of them) to change the order? I don't see it in the repository. Note that this notation is different from that used by most textbook and paper descriptions of the methods.</p>

<p>On Apr 17, 2012 7:09 PM, "Barry Smith" <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
>><br>
>><br>
>>   Since PETSc was written and always implemented with mathematician style* inner products, I have decided to keep it that way and call the BLASdot_() with the arguments reversed. Note that until Matt added the support for zdotc() we never called the BLAS for complex inner products and thus never used the engineers style inner products.<br>

>><br>
>>    Please report any problems,<br>
>><br>
>>    Barry<br>
>><br>
>> * please do not be upset by my joking reference to mathematician and engineering style inner products.<br>
>><br>
>><br>
>> On Apr 15, 2012, at 1:09 PM, Jed Brown wrote:<br>
>><br>
>> > On Sun, Apr 15, 2012 at 12:55, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
>> >   Real mathematicians conjugate the second one :-)<br>
>> ><br>
>> > I never unrderstood that choice. I like vectors to be column vectors, one forms to be row vectors, and operations to have standard fixity. How some mathematicians ended up with infix operators and postfix inner products is beyond me.<br>

>> ><br>
>> ><br>
>> >   The code to check is PETSc's conjugate gradient, there the conjugate does mater :-).<br>
>> ><br>
>> > Looks right to me.<br>
>> ><br>
>> >        ierr = KSP_MatMult(ksp,Amat,P,W);CHKERRQ(ierr);          /*     w <- Ap         */<br>
>> >        ierr = VecXDot(P,W,&dpi);CHKERRQ(ierr);                  /*     dpi <- p'w     */<br>
>> ><br>
>><br>
</p>