On 2/14/17 4:10 PM, Barry Smith wrote:
Ok, you don't recompile but forcing that into user code is still disgusting.
With my api the user code is
TSSetRHSFunction(ts,NULL,RHSFunction,&ptype[0]);
TSSetLHSFunction(ts,NULL,LHSFunction,&ptype[0]);
TSSetRHSJacobian(ts,Jac,Jac,RHSJacobian,&ptype[0]);
TSSetLHSJacobian(ts,Jac,Jac,LHSJacobian,&ptype[0]);
and -ts_type xxx works correctly for ALL methods, implicit, explicit and imex
without requiring any special command line options for different methods.
Is this a viable solution? Growing the API to fix this situation will
just put a burden with each new TS method after we refactor it in the
current landscape. If the user experiments with different ways of
splitting the solution they would have to define RHS and IF or RHS and
LHS in different ways (according to the splittings they experiment
with). It may look disgusting, but I don't see another way around it
unless you allow for a list of operators to be defined and then the user
to assign them to LHS or RHS.
Adding all that logic to keep track of left sides and right sides for academic
examples is likely not the best development.
I don't think it is "just academic examples", it is all examples without a
mass matrix.
Once the user has decided with ts_type to use for production if it is fully
implicit or explicit then they can depending on the type selected, write just a
left hand side, just a right hand side for higher efficiency (less update of
ghost points, fewer iterations over loops etc).
With a constant mass matrix we can have TSSetMassMatrix() and then
TSSetIFunction() is reserved for when it is absolutely needed.
As much as I would disagree with growing the API at the level of
defining the problem, I think TSSetMassMatrix() would let us do more
things in the solvers. Also it would be useful to know if the mass
matrix is singular or not for efficiency reasons.
Emil
Barry
