Solver's stopping criteria and status

[abelsiqueira]

Started by @metelkin in https://github.com/JuliaSmoothOptimizers/DerivativeFreeSolvers.jl/pull/16/files#r606979001
Related to #19

Should apply to Krylov solvers?

Pinging @dpo, @amontoison @tmigot

What stopping criteria should we aim for:

• First-order conditions (:first_order) for all derivative-based solvers
• Derivative-free conditions (:acceptable). For instance, small mesh size. Should it be named differently?
• Maximum time (:max_time)
• Maximum number of evaluations (:max_eval). Should this be always f + c? sum_counters?
• Maximum number of iterations (:max_iter). Even though it's not comparable between solvers, it is something we usually keep.
• Objective stalled: |f_{k-1} - f_k| < fatol + frtol * f_0
• Solution stalled: ||x_{k-1} - x_k|| < xatol + xrtol * |x_0|
• User requested: When we define callbacks, some user condition based on the solver workflow variables.
• First-order for the infeasibility problem
• Provable infeasible
• Unbounded f
• Unbounded x
• Untreatable NaN or Inf
• Solver-specific, such as negative Pred. Suggestion: :subproblem_failure

[tmigot]

In Stopping.jl, we had a similar list and added:

• Unbounded_pb: also accounts for the solution x being unbounded.
• Domainerror: say there is a NaN or an Inf somewhere.
• SubProblemFailure: that generalizes the solver-specific.

Also, it might be worth having both infeasible and 1st order infeasible as I think this is two different things.

About the counters, couldn't we have a Dict containing max evaluation limit for each value in the counters and then have a function that compare both?

[abelsiqueira]

I've edited with a few changes.
About domain error, there are treatable NaN and Inf, such as when F(x) = f(x) + !feasible(S) * Inf. If you start feasible, then it's fine. But if your starting point is NaN of Inf, then is gone.

About the counters, is that something we're gonna use in practice?

[tmigot]

My point is that we could imagine an algorithm where depending on the problem we want to either:

• limit nb of obj and cons because it is a good measure of overall resources;
• or, limit the nb of hess and jac because it is the only limiting resource (for problems where computing obj and cons are very easy but hess and jac very hard).

[abelsiqueira]

Makes sense. We do need a good way to implement that.

[tmigot]

In Stopping.jl, I was:

• initializing a Dict containing max evaluation for each entry _init_max_counters
• Then, when checking the resources, it is just:

    for f in intersect(fieldnames(Counters), keys(max_cntrs))
      max = (getfield(cntrs, f) > max_cntrs[f])
    end

In my experience using this implementation, all the problems are reduced to the initialization of the max_counters.
If you think that's useful, I can start a PR in SolverCore.jl to discuss it more concretly.

[metelkin]

Sorry for an off top question, but is there an actual list of acceptable return codes with explanations? Cannot find it in the documentation.

[abelsiqueira]

It's the dict SolverCore.STATUSES, there is a function to print that, I think it is show_statuses.