Emil,

thanks for the explanations. I’ve added TSSetEquationType(ts,TS_EQ_IMPLICIT) and things actually got worse with arkimex.
Adding -ts_arkimex_fully_implicit still gives the same inconsistency.

Running with -m_lhs -snes_monitor -ts_type arkimex -ts_arkimex_type 5, it reports for the first three TSSteps

0 TS dt 0.01 time 0.
    0 SNES Function norm 2.881332954700e-01 
    1 SNES Function norm 5.764785317497e-16 
    0 SNES Function norm 2.656435502730e-01 
    1 SNES Function norm 1.351993391899e-15 
    0 SNES Function norm 2.748681648224e-01 
    1 SNES Function norm 9.153705366186e-16 
    0 SNES Function norm 2.654405587243e-01 
    1 SNES Function norm 2.165715847788e-15 
    0 SNES Function norm 1.327202793622e-01 
    1 SNES Function norm 1.851465123731e-15 
    0 SNES Function norm 3.703291910243e-02 
    1 SNES Function norm 1.946066132445e-15 
    0 SNES Function norm 2.917498324433e-01 
    1 SNES Function norm 1.680056316341e-15 
    0 SNES Function norm 1.972362337024e-01 
    1 SNES Function norm 1.055632173875e-15 
    0 SNES Function norm 4.087125686933e-02 
    1 SNES Function norm 2.555645968009e-15 
    0 SNES Function norm 3.547915829559e-01 
    1 SNES Function norm 2.103175616151e-15 
2 TS dt 0.01 time 0.02
    0 SNES Function norm 1.965807268111e-15 
    1 SNES Function norm 0.000000000000e+00 
    0 SNES Function norm 1.597532788386e-19 
    1 SNES Function norm 0.000000000000e+00 
    0 SNES Function norm 1.965807242146e-15 
    1 SNES Function norm 0.000000000000e+00 
    0 SNES Function norm 3.815060728816e-15 
    1 SNES Function norm 7.476292242926e-16 
    0 SNES Function norm 1.837692463276e-15 
    1 SNES Function norm 0.000000000000e+00 
    0 SNES Function norm 0.000000000000e+00 
    0 SNES Function norm 1.965807300567e-15 
    1 SNES Function norm 0.000000000000e+00 
3 TS dt 0.01 time 0.03
    0 SNES Function norm 0.000000000000e+00 
    0 SNES Function norm 0.000000000000e+00 
    0 SNES Function norm 0.000000000000e+00 
    0 SNES Function norm 0.000000000000e+00 
    0 SNES Function norm 0.000000000000e+00 
    0 SNES Function norm 0.000000000000e+00 
    0 SNES Function norm 0.000000000000e+00 

Then, all the other SNES function norms are zero.



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

Stefano, thanks for your note. The consistent splittings currently supported under ts_type arkimex are give in Table 11 in the manual: http://www.mcs.anl.gov/petsc/petsc-current/docs/manual.pdf

Your case a) is not treated as you wrote it down. The reasoning behind the use cases is that M will have to be inverted directly or indirectly if you put it in F(...) because it's in implicit ODE. In your case b) you handle that directly; however, in case a) the M in F(...) is ignored in some steps leading to inconsistent formulations. That being said, there are ways of solving it as in case a) if M is full rank: some hints are in the caption in Table 11, but I can expand.

Also in Table 11, there is a note about instructing TS that the user is specifying an implicit ODE (M*ydot....): " set TSSetEquationType() to TS_EQ_IMPLICIT or higher". That sould solve the -ts_arkimex_fully_implicit inconsistency issue.

Emil


On 11/14/16 4:09 AM, Stefano Zampini wrote:
I came across this thing recently, and I couldn't figure out where the
issue could be.

The problem I'm solving is a simple DG advection, the ode is M*udot =
K*u+b, M is diagonal.

Attached is a MWE that reproduces the problem.

The problem is formed in two different cases depending on the command
line option -m_lhs

a) -m_lhs 1 : F(u,udot,t) = M*udot, G(u,t) = K*u+b
b) -m_lhs 0 : F(u,udot,t) = udot, G(u,t) = M^-1(K*u+b)

Using option b) and RK4, the solution is ok.
If run with any implicit TS method except arkimex, no matter if I'm
choosing option a) or b), the solution is always very close (say, final
error < 0.05) to the expected one (computed with BDF).

When using ARKIMEX, case b) gives a good solution, but not case a). In
fact, the solution does not seem to be advected at all in this case.

I was wondering if I'm doing something wrong or there's a bug in the
ARKIMEX implementation.

I also noticed that, using  -ts_arkimex_fully_implicit does not produce
the same output for case a) and b). Shouldn't they produce the same
method with this option?

Thanks,
--
Stefano
<1_Warning.txt>