Stefano,
Sorry, the equation type is needed for when the fully implicit option is
used.
I assume you are in the b) case, that would correspond to "mass &
stiff-nonstiff ODE" entry in Table 11 with f(t,y)=0. Have you tried the
forms suggested there, they are slightly different from what you
indicate in your original message for case b)? Also, please use
-ts_monitor and comment out the equation type.
In your case, you would either use the setup corresponding to "stiff ODE
w/ mass matrix" or "nonstiff ODE w/ mass matrix".
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.
Thanks,
Emil
On 11/14/16 11:45 AM, Stefano Zampini wrote:
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 <[email protected]
<mailto:[email protected]>> 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>
