Optimization Toolbox: Global optimization
← Optimization Toolbox overview · Solver guide · Modeling guide · Examples · Reference
Why global optimization is different
A local nonlinear solver answers a narrower question than a global-search method.
A successful local solve can establish that, under its algorithm and numerical tolerances, it cannot find a better nearby point. It does not establish that no better basin exists elsewhere in the feasible region.
Global optimization methods spend additional evaluations exploring the domain. For practical nonconvex problems, that can produce substantially better candidates, but many methods still cannot provide a mathematical certificate that the reported point is globally optimal.
The workbench therefore uses deliberately conservative language:
- local solve →
LOCAL_OPTIMUMwhen feasible; - global comparison →
BEST_FOUNDfor the best independently feasible candidate.
It never relabels a stochastic-search winner as GLOBAL_OPTIMUM merely because one algorithm terminated successfully.
Current global workflow
The beta’s global module is designed around bounded nonlinear objectives. Every variable must have finite lower and upper bounds.
For the included multimodal fixture, Recommended mode runs four approaches:
- Local SLSQP from the worksheet initial point.
- MultiStart using the worksheet initial point plus seeded uniformly sampled starts.
- Differential Evolution over the finite bounds.
- SHGO over the same finite bounds.
The candidates are normalized into a common comparison table and independently checked for feasibility. The best feasible natural-objective value becomes the reported result.
MultiStart
Purpose
MultiStart is useful when a smooth objective may have several basins of attraction and a local method is inexpensive enough to run repeatedly.
Beta implementation
The workbench:
- always includes the authored InitialValue vector;
- generates additional starts with NumPy’s seeded random generator;
- samples uniformly inside finite bounds where provided;
- falls back to a small interval around the initial value when local bounds are infinite in a local MultiStart context;
- runs the same local SLSQP solve from each start;
- filters feasible results;
- selects the best natural-objective value.
The global workflow currently uses seven starts. This is fixed in the beta rather than exposed as another workbook tuning parameter.
Interpretation
If several starts converge to the same objective and decision vector, confidence in that basin increases. It is still not a mathematical global certificate.
If starts produce materially different local optima, the workbook has surfaced evidence that initial conditions matter and a stronger global strategy may be warranted.
Differential Evolution
Differential Evolution is a population-based stochastic search method suitable for bounded domains.
Beta controls
- Random seed controls reproducibility.
- Global budget influences the number of generations permitted.
- Population size is fixed to a browser-conscious setting.
workers=1is explicit because the browser workbench does not rely on true multicore Python execution.- SciPy polishing is enabled, allowing a local refinement after the global population search.
What the budget means
The workbook’s Global budget is not passed as a literal one-to-one maximum-function-evaluation count for every global method. For Differential Evolution, the notebook derives a bounded number of iterations from budget, population size, and problem dimension.
Therefore compare runs by both objective and Evaluations rather than assuming equal budget values mean identical computational work across algorithms.
SHGO
SHGO—simplicial homology global optimization—is used as a deterministic bounded global method in the current fixture.
The beta supplies:
- finite variable bounds;
- a sampling count capped by the Global budget;
- one simplicial iteration.
SHGO provides a useful contrast with the stochastic Differential Evolution path because rerunning the same model does not depend on the random seed in the same way.
The current global fixture is unconstrained apart from variable bounds. Authors should not assume that every future nonlinear-constraint combination has been validated with every global backend merely because the local compiler supports nonlinear constraints.
Local/global comparison table
For a global model, Analysis publishes:
| Field | Meaning |
|---|---|
| Solver | Local/global method name |
| Status | Normalized workbench status |
| Objective | Natural objective value |
| Feasible | Independent feasibility result |
| Max violation | Largest modeled violation |
| Runtime (s) | Wall-clock solve time measured in the notebook |
| Evaluations | Solver-reported objective evaluation count where available |
| Seed | Worksheet seed for stochastic/repeated-start methods where applicable |
Use this table to ask:
- Did the global methods improve materially on the local result?
- Are all reported candidates actually feasible?
- Did stochastic and deterministic methods agree?
- Is improvement worth the extra evaluation cost?
Reproducibility
Reproduce a stochastic run
Keep all of these unchanged:
- model inputs;
- scenario;
- objective direction;
- variable bounds;
- random seed;
- global budget;
- runtime/library version.
The workbook records the seed in summary/comparison output where relevant.
Test robustness
To test search robustness rather than exact reproducibility, intentionally change the seed and compare the best objective and solution basin.
Repeated agreement across seeds is evidence, not proof, that a better basin may not be easy to find.
Finite bounds are part of the model
Global bounds should be economically, physically, or operationally defensible. Do not invent enormous bounds simply to satisfy the solver.
Poor global bounds can:
- waste evaluations on meaningless regions;
- magnify numerical scale problems;
- make a stochastic search appear unstable;
- hide that the true modeling question lacks a well-defined feasible domain.
If a variable truly has no meaningful finite global range, the current global module may not be the right tool.
Hybrid search
MathWorks documents hybrid global-search strategies where a global method hands a promising point to a second solver for local refinement.
The beta contains related ideas but does not expose a general hybrid-function framework:
- Differential Evolution uses SciPy’s polish step.
- MultiStart is explicitly repeated local optimization.
- The final global workflow compares local and global candidates under the same feasibility check.
A future richer workbench could make hybrid selection explicit and user-configurable after the use cases justify the added controls.
Global constraints
The common compiler supports linear and safe nonlinear constraints for local NLP solving, but the current Global strategy intentionally accepts only finite variable bounds. General linear or nonlinear constraints cause a validation error before Differential Evolution or SHGO is dispatched.
That boundary is deliberate: the beta is browser-validated for bounded unconstrained global objective search, not for arbitrary constrained global optimization. A constrained nonconvex model remains class NLP; solve and validate it with Local or MultiStart unless a future adapter explicitly adds and tests the required global constraint semantics.
This separation also keeps terminology precise: NLP is the mathematical problem class; Global is a solve strategy. A model does not become a different class merely because the operator asks for broader search.
Comparison with MATLAB Global Optimization Toolbox
MathWorks currently groups Global Optimization Toolbox around GlobalSearch/MultiStart, direct search, genetic algorithms, particle swarm, surrogate optimization, simulated annealing, and multiobjective global optimization.
The beta covers the domain selectively:
| MATLAB capability | Current Toolbox | Status / difference |
|---|---|---|
MultiStart |
Seeded repeated SLSQP starts | Available in core form; no user-defined start-point-set object or parallel mode |
GlobalSearch |
Multi-method bounded comparison | Capability overlap, not algorithm parity; no MATLAB scatter-search basin-rejection algorithm |
| Pattern search | None | Exploring |
Genetic algorithm (ga) |
None | Exploring; no MINLP claim |
Multiobjective GA (gamultiobj) |
Epsilon-constraint linear Pareto sweep | Different method / partial capability |
| Particle swarm | None | Exploring |
| Surrogate optimization | None | Planned for expensive black-box Excel models |
| Simulated annealing | None | Exploring |
| Pareto search | Linear epsilon-constraint frontier | Partial capability |
| Hybrid function framework | DE polish + repeated local solves | Partial concept, not general user-configurable parity |
| Custom start-point sets | Internally generated seeded starts | Not exposed |
| Parallel global solving | Single-worker browser execution | Not available |
| Output/plot functions | Published Analysis/Diagnostics tables and notebook plot | Different interaction model |
| Reproducibility controls | Worksheet random seed | Available |
This difference is intentional. The workbench should add algorithms when they improve an Excel decision workflow, not simply to make a solver-name checklist longer.
When to use global mode
Good candidates:
- bounded design variables;
- smooth but visibly multimodal objectives;
- a local solution changes significantly with starting point;
- objective evaluations are cheap enough for dozens/hundreds of browser calls;
- a better basin has material business value.
Poor candidates for the current beta:
- unbounded variables;
- very expensive simulations;
- high-dimensional black-box problems;
- mixed-integer nonlinear optimization;
- problems requiring parallel workers;
- cases where a formal global certificate is mandatory.
Practical review checklist
Before accepting BEST_FOUND:
- Confirm
Feasible = Yesand maximum violation is acceptable. - Compare against the local objective.
- Compare stochastic and deterministic global methods.
- Repeat with at least one alternate seed for important decisions.
- Check whether the decision vector changes materially even when objectives are similar.
- Validate bounds as business constraints, not arbitrary numerical fences.
- Record the seed and budget with the decision package.