<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>Sorry, the equation type is needed for when the fully implicit option is used.<br><br></div></blockquote><div><br></div><div>the output with -m_lhs -ts_type arkimex -ts_arkimex_type 5 -ts_arkimex_fully_implicit (case a) ) is different from -m_lhs 0 -ts_type arkimex -ts_arkimex_type 5 -ts_arkimex_fully_implicit (case b) )</div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">I assume you are in the b) case,</div></blockquote><div><br></div>No,  case a) mass matrix on the left-hand side</div><div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"> 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.<br><br></div></blockquote><div><br></div><div>I do have pasted the output for ts_monitor for the first three steps.</div><div><br></div><div>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)</div><div><br></div><div>Indeed, using what is listed in Table 11 for the case  "mass & stiff-nonstiff ODE", we have</div><div>ODE: M * ydot = g(t,y) + f(t,y), F = M * ydot - f(t,u), G = M^-1 * g(t,y)</div><div>Putting F and G in the form F(u,udot,t) = G(u,t), we will have the ODE M * ydot  =  f(t,u) + M^-1 * g(t,y)</div><div><br></div><div><br></div><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">In your case, you would either use the setup corresponding to "stiff ODE w/ mass matrix" or "nonstiff  ODE  w/  mass  matrix”.<br></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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.<br><br></div></blockquote><div><br></div><div><div>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.</div></div><div><br></div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Thanks,<br>Emil<br><br>On 11/14/16 11:45 AM, Stefano Zampini wrote:<br><blockquote type="cite">Emil,<br><br>thanks for the explanations. I’ve added<br>TSSetEquationType(ts,TS_EQ_IMPLICIT) and things actually got worse with<br>arkimex.<br>Adding -ts_arkimex_fully_implicit still gives the same inconsistency.<br><br>Running with -m_lhs -snes_monitor -ts_type arkimex -ts_arkimex_type 5,<br>it reports for the first three TSSteps<br><br>0 TS dt 0.01 time 0.<br>   0 SNES Function norm 2.881332954700e-01<br>   1 SNES Function norm 5.764785317497e-16<br>   0 SNES Function norm 2.656435502730e-01<br>   1 SNES Function norm 1.351993391899e-15<br>   0 SNES Function norm 2.748681648224e-01<br>   1 SNES Function norm 9.153705366186e-16<br>   0 SNES Function norm 2.654405587243e-01<br>   1 SNES Function norm 2.165715847788e-15<br>   0 SNES Function norm 1.327202793622e-01<br>   1 SNES Function norm 1.851465123731e-15<br>   0 SNES Function norm 3.703291910243e-02<br>   1 SNES Function norm 1.946066132445e-15<br>   0 SNES Function norm 2.917498324433e-01<br>   1 SNES Function norm 1.680056316341e-15<br>   0 SNES Function norm 1.972362337024e-01<br>   1 SNES Function norm 1.055632173875e-15<br>   0 SNES Function norm 4.087125686933e-02<br>   1 SNES Function norm 2.555645968009e-15<br>   0 SNES Function norm 3.547915829559e-01<br>   1 SNES Function norm 2.103175616151e-15<br>2 TS dt 0.01 time 0.02<br>   0 SNES Function norm 1.965807268111e-15<br>   1 SNES Function norm 0.000000000000e+00<br>   0 SNES Function norm 1.597532788386e-19<br>   1 SNES Function norm 0.000000000000e+00<br>   0 SNES Function norm 1.965807242146e-15<br>   1 SNES Function norm 0.000000000000e+00<br>   0 SNES Function norm 3.815060728816e-15<br>   1 SNES Function norm 7.476292242926e-16<br>   0 SNES Function norm 1.837692463276e-15<br>   1 SNES Function norm 0.000000000000e+00<br>   0 SNES Function norm 0.000000000000e+00<br>   0 SNES Function norm 1.965807300567e-15<br>   1 SNES Function norm 0.000000000000e+00<br>3 TS dt 0.01 time 0.03<br>   0 SNES Function norm 0.000000000000e+00<br>   0 SNES Function norm 0.000000000000e+00<br>   0 SNES Function norm 0.000000000000e+00<br>   0 SNES Function norm 0.000000000000e+00<br>   0 SNES Function norm 0.000000000000e+00<br>   0 SNES Function norm 0.000000000000e+00<br>   0 SNES Function norm 0.000000000000e+00<br><br>Then, all the other SNES function norms are zero.<br><br><br><br>On Nov 14, 2016, at 6:23 PM, Emil Constantinescu <<a href="mailto:emconsta@mcs.anl.gov">emconsta@mcs.anl.gov</a><br><<a href="mailto:emconsta@mcs.anl.gov">mailto:emconsta@mcs.anl.gov</a>>> wrote:<br><br><blockquote type="cite">Stefano, thanks for your note. The consistent splittings currently<br>supported under ts_type arkimex are give in Table 11 in the manual:<br><a href="http://www.mcs.anl.gov/petsc/petsc-current/docs/manual.pdf">http://www.mcs.anl.gov/petsc/petsc-current/docs/manual.pdf</a><br><br>Your case a) is not treated as you wrote it down. The reasoning behind<br>the use cases is that M will have to be inverted directly or<br>indirectly if you put it in F(...) because it's in implicit ODE. In<br>your case b) you handle that directly; however, in case a) the M in<br>F(...) is ignored in some steps leading to inconsistent formulations.<br>That being said, there are ways of solving it as in case a) if M is<br>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<br>is specifying an implicit ODE (M*ydot....): " set TSSetEquationType()<br>to TS_EQ_IMPLICIT or higher". That sould solve the<br>-ts_arkimex_fully_implicit inconsistency issue.<br><br>Emil<br><br><br>On 11/14/16 4:09 AM, Stefano Zampini wrote:<br><blockquote type="cite">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><1_Warning.txt></blockquote></blockquote></div></blockquote></div><br></body></html>