[petsc-dev] Proposed changes to TS API
Jed Brown
jed at jedbrown.org
Fri May 11 17:09:37 CDT 2018
"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. If the user is calling
SNESSetJacobian, then we would need to open up the bowels of every
SNESTSFormJacobian_* and make stable public APIs out of those internals
(including the wiring for nonlinear multigrid). This sounds like a
terrible thing to make public.
More information about the petsc-dev
mailing list