<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 11, 2018 at 4:36 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">"Zhang, Hong" <<a href="mailto:hongzhang@anl.gov">hongzhang@anl.gov</a>> writes:<br>
<br>
> We are not forcing users to do two matrix assemblies per time<br>
> step. For most cases, there is even no need to update dF/dUdot at<br>
> all. For extreme cases that the application requires frequent update<br>
> on dF/dUdot and assembly is expensive, one can always assemble the<br>
> single-matrix Jacobian and throw it to SNES directly.<br>
<br>
</span>For the vast majority of cases, the mass matrix terms are inexpensive<br>
and can be summed during each assembly at negligible cost (cheaper than<br>
accessing those terms from an already-assembled matrix).<br>
<span class=""><br>
><br>
> TS used to be an unusable pile of crap until Jed proposed the marvelous<br>
> IJacobian interface. Suddenly COMPLEX fully-implicit DAE problems become<br>
> SIMPLE to express, and a single IFunction/IJacobian pair reusable for<br>
> different timestepper implementations a reality. And we got an added<br>
> bounus: this was efficient, it involved a SINGLE global matrix assembly. If<br>
> the issue is in supporting simpler problems, then we should go for an<br>
> alternative interface with broken Jacobians, just as Stefano propossed in a<br>
> previous email. I'm totally in favor of an additional broken Jacobians API,<br>
> and totally againt the removal of the single-matrix IJacobian interface.<br>
><br>
> The current IJacobian is essentially SNESJacobian. And the single-matrix SNESJacobian interface is always there. Power users could set up the SNESJacobian directly if we pass a read-only shift parameter to them. So we are by no means prohibiting power users from doing what they want.<br>
<br>
</span>You mean the user would call TSGetSNES and SNESSetJacobian, then<br>
internally call TSGetIJacobianShift and some new function to create<br>
Udot?  That sounds way messier and error-prone.</blockquote><div><br></div><div>And completely impossible to compose. We should be explicitly talking about subsystems that use TS. For example,</div><div>I have a nonlinear system for plasticity. I want to use a preconditioner that introduces some elasticity and timesteps to</div><div>steady state to provide a good Newton direction. I need to to be able to create the solver without all sorts of digging</div><div>in and setting things. This idea that you "just set SNESJacobian" is a non-starter.</div><div><br></div><div>  Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> IJacobian with shift mixes TS Jacobian and SNES Jacobian. This is the issue we need to fix.<br>
<br>
</span>It is just one interface producing exactly the matrix that the solver<br>
needs.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>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</div><div><br></div><div><a href="http://www.caam.rice.edu/~mk51/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div>
</div></div>