[petsc-dev] perhaps where the custom adapativity perversity began

Lisandro Dalcin dalcinl at gmail.com
Sun Apr 30 04:50:56 CDT 2017

On 30 April 2017 at 07:08, Jed Brown <jed at jedbrown.org> wrote:
> The error estimation requires storage of extra vectors and the
> implementation was broken.  For whatever reason, Shri wanted TSTheta to
> use TSADAPTNONE by default and probably thought it would be better to
> have an explicit option than to overwrite it.  I don't see the point in
> litigating what was running through his head at the time.  But we see
> similar patterns frequently, where something doesn't really work and
> there are some hacks to make up for it.  The problem is that those hacks
> aren't removed even if the fundamental problem is fixed.

Well, I guess I'm partially responsible for it, because I "fixed" the
fundamental problem, but not really, see discussion below, that's the
reason I decided to keep the flag.

The current time adaptivity for THETA (and ALPHA) is not based in a
true, sound computation of the LTE, simply because for these low-order
methods we do not have a reliable way of estimating the LTE. What I
did was to estimate the LTE of the lowest-order method (i.e backward
Euler) by using a BDF formula which required keeping track of the
previous solution. But the error estimator is not even close to the
LTE of THETA or ALPHA (which are second order methods, thus LTE =
O(dt^3) ), it is an just an estimator for the backward Euler method (
LTE = O(dt^2) ), thus is gross, REALLY conservative estimate for the
higher order method. Of course, if you keep the backward Euler error
under control, then for sure the error of a second order order method
like THETA or ALPHA is lower (maybe a couple of orders of magnitud
lower?). Why I implemented such a dumb thing? Because I considered
that having something was better than nothing, and adaptivity for
THETA was totally broken.

Could this be improved? Well, I could use a higher-order BDF formula
keeping track of an extra past solution vector and estimate the LTE of
a BDF-2 method, which would be of equivalent order (up to a constant,
possibly large?) to the LTE of second-order methods like THETA and
ALPHA. But I'm not sure we really want this, unless there is a
reliable way to correlate the constants in front of LTEs for BDF-2 and
THETA/ALPHA. Otherwise, we will be accepting steps without being sure
the LTE is below the user-prescribed tolerance.

A second option would be to add a flag to THETA/ALPHA to optionally
compute the higher-order estimator BDF-2 rather than the lower-order
BDF-1. As explained above, I'm not sure defaulting to a BDF-2
estimator would be wise.

Lisandro Dalcin
Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)

4700 King Abdullah University of Science and Technology
al-Khawarizmi Bldg (Bldg 1), Office # 0109
Thuwal 23955-6900, Kingdom of Saudi Arabia

Office Phone: +966 12 808-0459

More information about the petsc-dev mailing list