Race, Exchange, Improve: Finding high-quality MIP solutions quickly

Race, Exchange, Improve: Finding high-quality MIP solutions quickly Gioni Mexi1 and Daniel Rehfeldt1,2

arXiv:2609.05954v1 [math.OC] 5 Sep 2026

2

1 Zuse Institute Berlin, Takustraße 7, 14195 Berlin, Germany IVU Traffic Technologies AG, Bundesallee 88, 12161 Berlin, Germany {mexi, rehfeldt}@zib.de

Abstract Mixed-integer programming (MIP) is a cornerstone in applied optimization, both in industry and academia. Recently, there has been increased attention to finding strong primal solutions quickly. This is reflected, for example, in the development of the NVIDIA cuOpt solver and, most recently, in the new MIPFEAS benchmark, which has a tight time limit of 600 seconds and evaluates solvers based on how quickly they find high-quality primal solutions. This article introduces a MIP portfolio parallelization scheme, focusing on efficiently exchanging information between its workers. We present two implementations of this scheme: one built directly into the open-source MIP solver SCIP, and an external one, which we call ReXi. ReXi is currently the fastest non-commercial solver in the MIPFEAS benchmark, followed by the SCIP-integrated implementation. Moreover, we present new versions of both implementations that considerably outperform their predecessors on the MIPFEAS benchmark.

1

Introduction

Mixed-integer programming solvers have long been a standard tool for solving optimization problems in virtually all industry sectors as well as in academia. Several powerful commercial (e.g., CPLEX [16], Gurobi [12], Xpress [1], and COPT [8]) and academic (e.g., SCIP [13], HiGHS [14], and CBC [7]) solvers are available. Recently, there has been increased attention to finding strong primal solutions quickly. Examples are the development of the NVIDIA cuOpt solver [20] and, most recently, the release of the MIPFEAS benchmark [3], which has a tight time limit of 600 seconds and evaluates solvers based on the primal integral [2], which favors methods that quickly find high-quality solutions. At the same time, improved hardware, such as GPUs and modern multicore CPUs, provides additional opportunities for accelerating MIP solving. Running multiple solver configurations in parallel can exploit their complementary strengths, an idea already used in parallel solver frameworks such as FiberSCIP [24] and CP-SAT [21]. An early demonstration for MIP is due to Carvajal et al. [4], who race diversified workers that exchange incumbent solutions and bounds. This article introduces a shared-memory parallel framework, based on SCIP, aimed at finding high-quality solutions within short running times. It is implemented both directly in SCIP, extending its concurrent solving framework, and in a new, more specialized solver called ReXi. Both implementations build a racing portfolio of diversified SCIP workers, each using one thread. No coordinator thread is used, but information is shared between workers through a solution pool and a bound pool, both designed for minimal blocking. Importantly, some of the workers are run without presolving, which allows finding solutions more quickly, while some of the lost problem strengthening is regained via the bound pool (which communicates some of the presolving results of other workers). With the focus being primal feasibility, ReXi devotes two of its workers 1

entirely to primal heuristics, a highly optimized local search and a large neighborhood search, rather than to branch-and-bound search. We report a computational study that separates the contribution of racing, of each exchange mechanism, and of the two primal workers. While none of the components is completely new, the main contribution of this article lies in incorporating them into a lean design, based on SCIP, with a carefully optimized implementation. Using ten threads, this improves the primal integral by more than a factor of five over single-threaded SCIP. ReXi is currently the fastest non-commercial solver in the MIPFEAS benchmark [3], followed by concurrent SCIP. Moreover, the latest version of ReXi is considerably faster and is on par with the average performance of three leading commercial solvers on this benchmark. It should be noted, however, that these commercial solvers are run with their default settings, whereas ReXi is specifically designed to find high-quality primal solutions quickly. The remainder of this article is organized as follows. Section 2 describes the framework along its three pillars: the racing portfolio, the exchange of solutions and bounds, and the dedicated primal workers. Section 3 presents the two implementations, and where they differ. Finally, Section 4 reports the computational study.

2

Race, Exchange, Improve

The architecture is based on three pillars, encoded in the name of the new solver ReXi1 : – Race: MIP solvers are well known for their performance variability [18]. A diversified portfolio can transform this behavior into an asset [15, 10, 6]. – Exchange: We aim to share as much relevant information as possible among workers, while keeping overhead minimal. This includes the exchange of primal solutions, primal bounds, and variable bounds. – Improve: LP-free heuristics can sometimes outperform MIP workers. Thus we include such heuristics in our solver. Instead of calling them within a MIP worker, we give them a full thread for continuous work, but still tightly integrate them with the MIP workers via mutual solution and primal bound exchange. Much effort went into spending as little time as possible on exchanging information. Notably, we do not use a coordinator or supervisor thread, but exchange information via shared data structures. The communication is not lock-free, but in practice has minimal contention and very short waiting times. Figure 1 gives an overview.

2.1

Race: The Portfolio

ReXi races N independent SCIP instances on the same model, each with its own parameter setting and its own random seed. We use the following ten SCIP settings: default SCIP; no separation combined with fast presolve; two emphasis feasibility settings that differ only through seed diversification; no presolving; SAT-like depth-first search without any LP solves; periodic feasibility jump; periodic local search; a local search running perpetually; and depth-first search with aggressive restarting and primal heuristics. These ten settings are exactly the portfolio raced by SCIP’s concurrent mode and ReXi. Note that ReXi runs ReXiLS perpetually instead of SCIP’s local search, and replaces another setting by a large neighborhood search (LNS) worker, as described in Section 2.3. The workers do different amounts of presolving, some none at all, and use different search strategies, primarily to find good solutions quickly, but also to diversify the search. 1

Which, by sheer luck, also happens to fit the last names of the authors.

2

branch-and-bound workers SCIP1

SCIP2

best objective

···

SCIP8

solution pool

primal workers ReXiLS

ReXiLNS

bound pool

Figure 1: Architecture of ReXi. Every worker races the same model and communicates only through the shared structures (Section 2.2). Eight workers run branch-and-bound with diversified settings (Section 2.1); ReXiLS and ReXiLNS own a thread each (Section 2.3). Concurrent SCIP uses the same layer with ten branch-and-bound workers.

2.2

Exchange: Solutions and Bounds

We mostly exchange two classes of solving information among the workers. First, primal solutions and primal bounds, and, second, variable bounds. For solution and primal bound exchange, we use a two-lane approach: The fast lane exchanges only the current best primal bound. The exchange has negligible overhead but still delivers very important information (for example, to cut off branch-and-bound trees or for reduced-cost fixing). The slow lane exchanges actual primal solutions via a pool described in the following. The solutions are exchanged less often to minimize overhead. More accurately: they are pulled less often from the pool, but published right away. The latter is especially important for the two side-heuristics described in the next subsection. For the solution pool, we use the following: – Solutions in the pool live in the original (unpresolved) space. This is important because workers do different presolving. – Each worker publishes a new solution only if it is better than the current best one in the pool. – Each publisher is responsible for checking the feasibility of each solution in the original space before publishing. – We avoid waiting times when publishing solutions by using a pointer-based pool. Each worker creates the best solution in the original space, then checks for feasibility, and only then locks the pool for simply adding a pointer to this new solution. – As to pulling solutions (which is done less often): we transform the current best solution to the presolved space, which might lead to an invalid solution. In this case, we continue with the next best solution from the pool and so on. In contrast to the solution pool, for bound exchange we use fixed-size data structures to store globally valid variable bounds, which are strengthened through the solution process. Such sharing of bound tightenings between concurrently solving workers goes back to distributed domain propagation [11]. – Workers share bounds from domain propagation, but also from presolving. The latter benefits especially the workers that were run without presolving. – Improved bounds are published immediately. New bounds are only pulled at specific points, since the additional domain propagations that are triggered in SCIP after bound changes can be expensive.

3

– Strong dual reductions can only be performed by one worker. Otherwise, we could potentially cut off all optimal solutions. The main weak points of the bound pool used for SCIP are that strong dual reductions are confined to one worker, plus the cost of SCIP’s re-propagation of new bounds. More details on the implementation of both the bound and solution pool can be found in Section 3.

2.3

Improve: Primal Workers

There are three types of workers: – Standard branch-and-bound SCIP workers. These also work on the dual side, which in turn allows for finding better primal solutions. – One pure primal LP-free heuristic that runs perpetually. – One improvement heuristic that perpetually uses solutions added by other workers to the common pool and recombines them, running LNS. The local search worker runs an LP-free local search [17] on a minimally presolved problem. This heuristic maintains a single complete variable assignment and improves it by single-variable moves scored on constraint violation and objective value. The heuristic is restarted from the best incumbent in the pool whenever its own search stalls. This heuristic is especially important for instances that spend a significant amount of time in presolving or the initial root LP, because SCIP runs most other primal heuristics only afterwards. The LNS [23, 5] worker needs at least one reference point to define the search neighborhood. It takes the best solution in the shared pool; while the pool is still empty it takes the latest retained point of smallest constraint violation from the local search. From that reference it builds a neighborhood in one of two ways. Mutation fixes each integer variable independently with probability α to its rounded reference value. Crossover fixes the agreement set of two pooled solutions from different workers. Whenever an incumbent exists it is also imposed as an objective limit, so a neighborhood that contains nothing better is proven empty and abandoned quickly. The crossover mode is closely related to the evolutionary algorithm for polishing MIP solutions of Rothberg [22], known as solution polishing in CPLEX. Dedicating whole workers to large neighborhood search over a shared solution pool is also done by CP-SAT [21].

3

Two implementations: Concurrent SCIP and ReXi

This section describes the two implementations of the race-exchange-improve framework introduced in the previous section. Both are based on SCIP, but while the first one is directly implemented in SCIP, the second, ReXi, implements several key components outside of SCIP for increased efficiency. In this way, one can use more specialized data structures and implementations.

3.1

Concurrent SCIP

Our implementation builds on the existing concurrent SCIP framework, introduced in SCIP 4.0 [19]. That framework already races a portfolio of SCIP workers, with the difference that information is exchanged at fixed synchronization points. A solver that reaches the synchronization point writes its solutions and bounds into a shared store and then waits until every other solver has reached that point before reading. Therefore, 4

the exchange is only as fast as the slowest worker, and a solver that has just found a good solution cannot pass it on until the others have caught up. The solution and bound pools of Section 2.2 avoid this. We use a fast size-hint atomic to check for each consumer whether anything has been added to the pool since the last pull. The bound pool is relatively simple: static arrays, with the whole pool locked for each update or pull. Concurrent SCIP also uses a local search heuristic [17] that runs alongside the solve, which will be part of the SCIP 11 release.

3.2

ReXi

ReXi (including its two primal workers) is written in C++, making use of C++ parallelization utilities, such as threads, atomics and mutexes. The solution pool is mostly implemented as described in Section 2.2. As in concurrent SCIP, we use a size-hint atomic to check before each pull whether anything new has been added to the pool. The best primal bound is shared via a single atomic variable. The bound pool implementation includes some additional details compared to those given in Section 2.2. We experimented with bound pools from the literature, including the “dirty sets” implementation of OR-Tools/CP-SAT. However, in our application, we have the somewhat special case that, on the one hand, we have very aggressive updates of bound changes at the beginning of the solve, because we update the bounds also during presolving. On the other hand, different workers pull these bounds aggressively. On some instances this leads to noticeable blocking times (even though it never costs more than a few percent of runtime). We use the following design: – Three contiguous, fixed-size arrays over the original variables: lb, ub, var version. Bounds are monotone and overwritten in place, so memory is constant regardless of the number of tightenings, and a worker restarting its search can recover the complete current state with a single pull (important for workers without presolving). – The variable range is split into 32 contiguous shards, each with its own mutex and its own atomic published version. Updating or reading bounds locks exactly one shard, leading to reduced contention. – Per-reader state (seen versions, counters); the reader-owned fields are touched only by the owning thread. – Change detection is a three-level mechanism, to minimize blocking. As in the solution pool, one atomic global counter gives a lock-free fast path (to signify if anything has changed at all); the per-shard counters let a reader skip untouched shards without locking; and the per-variable versions give exactly the changed bounds within a locked shard. For each instance of the MIPFEAS benchmark, the waiting time of the above bound pool is far below 1 percent of the overall runtime, so completely negligible. Still, as already mentioned, there is a significant performance penalty from the rather slow repropagations triggered in SCIP. Similarly, using strong dual reductions only on one worker (as required when the bound pool is active) costs performance. For the local-search worker ReXiLS we mostly follow [17], but with an optimized implementation that is significantly faster than the one from [17]. For some key instances, for which local search finds the first good solution, we observe a speed-up of more than a factor of three compared to the original implementation. Besides ReXiLNS, described already in Section 2.3, another difference of ReXi compared to concurrent SCIP is the solution feasibility checking which happens before each publication in the solution pool. In ReXi this is performed with a more cache-efficient CSR-based check, which still uses the same tolerances as native SCIP, but is faster. 5

4

Computational Study

In this section, we measure the performance gains from racing, information sharing, the implementation differences and the two specialized workers of ReXi. Experiments are run on AMD EPYC 9B45 CPUs with up to 10 threads, a 96 GB memory limit and a 600 s time limit, with cluster nodes used exclusively. All runs use pre-release versions of SCIP 11 and its LP solver SoPlex 9. Our testset consists of the 233 instances of the MIPLIB 2017 benchmark [9], excluding instances known to be infeasible. For primal feasibility, the metric we use is the primal integral, in the form used by the MIPFEAS benchmark [3], which adapts the original definition of Berthold [2]. Let x̄(t) be the objective value of the incumbent at time t and x⋆ the reference value, and let  2, no feasible solution is known at time t,      x̄(t) and x⋆ have opposite signs, 1, p(t) = 0, |x̄(t)| < 10−6 and |x⋆ | < 10−6 ,     |x̄(t) − x⋆ |   , otherwise max{|x̄(t)|, |x⋆ |} be the penalty incurred at time t. Since p changes only when a new incumbent is found, it is piecewise constant, and its average over the time limit T is a finite sum: with 0 = t0 < t1 < · · · < tk ≤ T the times at which the incumbent improves and tk+1 = T , k

P (T ) =

1X p(ti ) (ti+1 − ti ) ∈ [0, 2]. T i=0

A value of 2 means that no feasible solution was found within the time limit; smaller values mean that good solutions were found earlier. In the tables below, “opt. found” counts instances whose reference objective was reached and “opt. proven” those on which the run closed its own primal–dual gap. Time and primal integral (PI) are shifted geometric means with shifts 1 s and 0.001. Table 1 gives the overall picture. It compares default SCIP, SCIP’s concurrent mode, and ReXi. The row marked “concurrent settings” races the same ten settings as SCIP’s concurrent mode (Section 2.1); the last row is ReXi in its default configuration, which replaces one of those settings by the LNS worker. Table 1: Performance comparison of default SCIP, SCIP’s concurrent mode, and ReXi with and without its LNS worker. threads feas. opt. found opt. proven time [s]

PI

SCIP SCIP concurrent ReXi (concurrent settings)

1 211 10 224 10 225

119 154 158

95 119 123

201.2 149.6 142.8

0.0568 0.0178 0.0134

ReXi

10 225

160

124

135.3 0.0107

Going from one thread to ten cuts the shifted geometric mean of the primal integral by 69%, from 0.0568 to 0.0178. It also adds 13 instances on which a feasible solution is found at all, and 35 on which the reference optimum is reached. Comparing the two SCIP runs against each other instance by instance, the ten-thread configuration is at least 10% better on the primal integral on 202 of the 233 instances, against 7 for the single-thread run. This is not the effect of a small subset of instances. As Figure 2 shows, the two distributions are separated over the whole range. The last two rows show ReXi. The third row races the same settings as concurrent SCIP, so the two differ only in the engine that runs the race and in the ReXiLS implementation. The 6

instances with PI ≤ x

200

SCIP, 1 thread SCIP concurrent ReXi (concurrent settings) ReXi

100

0 10−5

10−4

10−3

10−2

10−1

100

primal integral x

Figure 2: Cumulative distribution of the primal integral over the 233 instances, for the four configurations of Table 1. For a threshold x the curve gives the number of instances reaching a primal integral of at most x. shifted geometric mean of the primal integral is 0.0134 against 0.0178. The solution pool then enables further ideas, such as the LNS worker of Section 2.3, which in the last row replaces one of the portfolio settings. This brings the primal integral to 0.0107, another 20% below the row above it and 40% below concurrent SCIP, cuts solving time by 10% against concurrent SCIP and reaches the reference optimum on six more instances. We see the same effect on the dual side, where ReXi proves the most optima of the four, 124 against concurrent SCIP’s 119. Table 2 switches off one of the two exchange mechanisms at a time, leaving the ten-thread portfolio otherwise unchanged. Note that without solution exchange the LNS worker has nothing to build neighborhoods from, so it is not used and its seat falls back to the default portfolio setting, i.e. to the ReXi configuration of the third row of Table 1. Table 2: Effect of disabling one of the two exchange mechanisms in ReXi, ten threads. feas. opt. found opt. proven time [s] ReXi 225 no solution exchange 224 no bound exchange 224

160 150 157

124 115 124

PI

135.3 0.0107 156.0 0.0146 137.6 0.0118

Of the two mechanisms, solution exchange turns out to be the more important one. Without it the shifted geometric mean of the primal integral rises by 37%, from 0.0107 to 0.0146, solving time by 15%, and the number of instances solved to proven optimality falls from 124 to 115. The workers also find around 22% more solutions in total, since each of them has to rediscover solutions that another worker might have already discovered. Switching off bound exchange costs 10% on the shifted geometric mean, 0.0107 to 0.0118, one instance on which a feasible solution is found and three on which the reference optimum is reached, while the number of instances closed to proven optimality is unchanged at 124 and solving time rises by less than 2%. So the shared bounds help the workers find better solutions sooner, but they do not increase the number of instances on which we can prove optimality. Both concurrent SCIP and ReXi have been part of the MIPFEAS benchmark [3]. Table 3 compares the configuration above against the ReXi build used there. The improvements made since, including ReXiLS, bound sharing and the LNS worker, have lowered the shifted geometric mean of the primal integral by 35%, from 0.0164 to 0.0107; the reference optimum is reached on 12 more instances and proven on 8 more, and the shifted geometric mean of the solving time falls by 11%. Per instance the current build is at least 10% better on 165 of the 233 instances, against 26 the other way. On the benchmark itself the submitted build scores 0.0165 against 0.0105 for 7

the virtual mean commercial solver [3], so the 0.0107 of the current build (using a cross-machine comparison) is on par with the average of three leading commercial solvers. Default SCIP and its concurrent mode have likewise improved since their benchmark submissions, mainly through the introduction of the local search heuristic and improvements in the LP solver SoPlex (the latter were motivated by the development of ReXi). Table 3: ReXi against the build submitted to the MIPFEAS benchmark, ten threads. feas. opt. found opt. proven time [s] ReXi MIPFEAS submission

5

225 225

160 148

124 116

PI

135.3 0.0107 151.7 0.0164

Conclusion

Race, exchange, improve showed significant results. Racing diversified SCIP workers, exchanging solutions and variable bounds without a coordinator thread, and spending threads on specialized primal heuristics improves the primal integral on ten threads by more than a factor of five over sequential SCIP. On the MIPFEAS benchmark instances, the latest ReXi is competitive with the average of three leading commercial solvers. Multiple directions for further research are open. More threads and more specialized workers are among them, since the portfolio has ten settings today while the machines have many more cores. Also, workers of a different kind, such as GPU-based solvers, are left for future research. Acknowledgements The authors thank the current and former SCIP developers, whose work this framework builds upon. Further thanks go to Yuji Shinano for his work on FiberSCIP, which facilitated the use of SCIP in this work, and Michael Bussieck and GAMS for the MIPFEAS benchmarking initiative. Funding disclosure Research reported in this paper was partially supported through the Research Campus Modal funded by the German Federal Ministry of Education and Research (fund numbers 05M14ZAM, 05M20ZBM) and the Deutsche Forschungsgemeinschaft (DFG) through the DFG Cluster of Excellence MATH+.

References [1] Belotti, P., Berthold, T., Gally, T., Gottwald, L., Pólik, I.: Solving MINLPs to global optimality with FICO Xpress Global. Optimization pp. 1–19 (2025). DOI 10.1080/02331934. 2025.2595437 [2] Berthold, T.: Measuring the impact of primal heuristics. Operations Research Letters 41(6), 611–614 (2013). DOI https://doi.org/10.1016/j.orl.2013.08.007. URL https:// www.sciencedirect.com/science/article/pii/S0167637713001181 [3] Bussieck, M., Dirkse, S.: Expanding the focus: Introducing the MIPfeas benchmark. GAMS Blog (2026). URL https://www.gams.com/blog/2026/03/ expanding-the-focus-introducing-the-mipfeas-benchmark/. Accessed: 2026-08-31 [4] Carvajal, R., Ahmed, S., Nemhauser, G., Furman, K., Goel, V., Shao, Y.: Using diversification, communication and parallelism to solve mixed-integer linear programs. Operations Research Letters 42(2), 186–189 (2014). DOI 10.1016/j.orl.2013.12.012 [5] Danna, E., Rothberg, E., Pape, C.L.: Exploring relaxation induced neighborhoods to improve MIP solutions. Mathematical Programming 102(1), 71–90 (2005) 8

[6] Fischetti, M., Monaci, M.: Exploiting erraticism in search. Operations Research 62(1), 114–122 (2014). DOI 10.1287/opre.2013.1231 [7] Forrest, J., Lougee-Heimer, R.: CBC user guide. In: Emerging theory, methods, and applications, pp. 257–277. INFORMS (2005) [8] Ge, D., Huangfu, Q., Wang, Z., Wu, J., Ye, Y.: Cardinal optimizer (COPT) user guide. arXiv preprint arXiv:2208.14314 (2022) [9] Gleixner, A., Hendel, G., Gamrath, G., Achterberg, T., Bastubbe, M., Berthold, T., Christophel, P., Jarck, K., Koch, T., Linderoth, J., et al.: MIPLIB 2017: data-driven compilation of the 6th mixed-integer programming library. Mathematical Programming Computation 13(3), 443–490 (2021) [10] Gomes, C.P., Selman, B.: Algorithm portfolios. Artificial Intelligence 126(1–2), 43–62 (2001) [11] Gottwald, R.L., Maher, S.J., Shinano, Y.: Distributed domain propagation. In: 16th International Symposium on Experimental Algorithms (SEA 2017), Leibniz International Proceedings in Informatics (LIPIcs), vol. 75, pp. 6:1–6:11. Schloss Dagstuhl – LeibnizZentrum für Informatik (2017). DOI 10.4230/LIPIcs.SEA.2017.6 [12] Gurobi Optimization, LLC: Gurobi Optimizer Reference Manual (2023). URL https: //www.gurobi.com [13] Hojny, C., Besançon, M., Bestuzheva, K., Borst, S., Dionı́sio, J., Ehls, J., Eifler, L., Ghannam, M., Gleixner, A., Göß, A., Hoen, A., von Holly-Ponientzietz, J., van der Hulst, R., Kamp, D., Koch, T., Kofler, K., Lentz, J., Lübbecke, M., Maher, S.J., Meinhold, P.M., Mexi, G., il Mohr, T., Mühmer, E., Patel, K.K., Pfetsch, M.E., Pokutta, S., Groba, C.R., Serrano, F., Shinano, Y., Turner, M., Vigerske, S., Walter, M., ieter Weninger, D., Xu, L.: The SCIP Optimization Suite 10.0 (2025). URL https://arxiv.org/abs/2511.18580 [14] Huangfu, Q., Hall, J.A.J.: Parallelizing the dual revised simplex method. Mathematical Programming Computation 10(1), 119–142 (2018). DOI 10.1007/s12532-017-0130-5 [15] Huberman, B.A., Lukose, R.M., Hogg, T.: An economics approach to hard computational problems. Science 275(5296), 51–54 (1997) [16] IBM: ILOG CPLEX 12.5 User’s Manual (2013) [17] Lin, P., Cai, S., Zou, M., Lin, J.: Local-MIP: Efficient local search for mixed integer programming. Artificial Intelligence 348, 104405 (2025). DOI https://doi.org/ 10.1016/j.artint.2025.104405. URL https://www.sciencedirect.com/science/article/ pii/S0004370225001249 [18] Lodi, A., Tramontani, A.: Performance variability in mixed-integer programming. In: Theory Driven by Influential Applications, pp. 1–12. INFORMS (2013). DOI 10.1287/ educ.2013.0112 [19] Maher, S.J., Fischer, T., Gally, T., Gamrath, G., Gleixner, A., Gottwald, R.L., Hendel, G., Koch, T., Lübbecke, M., Miltenberger, M., Müller, B., Pfetsch, M., Puchert, C., Rehfeldt, D., Schenker, S., Schwarz, R., Serrano, F., Shinano, Y., Weninger, D., Witt, J.T., Witzig, J.: The SCIP Optimization Suite 4.0. Tech. Rep. 17-12, ZIB, Takustr. 7, 14195 Berlin (2017) [20] NVIDIA Corporation: NVIDIA cuOpt: GPU-accelerated optimization solver. https:// developer.nvidia.com/cuopt (2025). Open-source release 9

[21] Perron, L., Didier, F., Gay, S.: The CP-SAT-LP solver. In: R.H.C. Yap (ed.) 29th International Conference on Principles and Practice of Constraint Programming (CP 2023), Leibniz International Proceedings in Informatics (LIPIcs), vol. 280, pp. 3:1–3:2. Schloss Dagstuhl – Leibniz-Zentrum für Informatik, Dagstuhl, Germany (2023). DOI 10.4230/LIPIcs.CP.2023. 3. URL https://drops.dagstuhl.de/opus/volltexte/2023/19040 [22] Rothberg, E.: An evolutionary algorithm for polishing mixed integer programming solutions. INFORMS Journal on Computing 19(4), 534–541 (2007) [23] Shaw, P.: Using constraint programming and local search methods to solve vehicle routing problems. In: Principles and Practice of Constraint Programming — CP98, Lecture Notes in Computer Science, vol. 1520, pp. 417–431. Springer (1998) [24] Shinano, Y., Heinz, S., Vigerske, S., Winkler, M.: FiberSCIP—a shared memory parallelization of SCIP. INFORMS Journal on Computing 30(1), 11–30 (2018). DOI 10.1287/ijoc.2017.0762

10