Checkers

Abstract Base Checker

class glompo.convergence.basechecker.BaseChecker

Abstract class from which all checkers must inherit to be compatible with GloMPO.

logger

logging.Logger instance into which status messages may be added.

Type:logging.Logger

__call__(manager: GloMPOManager) → bool

Evaluates if the checker condition is met.

Parameters:manager – GloMPOManager instance which is managing the optimization. Its attributes can be accessed when determining the convergence criteria. Returns:True if the convergence criteria is met, False otherwise. Return type:bool

Notes

For proper functionality, the result of this method must be saved to last_result before returning.

__iter__() → Iterable[glompo.common.corebase._CoreBase]

Provides a (flattened) iteration through all the bases which comprise the combined hunter/checker.

__str__() → str

Produces a string of the hunter/checker’s name and configuration.

last_result

The result of the last __call__().

reset()

Clears previous evaluation result to avoid misleading printing. Resets last_result to None. Given that hunters and checkers are evaluated lazily, it is possible for misleading results to be returned by str_with_result() indicating a hunt/check has been evaluated when it has not. Bases are thus reset before __call__() to prevent this.

str_with_result() → str

String representation of the object with its convergence result.

Combining Base Checkers

Instances of BaseChecker can be combined with & and | boolean operations. This allows individual checkers to be very simple, but be combined into more sophisticated conditions. Combining checkers in this way produces a new BaseChecker object which itself can be further combined. This allows conditions to be as deeply nested as one desires. For example:

>>> a = CheckerA()
>>> b = CheckerB()
>>> c = CheckerC()
>>> d = CheckerD()
>>> combi = a & b | c & d

The order of evaluation is & before |, thus the above would be equivalent to:

>>> combi = ((a & b) | (c & d))

Important

A combined BaseChecker is evaluated lazily. This means:

1. a & b will not evaluate b if a is False
2. a | b will not evaluate b if a is True

Lazy evaluation ensures a faster return, and explains the presence of None when a hunt evaluation statement is printed. For example:

>>> combi(...)
True
>>> from glompo.common.helpers import nested_string_formatting
>>> nested_string_formatting(combi.str_with_result())
'[
  CheckerA() = True &
  CheckerB() = True
 ] |
 [
  CheckerC() = None &
  CheckerD() = None
 ]'

Make sure to structure your nesting in the correct order. For example, if you want to make sure a certain checker is always evaluated, place it first. If a checker is slow to evaluate, place it last.

All of the above holds true for Hunters too as they share a common hidden base.

Included Checkers

For convenience, GloMPO comes bundled with several simple checkers already included.

class glompo.convergence.KillsAfterConvergence(n_killed: int = 0, n_converged: int = 1)

Bases: glompo.convergence.basechecker.BaseChecker

Evaluation based on the number of single optimizers converged and the number of optimizers killed thereafter. Returns True after n_killed optimizers have been stopped by GloMPO after n_converged optimizers have reached normal convergence.

class glompo.convergence.MaxFuncCalls(fmax: int)

Bases: glompo.convergence.basechecker.BaseChecker

Returns True after fmax function evaluations have been executed across all managed optimizers.

class glompo.convergence.MaxKills(kills_max: int)

Bases: glompo.convergence.basechecker.BaseChecker

Returns True after kills_max optimizers have been shutdown by the manager.

class glompo.convergence.MaxOptsStarted(omax: int)

Bases: glompo.convergence.basechecker.BaseChecker

Returns True after omax optimizers have been started.

class glompo.convergence.MaxSeconds(*, session_max: Optional[float] = None, overall_max: Optional[float] = None)

Bases: glompo.convergence.basechecker.BaseChecker

Time based convergence criteria. Differentiates between session time and overall optimisation time, the difference is only relevant in the case where checkpointing is being used.

Parameters:

• session_max – Maximum time in seconds which may elapse from the time GloMPOManager.start_manager() is called.
• overall_max – Maximum time in seconds which may elapse in total over all optimisation sessions. In other words the total time used previously is loaded from the checkpoint. In the case where checkpoint is not used, both quantities are equivalent.

Notes

For the avoidance of doubt, both times cannot be used simultaneously. If required rather initialise two instances with one condition each.

class glompo.convergence.NOptConverged(nconv: int)

Bases: glompo.convergence.basechecker.BaseChecker

Returns True when nconv optimizers have converged normally. ‘Normally’ here is defined as exiting the minimization loop according to the optimizer’s own internal convergence criteria, rather than any GloMPO intervention.

class glompo.convergence.TargetCost(target: float, atol: float = 1e-06)

Bases: glompo.convergence.basechecker.BaseChecker

Returns f_best <= target + atol, where f_best is the best value seen thus far by the manager.