[petsc-users] TS question 1: how to stop explicit methods because they do not use SNES(VI)?

[Emil Constantinescu]

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
>