[petsc-dev] add TSGetIJacobian()

[Jed Brown]

On Fri, 19 Mar 2010 12:12:52 -0200, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> On 19 March 2010 09:34, Jed Brown <jed at 59a2.org> wrote:
> > On Thu, 18 Mar 2010 16:23:15 -0300, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> >> Jed, could you add a TSGetIJacobian(ts, &A, &B, &f, &ctx) call in
> >> petsc-release-31?
> >
> > I can do this, but what should the behavior be if the user has not set
> > an IJacobian (e.g. they are using RHSJacobian)?  Currently everything
> > that uses IJacobian works transparently when the RHS form is used
> > instead of the Implicit form.
> 
> Well, it has a side efect on Alhs if it is already set.

Could you elaborate?

> >  I'm hesitant to have a "dumb" accessor
> > because this is likely to be surprising when TSGetIJacobian returns NULL
> > even though TSComputeIJacobian will work fine (because the user employed
> > the RHS interface).  Perhaps the right thing is to return a new function
> > that evaluates the implicit Jacobian (basically the body of the else in
> > TSComputeIJacobian), but I think this could also be surprising.
> >
> 
> I'm actually interested in the matrices.
> 
> > Note that if all you want are the matrices, then TSGetRHSJacobian will
> > give them to you (not that this is good either, but with the current
> > design, the caller kind of has to know which interface (nonlinear versus
> > linear variants) is being used).
> >
> 
> I'm confused. TSGetRHSJacobian returns (ts->Arhs,ts->B), but
> TSSetIJacobian sets(ts->A,ts->B) ...

You're right, I've pushed the TSGetIJacobian.

> 
> > Do you have opinions about this?  I'm not wild about a function that
> > can't be used correctly without the caller having an unreasonable amount
> > of knowledge.
> 
> That's a very valid concern. But I need the matrices ! :-) ... and
> getting a NULL function pointer could be seen as a plus, as it could
> let you know what interface the TS is actually using ...
> 
> > Symmetry implies that TS also need getters for
> > RHSFunction, IFunction, pre- and post-steps, step adaptors, and
> > acceptance testers.
> >
> 
> I agree that having getters for EVERY user routine is not that useful,
> at least in C.