**Project** `gemseo/dev/gemseo-bilevel-outer-approximation` **Reproduced on** `develop` at `1279c11076e136a1991057c7fb1970e9d7d74d41`, with `gemseo` 6.3.3, `ortools` 9.15.6755, Linux, CPython 3.12. **Severity** wrong results. No exception; in one of the two regimes below, no warning and no flag either. **Fix** not proposed — the repair is a design choice, see the end. Found while writing the tests for !141, and reported separately because it is neither of the two faults that merge request fixes (#9) and is more serious than both: nothing raises. ## Summary `OrtoolsMILP._run` builds its model from two sources that disagree about coordinates: ```python _x_0, l_b, u_b = get_value_and_bounds( # <- NORMALISED, by default problem.design_space, normalize_ds=self._settings.normalize_design_space, as_dict=False, ) obj_coeff = problem.objective.original.coefficients[0, :].real # <- NOT normalised constraints = list(problem.constraints.get_originals()) # <- NOT normalised ``` `normalize_design_space` defaults to `True`. The **variable bounds** are therefore scaled to $[0, 1]$ while the **objective and constraint rows** keep the coefficients of the original design space. The solution is then read back as though it were normalised and scaled to the real bounds. So a continuous design space whose bounds are not already $[0, 1]$ produces a model whose box and whose rows are in different coordinate systems, and a point that satisfies neither problem. ## Observed Minimise $-2x - y$ subject to $x + y \le 3$, $x - y = 1$, over $0 \le x, y \le 5$. The optimum is $x = (2, 1)$, $f = -5$. Instrumenting `Solver.Solve` shows what the solver is actually handed: ```text normalize_design_space=True solver: 2 vars, 3 rows -> OPTIMAL x_1: lb=0.0 ub=1.0 value=1.0 <- bounds normalised x_2: lb=0.0 ub=1.0 value=0.001 <- rows are x+y<=3, x-y=1, unnormalised point reaching the database: [5.0, 0.005] <- the above, scaled back up by 5 g = 2.005 (violates x + y <= 3) h = 3.995 (violates x - y = 1) reported: x_opt=[2.5 2.5] f_opt=-7.5 is_feasible=False ``` `[2.5, 2.5]` is the **starting point**. Every point the run evaluated was infeasible, so the least infeasible one is reported. ## Two regimes, and only one of them is noisy What the scale does depends on whether the bound range is wider or narrower than the unit interval. **Range > 1 — the point is pushed out, and the run says so.** As above: no feasible point is found, `is_feasible` is `False` and a warning is logged. A caller that checks `is_feasible` is protected; one that reads `f_opt` is not. **Range < 1 — the point is pulled back in, and nothing says anything.** Minimise $-x$ subject to $x + y \le 0.4$ over $0 \le x, y \le 0.5$. The optimum is $x = (0.4, 0)$, $f = -0.4$: | | `x_opt` | `f_opt` | `is_feasible` | | --- | --- | --- | --- | | `normalize_design_space=True` | `[0.2, 0]` | **-0.2** | **`True`** | | `normalize_design_space=False` | `[0.4, 0]` | -0.4 | `True` | | `Scipy_MILP`, either way | `[0.4001, 0]` | -0.4001 | `True` | A converged, feasible, **wrong** answer — half the optimum — with no exception, no warning and no flag. This is the regime that matters. ## `Scipy_MILP` is not affected It returns the same answer with normalisation on and off, on both problems above, so the contract is already honoured by the sibling library and this is specific to `OrtoolsMILP`. ## Why the master never sees it — and that it already knows Most directly: **the master forbids the setting.** `BiLevelMasterOuterApproximation_Settings` declares ```python normalize_design_space: bool = Field( default=False, frozen=True, description=( "The design space normalization must be ``False``. It cannot be changed." ), ) ``` So the project has already concluded that normalising is wrong here and has frozen it off for its own solver — while `OrtoolsMILP` still defaults it to `True` for everyone else. That is the gap this issue is about. It would escape anyway, for two further reasons, though both are accidents of its design space rather than guarantees: - its one-hot components are bounded $[0, 1]$ already, where normalising is the identity; - its epigraph variable `eta` is unbounded, and an infinite bound is not normalised — confirmed, `get_value_and_bounds` returns `-inf`/`inf` unchanged under either setting. The `test_milp.py` fixture is bounded $[0, 1]$ too, which is why the suite is green. Any caller reaching for `ORTOOLS_MILP` with its own design space is exposed, and gets `True` unless they know to say otherwise. Integer variables are unaffected in general: they are never normalised. ## Reproducing ```python from gemseo.algos.design_space import DesignSpace from gemseo.algos.opt.factory import OptimizationLibraryFactory from gemseo.algos.optimization_problem import OptimizationProblem from gemseo.core.mdo_functions.mdo_function import MDOFunction from gemseo.core.mdo_functions.mdo_linear_function import MDOLinearFunction from numpy import array names = ["x", "y"] design_space = DesignSpace() for name in names: design_space.add_variable(name, lower_bound=0.0, upper_bound=0.5, value=0.1) problem = OptimizationProblem(design_space, is_linear=True) problem.objective = MDOLinearFunction( array([-1.0, 0.0]), "f", MDOFunction.FunctionType.OBJ, names, 0.0 ) problem.add_constraint( MDOLinearFunction(array([1.0, 1.0]), "g", input_names=names), 0.4, MDOFunction.ConstraintType.INEQ, ) result = OptimizationLibraryFactory().execute(problem, algo_name="ORTOOLS_MILP") print(result.x_opt, result.f_opt, result.is_feasible) # [0.2 0.] -0.2 True expected [0.4 0.] -0.4 True ``` On `develop` this snippet raises instead, on the absent-equality fault of #9; run it against !141, or add an equality constraint, to reach the behaviour above. ## The repair is a choice Three ways, and which one is right depends on what `ORTOOLS_MILP` is meant to promise its callers: 1. **Build the rows from the normalised functions** rather than the originals, so the whole model is normalised, and denormalise the solution. Consistent with what the setting says, and the most work. 2. **Ignore the setting and always take unnormalised bounds**, since the rows are unnormalised anyway. One line, and it makes the results correct today, but it silently disregards a setting the caller set. 3. **Reject `normalize_design_space=True`** for this library, so the mismatch is a refusal rather than a wrong number. A MILP has no conditioning argument for normalising in the first place — the solver is exact and scale-free in a way a gradient method is not — and the master's own settings already say as much, in as many words. So 2 or 3 look more faithful to the project's existing position than 1, and 3 has the merit of never silently changing an answer anyone is currently getting. Which of them the library should do is still a maintainer's call — the setting is inherited from `BaseOptimizationLibrary`, so the choice touches an API promise and not only this function — which is why this is reported rather than patched.