> On Mar 10, 2016, at 12:03 PM, Justin Chang <[email protected]> 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 <[email protected]> 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 >
