Google Summer of Code with optimagic

[janosg]

Introduction

optimagic is participating in the 2025 Google Summer of Code (GSoC) under the NumFOCUS GSoC application. This is a great opportunity to contribute to a powerful open-source optimization library and gain experience in numerical methods and scientific computing.

optimagic is a Python package for numerical optimization that provides a unified interface to a wide range of optimization algorithms. It's designed to make it easy for researchers and practitioners to find the best optimizer for their specific problem, without needing to become experts in every algorithm. optimagic works seamlessly with optimizers from SciPy, NLopt, Pygmo, and others, offering a familiar minimize function that's a drop-in replacement for SciPy's. Beyond simply providing access to more algorithms, optimagic includes diagnostic tools, parallelization features, robust error handling, and compatibility with automatic differentiation via JAX. It supports diverse parameter structures, making it flexible for a variety of optimization problems.

Timeline

The timeline of the GSoC internships is available at the GSoC website.

How to apply

If you're interested in contributing to optimagic through Google Summer of Code, a great first step is to get familiar with our project. We recommend starting by reading our contributing guide. Since optimagic interfaces with many numerical optimization libraries, understanding the basics of numerical optimization will be very helpful. You can also learn a lot by exploring our tutorials, how-to-guides and explanations.

A key part of the GSoC application process for optimagic is making a contribution to the optimagic codebase. This doesn't have to be a major feature; a small documentation improvement, a fix for a minor bug, or an improvement to the test suite is perfectly fine. To find a good issue to get started, reach out to us on zulip. We're happy to help!

Projects ideas

We've listed some project ideas below to get you started, but we're also open to your own suggestions related to optimagic! If you have an idea that's not on the list, please get in touch with us on zulip before submitting a proposal. We won't consider proposals on unlisted topics from applicants who haven't discussed their idea with us first.

The ideas below are intentionally broad. Some might be too large for a single GSoC
project. Your proposal should focus on a specific, manageable set of tasks that you can
realistically complete within the GSoC timeframe. We have added estimates for the
complexity and duration for each project, but of course this also depends on your
background. Please feel free to reach out to us to discuss your application or any
questions!

1) Adding More Optimizer Interfaces to optimagic

Project Overview

• Complexity: Beginner to Intermediate. Requires solid Python programming skills
  and basic understanding of numerical optimization. Familiarity with different
  optimization algorithms is a plus.
• Duration: 90h, 175h, or 350h. The scope can be adjusted based on the student's
  background and the number of optimizers they choose to integrate.
• Mentors: @janosg (@timmens)

The core of optimagic is an internal optimizer interface that makes it really easy to add new optimizers. Just as an example: wrapping optimizers from scipy or NlOpt took less than 50 lines of code per optimizer on average (e.g. here. This is possible because all of the heavy lifting is done in an algorithm agnostic way. This includes basic tests for each optimizer.

The main things that need to be done to add an optimizer to optimagic are:

Translate the names of all frequently occurring tuning parameters to our naming scheme and find good and descriptive names for the remaining ones
Translate the optimizer output to an optimagic.InternalOptimizeResult
Provide information about the optimizer via the mark.minimizer decorator.
Create a subclass of Algorithm and do the actual optimization in _solve_internal_problem
Create benchmarks and improve the default values of tuning parameters.
Write documentation

We are happy to help you with the first optimizer to make the process as smooth as possible.

Why is this important?

There is no single "best" optimization algorithm that works well for all problems. Look here and here for examples. Different algorithms have different strengths and weaknesses, and the best choice often
depends on the specific characteristics of the objective function (e.g., smoothness,
dimensionality, presence of constraints). By providing access to a wider range of
optimizers, optimagic empowers users to experiment and find the most efficient
solution for their particular problem. This also reduces the need for users to learn
the intricacies of multiple optimization packages.

Project Goals:

The core idea is to wrap additional optimizers, giving them a consistent interface
within optimagic's minimize function.

A good starting point for optimizers you could wrap is:

• Powell's gradient-free optimizers via [PRIMA](Link to PRIMA)
• Optimizers from [Nevergrad](Link to Nevergrad)
• Optimizers from [Bayesian Optimization](Link to a relevant Bayesian Optimization package)
• Migrad via [iminuit](Link to iminuit)
• SNOPT, SLSQP, and others via [PyOptSparse](Link to PyOptSparse) (or direct wrapping)
• Knitro (Link to Knitro)
• Optimizers from [ensmallen](Link to ensmallen) via pyensmallen
• Optimizers from the book "Practical Mathematical Optimization" (source code available in optimagic)
• Optimizers from the [argmin](Link to argmin) package (in Rust)

However, this list is not exhaustive, and you can propose other optimizers. The long run goal of optimagic is to support any optimizer with Python bindings!

Expected Output:

• Minimal Goal (90h): Wrap and document the optimizers from one optimizer library listed above. Write tests for the optimizers and benchmark their performance using optimagic’s built-in benchmarking capabilities
• Intermediate Goal (175h): Add extensive benchmarking and improve the default values for the tuning parameters of the algorithms you added.
• Main Goal (350h): Add half of the optimizers listed above to optimagic
• Stretch Goal: Add all of the optimizers listed above to optimagic

2) Enabling Backend-Agnostic Plotting in optimagic

Project Overview

• Complexity: Beginner to intermediate. Requires solid Python programming skills and
  experience with designing user-friendly interfaces. Familiarity with at least one
  plotting library (e.g., Matplotlib, Seaborn, Plotly) is essential. Some design skills and knowledge of color theory are a bonus.
• Duration: 175h
• Mentors: @timmens (@janosg)

This project aims to increase the flexibility of optimagic's plotting functions by
allowing users to choose their preferred plotting backend. Currently, optimagic relies
completely on Plotly for visualizations. This project will introduce a mechanism to
dynamically select the plotting backend (e.g., Matplotlib, Seaborn, or Plotly), giving
users more control over the appearance and interactivity of their plots.

Why is this important?

Different users have different preferences and requirements for plotting. Some may
prefer the static, publication-quality plots of Matplotlib, while others may need the
interactive features of Plotly, or the aesthetic style of Seaborn. By allowing users to
choose their backend, optimagic becomes more adaptable to diverse workflows and avoids
imposing a single plotting library on all users.

Project Goals:

1. Design a Backend Selection Mechanism: Develop a clean and user-friendly way for
   users to specify their desired plotting backend. This could involve:

   • A backend argument in plotting functions (e.g., slice_plot(..., backend="matplotlib")).
   • A global configuration setting that sets the default backend.

2. Implement Backend Support: Adapt the existing plotting functions to work with at
   least two backends (e.g., Matplotlib and Plotly). This will involve:

   • Separating all code that is not related to the actual plotting (e.g. the code for generating or transforming the data that is going to be plotted) from the actual plotting code.
   • Creating separate code paths within the plotting functions to generate plots using
     the selected backend.
   • Abstracting common plotting operations (e.g., setting titles, labels, legends) to
     minimize code duplication.

3. Add Documentation and Examples: Clearly document the new backend selection
   mechanism and provide examples demonstrating how to use different backends.

Expected Output:

• Intermediate Goal (175h): A modified set of optimagic's plotting functions (e.g.,
  criterion_plot, params_plot, slice_plot) that accept a backend argument and can generate plots using at least Matplotlib/seaborn and Plotly. This includes clear documentation
  and usage examples for each supported backend.
• Main Goal (350h): Add support for more backends (e.g. bokeh, Altair)
• Stretch Goal: Add support for plots in dark and light mode and style the plots for all backends in a recognizable optimagic design and make sure all plots are accessible for users with vision impairments.

[gauravmanmode]

hi, i am hoping to apply for gsoc 2025. i am interested in this project. how can i get started ?