__init__.py
This file acts as the lightweight index for the examples package.
There is no runnable logic here. It carries the version string and an __all__ list that points at the examples the package intends to expose. That makes it useful as a rough inventory of the scripts the repository treats as part of the public example set, even though the file itself is only bookkeeping.
- Main role: package metadata and a simple export list.
- How it fits: a directory-level signpost, not an example in its own right.
advexamples.py
This runner applies coordinated retry to the classic GTOP space-mission benchmarks.
The script loops over the benchmark problems exposed by fcmaes.astro and drives them with a small optimizer set through advretry. It is narrower than the broader benchmark scripts in the same directory. The focus here is not problem modeling. It is the advanced retry store and how it behaves on the space-flight cases that shaped much of the library.
- Main pieces: GTOP problem list, optimizer loop, repeated coordinated retry runs.
- How it fits: a compact reproduction script for the space benchmark results.
arm.py
This is a quality-diversity example built around a high-dimensional planar robot arm.
The script defines a forward-kinematics model for a many-joint arm and then asks MAP-Elites or the diversifier layer to fill an archive of reachable positions. The behavior space is the arm’s endpoint location, while the fitness can be based on the spread or magnitude of the joint angles. It is a clean file for understanding what a fcmaes quality-diversity setup looks like when the domain is simple enough to visualize.
- Main pieces: forward kinematics, archive plotting, a QD fitness class, and archive-based optimization.
- How it fits: a minimal but concrete QD example without heavy domain baggage.
benchmark_gtop.py
This is a stripped-down GTOP benchmark runner for the standard coordinated-retry workflow.
The file keeps the benchmark surface intentionally small. It picks the GTOP problems from fcmaes.astro, uses the usual DE-to-CMA sequence, and calls advretry.minimize. If you want a short script that shows how the library is actually used on the space-flight problems, this one is easier to read than the larger comparison drivers.
- Main pieces: GTOP problem list, one optimizer choice, one retry path.
- How it fits: a compact baseline for the space benchmark family.
benchmark_gtop_pygmo.py
This script compares the fcmaes retry idea with Pygmo and Pagmo algorithms on the GTOP problems.
Instead of only using the native fcmaes optimizer wrappers, the file defines small adapters around Pygmo’s DE and CMA variants, packages GTOP problems as Pygmo UDPs, and then compares archipelago-style execution with the coordinated retry approach. It is a bridge script. The interesting part is not one more benchmark score, but the way it puts two optimization ecosystems on roughly the same playing field.
- Main pieces:
pygmo_udp, optimizer wrappers, archipelago tests, coordinated retry tests. - How it fits: a comparison harness for the space benchmarks and external solver integration.
cassini2_minlp.py
This file explores a mixed-integer Cassini 2 mission setup by searching over discrete structural choices.
The script does not try to hide the discrete structure inside one large optimizer call. Instead, it packages the sequence choices as related problem variants and lets multiretry decide which variants deserve more budget. That makes the file a good example of the “enumerate structure, optimize the rest” style that appears in the mixed-integer space-flight work.
- Main pieces: a Cassini 2 wrapper class, candidate sequences, and staged multiretry evaluation.
- How it fits: one of the mixed-integer mission design examples.
cassini_minlp.py
This script does the same style of mixed-integer search for the Cassini 1 benchmark.
The structure mirrors the Cassini 2 variant, but with the Cassini 1 mixed-integer setup from fcmaes.astro. It compares plain coordinated retry with the tournament-style multiretry scheme over discrete sequence candidates. The script is short, but it captures an important design choice in the repo: when a discrete mission structure can be enumerated, the library often treats that enumeration explicitly instead of burying it inside a harder black-box problem.
- Main pieces: sequence list, coordinated retry, multiretry over problem variants.
- How it fits: a direct companion to the mixed-integer space tutorials.
clustering.py
This example treats balanced clustering as a derivative-free optimization problem.
The task is simple to state: split 200 cities into four equal groups while keeping the within-cluster travel pattern short. The script uses a compact integer-style encoding, a Numba-accelerated objective, and a retry-based optimizer rather than a standard clustering library. That makes it a nice example of using fcmaes for a problem that is not usually introduced through a black-box optimization lens.
- Main pieces: distance objective, equal-group constraint handling, visualization, retry with BiteOpt.
- How it fits: a small applied example that shows how flexible the integer-style encoding can be.
crypto.py
This is a full trading-strategy example with backtesting, single-objective tuning, multi-objective tuning, and archive search.
The script pulls price history, computes moving averages, simulates a trading rule, and then optimizes the rule parameters in several ways. It does not stop at one “best return” score. It also includes multi-objective and quality-diversity runs, which makes it one of the richer example files in the tree. The code is useful both as a domain demo and as a pattern for wrapping a moderately expensive simulation in several different fcmaes workflows.
- Main pieces: data loading, technical indicators, backtest simulation, retry, MODE, and archive search.
- How it fits: one of the clearest end-to-end application examples in the repository.
damp.py
This file turns a damped ODE control problem into both a retry benchmark and a quality-diversity exercise.
The script integrates a spring-like dynamical system, evaluates control policies, and then looks at the problem through two different lenses. One is straightforward retry for best performance. The other is archive-based search over behavior descriptors, which makes the file useful if you want to see how the same model can support both ordinary optimization and QD workflows.
- Main pieces: ODE integration, compiled and pure integration paths, retry, archive plotting, and QD optimization.
- How it fits: a bridge example between control, ODE simulation, and MAP-Elites-style search.
elitescass2.py
This script applies quality-diversity methods to the Cassini 2 mission benchmark.
Instead of asking for one best trajectory, the file defines a behavior space over mission properties and uses MAP-Elites or the diversifier layer to populate an archive of alternatives. It is an important example because it shows the QD machinery on a serious optimization problem, not a toy robot arm. The archive plots also make it easier to see what the behavior descriptors are buying you.
- Main pieces: behavior descriptors for Cassini 2, archive plotting, diversifier run, MAP-Elites run.
- How it fits: the space-flight QD counterpart to the lighter archive demos.
employee.py
This is a large employee-scheduling model with both single-objective and multi-objective optimization paths.
The script loads roster data, builds indexing helpers for shifts and employees, and encodes hard and soft constraints inside a Numba-accelerated fitness function. It then tries several solver styles, including retry, weighted-sum multi-objective search, and MODE. This is one of the stronger examples in the repo because it shows how far the library can be pushed on a practical combinatorial scheduling problem without leaving the derivative-free framework.
- Main pieces: data parsing, schedule encoding, hard and soft constraints, retry, MODE, and Pareto exploration.
- How it fits: a flagship scheduling example with realistic structure.
examples.py
This is the plain retry counterpart to advexamples.py.
The file sweeps across GTOP problems and a wider set of optimizer wrappers, but uses the simpler retry meta-algorithm rather than the store-driven coordinated version. That makes it a good reference if you want to compare the two retry styles or reproduce the broader space benchmark tables without reading a lot of domain code.
- Main pieces: GTOP problem list, optimizer list, repeated retry calls, logging setup.
- How it fits: a baseline comparison runner for space-flight examples.
f8.py
This file studies the F-8 aircraft bang-bang control problem with several retry and parallel-evaluation strategies.
The objective is built around a simple aircraft model and a sequence of switch times. The script keeps both a pure Python ODE path and a compiled integration path, then compares coordinated retry, parallel retry, and delayed-update population evaluation. It is a nice example of how the same control problem can be used to measure algorithm overhead, parallelism, and the benefit of compiled dynamics code.
- Main pieces: control-time encoding, ODE and compiled simulation paths, several retry modes, logging of best trajectories.
- How it fits: a control benchmark that stresses expensive function evaluation and optimizer coordination.
filter.py
This example trains a lightweight ranking model to filter out weak DE candidates on the noisy TSP.
The idea is simple but useful. The script stores recent candidate points and scores, fits an xgboost ranker, and lets the DE implementation skip some evaluations that are unlikely to improve on the current candidate. It only makes sense when the objective is expensive, which the file states plainly. That makes it more of a search-acceleration experiment than a general-purpose optimization recipe.
- Main pieces: a learned filter, pairwise ranking with
xgboost, and integration with the Python DE code path. - How it fits: an experimental example of mixing a surrogate idea into the optimization loop.
gear_train.py
This script solves a classic mixed-integer gear-train design problem with ordinary retry methods.
The interesting trick is that the solver does not need a dedicated mixed-integer backend here. The objective simply maps the continuous search vector to feasible tooth counts before scoring it. The file then sweeps the bound on the largest gear size to list a whole set of tradeoff points. It is one of the clearer examples of how far simple discretization can go on a small engineering design task.
- Main pieces: discrete tooth mapping, ratio error objective, repeated bound sweep, retry and coordinated retry comparisons.
- How it fits: a small design example that shows when a full mixed-integer solver may be unnecessary.
harvesting.py
This file extends the job-shop machinery to an asteroid-harvesting scheduling problem.
The model is derived from the flexible job-shop example, but it adds a different story and extra structural constraints. Factories move between asteroids, jobs depend on those deployments, and the script supports both single-objective and multi-objective runs. If you want to see how the repository adapts one scheduling core to a new domain rather than starting from scratch, this file is a strong example.
- Main pieces: a modified scheduling fitness, Gantt-style helpers, retry, MODE, and weighted-sum Pareto exploration.
- How it fits: a domain-specific offshoot of the job-shop work.
house.py
This is a hyperparameter-optimization example built around the Kaggle house-prices regression task.
The script wraps an XGBRegressor, cross-validation scoring, and a fairly detailed preprocessing path inside a derivative-free objective. It is not a small demo. It is a realistic machine-learning tuning example that uses fcmaes to search a mixed space of model choices and numeric parameters. The code is useful if you want to see how the library is used when the “simulation” is really a repeated training-and-validation loop.
- Main pieces: feature cleanup, cross-validation scoring, parameter conversion, and an optimization wrapper class.
- How it fits: a practical hyperparameter-search example rather than a benchmark toy.
interferometry.py
This script compares a parallel fcmaes workflow with Pygmo’s island model on an interferometry image-reconstruction problem.
The heavy problem logic lives in interferometry_udp.py. This file is the driver around it. It runs archipelago experiments, checks known good solutions, and launches a retry-based DE or CMA workflow for comparison. It is a benchmarking script, but it is grounded in a genuine inverse problem rather than a synthetic test function.
- Main pieces: archipelago runner,
fcmaesoptimizer runs, and result checks against the shared problem class. - How it fits: a side-by-side comparison between retry and island-style population search.
interferometry_udp.py
This file defines the interferometry problem class used by the comparison driver.
The module handles the domain mechanics: reading the target image, building the optical objective, and computing reconstruction error. It is not a generic library component. It is a problem definition with just enough extra machinery to support both Pygmo and fcmaes-based optimization in the driver script.
- Main pieces: the
Interferometryclass, image handling, FFT-based calculations, and error evaluation. - How it fits: the problem backend for
interferometry.py.
jobshop.py
This is the main flexible job-shop scheduling example in the repository.
The script reads job-shop instances, builds a Numba-accelerated scheduler, plots Gantt charts, and exposes both single-objective and multi-objective optimization flows. It is one of the more substantial example files because it combines data parsing, schedule construction, visualization, retry, MODE, and weighted-sum front generation in one place. If you want one large example that shows how the library handles hard combinatorial structure, this is a good candidate.
- Main pieces: FJSP parsing, scheduling logic, charting, retry, MODE, and Pareto runs.
- How it fits: a central scheduling example that other files, such as
harvesting.py, build on.
lotka.py
This script optimizes a policy over a predator-prey model rather than just fitting parameters.
The objective encodes a sequence of fox-killing decisions over time, simulates the Lotka-Volterra dynamics, and scores the resulting rabbit population. That makes the example closer to control or intervention planning than to classical curve fitting. The file then compares coordinated retry, plain retry, and delayed-update parallel evaluation on the same ODE-driven objective.
- Main pieces: predator-prey simulation, decision-time encoding, retry variants, and logging of intervention schedules.
- How it fits: an ODE-based control example that is easy to understand but still expensive enough to stress the optimizer stack.
maxcut.py
This is a quantum-optimization comparison built around VQE-based MaxCut.
The script adapts both sides of the interface. It wraps Qiskit’s SPSA so it can be called like an fcmaes optimizer, and it wraps fcmaes retry-based optimizers so they can sit inside Qiskit’s VQE workflow. That two-way bridge is the interesting part. The file is less about one quantum problem and more about how to compare different optimizer families fairly inside the same quantum loop.
- Main pieces: MaxCut setup, VQE configuration, SPSA wrapper,
fcmaeswrapper, and noisy-simulation support. - How it fits: the most explicit optimizer-comparison script in the quantum examples.
moexamples.py
This file is the broad multi-objective comparison script for the repository.
It bundles several synthetic and space-flight test problems, then compares weighted-sum retry, Python MODE, compiled MODE, and a deap-based NSGA-II baseline. The script also handles plotting and Pareto extraction, so it is both a benchmark harness and a practical cookbook for running the different multi-objective paths side by side.
- Main pieces: benchmark problem classes, plotting helpers, MODE wrappers, and NSGA-II comparisons.
- How it fits: the broadest multi-objective example in the top-level examples directory.
noisy_tsp.py
This module defines the noisy traveling-salesman problem used by several example scripts.
It contains the problem class, TSPLIB loading logic, and the noisy evaluation path. The file matters beyond its own standalone use because other examples build on it, especially the learned filter experiment. If you want to understand how a permutation-like routing problem is encoded as a derivative-free optimization target in this repo, this file is the place to start.
- Main pieces:
TSPclass, TSPLIB loader, noisy evaluation logic, bounds definition. - How it fits: a reusable problem definition, not just a driver script.
powerplant.py
This example optimizes a TESPy-based thermal power-plant model and then explores its behavior space with quality-diversity tools.
The file starts with a process-modeling problem, not an abstract function. It builds the plant in TESPy, defines decision variables and objectives, and runs both a direct optimization path and a QD archive search. That makes it one of the stronger demonstrations of the library on a structured engineering simulation where each function call has clear physical meaning.
- Main pieces: TESPy network model, efficiency objective, archive-based exploration, and 3D plotting of archive results.
- How it fits: a detailed engineering example that also connects to the quality-diversity machinery.
prophet_opt.py
This script treats an AI-generated trading strategy as an expensive parameter-search problem.
The code loads market data, builds a Prophet-based strategy, converts an optimizer vector into strategy parameters, and then uses fcmaes to search that space. It also shows how the journal wrapper can be used to stream progress into an Optuna-style dashboard. The result is not a tiny demo. It is an example of using the library around a practical model whose logic was assembled from outside the usual scientific-computing stack.
- Main pieces: strategy parameter conversion, expensive evaluation loop, DE-based optimization, and journal logging.
- How it fits: a modern workflow example that mixes forecasting, search, and monitoring.
quant.py
This is the simpler quantum example: optimize variational quantum-circuit parameters without the extra MaxCut wrapper layer.
The script works with single-qubit and VQE-style parameter optimization, compares several solver choices, and shows the weaknesses of COBYLA against the derivative-free optimizers provided by fcmaes. It is a cleaner read than maxcut.py if you want the core idea without as much scaffolding.
- Main pieces: variational-form setup, target distribution evaluation, several optimizer loops, and solver comparison.
- How it fits: the direct quantum optimization example in the repo.
reproblem.py
This file wraps the compiled RE multi-objective benchmark suite so it can be used from the fcmaes side.
The script is about integration rather than problem invention. It bridges to the external C version of the RE suite, exposes bounds and objective calls, and then runs weighted-sum or advanced-retry style multi-objective experiments. It is helpful if you want to compare fcmaes on an established benchmark family without rewriting those problems in Python first.
- Main pieces: the
re_problemwrapper, benchmark objective access, and retry-based Pareto experiments. - How it fits: one half of the RE benchmark support, with
repython.pyas the other half.
repython.py
This file reimplements several RE benchmark problems directly in Python and compares them with other multi-objective stacks.
The module defines the RE problems in Python, adds optional pymoo problem wrappers, and then exercises MODE, compiled MODE, DE-based search, and weighted-sum retry on top of them. It is broader than reproblem.py because it is not just a bridge. It is also a test bed for multi-objective tooling around the same benchmark family.
- Main pieces: RE problem classes, helper functions,
pymooadapters, and multi-objective driver code. - How it fits: a portable benchmark script and a useful comparison harness.
robot.py
This example optimizes a Box2D push-robot task with retry-based derivative-free search.
The script defines the simulation world, reward function, obstacles, and rendering helpers for a robot-pushing problem drawn from black-box optimization benchmarks. It is less about algorithm comparison and more about showing that a physics simulation with awkward control parameters can still be wrapped into a normal fcmaes workflow.
- Main pieces: Box2D world construction, reward class, simulation loop, and retry-based optimization.
- How it fits: one of the simulation-heavy robotics examples.
routing.py
This script models capacitated vehicle routing and solves it with both single-objective and multi-objective flows.
The file parses route data, defines a Numba-based routing fitness, and then explores several optimization styles: plain retry for route cost, a capacity-aware path, and multi-objective search over route quality and fleet-capacity tradeoffs. It is a good example of how the repo handles integer-style routing problems without giving up the general derivative-free API.
- Main pieces: routing parser, single-objective fitness, capacity-aware variant, retry, MODE, and weighted-sum front generation.
- How it fits: one of the main logistics examples.
rover.py
This file defines and optimizes a rover-trajectory problem with spline-based paths and obstacle costs.
The script contains more geometry code than most of the example directory. It builds trajectory representations, cost functions, and domain helpers for rover navigation, then hands the resulting black-box objective to retry-based optimizers. Together with robot.py, it shows how the library is used on robotics-style motion problems that come from benchmark suites rather than from the core optimization literature.
- Main pieces: spline trajectory model, terrain and obstacle cost functions, plotting, and retry-based optimization.
- How it fits: the rover-navigation companion to the push-robot example.
scheduling.py
This is the large GTOC-style scheduling example for a mission-planning problem.
The script combines trajectory-selection logic, timing constraints, Numba-accelerated scoring, and both single-objective and multi-objective search. It also includes archive plotting and some quality-diversity hooks. Compared with the other scheduling files, this one is the most domain-heavy. It is written around a specific space-competition scheduling problem rather than a generic benchmark format.
- Main pieces: timing logic, constraint checks, scoring functions, retry, MODE, and archive visualization.
- How it fits: the most specialized scheduling example in the top-level directory.
siemens.py
This file turns a simple plant material-flow problem into an optimization benchmark.
The problem comes from a Siemens challenge rather than from a standard numerical benchmark suite. The script models machines, buffers, and a plant-level simulation, then compares DE-style search and BiteOpt on top of that simulation. It is a compact example, but it says something useful about the library: even a custom queueing or flow model can be wrapped with very little ceremony.
- Main pieces: plant model classes, simulation function, and two optimizer drivers.
- How it fits: a small industrial-simulation example with a clear objective loop.
solo_mgar.py
This is the driver script for a difficult Solar Orbiter mission-design problem built on Pykep.
The file reads and verifies candidate solutions, runs retry and multi-objective flows, and can also compare those results with Pagmo-based execution. The actual problem definition lives in solo_mgar_udp.py, so this file reads like a mission-study harness: it is where solution quality is checked, optimizers are chosen, and search runs are launched.
- Main pieces: solution checking, retry-based optimization, Pagmo comparison, and result logging.
- How it fits: the driver around one of the most specialized space examples in the repo.
solo_mgar_udp.py
This file contains the Solar Orbiter problem model used by solo_mgar.py.
The class is a real domain model, not a helper. It handles the resonant gravity-assist mechanics, transfer modeling, and mission-constraint calculations needed for the optimizer to score a candidate trajectory. It is long because the mission logic is long. If you read the driver first, this file is the place to come next when you want the orbital details.
- Main pieces: the
solo_mgar_udpproblem class, orbital mechanics helpers, resonance logic, and trajectory scoring. - How it fits: the domain backend for the Solar Orbiter mission example.
spring.py
This is a small constrained spring-design example that compares retry against a standard local solver.
The file encodes the classic tension-compression spring problem with penalty terms for constraint violations. It is short, but it makes a useful point: for some constrained design problems, a derivative-free retry loop with a sensible penalty can be competitive with a standard SLSQP run. That makes the script more than just a textbook exercise.
- Main pieces: constraint functions, penalized objective, SLSQP reference path, retry and coordinated retry calls.
- How it fits: a compact constrained-design example.
subset.py
This file shows how a subset-selection problem can be posed as a single-objective derivative-free search.
The script defines a small synthetic value model and then searches for the best subset under the chosen scoring rule. The implementation is intentionally lightweight. It is best read as a pattern: encode membership choices inside a continuous vector, project or interpret them inside the objective, and use a standard retry path. The paired multi-objective version lives in subset_mo.py.
- Main pieces: transaction-value model, subset fitness, and a simple retry driver.
- How it fits: the single-objective subset example.
subset_mo.py
This is the multi-objective counterpart to subset.py.
Instead of reducing the subset task to one scalar score, this file exposes it to MODE and compiled MODE so a Pareto front can be built. The setup is deliberately small, which makes it a good teaching example for the jump from ordinary retry to explicit multi-objective search.
- Main pieces: the same subset-value model with a multi-objective wrapper and MODE-based optimization.
- How it fits: the paired Pareto version of the subset-selection example.
tandem_minlp.py
This is the Tandem mission variant of the mixed-integer multiretry pattern.
The script is short because it relies on the mission wrappers in fcmaes.astro and the retry machinery in fcmaes.multiretry. Its job is to define the candidate problem structure, run the staged retry search, and log results. It is best read alongside the Cassini mixed-integer scripts rather than on its own.
- Main pieces: mission wrapper selection, coordinated retry, multiretry over Tandem variants.
- How it fits: another small driver for the mixed-integer mission-design family.
tdesign.py
This file searches for weighted spherical t-designs and includes the geometry and harmonic calculations needed to score them.
The script is more mathematical than most of the example directory. It converts between coordinate systems, computes spherical harmonics and symmetry measures, visualizes point sets, and then optimizes both point placement and weights. It is a good example of the library being used on a hard scientific design problem where the objective is entirely custom.
- Main pieces: coordinate transforms, harmonic error calculations, symmetry checks, visualization, and retry-based optimization.
- How it fits: one of the most self-contained scientific examples in the repo.
top_trumps.py
This script wraps the Top Trumps game benchmark as both a single-objective and multi-objective optimization problem.
The benchmark is unusual, but the surrounding code is familiar for this repository. The file defines objective wrappers, bounds, plotting helpers, and several ways to solve the problem: weighted-sum retry, MODE, compiled MODE, and other single-objective paths. It is a good example of the library being pointed at a benchmark outside engineering or physics without changing the surrounding optimization ideas very much.
- Main pieces: benchmark objective wrappers, plotting, retry, MODE, and front-building drivers.
- How it fits: a game-benchmark example that doubles as a multi-objective comparison script.
trappist_delivery.py
This is a large competition-style scheduling script for the ESA delivery-scheduling challenge.
The file loads problem data, encodes a schedule representation, builds a Numba-accelerated fitness, and runs several optimizers over a large search space. Unlike the more compact tutorials, this is a full competition solver script. It is useful if you want to see what a serious one-off application looks like once all the parsing, logging, and problem-specific bookkeeping are kept in the same file.
- Main pieces: schedule class, fitness class, optimization driver, and validation helpers.
- How it fits: a large problem-specific script that still follows the same retry-first style as the rest of the repo.
tutorial.py
This is the hands-on companion to the tutorial overview for learning the basic fcmaes workflow.
The file walks through the GTOP examples and compares several styles of calling the library: coordinated retry, plain retry, Python and C++ CMA-ES, ask/tell loops, and a few SciPy baselines. It is one of the best files to open if you want to understand usage before diving into any specific application domain.
- Main pieces: small benchmark functions, side-by-side optimizer calls, and timing-oriented printouts.
- How it fits: the most direct tutorial-style code example in the repository.
vaccination.py
This file simulates vaccination dynamics and optimizes intervention choices over that model.
The code combines Numba-accelerated update rules, plotting helpers, and an execution path that turns a vaccination policy into a score. It is more of a model-and-experiment script than a solver comparison script. If you want to see how a public-health style simulation is wrapped into the same black-box optimization interface used elsewhere in the repo, this example does that clearly.
- Main pieces: epidemic update functions, fast simulation loops, plotting, and execution helpers.
- How it fits: a simulation example with a strong domain story and a light optimization wrapper.
vessel.py
This script solves the classic pressure-vessel design problem with mixed discrete and continuous variables.
The shell and head thicknesses are available only in fixed plate increments, while the remaining dimensions stay continuous. The example uses the same basic pattern as the spring and gear-train files: map the variables to feasible values, add penalties for constraint violations, and let retry-based derivative-free search do the rest. It is a straightforward engineering example, but still a useful one.
- Main pieces: discretization of thickness variables, constrained cost objective, SLSQP comparison, retry and coordinated retry runs.
- How it fits: a compact mixed-variable design example.
vilar.py
This example explores the Vilar oscillator model with both multi-objective search and archive-based diversity methods.
The file builds on GillesPy2, sweeps parameters, evaluates oscillatory behavior, and then runs either Pareto-style optimization or quality-diversity search to explore the model space. It is one of the clearest examples of a stochastic biochemical model being used as an optimization target rather than as a fixed simulation.
- Main pieces: oscillator model wrapper, behavior extraction, MODE and weighted-sum search, diversifier and MAP-Elites runs.
- How it fits: a bridge between the stochastic-model sweep tutorial and the diversity tutorial.
yahpo.py
This file uses YAHPO Gym as a fast surrogate benchmark for quality-diversity search over machine-learning configurations.
The script defines several QD objectives over the YAHPO surrogate benchmarks, such as hardware-performance and interpretability tradeoffs, and then runs the archive machinery over them. It is a good example of the repo moving beyond “find the single best hyperparameter setting” toward “map out the useful tradeoff space.”
- Main pieces: benchmark-set setup, objective reshaping, archive plotting, and diversifier-based search.
- How it fits: a quality-diversity example for ML configuration spaces rather than physical systems.