[petsc-dev] Strange behaviour from TSARKIMEX

[Stefano Zampini]

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 at 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20161114/47a44d66/attachment.html>