[petsc-dev] Strange behaviour from TSARKIMEX

[Stefano Zampini]

Emil,

I have modifed the example code to also include the convection matrix in the lhs.

Plain arkimex with -ts_arkimex_fully_implicit false and M*udot - K*u in the lhs works well.

Trying to summarize the thread, it seems that we may have problems using arkimex with default parameters when F(u,udot,t) will just depend on udot and not on u.

If this is the case, is the user supposed to write G(t,u) as F_udot ^(-1) g(t,u)? So why not provide an API to allow it, instead to have the user modify the G function?

Also, wouldn’t be better to have standard SDIRK the default? i.e. -ts_arkimex_fully_implicit false?

Stefano

On Nov 14, 2016, at 11:11 PM, Emil Constantinescu <emconsta at mcs.anl.gov> wrote:

> 
> 
> On 11/14/16 1:17 PM, Stefano Zampini wrote:
> > I do have pasted the output for ts_monitor for the first three steps.
> 
> I meant -ts_adapt_monitor, I wanted to see what TS solvers are used: The first step is probably an Euler method, that's why you have 10 SNES solves in place of 7 for the later ones.
> 
> > The entry you are referring to in Table 11 actually breaks the TS
> > assumption that the ODE can be written F(u,udot,t) = G(u,t) (I was
> > thinking it was a typo)
> 
> It works for certain forms as listed in the table. I'm not aware of any RK method that handles this case with G(u,t) treated explicitly.
> 
>>> In your case, you would either use the setup corresponding to "stiff
>>> ODE w/ mass matrix" or "nonstiff  ODE  w/  mass  matrix”.
>> 
>> I’m not interested in solving this specific advection problem with
>> arkimex. I came across this problem when writing a general interface to
>> TS from a FEM library.
> 
> Normally, I do that by solving udot=M^-1 f(u) + M^-1 g(u)
> 
>>> It is difficult to create a decision tree for every way of writing the
>>> splittings. Do you find Table 11 not clear about what splitting to
>>> use? I would welcome any kind of feedback for improving it.
>>> 
>> 
>> If the entry in Table 11 is correct, please add a comment on the manual
>> stating that ARKIMEX does not fully support the F(u,udot,t) = G(u,t)
>> interface.
> 
> I see how the first statement in the caption can be confusing; The last statement in the caption states:
> "General cases such as F(t;y;y')=G(t;y) are not amenable to IMEX Runge-Kutta, but can be solved by using fully implicit methods." A line in the table may be more clear. I'll go for that.
> 
> Emil