Question on relaxing feasibility tolerances in GLOP (C# API)

[Alfred Manoj]

Hello OR-Tools / GLOP team,

I’m reaching out for guidance regarding feasibility tolerances in the GLOP solver and how to correctly relax them.

We have a linear feasibility model for which GLOP is able to find a solution reliably using the default parameters. With the defaults (notably primal_feasibility_tolerance = 1e-8), the solver converges in ~ 740-750 iterations and returns a valid solution.

For our use case, we would like to be more lenient on feasibility - specifically allowing slightly larger bound or constraint violations. To do this, we attempted to relax the tolerance by setting:

• primal_feasibility_tolerance = 1e-7

(using the C# API via SetSolverSpecificParametersAsString).

Unexpectedly with this change, the solver no longer converges as expected. While the default settings consistently find a solution, the run with the relaxed tolerance does not.

To rule out mismatched feasibility criteria, we also tried explicitly setting:

• dual_feasibility_tolerance = 1e-7

However, this did not change the behavior.

Given that numerically 1e-7 is a looser tolerance than the default 1e-8, we were expecting feasibility to be easier to satisfy, not harder.

Our questions are:

1. Is relaxing feasibility tolerances in GLOP (e.g., to 1e-7 or 1e-6) a supported and recommended use case?

2. Are there additional parameters that should be adjusted in conjunction with primal_feasibility_tolerance when relaxing feasibility requirements?

3. Is there known solver behavior where loosening feasibility tolerances can lead to non-convergence or solver stalling due to changes in pivot selection or numerical stability?

4. Are there best-practice guidelines for using GLOP when a looser feasibility acceptance is desired, particularly when using the C# API?

For context:

• We are using the C# API of OR-Tools.

• The model is continuous (no integer variables).

• The objective is zero; this is effectively a feasibility problem.

• Default parameter settings solve the model reliably.

Any guidance on the correct parameter combinations or recommended approach would be greatly appreciated.

Thank you for your time and for maintaining OR-Tools.

Regards,

Alfred

[Frederic Didier]

Hi,

It is hard to tell without looking at the logs.

Can you send us the problem so we can run it ourselves ? That would be the easiest for us to have a look at what is going on.

Usually, when changing tolerances has a big impact, it means your problem might not be numerically stable, scaling it to have a lower range of coefficients/bounds might help.

--
You received this message because you are subscribed to the Google Groups "or-tools-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to or-tools-discu...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/or-tools-discuss/ef493490-3696-4891-90de-2e764ac592bfn%40googlegroups.com.