> On May 11, 2018, at 5:09 PM, Jed Brown <j...@jedbrown.org> wrote: > > "Smith, Barry F." <bsm...@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. Barry > 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.
