On Sat, May 9, 2009 at 1:09 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > After looking at the code I see why it ended up being so complicated. It > needs some thought. > The way the line search works is > > 1) if the full step satisfies the reduction criteria it returns > 2) if the full step is smaller (measured by the 2 norm) then stol it > returns (in other words if the full step satisfies the "small step" SNES > convergence criteria) > this catches the case when the full step is zero length (but also may > return with a bigger function norm than last time) This also returns with > the flag saying linesearch successful, > should it really say successful? My understanding was that this catches stagnation, so that a time step could be decreased or continuation parameter, etc. Thus I agree with Barry that this should say unsuccessful, like a divergence tolerance. > > 3) otherwise it fits the function to the quadratic or cubic function until > a) reduction criteria satisfied or > b) step length is too small as measured by this strange max_i p_i/x_i > "norm" using again stol this returns with a flag saying line search > unsuccessful c) or it has tried too many times (I think its 10) > > > > Now my first inclination was to change 3b to use a -snes_ls_minstep > <minstep> value instead of stol. Thus one could control the minimum step > size in the > line search without affecting the convergence tolerances. This may be a > correct fix. I like this. > > But what about 2a? Do I continue to use the stol here? Do I use the new > <minstep> value; I don't think so because that is used in 3a with a very > different norm so minstep has two meanings. Do I introduce a third > tolerance; yuck. Do I just check if it is exactly zero only? You do not need to check for zero step since the sufficient reduction criterion will rule this out. I think this also ought to rule out checking stol. If sufficient reduction is achieved, I could care less about how small the step is. > > My inclination is to have a check for exactly zero only and then let 3b > determine if it should return immediately (because the line search length is > too small). If we totally remove 2 (and the step is zero) then 3b will > return immediately BUT it will return with a flag saying linesearch failed > (while 2 currently says success). I think failure is fine. Matt > > Thoughts anyone? > > Barry > > > On May 8, 2009, at 6:34 PM, Eric Meier wrote: > > Hi, >> >> In the line search routines within SNES, I think there is some confusion >> about the option -snes_stol <stol>. >> >> On this page >> >> http://www.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/docs/manualpages/SNES/SNESSetTolerances.html >> stol is defined one way. But on this page >> >> http://www.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/docs/manualpages/SNES/SNESLineSearchQuadratic.html >> it is defined another way. >> >> When I look in the PETSc code (ls.c), it seems to me that PETSc uses the >> option set with -snes_stol as the minimum step size in the line search >> routines (quadratic and cubic). But, it seems to use that same tolerance in >> the sense that >> >> stol >> - convergence tolerance in terms of the norm of the change in the solution >> between steps >> >> Therefore, I don't see how to control the minimum step size in the line >> search routines without affecting the convergence tolerances. >> >> Eric >> > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090509/bd0ee26b/attachment.html>