pagmo2: the C++ core behind parallel optimisation runs

A library, not a solver you can run directly

pagmo2 is described as a C++ platform for performing parallel computations of optimisation tasks, both global and local, through the asynchronous generalized island model. The repository makes clear that this is infrastructure rather than an application. There is no CLI entry point in the top-level listing, and the tree is the usual shape of a C++ library: `include/`, `src/`, `tests/`, `benchmarks/`, `tools/`, `tutorials/`, `doc/` and `cmake_modules/`, with `CMakeLists.txt`, `pagmo-config.cmake.in` and `config.hpp.in` handling the build. The audience is a developer who already has a problem to solve and wants a library that will not dictate the algorithm or the parallelism strategy. The project positions itself as a unified interface to optimisation algorithms and to optimisation problems, with the explicit goal of making deployment in massively parallel environments easy.

The island model is the parallelism contract

The asynchronous generalized island model is the mechanism the whole project is named after conceptually, and it is stated plainly in the repository description. Rather than running one optimizer against one population and scaling it up, the model imagines a set of independent islands, each running its own algorithm and its own population, with migration between them. The asynchronous qualifier is the interesting part for engineers: islands evolve on their own schedule and exchange individuals when they make contact, so the slowest island does not hold up the rest. The library therefore needs to express both local optimization, a single island solving a single problem, and global optimization, many islands cooperating on one problem. Repository topics back this up with tags such as evolutionary-algorithms, evolutionary-strategy, genetic-algorithm, metaheuristics, multi-objective-optimization, stochastic-optimizers and parallel-computing. The README does not document the migration rate, the island topology or the scheduling policy, so those specifics have to be read from the documentation site or the source.

A unified interface over algorithms and problems

The core design idea is that two things meet at a single interface: the optimisation algorithms and the optimisation problems. An algorithm knows nothing about the domain, and a problem definition knows nothing about the search strategy. That separation is what makes the island model practical, since a problem implemented once can be handed to any algorithm, and any algorithm can be dropped into any problem, including multi-objective ones. The topic list spans both global strategies such as genetic algorithms and evolutionary strategies, and metaheuristics generally, which tells you the library is not specialised in evolutionary computation alone even though that is where its lineage sits. For a team, this means the cost of trying a new optimiser is the cost of implementing one interface rather than rewriting a driver, and the cost of adding a new problem is defining a fitness and its constraints rather than writing a search loop.

Building from source with CMake

The README does not give a copy and paste installation recipe, so the build path has to be read from the tree itself. `CMakeLists.txt` is the entry point, `cmake_modules/` holds the helper modules, and `pagmo-config.cmake.in` plus `config.hpp.in` are templates that get filled in during configuration, which is the usual pattern for a library that exports both a CMake package config and a generated header. `include/` and `src/` split the public headers from the implementation, `tests/` holds the test suite, and `benchmarks/` and `tools/` are separated so performance work does not sit in the library path. The `.clang-format` and `.clangd` files at the root tell you the project expects clang tooling for consistent formatting, and `tox.ini` is absent from the listing, so the test entry point is CMake driven rather than Python driven. The `pagmo2_devel.yml` file at the root is a conda environment description for development, which is the most direct hint about how a contributor is expected to set up a working environment.

Getting the library: conda-forge and the documentation site

Two distribution paths are visible. First, the README carries a conda-forge badge pointing at a package named `pagmo`, which means a prebuilt binary is published on that channel rather than everyone compiling from scratch. Second, the full documentation is hosted at `esa.github.io/pagmo2/`, and the README describes a large set of tutorials there that it asks readers to skim. The tutorial-heavy documentation matters more than usual for this project because of the version break described below. There is also a separate conda development environment file in the repository root for contributors who need the source tree, plus a Zenodo DOI for the latest version of the software and a Journal of Open Source Software paper with a BibTeX entry, which is the citation the README asks research users to include:

@article{Biscani2020,
  doi = {10.21105/joss.02338},
  url = {https://doi.org/10.21105/joss.02338},
  year = {2020},
  publisher = {The Open Journal},
  volume = {5},
  number = {53},
  pages = {2338},
  author = {Francesco Biscani and Dario Izzo},
  title = {A parallel global multiobjective framework for optimization: pagmo},
  journal = {Journal of Open Source Software}
}

The DOI, the conda-forge package and the documentation site are the three practical entry points.

GPL by default, with an LGPL copy alongside

The licence field on the repository says GPL-3.0, and the root contains `COPYING.gpl3` next to `COPYING.lgpl3`. Two licence texts in one tree usually mean the project keeps both a copy of the GPL and a copy of the LGPL ready, which is consistent with a library that can be consumed under different terms depending on how it is linked. That is an observation about the file layout, not a legal opinion, and anyone with a real distribution question needs to read both files and the build configuration themselves. The practical point for reviewers is that this is not a permissively licensed library by default, so the licence has to be cleared before pagmo2 enters a commercial product. The `pagmo-config.cmake.in` template is the place where such a choice would likely be expressed at build time, since the generated configuration is what downstream projects consume.

Version 2 is an entirely different codebase

The migration story is unusually stark. The README has a dedicated section, Upgrading from pagmo 1.x.x, that points to a wiki page named From 1.x to 2.x for the technical data on why a completely new API and code was developed, and it states plainly that the new pagmo, version 2, should be considered, and is, an entirely different code. It suggests skimming the tutorials in the documentation to realise the differences. For anyone with 1.x code, that is a rewrite rather than an upgrade, and the wiki page is the only public accounting of the changes. Release history reflects a steady but slow cadence: v2.19.0 in January 2023, v2.19.1 in August 2024, and v2.20.0 on 2026-09-25. The last push was on 2026-09-29, days after that release, so the tree is being maintained and the recent tag is current.

Python bindings live in a separate project

The most consequential line in the README is the important notice at the top: pygmo, the Python bindings for pagmo, have been split off into a separate project hosted at `esa/pygmo2`, and users are asked to update their bookmarks. This repository is therefore the C++ core, and the Python surface is maintained elsewhere. For most users that is a reasonable separation, since bindings track a stable C++ API and can be released on a different schedule. The practical consequence for evaluation is that installing this project no longer gives you a Python package. If your workflow is Python first, the thing you need to assess is pygmo2, and pagmo2 is the dependency underneath it. The repository listing backs this reading: `include/`, `src/`, `CMakeLists.txt` and `config.hpp.in` describe a compiled library, with no Python package directory in sight.

Editorial conclusion

pagmo2 fits C++ engineers who need one API across many optimizers and who can live with a GPL-3.0 default and a from source build. It does not fit teams that want Python bindings from this repository, since pygmo now lives in a separate project, or teams pinned to the pagmo 1.x API, because version 2 is an entirely different codebase. Before adopting it, check the licence fit for your distribution model, confirm the conda-forge pagmo package matches your platform, and read the migration notes in the From 1.x to 2.x wiki page if you have 1.x code.

Frequently asked questions

Official sources

1. esa/pagmo2 on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases