glp_simplex warning in remove_redundant_vertices

[schillic]

The following simple example (non-LazySets code) triggers glp_simplex warnings when presolve is active in the solver.

julia> using Polyhedra
julia> import GLPK, JuMP
julia> P = vrep([
 [1.0, 1.0, 1.0],
 [-1.0, 1.0, 1.0],
 [1.0, -1.0, 1.0],
 [-1.0, -1.0, 1.0],
 [1.0, 1.0, -1.0],
 [-1.0, 1.0, -1.0],
 [1.0, -1.0, -1.0],
 [-1.0, -1.0, -1.0]
]);

# presolve off
julia> solver = JuMP.optimizer_with_attributes(GLPK.Optimizer, "presolve" => GLPK.GLP_OFF);
julia> removevredundancy(P, solver);  # no warnings

# presolve on
julia> solver = JuMP.optimizer_with_attributes(GLPK.Optimizer, "presolve" => GLPK.GLP_ON);
julia> removevredundancy(P, solver);  # prints warnings
glp_simplex: unable to recover undefined or non-optimal solution
glp_simplex: unable to recover undefined or non-optimal solution
glp_simplex: unable to recover undefined or non-optimal solution
glp_simplex: unable to recover undefined or non-optimal solution
glp_simplex: unable to recover undefined or non-optimal solution
glp_simplex: unable to recover undefined or non-optimal solution
glp_simplex: unable to recover undefined or non-optimal solution
glp_simplex: unable to recover undefined or non-optimal solution

(This warning is printed in the following test files: Polytope, Polyhedron, CartesianProduct, concrete_convex_hull, but maybe not all for the same reason.)

I asked in JuliaPolyhedra/Polyhedra.jl#315.

[schillic]

I finally understood that this is expected behavior. The GLPK presolver prints a warning whenever the LP is infeasible. The options to avoid the warning seem to be to either raise the verbosity level or to not use the presolver. I personally find this a questionable design decision because feasibility queries are very common (as in this example).