[petsc-dev] Strange behaviour from TSARKIMEX

[Emil Constantinescu]

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