<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 14, 2016 at 9:23 AM, Emil Constantinescu <span dir="ltr"><<a href="mailto:emconsta@mcs.anl.gov" target="_blank">emconsta@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Stefano, thanks for your note. The consistent splittings currently supported under ts_type arkimex are give in Table 11 in the manual: <a href="http://www.mcs.anl.gov/petsc/petsc-current/docs/manual.pdf" rel="noreferrer" target="_blank">http://www.mcs.anl.gov/petsc/p<wbr>etsc-current/docs/manual.pdf</a><br>
<br>
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.<br>
<br>
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.</blockquote><div><br></div><div>I did not know any of this. It also has to go in the manual pages.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
Emil</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 11/14/16 4:09 AM, Stefano Zampini wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I came across this thing recently, and I couldn't figure out where the<br>
issue could be.<br>
<br>
The problem I'm solving is a simple DG advection, the ode is M*udot =<br>
K*u+b, M is diagonal.<br>
<br>
Attached is a MWE that reproduces the problem.<br>
<br>
The problem is formed in two different cases depending on the command<br>
line option -m_lhs<br>
<br>
a) -m_lhs 1 : F(u,udot,t) = M*udot, G(u,t) = K*u+b<br>
b) -m_lhs 0 : F(u,udot,t) = udot, G(u,t) = M^-1(K*u+b)<br>
<br>
Using option b) and RK4, the solution is ok.<br>
If run with any implicit TS method except arkimex, no matter if I'm<br>
choosing option a) or b), the solution is always very close (say, final<br>
error < 0.05) to the expected one (computed with BDF).<br>
<br>
When using ARKIMEX, case b) gives a good solution, but not case a). In<br>
fact, the solution does not seem to be advected at all in this case.<br>
<br>
I was wondering if I'm doing something wrong or there's a bug in the<br>
ARKIMEX implementation.<br>
<br>
I also noticed that, using  -ts_arkimex_fully_implicit does not produce<br>
the same output for case a) and b). Shouldn't they produce the same<br>
method with this option?<br>
<br>
Thanks,<br>
--<br>
Stefano<br>
</blockquote>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>