<div class="gmail_quote">On Fri, Mar 23, 2012 at 17:14, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":h1">  But you are implicitly assuming that for example the first component of input space is "somehow" tied to the first component of the output space etc. I submit this is only true if the user has chosen first component of the input space and output space "correctly" and the user may not have done this. Giving this additional freedom to the PCFieldSplit allows the person defining the components (first etc in the input and output spaces) to not be concerned with how those definitions affect the solver, since the PCFiledSplit stage can correct for dumb choices.<br>
</div></blockquote><div><br></div><div>Suppose I have a permutation matrix P, P^T P = P P^T = I. The usual point of pivoting is</div><div><br></div><div>A^{-1} = (P^T P A)^{-1} = (P A)^{-1} P^{-T} = (P A)^{-1} P</div><div>
<br></div><div>A typical reason for this is that A has 0 in the first diagonal block, but P A is nice. Now you're telling me that you want to inject the permutation into the original definition of the problem. So I guess the user would only give B = P A and they would define their problem as B x = (P b), never telling me about P anywhere.</div>
<div><br></div><div>Okay, but what needs to be written to change P? It sounds like I would need to change the way assembly is done and also the way residuals are evaluated. That just seems more intrusive and definitely less amenable to automatically detecting the need for pivoting. I wanted to be able to experiment with different elimination orders at run-time.</div>
</div>