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

[Ed Bueler]

Jed --

> Yup, this is the form I have,
> >    u_t - f(u) = g(u)
> Are these really separate terms?  As I mentioned, a very common case is
> to write
>   u_t - L u = f(u) - L u
> where L is some stiff part of the operator (linear or non).  This is
> common for stiff waves in fluid problems or stiff reaction terms in an
> otherwise slower network, for example.  In this case, the obvious thing
> is for the user to provide their own run-time options for what to
> evaluate in the IFunction versus RHSFunction.  If everything goes in the
> RHSFunction, then just evaluate f(u) rather than f(u) - L u + L u.


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)

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.

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

Ed




On Tue, Feb 14, 2017 at 10:41 AM, Jed Brown <jed at jedbrown.org> wrote:

> Ed Bueler <elbueler at alaska.edu> writes:
> > Yup, this is the form I have,
> >    u_t - f(u) = g(u)
>
> Are these really separate terms?  As I mentioned, a very common case is
> to write
>
>   u_t - L u = f(u) - L u
>
> where L is some stiff part of the operator (linear or non).  This is
> common for stiff waves in fluid problems or stiff reaction terms in an
> otherwise slower network, for example.  In this case, the obvious thing
> is for the user to provide their own run-time options for what to
> evaluate in the IFunction versus RHSFunction.  If everything goes in the
> RHSFunction, then just evaluate f(u) rather than f(u) - L u + L u.
>
> Obviously you could easily do this in your code, you just didn't.  But
> it's clearly more powerful to offer your own options.  Now my question
> is whether it's really more natural to implement f(u) and g(u)
> separately and have PETSc move the terms around.  If that really saves
> you work or makes something more robust, then I'm not opposed to adding
> it.
>
> But while offering f(u), g(u) may save you a few lines of code today, it
> greatly increases the incremental complexity of doing more intrusive
> splitting.  I'm concerned that we add this code to PETSc and then people
> don't think to use such splittings because there can't be a PETSc
> interface to do it.  Or they waste a lot of communication and grid
> traversal overhead to evaluate a bunch of terms independently instead of
> together.
>
> > and Barry is describing my situation with ice sheets.  I am trying to
> > escape the stupidly-obvious small time step restriction of explicit ...
> but
> > only the full stack
> > (ARKIMEX_or_BDF+SNESVI+a_yet_unknown_but_needs_to_be_good_
> PC_combination)
> > has a chance of actually beating explicit performance-wise because of
> > extreme low regularity arising from constraint/free-boundary.  To tell if
> > it is working I would really like to be able to switch from -ts_type rk
> to
> > -ts_type arkimex to -ts_type bdf without writing fragile code.
>
> What "fragile code"?
>



-- 
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/7806b19e/attachment-0001.html>