Choosing an optimization method is part of your methodology: you are not only picking a solver, but also justifying why it is appropriate for your model, your data, and your thesis goals.
There is no universally best optimizer (the “no free lunch” theorem): performance depends on problem structure and on what you count as success (Wolpert & Macready, 1997). So start by characterizing your problem, then pick the simplest method that can plausibly meet your requirements.
Start with Problem Structure (Not with Algorithms)
Write down the properties that drive method choice:
- Decision variables: continuous, integer/binary, or mixed?
- Objective and constraints: linear, nonlinear, convex, nonconvex?
- Derivatives: are gradients available/meaningful, or is this a black-box evaluation?
- Uncertainty: deterministic, stochastic/scenario-based, robust?
- Scale: number of variables/constraints, sparsity, and how often you need to solve it (once vs repeatedly).
If your problem is convex1, you will often spend more effort on formulation than on solving: once a problem is formulated as a convex optimization problem, it is relatively straightforward to solve compared to general nonlinear optimization (Boyd & Vandenberghe, 2004).
1 Here, convex typically means a convex objective and a convex feasible region (e.g., linear or convex inequality constraints).
Prefer Guarantees When You Can (Exact vs Approximate)
Many logistics theses end up with mixed-integer models. In that setting, the most important early decision is whether you aim for:
- Exact methods (e.g., MIP solvers): you get an incumbent solution and an optimality gap, but runtime can explode with problem size.
- Approximate methods (heuristics/metaheuristics): you trade guarantees for scalability, and you must compensate with careful benchmarking and sensitivity analysis.
In that setting, reporting gaps, bounds, and scalability limitations is normal (and expected) in a thesis.
Match the Method to the Information You Actually Have
Optimization methods differ in what they assume you can compute:
- Gradient-based methods are efficient when objectives/constraints are smooth and gradients are available (or can be computed reliably).
- Derivative-free methods become relevant when evaluations are expensive, noisy, or only available via simulation.
If you use nonlinear optimization, be explicit about differentiability assumptions, initialization, and convergence criteria. In local optimization, the starting point and algorithm settings can strongly affect the solution you end up with (Boyd & Vandenberghe, 2004).
The Metaheuristic Sea (Avoiding Bogus Novelty)
Once you leave exact optimization, you enter a sea of named metaheuristics: SA2, TS3, VNS4, ILS5, GRASP6, GA7, PSO8, ACO9, and hundreds of newer “nature-inspired” variants. You cannot test them all, and you do not need to.
2 SA = Simulated Annealing.
3 TS = Tabu Search.
4 VNS = Variable Neighborhood Search.
5 ILS = Iterated Local Search.
6 GRASP = Greedy Randomized Adaptive Search Procedure.
7 GA = Genetic Algorithm.
8 PSO = Particle Swarm Optimization.
9 ACO = Ant Colony Optimization.
One risk: choosing based on a metaphor (“this algorithm is inspired by X”) instead of the actual search mechanics. Sørensen argues that a wave of “novel” metaphor-based metaheuristics often changes the story more than the method (Sørensen, 2013). In a thesis, you do not want to rely on novelty-by-metaphor.
Good Practice: How to Justify Choosing a Metaheuristic
Use this as a defensible selection logic when time is limited:
- Start from representation + move operators (your neighborhood / construction steps). The metaheuristic is a wrapper around these. If the operators are weak, a fancy wrapper will not save you.
- Pick the simplest wrapper that fits your needs:
- Need controlled worsening moves to escape local minima, especially with noise/penalties? SA is easy to justify.
- Need explicit memory to avoid cycles or to intensify around good regions? TS is natural.
- Have multiple meaningful neighborhoods (small tweaks + larger shakes)? VNS is natural.
- Anchor in the literature for your problem class: show that your shortlist appears in recent/high-quality work on similar problems (this is your “not arbitrary” argument).
- Commit to a fair comparison: same instance set, same time budget, same stopping rule, and transparent parameter tuning. Publish parameters, and report variability across runs.
If You Want a Method: Algorithm Selection + Racing
There is a research area for making this systematic: the algorithm selection problem (Rice, 1975). A thesis-friendly version looks like this:
- Create a small portfolio (e.g., 2-4 candidates: SA/TS/VNS/ILS) using the same solution representation and neighborhood(s).
- Define a representative training set of instances and a clear performance measure (objective, constraint violations, runtime, robustness).
- Use a racing/configuration tool to allocate compute efficiently and tune fairly (e.g., iterated racing with
irace) (López-Ibáñez, Dubois-Lacoste, Pérez Cáceres, Birattari, & Stützle, 2016). - Freeze the best configuration and validate on a held-out test set (no more tuning).
This gives you a transparent justification: you chose from a principled shortlist, tuned comparably, and selected based on evidence rather than taste.
Writing It Up (So the Choice Doesn’t Look Arbitrary)
In your thesis, you want the reader to understand your choice even if they would have chosen differently. A simple structure that works:
- State the structure: what kind of problem is this (variables, constraints, convexity/nonconvexity, uncertainty, scale)?
- Explain the shortlist: which 2-4 approaches were realistic candidates, and why?
- Justify the final pick: what requirement does it satisfy (guarantees, scalability, interpretability, integration with data/simulation)?
- Commit to an evaluation plan: what baselines will you use and what counts as a win?
For benchmarking leagues (company baseline vs SOTA/BKS), experimental protocol, and how to write up negative results, see Benchmarking Optimization Methods. For terminology, see Method vs. Methodology. For framing baselines and evaluation logic, see Research Design and Scope and Limitations.