[petsc-dev] Proposed changes to TS API

[Smith, Barry F.]

> On May 11, 2018, at 5:26 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
> 
>>> On May 11, 2018, at 5:09 PM, Jed Brown <jed at jedbrown.org> wrote:
>>> 
>>> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
>>> 
>>>>>> 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.
>>>>> 
>>>>> And completely impossible to compose. We should be explicitly talking about subsystems that use TS. For example,
>>>>> I have a nonlinear system for plasticity. I want to use a preconditioner that introduces some elasticity and timesteps to
>>>>> steady state to provide a good Newton direction. I need to to be able to create the solver without all sorts of digging
>>>>> in and setting things. This idea that you "just set SNESJacobian" is a non-starter.
>>>> 
>>>>  But this is exactly what TSComputeIJacobian currently does, so is the current interface a non-starter?
>>> 
>>> It isn't at all the current interface.  
>> 
>>   You misunderstand what I am saying. The current interface produces exactly the Jacobian needed for the SNES solve (nothing more and nothing less) as a single monolithic matrix. Matt says this is a non-starter.
> 
> Matt says that having the user call TSGetSNES and SNESSetJacobian (my
> interpretation of Hong's "users could set up the SNESJacobian directly")
> to assemble that matrix is a non-starter.

   He said it in a very confusing way and brought in seemly irrelevant discussion about some pseudo time stepping inside the needed nonlinear solve.