**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** `TypeError` before any row is built; no model is produced. **Fix** proposed, see the merge request. These two are the faults recorded at the end of #8, filed on their own so that they outlive it: #8 is the model-construction performance issue and is closed by !140, which leaves these untouched. ## Summary `OrtoolsMILP._run` raises a `TypeError` before a single row reaches the solver on two shapes of problem. Both are reachable on `develop`, and the suite covers neither. ## 1. A design space of integer variables only cannot be solved ```text TypeError: in method 'Solver_IntVar', argument 2 of type 'double' ``` `Solver.IntVar(xl, xu, name)` takes its bounds as C `double`, and SWIG rejects a NumPy integer for them rather than converting it. The bounds come from `get_value_and_bounds`, and **integer variables are never normalised**, so a design space carrying nothing but integers hands `_run` an `int64` array: | design space | `normalize_ds` | `lower_bound` | dtype | | --- | --- | --- | --- | | all float, `[0, 5]` | `True` | `[0. 0.]` | `float64` | | all float, `[0, 5]` | `False` | `[0. 0.]` | `float64` | | all integer, `[0, 5]` | `True` | `[0 0]` | **`int64`** | | all integer, `[0, 5]` | `False` | `[0 0]` | **`int64`** | A mixed design space is unaffected: one float variable makes the whole array `float64`. The master carries a continuous epigraph variable beside its binaries, so it never reaches this. ## 2. A problem carrying only one kind of constraint raises `build_constraints_matrices` documents its return as `tuple[ndarray | None, ndarray | None]` and returns `(None, None)` for a kind of constraint the problem does not carry. `_run` reads it unguarded, and fails **either way round**, with a different error each way: | the problem carries | error | | --- | --- | | inequalities only | `TypeError: unsupported operand type(s) for -: 'NoneType' and 'float'` | | equalities only | `TypeError: 'NoneType' object is not iterable` | The first is `eq_rhs - self._settings.eq_tolerance`; the second is the inequality loop reading `ineq_lhs`. Only the first is recorded in #8 — the absent-inequality case fails earlier and differently. `SciPyMILP` reads the same helper and guards each block with `if ... is not None`, so the contract is already handled that way elsewhere in `gemseo`. ## Why the suite does not catch either The `test_milp.py` fixture mixes a float with an integer **and** carries an inequality and an equality, so it misses both. So does the master, for the same two reasons. Nothing else builds a MILP. ## Reproduction `tests/algos/opt/test_milp_degenerate_problems.py`, in the merge request: ```text without the fix 13 failed, 1 passed with the fix 14 passed ``` The one that passes without the fix is the continuous, both-kinds case — the shape the existing fixture already covers. ## A third fault, in the same function, reported not fixed Found while writing those tests, and **worse than either of the above** in that nothing raises. `_run` takes its variable bounds from `get_value_and_bounds`, which **normalises** them, and its rows from `problem.constraints.get_originals()`, which does not. With the default `normalize_design_space=True`, a continuous design space whose bounds are not already $[0, 1]$ therefore gets a model whose bounds and whose rows are in different coordinates. On $\min -2x - y$ subject to $x + y \le 3$, $x - y = 1$, $0 \le x, y \le 5$: | | `x_opt` | `f_opt` | | --- | --- | --- | | `normalize_design_space=True` | `[1, 1]` | `-3` | | `normalize_design_space=False` | `[2, 1]` | `-5` | | by hand | `[2, 1]` | `-5` | `[1, 1]` is the starting point and it violates the equality; the run reports it without an exception. Integer variables are unaffected, not being normalised. The master escapes this too, its binaries being $[0, 1]$ already — where normalising is the identity — and its epigraph variable unbounded. Left unfixed here because the repair is a choice between normalising the rows and not normalising the bounds, and which of those the master and its callers should get is a maintainer's call.