[petsc-dev] Proposed changes to TS API

[Jed Brown]

"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.