hugodovs/gl2o

1. What this repository is

- GL2O is a Python library for “learning to optimize”: it runs optimization algorithms, trains meta-optimizers over those runs, and then evaluates and visualizes the results.

- The codebase is organized around an experiment pipeline rather than a single application.

2. Top-level orchestration

- The main control flow lives under mlo/application/.

- These modules split the experiment lifecycle into distinct phases: building an experiment, preprocessing for meta-optimization, preprocessing for optimization, and postprocessing/analysis.

- main.py is the likely entry point that wires a chosen YAML config into this pipeline.

3. Configuration-driven experiments

- cfg/exp1/ contains the concrete experiment definitions.

- The train, pre_opt, and post_opt folders indicate a staged workflow: train/meta-learn first, then run optimization, then generate outputs such as plots.

- This configuration layer is the main boundary between experiment setup and algorithm code.

4. Experiment assembly and shared state

- mlo/application/builder.py and mlo/application/experiment.py appear to assemble the components for a run and hold the experiment-level coordination logic.

- mlo/components/infoset.py likely acts as a shared data container for metrics, observations, or run-state passed between stages.

5. Task model and benchmark domain

- Optimization problems are represented in mlo/components/tasks/.

- task.py defines the task abstraction, while bbob.py ties the project to the BBOB benchmark family.

- mlo/components/task_distributions/ adds a layer for sampling or managing collections of tasks, so experiments can train/evaluate over distributions rather than a single objective.

6. Optimization algorithms

- mlo/components/optimizers/ contains the concrete optimizers being compared or learned over.

- The set includes CMA-ES variants, DE, PSO, random search, one-plus-one, and specialized methods like LIOH and SHIWA.

- optimizer.py is the common interface boundary that the rest of the system uses, which lets the application treat all optimizers uniformly.

7. Meta-optimization layer

- mlo/components/metaoptimizers/ contains the learning-to-optimize machinery.

- The deepga_table/ subtree is the main meta-optimizer implementation, organized into population members, selection, mutation, slicing, and core algorithm logic.

- mpi_extensions.py suggests distributed or parallel execution support for scaling meta-optimization runs.

8. Factory-based dependency creation

- mlo/factories/ is the indirection layer that maps config names to concrete tasks, optimizers, meta-optimizers, and visualizers.

- This keeps the application layer from importing algorithm classes directly and makes the system extensible via configuration.

9. Postprocessing and visualization

- mlo/components/visualizers/ contains the output-generation layer.

- ecdf.py and heatmap.py indicate the main analysis products: benchmark-performance curves and performance landscapes.

- postprocessing_optimization.py likely turns raw experiment outputs into these visual artifacts.

10. Utility and experiment support

- mlo/utils/generator.py provides helper generation logic, likely for tasks, samples, or parameter sets.

- logexample.py and plot_metaloss.py are standalone analysis/demo scripts rather than core runtime components.

- The data/ directory is just a workspace placeholder, implying the repo expects experiment artifacts or datasets to be generated locally.

11. Architecture in one sentence

- The system flows from YAML experiment definitions into factory-built tasks and optimizers, runs them through a staged application pipeline, optionally meta-trains an optimizer with distributed support, and finally emits benchmark visualizations and summaries.