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

[Barry Smith]

> On Feb 14, 2017, at 9: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.

  I'm all ears.