Short answer: use NSGA-II for two or three objectives, NSGA-III (or RVEA) when you have four or more, and try MOPSO when you need fast early progress on smooth problems. If runs are cheap, benchmark two algorithms on your actual model — that beats any generic advice.
What makes NSGA-II the default choice?
NSGA-II combines non-dominated sorting (find the best trade-off ranks) with crowding distance (keep the front evenly spread) and elitism (never lose a good design). It is robust, parameter-light, and has two decades of published engineering applications behind it. Its main weakness appears above three objectives, where almost every design becomes non-dominated and selection pressure collapses.
When does NSGA-III win?
NSGA-III replaces crowding distance with a set of reference directions that pull the population toward an evenly distributed front — which is exactly what high-dimensional objective spaces need. Use it (or U-NSGA-III, which also handles 1–2 objectives gracefully) for four-plus objectives. Note that reference-direction methods need at least two objectives and their population size is tied to the number of directions.
Where does MOPSO fit?
Multi-Objective Particle Swarm Optimization flies a swarm through the design space, each particle steered by its own best find and the swarm’s. It often converges faster than genetic algorithms in early iterations on continuous, smooth problems — useful when each simulation is expensive and your budget is small. It can struggle on discontinuous or highly multi-modal landscapes, where genetic operators explore better.
What about SPEA2, MOEA/D, and the rest?
SPEA2 is a solid NSGA-II contemporary with a different diversity mechanism (worth trying when NSGA-II’s front looks clumpy). MOEA/D decomposes the problem into weighted sub-problems and excels when the front is regular in shape. AGE-MOEA and SMS-EMOA optimize the front’s hypervolume directly. This variety is the honest reason our tools — TRNSYS MO, EES MO, and COMSOL MO — ship all ten in one dropdown: switching algorithms costs one click, and the same model, bounds, and reports work for every one of them.
Rules of thumb that save wasted runs
- Population size: roughly 10× the number of design variables, minimum ~40 for two objectives
- Generations: expect useful fronts after 20–40 generations; convergence plots tell you when to stop
- Discrete variables (equipment counts, pipe diameters from a catalog) need an algorithm setup that respects integrality — flag them as discrete, don’t round afterward
- Parallelize evaluations before touching algorithm hyperparameters: 8 cores ≈ 8× more generations per night