Skip to content

Key Concepts

Note

This section describes how an optimization is set up — its variables, objectives, constraints, and the components that drive it. The examples here run their setup so you can see it work, but the setup itself is independent of how you run an optimization: that is covered in Running Optimizations or Optimization Workflows.

This page introduces the ideas and terms that appear throughout the ropt documentation and shows how they fit together. For the mathematical background behind ensemble-based robust optimization, see Background.

An optimization run works on a variable vector: the set of values the optimizer changes to improve the objective. For robust problems the same variable vector is evaluated across an ensemble of realizations, where each realization is one version of the model. A function evaluation combines the per-realization values into a single objective number.

Most optimizers also need a gradient evaluation. The objective usually cannot be differentiated by hand, so ropt estimates it: it evaluates small perturbations of the variable vector and infers the gradient from the differences.

The optimizer does not request these points one at a time. It groups them into batches that are evaluated together, and it works through the problem in iterations, where each iteration is one step of the algorithm.

Optimization components

Several parts of an optimization are pluggable: you select them in the configuration and ropt configures them for you. Four kinds of component can be chosen this way:

  • Optimization backends provide the optimization algorithms — the methods the optimizer runs. The built-in backend wraps SciPy; other backends add algorithms from external packages.
  • Samplers generate the perturbations used to estimate stochastic gradients.
  • Function estimators combine the per-realization values into the single robust objective, for example a mean, or a mean plus a standard-deviation term.
  • Realization filters select or reweight a subset of the realizations, for example to focus on the worst-performing ones.

A component is always an object. You can provide it in one of two ways:

  • Yourself — construct the object (an instance of a built-in class or of your own subclass) and pass it to the configuration directly. This is useful when a component needs custom Python logic.
  • Through the plugin system — let ropt build the object for you. You refer to the plugin by a short method string, such as "slsqp", or by a configuration object; ropt looks up the plugin and configures the component, applying any options you pass. This is the common case.

Plugins themselves are either built-in (shipped with ropt) or added by installing extra packages.

Each of the four kinds has its own place in the configuration. The exact syntax, the method naming convention (see method strings), and the available options are described in Configuration; the dedicated pages Realization Filters, Function Estimators, and samplers cover each component in depth.

The glossary below defines these terms precisely.

Glossary

The following terms are used throughout the ropt documentation. They reflect both standard optimization terminology and conventions specific to ensemble-based optimization as implemented by ropt.

Variable vector
A single point \(\mathbf{x}\) in the optimization space — the set of values the optimizer is trying to improve.
Realization
One member \(f_i\) of the function ensemble. Each realization represents a specific draw of uncertain parameters, capturing one possible "version" of the model. The ensemble of realizations is what makes the optimization robust.
Perturbation
A randomly modified copy of a variable vector, generated by a sampler. Perturbations are used for stochastic gradient estimation: the optimizer evaluates the objective at the perturbed points and infers the gradient from the differences.
Function evaluation
Computing objective (and optionally constraint) values at a variable vector across all realizations. The per-realization values are then combined (typically via a weighted sum) into a single scalar used by the optimizer.
Linear constraint
A constraint that is a linear function of the variables. Linear constraints are defined entirely in the configuration and are handled by ropt; they require no action from the function evaluation.
Nonlinear constraint
A constraint that is a general (nonlinear) function of the variables. Like a linear constraint it is declared in the configuration, but its value must be computed by the function evaluation, together with the objective, for each variable vector.
Gradient evaluation
Estimating the gradient at a variable vector by evaluating multiple perturbed variable vectors across all realizations. The resulting per-realization gradients are aggregated into a single gradient vector.
Batch
A group of one or more variable vectors evaluated together in a single call to the evaluator. These may include points in optimization space that the optimizer is exploring, or perturbed points for gradient calculations.
Iteration
One step of the optimization algorithm. Depending on the algorithm, an iteration may involve one or more batches.
Optimization backend
A component that provides the optimization algorithms (the methods) ropt runs. The built-in backend wraps SciPy; other backends add algorithms from external packages. See the backend configuration.
Sampler
A component that generates the perturbations used for stochastic gradient estimation. See Stochastic Gradients.
Function estimator
A component that combines the per-realization function values into the single robust objective, for example a mean, or a mean plus a standard-deviation term. See Function Estimators.
Realization filter
A component that selects or reweights a subset of the realizations, for example to focus on the worst-performing ones. See Realization Filters.
Scaling
The units the optimizer works in, as opposed to the ones you configure the problem in. Variables are scaled by the affine map given by their scales and offsets; aggregated objectives and nonlinear constraints by the affine map given by their scales and offsets. Results carry both domains: a field and its scaled counterpart sit at the same path.

Where to next