[petsc-dev] changing matrices

[Munson, Todd]

>  If you did this for the TAO user API then one could argue it should be done for TS also.  But I don't think it should be done for TS.
> 
>   Two reasons for not having a separate API for linear and nonlinear problems is

> 1) I may want to use a "nonlinear" ODE integrator (that is an integrator that works for nonlinear problems also) on my linear problem and I shouldn't need to have ifs if my code to switch to use it.  That is I don't want ugly code like
> 
>   if (using nonlinear integrator) {
>      TSSetIJacobian(..) 
>   } else {
>       TSSetConstantMatrix(...)
>   }
>   Now I could also have my "nonlinear integrators" support the TSSetConstantMatrix() API but that leads to more complex implementations that are more work to maintain. Why not just have something like
>      TSSetIJacobian(ts, J,TSConstantJacobianFunction()) when you are doing a linear ODE? 
> 
> 2) I may spend 3 months writing my linear ODE problem using the linear interface and then realize I have to add a nonlinear term, now I have to change my app use the nonlinear interface of TS. This is why Matt argues we should just publicly support the SNES api even for linear problems.

I was not planning on changing the API for TAO, just reorganizing the solvers and 
adding the type of problem solved to the name of the methods.

My problem is when a user, for example, passes a nonlinear ODE to a linear ODE solver.  
What you would like is for the linear solver to barf with an appropriate message 
when given a nonlinear problem.  I cannot tell which ODE solvers are for linear 
versus nonlinear problems from the existing names.  

Note: TAO has the same issues.  If a user gives a nonlinear problem to BQPIP, for 
example, then BQPIP will go off and solve the wrong problem.  (It will solve the
quadratic problem for the second-order Taylor series approximation of the
objective function around the starting point.)  Then we have to deal with 
"smart" users complaining we did not solve their real problem or 
"not smart" users reporting incorrect results.

I also understand the point of the reverse with getting the matrices from the
user only once when the user really has a linear problem and write their 
Jacobian routine is written to only fill the matrix on the first call.

>   Before doing anything let's try to generate a table that includes all (most of?)  the cases.

All the cases will be too long.  I will provide a table today with the more
relevant cases for PETSc/TAO.

Todd.