<div class="gmail_quote">On Tue, Feb 22, 2011 at 18:14, Ethan Coon <span dir="ltr"><<a href="mailto:ecoon@lanl.gov">ecoon@lanl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> Also suppose the succeeding statement of KSPSetOperators is KSPSetFromOptions(ksp_context) and I pass "-pc_type none" at the terminal, would this mean that Pmat is not at all needed<br>
><br>
> in PETSc's calculations??<br>
<br>
</div>Correct, pmat is not used in that case.  In that case, you still have to<br>
pass something in to KSPSetOperators, so Amat for both is the likely<br>
choice.</blockquote></div><br><div>I thought it was silly that Pmat needed to be passed in even if it was not used. It turns out that there was a copy-paste error in PCGetOperators() that would overwrite pc->mat if pc->pmat was not set. I updated that function and now PCNONE works even if Pmat was never set. Of course it still makes sense to pass Amat in both slots even if you plan to use PCNONE. More importantly, however, the new error message is at least sensible "null argument" instead of the confusing "type not set" within a MatMult.</div>