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

[Barry Smith]

> On Apr 30, 2017, at 4:50 AM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> 
> 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.
> 

   I don't completely understand what you are saying but here is may take: 

   TSAdapt is not just for "good" adaptors it is for all adaptors, so one should not introduce any constructs "on the side" of TSAdapt like -ts_theta_adapt ; If TSAdapt needs to be refactored to handle some other adaptors then that is where the action should be. To expect people to know about -ts_adapt   plus a bunch of -ts_theta/alpha/beta_adapt flags is not fair to users.



> 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)
> http://ecrc.kaust.edu.sa/
> 
> 4700 King Abdullah University of Science and Technology
> al-Khawarizmi Bldg (Bldg 1), Office # 0109
> Thuwal 23955-6900, Kingdom of Saudi Arabia
> http://www.kaust.edu.sa
> 
> Office Phone: +966 12 808-0459