If I understand correctly, the objection is that apply for MatShell is<br><br>  apply(Mat, Vec, Vec)<br><br>and for PCShell is<br><br>  apply(ctx, Vec, Vec)<br><br>I agree that this is crap. Its an easy fix to jsut pass the PC instead of<br>
the ctx and let the user pull out the ctx manually if he wants. I am for<br>this.<br><br>  Matt<br><br><div class="gmail_quote">On Wed, Jun 10, 2009 at 9:57 AM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">With MatShell and the SNES/TS interfaces, the user's callback gets the<br>
PETSc object, but this is not so in PCShell.  I find this pretty clumsy,<br>
for example, since there is no PC, the user preconditioner can't call<br>
PCGetOperators.  This means that in contrast to MatShell, the user<br>
really can't write first-class PC implementations using PCShell.  It<br>
also appears that it is not possible to implement PCApplyBAorAB without<br>
obtaining the operator through some other channel.<br>
<br>
Perhaps it's better in the long run to always write a full-blown<br>
implementation (i.e. copy jacobi.c and modify), but I think it would<br>
still be more consistent if PCShell passed the PC to the user's<br>
callbacks.  What do you think?<br>
<font color="#888888"><br>
Jed<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener<br>