[petsc-dev] Proposed changes to TS API

[Jed Brown]

"Smith, Barry F." <bsmith at mcs.anl.gov> writes:

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

Hmm, but the time stepping uses the same matrix.  The mass matrix alone
is only used in the initial and final conditions for the adjoint system
(i.e., not performance sensitive).  What am I missing?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: implict-ode.png
Type: image/png
Size: 46051 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180511/17976606/attachment-0001.png>