[petsc-dev] Proposed changes to TS API

[Smith, Barry F.]

> On May 11, 2018, at 3:36 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> "Zhang, Hong" <hongzhang at anl.gov> writes:
> 
>> We are not forcing users to do two matrix assemblies per time
>> step. For most cases, there is even no need to update dF/dUdot at
>> all. For extreme cases that the application requires frequent update
>> on dF/dUdot and assembly is expensive, one can always assemble the
>> single-matrix Jacobian and throw it to SNES directly.
> 
> For the vast majority of cases, the mass matrix terms are inexpensive
> and can be summed during each assembly at negligible cost (cheaper than
> accessing those terms from an already-assembled matrix).
> 
>> 
>> TS used to be an unusable pile of crap until Jed proposed the marvelous
>> IJacobian interface. Suddenly COMPLEX fully-implicit DAE problems become
>> SIMPLE to express, and a single IFunction/IJacobian pair reusable for
>> different timestepper implementations a reality. And we got an added
>> bounus: this was efficient, it involved a SINGLE global matrix assembly. If
>> the issue is in supporting simpler problems, then we should go for an
>> alternative interface with broken Jacobians, just as Stefano propossed in a
>> previous email. I'm totally in favor of an additional broken Jacobians API,
>> and totally againt the removal of the single-matrix IJacobian interface.
>> 
>> 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.
> 
> You mean the user would call TSGetSNES and SNESSetJacobian, then
> internally call TSGetIJacobianShift and some new function to create
> Udot?  That sounds way messier and error-prone.
> 
>> IJacobian with shift mixes TS Jacobian and SNES Jacobian. This is the issue we need to fix.
> 
> It is just one interface producing exactly the matrix that the solver
> needs.

    The implicit solver needs it, but the explicit solvers do not, nor do the adjoint computations. This is the issue.