Separating Algorithm and Problem Modules

In EvoX'sopen decoupled foundation, a complete evolutionary workflow is split into two replaceable "building blocks":the algorithm moduleanswers "how to search," andthe problem moduleanswers "what to evaluate and how the environment responds." The two connect through a clear set of interface contracts, composing an evolutionary workflow that is reusable, replaceable, and transferable.

Algorithm Module: Encapsulating "How to Search"

Candidate solution generation and population update: Evolutionary logic such as initialization, mutation, crossover, selection, and elitism is implemented uniformly by the algorithm module.
Search control: Iteration count, population size, restart and convergence criteria, and operator parameter scheduling are all decisions on the algorithm side.
The algorithm module relies only on the abstract premise that "candidate solutions will be evaluated" and does not concern itself with the physical meaning or specific form of the objective function.

Problem Module: Defining "What to Evaluate and How the Environment Responds"

Turn candidate solutions into comparable feedback: Objective values, fitness, constraint violation, or the result of an environment interaction.
Declare problem boundaries and constraints: Variable dimensions, value ranges, and feasible-region rules, so the algorithm knows where it can generate candidate solutions.
Provide consistent evaluation for the same batch of candidate solutions, so that different individuals, generations, and algorithms can be compared on equal footing.

Interface Contract: Candidate Solution Batch ⇄ Evaluation Results

The algorithm module submits to the problem modulea batch of candidate solutions; the problem module returnsstructured evaluation results(objective vectors, constraint violation, and optional additional diagnostic information); the algorithm module then updates the population and advances to the next generation. This one "submit–return" round trip constitutes one generation of evolution.

Benefits of Decoupling

Independent extension: Adding or replacing algorithms does not affect the problem definition; modifying or adding problems does not require rewriting the algorithm module.
Composability: The same problem module can connect to different evolutionary algorithms, and the same algorithm module can switch to different problem modules.
Transferability: As long as the interface contract remains stable, algorithms and problems can be reused, replaced, and transferred across tasks.

Why This Matters Especially in This Lesson's Context: Multi-Objective Trade-offs and Expensive Feedback

This lesson focuses on engineering problems in the real physical world—for example, COMAC'ssupercritical airfoil design. Such problems typically have three characteristics at once: multiple conflicting objectives (e.g., increasing lift often brings higher drag and reduced stability), mutually nested constraints (e.g., critical buffet lift coefficient, maximum stress must not exceed the material's allowable value), andexpensive and sparse feedback(a single high-fidelity simulation evaluation is very costly). Module separation was designed precisely to address these three points.

On the problem module side, multiple objectives and constraints are uniformly converted into comparable evaluation results: objective vectors characterize each metric, constraint violation quantifies the degree of violation, and when necessary,surrogate modelsare used to provide approximate evaluations at lower cost, alleviating the feedback bottleneck caused by high-fidelity simulation. On the algorithm module side, the search no longer aims for premature convergence to a single "optimal answer," but instead maintainsa diverse set of candidate solutions, allowing experts to perform preference optimization and trade-offs among lift, drag, and safety margins.

Therefore, the "candidate solution batch ⇄ evaluation results" contract must carry not only a single scalar fitness but also objective vectors and constraint violation: multi-objective trade-offs require the algorithm to perform non-dominated comparisons, and constraint handling requires the algorithm to distinguish feasible from infeasible. Once the contract is incomplete, multi-objective and constraint information is permanently lost at the interface, and the reuse and transferability that decoupling brings are likewise lost.

Common Pitfalls

Writing the objective function, constraint handling, or problem-specific heuristic rules into the algorithm module, or implementing selection and population updates in the problem module. On the surface this looks like "saving a layer," but in reality it re-couples the two sides: changing the problem requires changing the algorithm, and changing the algorithm requires changing the problem—both reuse and transferability fail at the same time.

Interfaces Should Be "Narrow yet Complete"

"Narrow" means few and stable fields—passing only two types of information: candidate solution batches and evaluation results. "Complete" means information must not be incomplete—objective vectors, constraint violation, and variable bounds must all be present. Returning only a single scalar fitness permanently loses constraint information, making constrained problems difficult to handle correctly.

Input/output interaction diagram between the algorithm module and the problem module

The algorithm module handles candidate solution generation, population updates, and search control, while the problem module evaluates candidate solutions into objective values, fitness, or constraint violation. The two interface back and forth through the contract of candidate solution batches and evaluation results—one submission and return constitutes one generation of evolution. The contract must carry both objective vectors and constraint violation; otherwise, multi-objective trade-off and constraint information is lost at the interface, and reuse and transferability are lost along with it.

Question 1

In EvoX's decoupled foundation, which part is responsible for "how to search"?

Visualization module: plotting convergence curves

Data module: storing historical best solutions

Algorithm module: generating candidate solutions and updating the population

Problem module: defining objectives and constraints

Question 2

What is the core responsibility of the problem module?

Controlling population size and iteration count

Converting candidate solutions into objective values, constraint violation, or environment interaction results

Executing crossover and mutation operators to produce new individuals

Deciding which selection strategy and non-dominated sorting to use

Question 3

What is the typical data flow of the interface contract between the algorithm module and the problem module?

The algorithm module produces candidate solution batches, and the problem module returns evaluation results

The problem module first produces candidate solutions, and the algorithm module returns objective values

Both sides run independently with no data exchange needed

Data is exchanged only once, at the moment the experiment ends

Question 4

Regarding the independent extension capability brought by decoupling, which of the following descriptions is correct?

Decoupling only works for simple single-objective, unconstrained problems

When replacing the evolutionary algorithm, the problem module's evaluation logic must be rewritten accordingly

As long as the interface contract remains unchanged, replacing either side requires no rewriting of the other

Adding a new problem requires reimplementing the entire selection and update mechanism

Question 5

If evaluation results return only a single scalar fitness and discard constraint and structural information, what is the most likely consequence?

The problem module becomes more general and easier to reuse

The computational accuracy of objective values automatically improves

The algorithm cannot obtain constraint feedback, making constrained problems difficult to handle correctly

The evolutionary process will certainly converge faster

Case Study: Migrating from Airfoil Aerodynamic Optimization to Wing Structural Weight Reduction

Read the scenario and answer the following questions using module separation and interface contracts.

A team has built an evolutionary workflow on EvoX. The problem module parameterizes the airfoil geometry as candidate solutions, calls a surrogate model for fast evaluation, and returns two objectives (cruise lift-to-drag ratio, buffet lift coefficient) along with the violation of one constraint (maximum stress must not exceed the material's allowable value); the algorithm module handles population initialization, mutation, crossover, selection, and iteration control. The team now plans to do two things: first, replace the current evolutionary algorithm with another multi-objective algorithm; second, reuse the same algorithm module to optimize the wing's internal structure, minimizing structural weight while satisfying stiffness and geometric feasibility constraints. The design premise of the entire workflow is that both sides are connected through a stable interface contract and are unaware of each other's internal implementation.

1. When replacing the evolutionary algorithm, does the airfoil's problem module need to be rewritten? Explain your reasoning with reference to the interface contract.

Answer:
No rewriting is needed. The contract exposed by the problem module is "input candidate solution batch, output evaluation results (objective vectors and constraint violation)," which is independent of whatever selection, update, or sorting mechanism the algorithm uses internally. After replacing the algorithm, the new algorithm still submits candidate solutions and reads evaluation results in the same format, so the same problem module can continue to be used. Only when the interface itself changes (for example, from a single-objective scalar to objective vectors plus constraint violation, or changing the encoding format of candidate solutions) do both sides need to adjust how they connect—and this is a contract upgrade, not a rewrite of the problem's evaluation logic.

2. When reusing the same algorithm module for the "structural weight minimization" problem, what information must the problem module at minimum return? Why is none of this information dispensable?

Answer:
At minimum, three types of information must be returned: ① objective values, i.e., structural weight (or an objective vector if stiffness metrics are also considered); ② constraint violation, i.e., the degree of violation for constraints such as stiffness and geometric feasibility; ③ the variable dimensions and value ranges of the search space, used to generate valid candidate solutions. None is dispensable because the algorithm module only handles search and does not understand specific physical quantities: it needs objective values to judge individual quality, constraint violation to distinguish feasible from infeasible and perform constraint handling, and consistent variable bounds to ensure generated candidate solutions are valid. If only a single scalar fitness is returned, constraint and dimension information is discarded, and the algorithm can neither handle constrained structural problems nor migrate smoothly from the airfoil task—reuse then fails.