On Wed, Mar 18, 2009 at 5:27 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Wed 2009-03-18 13:59, Matthew Knepley wrote:<br>
> I cannot understand why you cannot use TSSetMatrices()<br>
<br>
</div>TSSetMatrices is only for linear problems and doesn't generalize nicely<br>
to nonlinear problems, especially with matrix-free methods.  The<br>
functionality I'm looking for involves a possibly variable, possibly<br>
singular (with huge null space for DAE), possibly nonlinear (as with fully<br>
implicit moving mesh schemes) Alhs.  With my high-order Galerkin scheme,<br>
Alhs can only be available as MatShell (so MatAXPY is hard to implement)<br>
because an assembled Alhs would be an order of magnitude denser than the<br>
preconditioning matrix associated with the unshifted Jacobian (J=F' if<br>
we are solving Alhs(u,t) u_t = F(u,t)). <br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
This can all be handled in a way that would work nicely with JFNK and<br>
avoid storing Alhs in any form, but I think the user's function<br>
evaluation and matrix assembly needs to provide shifted versions (such<br>
as 1/dt*Alhs-J where J = F'(u)).  The shift is usually a trivial amount<br>
of work during function evaluation and matrix assembly.  Preconditioners<br>
can still be lagged effectively as long as the shift does not change<br>
rapidly.  Even if the shift does change rapidly, reassembling the<br>
preconditioning matrix could still often be avoided by just doing a<br>
lumped shift (function evaluation and matrix-free Jacobians can change<br>
the shift, using a consistent mass matrix, at zero cost).<br>
<br>
Is this more clear?</blockquote><div><br>Not a whole lot. Needs to go slower, since I think there are a bunch of embedded<br>assumptions, and I worry that the most simple, general interface cannot be seen<br>until they are clarified. I want it spelled out very very explicitly. So, to begin, you<br>
are unhappy with<br><br>  A_lhs(t) u_t = F(u,t)<br><br>where A_lhs is a linear operator. Is this true?<br><br>For now, I will assume that A_lhs(t) is actually a nonlinear operator O_lhs(u,u_t,t). Then<br>we have<br><br>  O_lhs(u,u_t,t) - F(u,t) = 0<br>
<br>So if we do Backward-Euler,<br><br>  O_lhs(u^n+1,t^n+1) - dt F(u^n+1,t^n+1) - O_lhs(u^n,t^n) = G = 0<br><br>so for Newton<br><br>  (O'_lhs - dt F') du = G<br><br>So are you asking for a nonlinear operator O?<br>
<br>After I understand the answers to these, I can start to understand the comments about<br>shifts, etc. that talk about implementing this new model.<br><br>I just want to clarify the movement away from the original TS model.<br>
<br>  Matt<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888"><br>
Jed<br>
</font></blockquote></div>-- <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>