I think > u_t = f(u) + g(u) where one wishes to switch from fully implicit to imex to fully explicit (with a likely small time-step constraint) is common enough that we should support it (we don't currently). The reason is that users may not know which form they should use and the easier we make it to try all forms the better it is for users. You, as an expert, might be able to say before hand based on the problem what specific form should be used but not everyone is an expert so it is better to make it painless to try everything without reorganizing your code. In the same way we try to support as many preconditioners etc without needed to change code and recompile.
Barry > On Feb 14, 2017, at 11:55 AM, Jed Brown <[email protected]> wrote: > > Barry Smith <[email protected]> writes: >> Hence my suggestion to have TSSetLeftHandSideFunction() (or Jed's >> suggestion to have multiple Right Hand side functions) this will allow >> comparison of implicit, explicit, imex without recompiling (which we don't >> have currently) for the case with no mass matrix. With a mass matrix, unless >> we use mass lumping and have a TSSetMassMatrix() you cannot switch to full >> explicit, but that is due to mathematics, not the interface. > > Who in reality has a problem that looks like > > u_t = f(u) + g(u) + h(u) > > where it may make sense to move some of this to the left (implicit)? > I'm concerned that this isn't natural for many applications so adding an > interface would be solving a problem that doesn't really exist outside > perhaps a few academic examples.
