Ed Bueler <[email protected]> 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.
signature.asc
Description: PGP signature
