<div dir="ltr">Jed --<br><br>>> u_t - div (u^k |grad u|^{p-2} grad u) = g(t,u)<br>>Are you also interested in the case with sliding?<br><br>You must be getting grumpy. There is this 2009 paper about sliding ... Yes I am interested in sliding but I was trying to keep things simple for you. ;-)<div><br></div><div>The code in question is an under-development example in my book that I am trying to use to show off SNESVI functionality in an interesting case and yet not get too nasty. See the help string at the top of the file for what it actually does:<br><br><a href="https://github.com/bueler/p4pdes/blob/master/c/ch11/ice.c">https://github.com/bueler/p4pdes/blob/master/c/ch11/ice.c</a><br><br>In summary, the actual flux is<br><br>q_total = - Gamma H^{n+2} |grad s|^{n-1} grad s + V H<br><br>and it is all handled implicitly by preference, i.e. in the current API I have IFunction = u_t - div q_total.<div><br></div><div>The real interest of the problem is the failure of long-range communication of low-(spatial)-frequency information when you hit the free boundary, and these barriers can emerge anywhere in the domain. (In a mountain range you can have neighboring small glaciers completely out of phase; how should multigrid ... or any other preconditioning one would hope for ... work for all the glaciers in a mountain range? So now I'll emphasize what I said before: it is *degenerate* p-bratu. Doubly-degenerate because p>2, but the "H^{n+2}" aka "u^k" is the bad thing that makes the abrupt free boundary.) Sliding, in this regard, is the easy case, so I am throwing it in by generating an artificial velocity field; yes this is the coupling that should include the SSA in the future ... we already have an SSA solver or two that behave surprisingly well, you know, as long as the boundary conditions can be figured-out.</div><div><br></div><div>> <span style="font-size:12.8px">I would just have a PetscOptionsEList() for whether to evaluate the</span></div><span style="font-size:12.8px">> diffusive term on the left or right. Shouldn't be more than a few lines</span><br style="font-size:12.8px"><span style="font-size:12.8px">> of code.</span><div><br></div><div><span style="font-size:12.8px">So I have something like?:</span></div><div><span style="font-size:12.8px"> -ice_diffusive_side left,right</span></div><div><span style="font-size:12.8px"><br></span></div><div>O.k. What if user says</div><div> -ts_type rk -ice_diffusive_side left</div><div>Then I get the current brokenness: code runs and produces nonsense because RK does not call SNESVI (constraint never enforced) *and* diffusive stuff is never evaluated (because RK does not call IFunction).</div><div><br></div><div>So maybe then I also go through possible -ts_types and check whether the option combination made sense? Or move some terms to the correct side based on what that -ts_type should want? Do I include -ts_type sundials because somebody's config might include that third-party thing (even though mine doesn't)?</div><div><br></div><div>That's what I mean by fragile code.</div><div><br></div><div>Such things build up! Each time you shove cool stuff in my face I have to get used to seeing ugly stuff turn into beautiful stuff as my aesthetic sense follows my growing understanding. But it takes time (learning curve) and all the time it is fragile code (i.e. for me ... because I don't appreciate all the motivations behind that part of the API ...)</div><div><br></div><div>On the other hand ... I agree that if I am convinced this is really a good API for something I want, then indeed I will suck it up and learn it and write it.</div><div><br></div><div>Recall my original request was for the ability to know if the TS type I have chosen will actually use the SNES I have set ... so long ago it now seems.</div><div><br></div><div>Ed</div><div><br><div><span style="color:rgb(24,54,145);font-family:sfmono-regular,consolas,"liberation mono",menlo,courier,monospace;font-size:12px;white-space:pre"><br></span></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 14, 2017 at 6:56 PM, 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>
> Your question makes me think about why I am splitting the way I am. For<br>
> sure *yes*, in my case they are separate terms and *no* I am not just<br>
> subtracting Lu from both sides.<br>
><br>
> The ice sheet thickness problem (u(t,x,y) >= 0 is thickness) is like<br>
> degenerate p-bratu, right? My form is like<br>
><br>
> u_t - div (u^k |grad u|^{p-2} grad u) = g(t,u)<br>
<br>
</span>Are you also interested in the case with sliding?<br>
<span class=""><br>
> where the right side is only the elevation-dependent surface mass balance<br>
> in my context. The right-hand stuff is (potentially) coupling to other<br>
> models which will be time-split, and provided by other codes, so the<br>
> "ultimate" coupled model will inevitably be imex in some vague sense. The<br>
> stiff stuff on the left should be handled implicitly both for imex and<br>
> implicit, of course. And I want to see the solver robustness effects of my<br>
> imex splitting of the problem. I also want to compare actual explicit runs<br>
> despite their absurd short time step.<br>
><br>
> In any case, whatever my motivation, I am currently providing<br>
><br>
> RHSFunction = g(t,u)<br>
> IFunction = u_t - div (u^k |grad u|^{p-2} grad u)<br>
><br>
> Currently ARKIMEX, THETA, BDF all seem to work well, but explicit breaks.<br>
> As I understand it, Barry's PR will "fix" this by erroring-out when I try<br>
> to run it explicitly. This is fine until ya'll work out a better API.<br>
<br>
</span>I would just have a PetscOptionsEList() for whether to evaluate the<br>
diffusive term on the left or right. Shouldn't be more than a few lines<br>
of code.<br>
<br>
>> What "fragile code"?<br>
><br>
<span class="">> I mean I fear the prospect of a PETSc API which requires so conditionals<br>
> determining which "side"' various terms appear on, depending on user code<br>
> testing what method is running etc.. No such thing for now; my current<br>
> code is not fragile. (Is an API based on "side" of an equation inherently<br>
> suspect?)<br>
<br>
</span>I think it's a bit peculiar and would prefer a named basket of terms if<br>
Barry insists on adding this interface.<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>