[petsc-users] Tao TRON solver tolerances

[Barry Smith]

> On Mar 15, 2016, at 10:31 PM, Justin Chang <jychang48 at gmail.com> wrote:
> 
> Thanks Barry. Yes, KSP solver computing an "update" to the solution makes sense. I also get that it's impossible to know whether this update is "enough of" a descent direction.
> 
> What I am wondering, however, is why TAO no longer has -tao_fatol or -tao_frtol options. 9 months ago, TAO had those options and that's what I used for my problems. Back then, when I used BLMVM, it took ~900 tao iterations and ~5000 seconds of wall-clock time for one of my problems. Today, when I run the exact same problem but with -tao_grtol, it now takes ~1900 iterations and ~1000 seconds. Same solution, but twice the amount of work. 
> 
> I am guessing this means that the gradient tolerance need not be as stringent as the objective functional tolerance. But do you guys know why it was removed in the first place?

   We considered them redundant and not a good measure of the actual quality of the solution. The problem with all of the convergence criteria is that they do not measure the error of your solution, they are only some "indirect" measure of the error, that is we measure something that we can measure and then "hope" that what we measure actually has something to do with the actual error.

   You should be able to use a lesser tolerance with the grtol then you currently use and yet still get as "quality" a solution as you previously got. I suggest "calibrating" what you should set for grtol by running "the old code" with fa or frtol and determining what you need to use for grtol to get a similar reduction and then use that "calibrated" grtol for future runs.

  Barry

> 
> Thanks,
> Justin
> 
> On Tue, Mar 15, 2016 at 9:54 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
> > On Mar 10, 2016, at 12:03 PM, Justin Chang <jychang48 at gmail.com> wrote:
> >
> > Hi again,
> >
> > I was reading through the TAO manual and the impression I am getting is that the KSP solver computes the gradient/projection, not necessarily the solution itself. Meaning it matters not how accurate this projection is, so long as the actual objective tolerance is met.
> 
>   Not sure what you mean by this.
> 
>   The KSP solver computes an "update" to the solution. So long as the update is "enough of" a descent direction then you will get convergence of the optimization problem.
> 
> >
> > Is this a correct assessment of why one can get away with a less stringent KSP tolerance and still attain an accurate solution?
> 
>   Of course knowing how accurate the KSP must be to insure the update is "enough of" a descent direction is impossible :-)
> 
>   Barry
> 
> >
> > Thanks,
> > Justin
> >
> > On Tuesday, March 8, 2016, Justin Chang <jychang48 at gmail.com> wrote:
> > Hi all,
> >
> > So I am solving a convex optimization problem of the following form:
> >
> > min 1/2 x^T*H*x - x^T*f
> > s.t. 0 < x < 1
> >
> > Using the TAOTRON solver, I also have CG/ILU for KSP/PC. The following TAO solver tolerances are used for my specific problem:
> >
> > -tao_gatol 1e-12
> > -tao_grtol 1e-7
> >
> > I noticed that the KSP tolerance truly defines the performance of this solver. Attached are three run cases with -ksp_rtol 1e-7, 1e-3, and 1e-1 with "-ksp_converged_reason -ksp_monitor_true_residual -tao_view -tao_converged_reason -log_view". It seems that the lower the KSP tolerance, the faster the time-to-solution where the number of KSP/TAO solve iterations remains roughly the same.
> >
> > So my question is, is this "normal"? That is, if using TRON, one may relax the KSP tolerances because the convergence of the solver is primarily due to the objective functional from TRON and not necessarily the KSP solve itself? Is there a general rule of thumb for this, because it would seem to me that for any TRON solve I do, i could just set a really low KSP rtol and still get roughly the same performance.
> >
> > Thanks,
> > Justin
> >
> 
>