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

Barry Smith bsmith at mcs.anl.gov
Tue Feb 14 12:53:56 CST 2017


   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 <jed at jedbrown.org> wrote:
> 
> Barry Smith <bsmith at mcs.anl.gov> 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.



More information about the petsc-users mailing list