<div dir="ltr">Jed --<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-3705280918639162976gmail-im" style="font-size:12.8px">> Yup, this is the form I have,<br></span><span class="gmail-m_-3705280918639162976gmail-im" style="font-size:12.8px">> u_t - f(u) = g(u)</span><span class="gmail-m_-3705280918639162976gmail-im" style="font-size:12.8px"><br></span><span style="font-size:12.8px">Are these really separate terms? As I mentioned, a very common case is<br></span><span style="font-size:12.8px">to write</span><br style="font-size:12.8px"><span style="font-size:12.8px"> u_t - L u = f(u) - L u</span><br style="font-size:12.8px"><span style="font-size:12.8px">where L is some stiff part of the operator (linear or non). This is<br></span><span style="font-size:12.8px">common for stiff waves in fluid problems or stiff reaction terms in an<br></span><span style="font-size:12.8px">otherwise slower network, for example. In this case, the obvious thing<br></span><span style="font-size:12.8px">is for the user to provide their own run-time options for what to<br></span><span style="font-size:12.8px">evaluate in the IFunction versus RHSFunction. If everything goes in the<br></span><span style="font-size:12.8px">RHSFunction, then just evaluate f(u) rather than f(u) - L u + L u.</span></blockquote><div><br></div><div>Your question makes me think about why I am splitting the way I am. For sure *yes*, in my case they are separate terms and *no* I am not just subtracting Lu from both sides.</div><div><br></div><div>The ice sheet thickness problem (u(t,x,y) >= 0 is thickness) is like degenerate p-bratu, right? My form is like</div><div><br></div><div>u_t - div (u^k |grad u|^{p-2} grad u) = g(t,u)</div><div><br></div><div>where the right side is only the elevation-dependent surface mass balance in my context. The right-hand stuff is (potentially) coupling to other models which will be time-split, and provided by other codes, so the "ultimate" coupled model will inevitably be imex in some vague sense. The stiff stuff on the left should be handled implicitly both for imex and implicit, of course. And I want to see the solver robustness effects of my imex splitting of the problem. I also want to compare actual explicit runs despite their absurd short time step.</div><div><br></div><div>In any case, whatever my motivation, I am currently providing</div><div><br></div><div>RHSFunction = g(t,u)</div><div>IFunction = u_t - div (u^k |grad u|^{p-2} grad u)</div><div><br></div><div>Currently ARKIMEX, THETA, BDF all seem to work well, but explicit breaks. As I understand it, Barry's PR will "fix" this by erroring-out when I try to run it explicitly. This is fine until ya'll work out a better API.</div><div><br></div><div>> <span style="font-size:12.8px">What "fragile code"?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I mean I fear the prospect of a PETSc API which requires so conditionals determining which "side"' various terms appear on, depending on user code testing what method is running etc.. No such thing for now; my current code is not fragile. (Is an API based on "side" of an equation inherently suspect?)</span></div><div><span style="font-size:12.8px"><br></span></div><div>Ed</div><div><br></div><div><br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 14, 2017 at 10:41 AM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Ed Bueler <<a href="mailto:elbueler@alaska.edu">elbueler@alaska.edu</a>> writes:<br>
> Yup, this is the form I have,<br>
> u_t - f(u) = g(u)<br>
<br>
</span>Are these really separate terms? As I mentioned, a very common case is<br>
to write<br>
<br>
u_t - L u = f(u) - L u<br>
<br>
where L is some stiff part of the operator (linear or non). This is<br>
common for stiff waves in fluid problems or stiff reaction terms in an<br>
otherwise slower network, for example. In this case, the obvious thing<br>
is for the user to provide their own run-time options for what to<br>
evaluate in the IFunction versus RHSFunction. If everything goes in the<br>
RHSFunction, then just evaluate f(u) rather than f(u) - L u + L u.<br>
<br>
Obviously you could easily do this in your code, you just didn't. But<br>
it's clearly more powerful to offer your own options. Now my question<br>
is whether it's really more natural to implement f(u) and g(u)<br>
separately and have PETSc move the terms around. If that really saves<br>
you work or makes something more robust, then I'm not opposed to adding<br>
it.<br>
<br>
But while offering f(u), g(u) may save you a few lines of code today, it<br>
greatly increases the incremental complexity of doing more intrusive<br>
splitting. I'm concerned that we add this code to PETSc and then people<br>
don't think to use such splittings because there can't be a PETSc<br>
interface to do it. Or they waste a lot of communication and grid<br>
traversal overhead to evaluate a bunch of terms independently instead of<br>
together.<br>
<span class=""><br>
> and Barry is describing my situation with ice sheets. I am trying to<br>
> escape the stupidly-obvious small time step restriction of explicit ... but<br>
> only the full stack<br>
> (ARKIMEX_or_BDF+SNESVI+a_yet_<wbr>unknown_but_needs_to_be_good_<wbr>PC_combination)<br>
> has a chance of actually beating explicit performance-wise because of<br>
> extreme low regularity arising from constraint/free-boundary. To tell if<br>
> it is working I would really like to be able to switch from -ts_type rk to<br>
> -ts_type arkimex to -ts_type bdf without writing fragile code.<br>
<br>
</span>What "fragile code"?<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Ed Bueler<br>Dept of Math and Stat and Geophysical Institute<br>University of Alaska Fairbanks<br>Fairbanks, AK 99775-6660<br>301C Chapman and 410D Elvey<br>907 474-7693 and 907 474-7199 (fax 907 474-5394)</div>
</div>