Summary
cuOptCreateProblem fails with CUOPT_INVALID_ARGUMENT for any problem with zero linear constraints — including pure bound-constrained LPs and QCQP-style problems (quadratic constraints only, no linear rows).
Repro (Java, but this is a C API issue)
try (Problem problem = new Problem("no-constraint")) {
Variable x = problem.addVariable(0.0, 10.0, 1.0, VariableType.CONTINUOUS, "x");
problem.setObjective(x, ObjectiveSense.MINIMIZE);
try (Solution solution = problem.solve()) { // throws here
System.out.println(solution.getTerminationStatus());
}
}
Exception in thread "main" com.nvidia.cuopt.mathematicaloptimization.CuOptException: cuOptCreateProblem failed with status 1
at com.nvidia.cuopt.mathematicaloptimization.NativeCuOpt.createProblem(Native Method)
...
Same failure with any zero-linear-constraint problem, e.g. a QuadraticExpression constraint with no linear rows, or a single SEMI_CONTINUOUS variable with no addConstraint calls at all.
Root cause (traced, not fixed)
cuOptCreateProblem (cpp/src/pdlp/cuopt_c.cpp:338) has no explicit num_constraints <= 0 check itself — unlike sibling functions such as cuOptSetInitialDualSolution, which does. The failure comes from a raft::exception thrown somewhere inside problem->set_csr_constraint_matrix(...) (or a related setter) on a zero-row CSR matrix, caught and converted to CUOPT_INVALID_ARGUMENT. Not traced further than that.
Why this looks unintentional
- No explicit validation rejects it at the API boundary (contrast with the
num_constraints <= 0 check present elsewhere in the same file).
- Pure bound-constrained LPs and quadratic-only-constrained problems are mathematically valid; other solvers support them.
Impact
Found while writing/testing Java doc examples for #1999 — had to add an artificial non-binding linear constraint to two examples (quadratic-constraint-only, and a semi-continuous variable with no other constraints) purely to work around this.
Ask
Could someone with more context on the CSR/problem construction path confirm whether zero-row problems are meant to be supported, and if so where the fix belongs?
Summary
cuOptCreateProblemfails withCUOPT_INVALID_ARGUMENTfor any problem with zero linear constraints — including pure bound-constrained LPs and QCQP-style problems (quadratic constraints only, no linear rows).Repro (Java, but this is a C API issue)
Same failure with any zero-linear-constraint problem, e.g. a
QuadraticExpressionconstraint with no linear rows, or a singleSEMI_CONTINUOUSvariable with noaddConstraintcalls at all.Root cause (traced, not fixed)
cuOptCreateProblem(cpp/src/pdlp/cuopt_c.cpp:338) has no explicitnum_constraints <= 0check itself — unlike sibling functions such ascuOptSetInitialDualSolution, which does. The failure comes from araft::exceptionthrown somewhere insideproblem->set_csr_constraint_matrix(...)(or a related setter) on a zero-row CSR matrix, caught and converted toCUOPT_INVALID_ARGUMENT. Not traced further than that.Why this looks unintentional
num_constraints <= 0check present elsewhere in the same file).Impact
Found while writing/testing Java doc examples for #1999 — had to add an artificial non-binding linear constraint to two examples (quadratic-constraint-only, and a semi-continuous variable with no other constraints) purely to work around this.
Ask
Could someone with more context on the CSR/problem construction path confirm whether zero-row problems are meant to be supported, and if so where the fix belongs?