The current LP interface of Fast Downward assumes that constraints are two-sided, i.e., lb <= a^{T}x <= ub. However, all currently implemented LP-generating algorithms only use one-sided constraints (a^{T}x <= ub, a^{T}x >=, or a^{T}x = b). 

We believe that making one-sided constraints the default would simplify the implementation of many solver backends. A branch with the current implementation is here:

https://github.com/remochristen/downward/tree/issue1199-part1

We modified the branch with the new interface so that the redundant constraints were added back.  This modification is not enough to replicate the behavior of the old interface. In the old interface, a model is created with a single two-sided constraint, i.e., lb <= a^{T}x <= ub, while the modification we are testing creates a model with two one-sided constraints, i.e., a^{T}x >= lb and a^{T}x <= ub. The branch with the modification is here: 

https://github.com/remochristen/downward/tree/issue1224-redundant-constraints. 

We compared the implementation of the new interface with and without this change on the full optimal benchmark suite.  

The results are here:
https://ai.dmi.unibas.ch/_experiments/ai/downward/issue1224/data/sprint2026_lpsolvers-issue_1224_redundant_constraints-eval/

A comparative report is here: 
https://ai.dmi.unibas.ch/_experiments/ai/downward/issue1224/data/sprint2026_lpsolvers-issue_1224_redundant_constraints-eval/comparativereport.html#summary

For references, the revisions we consider are 
- baseline: baseline Fast Downward
- baseline_new_interface: implementation of the new interface
- new_interface_redundant_constraints: new interface + redundant constraints

Results: for CPLEX, coverage drops from 494 to 492 with config OC_hplusLP, and from 540 to 536 with config OC_hplus. For SoPLEX, coverage drops from 497 to 488 with config OC_hplusLP. SoPLEX does not support MIPs, so we cannot test config OC_hplus.

In summary, adding the redundant constraints back as two one-sided constraints does not seem beneficial.

We believe we found a reason for the performance variation observed with the OC_hplusLP configuration. 

For this config, the LP constraints are created in the file delete_relaxation_rr_constraints.cc. In the implementation of the new interface, this file was modified to avoid adding redundant constraints to the model. Apparently, removing these constraints can reduce performance, particularly in the miconic domain. 

We did the following experiment: the redundant constraints in delete_relaxation_rr_constraints.cc are added in line 353, which looks like this:
    lp::LPConstraint constraint(0, 1)
This line adds a constraint of the form 0 <= a^{T}x <= 1. We replaced this line with 
    lp::LPConstraint constraint(0, infinity)
which adds a constraint of the form 0 <= a^{T}x. 

We then compared the baseline and this modified version on the miconic domain. Notice that we are not testing the new interface here, but only baseline Fast Downward with and without a simple modification. 

Results: https://ai.dmi.unibas.ch/_experiments/ai/downward/issue1224/data/sprint2026_lpsolvers-issue_1224-eval/

Coverage with CPLEX dropped from 121 to 114, and with SoPLEX from 104 to 93. 

For comparison, in the previous experiment comparing the baseline with the new interface, CPLEX coverage dropped from 121 to 114, and SoPLEX from 103 to 94. 

In summary, the observed variation for config OC_hplusLP in the miconic domain seems related to these redundant constraints that are not being added.

We ran experiments comparing Fast Downward with our changes against a baseline version of Fast Downward. The experiments used A* with the following heuristics:
- Diverse potential heuristic (*-potentials)
- Operator counting over h^+ constraints (*-OC_hplus)
- Operator counting over h^+ constraints LP relaxation (*-OC_hplusLP)
- Landmark cost partitioning over RHW and h^1 landmarks (*-lmcut)
- Operator counting over state equation and LM-cut constraints (*-OC_se_lmcut)
- Potential heuristic optimized for all states (*-all_states_potentials)
 

Each combination of LP solver and heuristic (11 combinations) was evaluated on the full optimal benchmark suite. The data is available here:

https://ai.dmi.unibas.ch/_experiments/ai/downward/issue1224/data/

Some visualizations are here:

- Diff tables: https://ai.dmi.unibas.ch/_visualizer/?c=eJyNkcGKwjAQhl-l5Nw2thZFr3td2L2LhNl2VgNpGjJTlZW--yYKy4Jt9RBImi_f_DO9ihN60p0V20SU-UKkifDo4nEZtg0whO1V9N5E4sjsaCsl6Lxpdd5b_QWU10ep8OLQ6xYtU7iVTXe2Z_CN1EQ9FmVZyeiS5Ly2XC7KlTKOOhOrZ3em2GyUA89Fhicw0vkuGFkj5Qw-v_zEaHA40C1PFdO0CDZ-XcYD9a0Yhnv8GwLMPsK70Mg6TYpFmpRVWKs0qeJa76PQ3ZCdCH2g0Raz2hm8ZB9v6uhMT1Fv8axCaPTfUD_cB8nk4_fPZ88DMSEgVKate54x_CFjCjBGEQMjKddx-C0azGQ34_CYdjbTdJrnESbrUvd0po_IlGJ6qiPMqOTFuc7So-L5XDOJXojxv_Z-GH4BxqdjVQ%3D%3D


- Scatter plot: https://ai.dmi.unibas.ch/_visualizer/?c=eJyNkcFuwjAMhl8F5UwbWtgkuO46absjFHmtB5HSNIpd6Ib67ktAmpBoCje7-fP5i3sWR_SkWys2M1HmCzGfCY8uti-hrIEhlGfReRMTB2ZHGylB53Wj887qL6C8OkiFvUOvG7RM4VTW7cmewNdSE3VYlOVKRpYk57XlclG-KuOoNXF6ds0U67Vy4LnI8AhGOt8GImuknMHn_W9Ug_2eLj6raNMg2Ph1GRvqGjEMV_1LpAdmH6plfMjPbQMuQrZbEeTRaItZ5Qz22cebOjjTUWRaPKlgiv4bqrvz3XyWvPz--eh6SCQAhMo0VccThP_IGAKMUcTASMq1HP6FBpN8zXh4DDvplLZ5rJCcS-3Dnd5HUoj0Vkcyo5An9zqZHgVPe00YPaFxO3s3DH-akGJc

Some comments:
1) Overall, the changes increased coverage for most configurations and reduced memory usage.
2) CPLEX performance increased substantially for configs OC_hplus and lmcut. For OC_hplusLP, performance varied considerably on some tasks, and I do not know how to explain this variation. Performance remained approximately the same for the other configurations.
3) SoPLEX performance remained approximately the same for most configurations. For OC_hplusLP, there was also considerable variation that I cannot explain.
4) For every task solved by both the baseline and modified versions, I checked whether the number of expansions, number of evaluations, plan cost, and plan length were equal. They were equal in every case.