[petsc-users] TS question 1: how to stop explicit methods because they do not use SNES(VI)?

[Ed Bueler]

Jed --

>> u_t - div (u^k |grad u|^{p-2} grad u) = g(t,u)
>Are you also interested in the case with sliding?

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.  ;-)

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:

https://github.com/bueler/p4pdes/blob/master/c/ch11/ice.c

In summary, the actual flux is

q_total = - Gamma H^{n+2} |grad s|^{n-1} grad s + V H

and it is all handled implicitly by preference, i.e. in the current API I
have IFunction = u_t - div q_total.

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.

> I would just have a PetscOptionsEList() for whether to evaluate the
> diffusive term on the left or right.  Shouldn't be more than a few lines
> of code.

So I have something like?:
  -ice_diffusive_side left,right

O.k.  What if user says
  -ts_type rk -ice_diffusive_side left
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).

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)?

That's what I mean by fragile code.

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 ...)

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.

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.

Ed



On Tue, Feb 14, 2017 at 6:56 PM, Jed Brown <jed at jedbrown.org> wrote:

> Ed Bueler <elbueler at alaska.edu> writes:
> > 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.
> >
> > The ice sheet thickness problem (u(t,x,y) >= 0 is thickness) is like
> > degenerate p-bratu, right?  My form is like
> >
> > u_t - div (u^k |grad u|^{p-2} grad u) = g(t,u)
>
> Are you also interested in the case with sliding?
>
> > 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.
> >
> > In any case, whatever my motivation, I am currently providing
> >
> > RHSFunction = g(t,u)
> > IFunction = u_t - div (u^k |grad u|^{p-2} grad u)
> >
> > 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.
>
> I would just have a PetscOptionsEList() for whether to evaluate the
> diffusive term on the left or right.  Shouldn't be more than a few lines
> of code.
>
> >> What "fragile code"?
> >
> > 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?)
>
> I think it's a bit peculiar and would prefer a named basket of terms if
> Barry insists on adding this interface.
>



-- 
Ed Bueler
Dept of Math and Stat and Geophysical Institute
University of Alaska Fairbanks
Fairbanks, AK 99775-6660
301C Chapman and 410D Elvey
907 474-7693 and 907 474-7199  (fax 907 474-5394)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20170214/4ff36502/attachment.html>