Jcbc: Calsim and Callite Solver

jCbc an open source LP/MILP solver for CalSim/CalLite*

ZHAOJUN BAI WITH B. MOAZZEZ, M. GHAMKHARI, M. KOEPPE (UC DAVIS) J. AS-SALEK (USBR), AND T. KADIR, K. KAO, P. SANDHU. S. SENEVIRATNE (DWR) * SUPPORTED BY USBR GRANT R13AC20028 Outline I. Introduction II. jCbc III. Performance analysis IV. Recap and additional info I. Introduction Mixed Integer Linear Programming (MILP)

min 푐푇푥 푆. 푡. 퐴푥 ⋚ 푏 푙 ≤ 푥 ≤ 푢 푥푖 ∈ ℤ 푓표푟 푖 ∈ 퐼 where 퐼 is a subset of variable indices and 푙 and 푢 can be ±∞. I. Introduction 1) jCbc is a Java Native Interface for COIN OR solvers Cbc for MILP and Clp for LP, with modifications and new capabilities added. 2) jCbc is open source with LGPL license. 3) jCbc is developed for CalSim and CalLite applications, but can also be used independently I. Introduction .Cbc (Coin-or branch and cut): an open-source MILP solver, and is written in C++. .Coin OR = Computational Infrastructure for Operations Research: including tools for linear programming, nonlinear programming, integer programming, algebraic modeling languages and more. .COIN-OR is run by an educational non-profit foundation. II. jCbc .jCbc is Java Native Interface (JNI) for Coin OR Cbc .jCbc is currently available for download https://github.com/JNICbc/jCbc .jCbc version 1.0 is scheduled in the summer of 2017. II. jCbc Contents of jCbC package: 1. manual.pdf

2. jCbc.dll : the library that should be loaded into the Java code (jCbc.so for Lunux) 3. jCbc.i : SWIG input file 4. jCbc.cpp: source file 5. jCbc-wrap.cxx : object file for swig 6. /src : source file folder 7. /example : exemples in Java 8. /include : Header files 9. make : make file to compile jCb II. jCbc Supported platforms: .Windows 64 bit with MinGW 64 bit compiler, MSYS, SWIG .Linux 64 bit with GNU g++ compiler, SWIG

To be supported platforms: .Windows 32 bit with Intel and MinGW 32 bit compilers, MSYS, SWIG .Windows 64 bit with Intel compiler

II. jCbc Extended Functionalities ◦ Solve_whs: when a warm start solution is provided. Uses ClpPresolve ◦ Solve_2: if no warm start solution is provided. Uses CglPreprocessing ◦ Solve_3: uses ClpPresolve ◦ Solve_unified ◦ Par_solve

II. jCbc Synergistic effort : .Calsim models are serial: construction of model each model depends Warm on the solution from a start Solve_whs Optimal? previous model plus solution some data from user and/or database. Solve_2 Optimal? .Warm start made it a lot faster Solve_2 Optimal? primalT 1e-4

II. jCbc Warm Start solver Stop, report infeasible Stop, report infeasible warm start solution

No No

Yes Make a LP Yes Branch and Bound + cutting Feasible? warm start Successful? planes on pre-solved model Model pre-solve solution with warm start

Initial Solution Yes Stop Optimal? (Integer)

No Apply another solver II. jCbc Optimal tuning ◦ CglPreprocessing or ClpPresolve ◦ Cutting planes in all nodes or only at root ◦ Which heuristics to use Optimal tolerances ◦ integerT = 1e-9 ◦ primalT = 1e-9 or 1e-8, depending on the solve function

III. Performance analysis jCbc is ready to use as a substitute of XA. Case studies:

Scenarios 1_DCR2015_Base 2_DCR2015_ELT 3_DCR2015_ECHO 4_DCR2015_ECLO 5_DCR2015_Alt4_H3 test_02_CalLite_3.0Final_20141023_default test_03_CS3A2010Existing test_05_CS3LOD2010_R374SG2 III. Performance analysis CalSim/CalLite running time is divided into three categories: ◦ WRIMS processes time ◦ Model construction time ◦ Solve time III. Performance analysis

Case I: LP time comparison

Configuration WRIMS Initial processes (sec) Solve time (sec)

XA JNI r215 56 1296 CBC JNI solve_2 r236 52 1293 III. Performance analysis Case II: MILP time comparison -- construction time

jCbc vs XA model construction time 1921-1930

jCbc vs XA model construction time 1921-2003 III. Performance analysis Case II: MILP time comparison -- solve time

Scenario WRIMS XA jCbc XA total jCbc ratio time + solve solve time total constr. time time time 2_DCR2015_ELT 20 4 9 24 29 1.2 3_DCR2015_ECHO 21 4 10 25 31 1.24 4_DCR2015_ECLO 21 4 10 25 31 1.24 5_DCR2015_Alt4_H3 20 7 12 27 32 1.18 test_03_CS3A2010Existing 55 13 26 68 81 1.19 test_06_CS3_Existing_v3120 59 14 38 73 97 1.32 III. Performance analysis 64 bit WRIMS: jCbc is faster than XA (preliminary data)

total time (sec)

XA 3200

jCbc 2900 III. Performance analysis jCbc has shown two major benefits over XA. 1. There are studies where XA returns suboptimal solutions

Model name Gurobi jCbc XA

test_06_045_HadGEM2-ES_r3 -1.2077986245487712E11 -1.2077986245488326E11 -1.7039344157572023E10 i1p1_rcp85+2000_03_c07 test_06_045_HadGEM2- -1.2077777688889745E11 -1.2077777688890361E11 -1.7039344157572023E10 ES_r3i1p1_rcp85+2000_03_c08 test_06_045_HadGEM2- -1.2076934346746957E11 -1.2076934346747577E11 -1.7039344157572023E10 ES_r3i1p1_rcp85+2000_03_c11 test_06_045_HadGEM2- -1.2076827030808171E11 -1.2076827030808788E11 -1.535608722178062E10 ES_r3i1p1_rcp85+2000_03_c13 More in Mahdi’s talk III. Performance analysis 2. XA is not capable of solving any of ``MIPLIB 2003 and 2013’’ instances, but jCbc solves them successfully.

1 thread CBC CPLEX GUROBI SCIPC SCIPS XPRESS MATLAB MIPCL unscal 1925 86 74 416 642 93 3416 641 scaled 26 1.16 1 5.63 8.68 1.25 46.2 8.68 solved 48 86 86 75 70 86 25 65

4 threads CBC CPLEX FSCIPC FSCIPS GUROBI XPRESS MIPCL unscal 1053 46 339 641 39 49 396 scaled 27.4 1.19 8.82 17 1 1.28 10.3 solved 61 86 75 69 87 86 74

12 threads CBC CPLEX FSCIPC FSCIPS GUROBI XPRESS MIPCL unscal 615 41 327 511 37 44 336 scaled 17 1.11 8.85 14 1 1.2 8.85 solved 69 87 74 70 87 86 76 Recap 1. jCbc is an open-source LP/MILP solver 2. https://github.com/JNICbc/jCbc 3. jCbc has more tuning options 4. Coin OR Cbc is an active project 5. Additional info, Mahdi’s talk

Thank You Additional Info Outline for additional info 1. Water Resource Allocation in CalSim- MILP Modeling Aspects 2. Mixed Integer Linear Programming- Mathematics Aspects 3. Solvers for MILP – Essential Components 4. Why We Choose Cbc as the underlying solver 5. Programming Challenges in Developing jCbc for CalSim Water Resource Allocation in CalSim The CalSim model represents water resource systems, consisting of reservoirs and channels as a network of nodes and arcs.

Water Resource Allocation in CalSim Nodes in the network may represent reservoirs, groundwater basins, junction points of two or more flows, or simply a point of interest on a channel. Arcs represent water flows between nodes, or out of the system, and may be inflows, channel flows, return flows, or diversions. The mathematical formulation used in the CalSim model consists of a linear objective function and a set of linear constraints. constraint set describes the physical and operational limitations toward achieving the objective. CalSim maximizes the objective function in each time period to obtain an optimal solution that satisfies all constraints. Priority weights assigned to variables in the objective function describe the relative importance of particular variables in the system operation.

Decision and State Variables Decision variables represent the choices available to the LP modelers for storing water in or routing water through arcs. Weights on the decision variables encourage or discourage the router to allocate water to the specified variables State variables in CalSim describe the state of the system at the beginning of any time period. State variables have known constant values for the upcoming period and can be thought of as the information available to planner/operator prior to any system operation. Constraints To insure that mass balance is maintained at each node, continuity equations serve as constraints at these locations. In general, inflow minus outflow must equal change in storage.

푡 푡−1 퐼 + 퐷 + 퐶 + 푅 − 퐷 + 퐶 + 퐸 + 퐹 = 푆푖 − 푆푖 푖푛 표푢푡

Storage zones are specified for each reservoir or ground water basin representing volumes between physical and operational levels. The zones are weighted and dynamically bounded to insure proper filling of the reservoir, meeting target storage levels, and minimizing encroachment in the flood pool. In general the zones are bounded as

0 ≤ 푆푖푗 ≤ 푆푖푙푒푣푒푙푗 − 푆푖푙푒푣푒푙푗−1

Constraints: Storage Zones Storage zones are specified for each reservoir or ground water basin representing volumes between physical and operational levels.

0 ≤ 푆푖푗 ≤ 푆푖푙푒푣푒푙푗 − 푆푖푙푒푣푒푙푗−1.

The total storage must be the sum of the individual zones,

푛푧표푛푒푠

푆푖 = 푆푖푗 . 푗=1 Constraints: Channel Capacity Constraints Channel constraints represent the physical maximum carrying capacity of the channel and the absolute minimum channel flow.

퐶푖푚푖푛 ≤ 퐶푖 ≤ 퐶푖푚푎푥 A minimum instream flow is formulated in CalSim by splitting the channel arc into zones and weighting and bounding one zone to the minimum flow target

0 ≤ 퐶푖푗 ≤ 푚푖푛 푓푙표푤푖 sum of all zones must be equal to the total arc

푛푧표푛푒푧

퐶푖 = 푆푖푗 . 푗=1

Soft Constraints Some operational and institutional constraints may be best modeled as a goal minimizing the deviation between a decision variable and its’ target value. Balancing storage in two parallel reservoirs is a good example of this goal programming technique. Each reservoir must meet the immediate downstream demands, but there may be demands and minimum flows further downstream that could be satisfied by either reservoir. The constraint can be stated as “Given the choice between releases from Reservoir A or from Reservoir B to meet the shared Demand C, establish releases such that the resulting storages in A and B are the same”. Constraints such as these are termed “soft constraints” because they may be violated when other system constraints do not allow the goal to be achieved. These constraints are internally reformulated by CalSim by the introduction of auxiliary variables.

Soft Constraints vs Hard Constraints A “hard” constraint forcing the two decision variables equal may be:

푆퐴 − 푆퐵 = 0 Reformulating the constraint to allow for potential violation (both positive and negative violation) would result in − + 푆퐴 − 푆퐵 + 푥 − 푥 = 0. Two new positive auxiliary variables have been Introduced to relax the constraint.

The power of this technique lies in the ability to penalize the slack and surplus variables in the objective function, by multiplying the variables by penalty weights (negative values in a maximizing objective function), resulting in the minimization of the deviation between the LHS and RHS. Objective Function The objective function in the CalSim model is linear combination of decision variables and their associated priority weights. In addition, slack and surplus variables added to the objective function from “soft” constraints are multiplied by their associated negative penalties. The complete objective function is: 푛푤푡 푛푝푒푛 + − max 푍 = 푤푖 . 푋푖 + −푝푗 . 푥푗 |푥푗 푖=1 푗=1 Mixed Integer Linear Programming An MILP is in the following form: Min 푐푇. 푥 Subject To: 퐴푥 = 푏 푙 ≤ 푥 ≤ 푢

푥푖 is integer for 푖 ∈ 퐼 An MILP is an LP in which some variables are integers The integrality constraints allow MILP models to capture the discrete nature of some decisions. For example, a variable whose values are restricted to 0 or 1, called a binary variable, can be used to decide whether or not some action is taken. The Steps in Solving an MILP

Solving MILP constitutes of two parts: 1) Searching over the combinations of Integer Variables. 2) Solving a Linear Program for certain combination of Integer Variables. To carry on these two parts, an MILP solver takes the following steps: Presolve Preprocess Heuristics Initial Solve Warmstart Branch and Cut/Branch and Bound Postsolve/Postprocess

The Steps in Solving an MILP: Presolve Presolve refers to a collection of problem reductions that are typically applied in advance of the start of the branch-and-bound procedure. These reductions are intended to reduce the size of the problem and to tighten its formulation. For example consider an MILP with the following constraints: 푥1 + 푥2 + 푥3 ≥ 15 푥1 ≤ 7 푥2 ≤ 3 푥3 ≤ 5

Clearly the only way that all of these constraints can be satisfied is if 푥1 = 7, 푥2 = 3, and 푥3 = 5. In this case we can substitute out these variables, completely removing them from the formulation along with the above four constraints. The list of such possible reductions is quite extensive and can have an enormous effect on the overall size of the problem. The Steps in Solving an MILP: Preprocessing Preprocess is a collection of methods to analyze each of the inequalities of the system of inequalities defining the feasible region, trying to establish whether the inequality forces the feasible region to be empty, whether the inequality is redundant, whether the inequality can be used to improve the bounds on the variables, whether the inequality can be strengthened by modifying its coefficients, or whether the inequality forces some of the binary variables to either zero or one. The Steps in Solving an MILP: Branch-and-Bound Mixed Integer Linear Programming problems are generally solved using a linear-programming based branch-and-bound algorithm. We begin with the original MILP and remove all of the integrality restrictions, and solve the resulting LP. If the result happens to satisfy all of the integrality restrictions, then this solution is an optimal solution of the original MILP, and we are done. If not, integer variables have fractional values in the relaxed problem. For example an integer variable x may have the fractional value 1.3. We can branch upon x by imposing the constraints 푥 ≤ 1.0 and 푥 ≥ 2.0 on the MILP.

The original MILP is denoted 푃0. The MILP that is obtained by imposing the constraint 푥 ≤ 1.0 is denoted by 푃1and the MILP that is obtained by imposing the constraint 푥 ≥ 2.0 is denoted by 푃2. The variable 푥 is then called a branching variable, and we are said to have branched on 푥, producing two sub-MILPs 푃1 and 푃2.

The Steps in Solving an MILP: Branch-and-Bound

It should be clear that if we can compute optimal solutions for each of 푃1 and 푃2, then we can take the better of these two solutions and it will be optimal to the original problem 푃0.

In this way we have replaced 푃0 by two simpler MILPs. We now apply the same idea to these two MILPs, solving the corresponding LP relaxations and, if necessary, selecting branching variables. In so doing we generate what is called a search tree. The MILPs generated by the search procedure are called the nodes of the tree, with 푃0 designated as the root node. The leaves of the tree are all the nodes from which we have not yet branched. In general, if we reach a point at which we can solve or otherwise dispose of all leaf nodes, then we will have solved the original MILP.

Branch and Bound Tree The Steps in Solving an MILP: Branch-and-Bound The original problem, also referred to as a “root problem” is bounded from below and above. If the bounds match, the optimal solutions have been found. Otherwise the feasible region is partitioned into sub-regions. The sub-regions constitute feasible regions for sub-problems, which become children of the root problem in a search tree. Despite of the original problem, relaxed sub-problems of the original problem can be solved within a reasonable amount of time. If a sub-problem can be optimally solved, its solution is a feasible solution to the original problem. Therefore, it provides a new upper bound for the original problem. Any node of the search tree with a solution that exceeds the global upper bound can be removed from consideration. In the other words, the branching procedure will not be applied to that node. The tree is searched until all nodes are either removed or solved. Branch-and-Bound is guaranteed to reach the optimal solution, conditioned that the MILP is feasible.

The Steps in Solving an MILP: Heuristics Why Heuristics? Having good incumbents, and finding them as quickly as possible, can be extremely valuable in the MILP search for a number of reasons. Having good feasible solutions also helps the search process to terminate faster. The better the objective value of the incumbent, the more likely it is that the value of an LP relaxation will exceed it (in a minimization problem) and hence lead to a node being fathomed. It may not be possible to solve a problem to provable optimality. For example, the underlying MILP may just be too difficult, or there may be some user imposed restriction on the amount of time that we can allow our MILP algorithm run. In either case, we want to have the best possible feasible solution at termination.

The Steps in Solving an MILP: Heuristics It has turned out to be extremely valuable to do a little extra work at some of the nodes of the search tree to see if a good integer feasible solution can be extracted, even though integrality has not yet resulted due to the branching. For example, it may be that many of the integer variables, while not integral, have values that are quite close to integral. We could then consider rounding some of these variables to their nearby values, fixing them to these values, solving the resulting LP relaxation, and repeating this procedure several times in the hopes that all integer variables will fall into line. If they do, and if the resulting feasible has a better objective value than the current incumbent, we can replace that incumbent and proceed.

The Steps in Solving an MILP: Warmstart If the solution has been stopped for some reason, then the current information can be stored and be used as a warm start for the solver to pick up where the solution is left off. If there have been some minor changes to the LP since the solution process was stopped, then the previous solution can be used as an initial point for the new MILP. Warm starts are extremely useful if you are repeatedly solving different versions of the same MILP, each version of which is slightly different from the last. Warm starts are useful in speeding up mixed-integer linear programming, and also in the algorithms for analyzing infeasibility in linear programs.

The Steps in Solving an MILP: Branch-and-Cut Branch and Cut is a hybrid method for solving MILP problems. It uses LP based branch and bound and cutting planes. A key concept here is a cutting plane. The idea of cutting planes is that they tighten the formulation by removing undesirable fractional solutions, as in the case of MILP presolve. Cutting plans are added during the solution process without the undesirable side-effect of creating additional sub-problems (unlike branching).

Picture from gurobi.com A need for an MILP Solver Implementation of simplex and branch-and-bound algorithms is not an easy task. A package/software that implements these algorithms is called a solver and should consider various factors including the speed and memory-efficiency. In implementation of the simplex algorithms LAPACK and BLAS packages should be used to speed up the algorithm. However, these two later packages don’t come with an easy-to-read API. Therefore, rather than developing a solver from scratch we should either use a commercial solver or an open source solver. Previously, XA was used in Calsim as the optimization suite. Why an open source MILP Solver? There are four main issues with using XA as the underlying solver 1. Using XA comes with considerable cost of $2000/per license. 2. We don’t know what is happening inside XA and there is no tool for monitoring and double- checking the solver mechanism. 3. XA comes with limited functionality and does not comply with the state-of-art techniques in mixed integer linear programming. 4. XA solves only small problems and cannot be used for increasing the simulations horizon in CalSim. Therefore, in this project we have taken a path to overcome the above issues by developing an open source optimization solver.

A list of sixty Linear Programming solvers Open Source Proprietary CLP (Coin-OR) Gurobi (Most Powerful) SoPlex (ZIB) CPLEX (IBM ILOG) lp_solve (MIT) FortMP GLPK (GNU LP Kit) Mosek Coopr (Sandia National Laboratories - A Xpress collection of Python Packages) Cassowary (Very Old) SNOPT (Stanford) Joptimizer (Java) SAS/OR BPMPD (Old 1998) LINDO HOPDM (A little old) XA DyLP (Coin-OR Dynamic Simplex Method) SYMPHONY (Uses CLP) OpenOpt (Uses other solvers) Criteria for Selecting the Solvers Questions to accept/reject a solver as a candidate:

◦ Is it an LP solver? ◦ Is it free/open source? ◦ Is it mature? ◦ Is it reliable? ◦ Is it fast? ◦ Is it a stand alone solver?

Candidates:

◦ CLP ◦ GLPK ◦ LP_SOLVE Benchmarking

Primal Simplex CPU Time (seconds) 2 1.8 1.6 1.4 1.2 1 0.8 0.6 0.4 0.2

1921_10_c16.mps 1923_05_c16.mps 1924_12_c16.mps 1926_07_c16.mps 1928_02_c16.mps 1929_09_c16.mps 1931_04_c16.mps 1932_11_c16.mps 1934_06_c16.mps 1936_01_c16.mps 1937_08_c16.mps 1939_03_c16.mps 1940_10_c16.mps 1942_05_c16.mps 1943_12_c16.mps 1945_07_c16.mps 1947_02_c16.mps 1948_09_c16.mps 1950_04_c16.mps 1951_11_c16.mps 1953_06_c16.mps 1955_01_c16.mps 1956_08_c16.mps 1958_03_c16.mps 1959_10_c16.mps 1961_05_c16.mps 1962_12_c16.mps 1964_07_c16.mps 1966_02_c16.mps 1967_09_c16.mps 1969_04_c16.mps 1970_11_c16.mps 1972_06_c16.mps 1974_01_c16.mps 1975_08_c16.mps 1977_03_c16.mps 1978_10_c16.mps 1980_05_c16.mps 1981_12_c16.mps 1983_07_c16.mps 1985_02_c16.mps 1986_09_c16.mps 1988_04_c16.mps 1989_11_c16.mps 1991_06_c16.mps 1993_01_c16.mps 1994_08_c16.mps 1996_03_c16.mps 1997_10_c16.mps 1999_05_c16.mps 2000_12_c16.mps 2002_07_c16.mps 2004_02_c16.mps 2005_09_c16.mps 2007_04_c16.mps 2008_11_c16.mps XA GLPK CLP Gurobi Benchmarking

Dual Simplex CPU Time (seconds) 2 1.8 1.6 1.4 1.2 1 0.8 0.6 0.4 0.2

1921_10_c16.mps 1923_04_c16.mps 1924_10_c16.mps 1926_04_c16.mps 1927_10_c16.mps 1929_04_c16.mps 1930_10_c16.mps 1932_04_c16.mps 1933_10_c16.mps 1935_04_c16.mps 1936_10_c16.mps 1938_04_c16.mps 1939_10_c16.mps 1941_04_c16.mps 1942_10_c16.mps 1944_04_c16.mps 1945_10_c16.mps 1947_04_c16.mps 1948_10_c16.mps 1950_04_c16.mps 1951_10_c16.mps 1953_04_c16.mps 1954_10_c16.mps 1956_04_c16.mps 1957_10_c16.mps 1959_04_c16.mps 1960_10_c16.mps 1962_04_c16.mps 1963_10_c16.mps 1965_04_c16.mps 1966_10_c16.mps 1968_04_c16.mps 1969_10_c16.mps 1971_04_c16.mps 1972_10_c16.mps 1974_04_c16.mps 1975_10_c16.mps 1977_04_c16.mps 1978_10_c16.mps 1980_04_c16.mps 1981_10_c16.mps 1984_10_c16.mps 1986_04_c16.mps 1987_10_c16.mps 1989_04_c16.mps 1990_10_c16.mps 1992_04_c16.mps 1993_10_c16.mps 1995_04_c16.mps 1996_10_c16.mps 1999_10_c16.mps 2001_04_c16.mps 2002_10_c16.mps 2004_04_c16.mps 2005_10_c16.mps 2007_04_c16.mps 2008_10_c16.mps XA Gurobi glpk lp_solve CLP Benchmarking

Dual Simplex Iterations 2500

2000

1500

1000

500

Primal Simplex Iterations 3500

3000

2500

2000

1500

1000

500

Elizabeth D. Dolan · Jorge J. Moré Benchmarking optimization software with performance profiles, Math. Program., Ser. A 91: 201–213 (2002)

푇푝,푠 푟푝,푠 = min{푇푝,푠:1≤푠≤푁푠} where 푟푝,푠 is the performance ratio of solver 푠 for problem 푝, 푇푝,푠 is the CPU time spent on some activity in the optimization software and 푁푠 is the total number of optimizers.

If solver 푠 fails to solve problem 푝 then we set 푟푝,푠 = 푃푀 where 푃푀 ≥ 푟푝,푠 for all 푝, 푠. Using this definition, the overall assessment of solver performance is defined to be: 1 휌푠 휏 = ∥ {푝 ∈ 푃: 푟푝,푠 ≤ 휏} ∥ 푁푝

Where 휌푠(휏) is the cumulative distribution function for the performance ratio (reflecting the probability that performance ratio 푟푝,푠 is within a factor 휏 of the best possible ratio), 푁푝 is the number of problems and 푃 is the set of all problems.

Performance Profile

}

풔

푵

≤

풔

≤

ퟏ

∶

흉

≤

풑

풔

풓

{ 푷풓풐풃

흉 Licenses: Merging EPL and GLP EPL: Eclipse Public License GPL: GNU Public License Are EPL and GNU compatible? No In order to combine two programs into a larger work, we need to have permission to use both programs in this way. If the two programs' licenses permit this, they are compatible. If there is no way to satisfy both licenses at once, they are incompatible. Based upon the position of the Free Software Foundation, you may not combine EPL and GPL code in any scenario where linking exists between code made available under those licenses. The above applies to both GPL version 2 and GPL version 3. However, if we just want to install two separate programs in the same system, it is not necessary that their licenses be compatible, because this does not combine them into a larger work.

Licenses Does the EPL allow me to take the Source Code for a Program licensed under it and include all or part of it in another program licensed under the GPL license? No. Only the owner of software can decide whether and how to license it to others. Contributors to a Program licensed under the EPL understand that source code for the Program will be made available under the terms of the EPL. Unless you are the owner of the software or have received permission from the owner, you are not authorized to apply the terms of another license to the Program by including it in a program licensed under another Open Source license. Can I apply the GPL when writing a plug-in for a non-free program? If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. So you can use the GPL for a plug-in, and there are no special requirements.

Easy LP Problems

Easy Problems

400000

40000

4000 Constraints

400

40 25 250 2500 25000 Variables Hard LP ProblemsHard Problems

500000

50000 Constraints

5000

500 1500 15000 150000 1500000 15000000 Variables Benchmarking on Easy Problems

Kennington

PDS-20.mps KEN-13.mps OSA-60.mps CRE-B.mps CRE-D.mps PDS-10.mps KEN-11.mps OSA-30.mps PDS-06.mps OSA-14.mps CRE-A.mps OSA-07.mps

0 10 20 30 40 50 60 70 80 90 100 Gurobi Clp 1.15 GLPK soplex Benchmarking on Hard Problems

Netlib

pilot87.mps

pilot.mps

fit2p.mps

d6cube.mps greenbeb.mps

25fv47.mps

pilot.ja.mps

grow22.mps 0 5 10 15 20 25 30 35 Gurobi Clp 1.15 GLPK soplex Why we choose Cbc From the extensive numerical results in previous slides, we see that Clp is the best choice as the underlying LP solver. Therefore, we choose Cbc as the underlying MILP solver for the following reasons:

1. By choosing Cbc from Coin-or package, we are benefiting from full integration of two projects (i.e. Cbc and Clp) within a single framework (i.e. Coin-or initiative). 2. Cbc comes with extensive flexibilities in tuning and optimization of Branch-and-Bound algorithm for domain specific applications (CalSim/CalLite).

Development of jCbc: Interfacing C++ to Java CBC source code is in C++, however CalSim and CalLite source code are in Java.

.dll file C++ code Java Environment (.so file in (COIN-OR CBC) (WRIMS) SWIG unix) JNI import src.jCbc; import src.SWIGTYPE_p_CbcModel; import src.SWIGTYPE_p_CoinModel; import src.SWIGTYPE_p_OsiClpSolverInterface; import src.SWIGTYPE_p_double; import src.SWIGTYPE_p_int; import src.SWIGTYPE_p_std__string; System.loadLibrary("jCbc"); jCbc Objects jCbcModel ◦ core object to build a model. ◦ SWIGTYPE_p_CbcModel Model = jCbc.new_jCbcModel() jOsiClpSolverInterface ◦ LP solver that is used inside a jCbcModel object. ◦ SWIGTYPE_p_OsiClpSolverInterface solver = jCbc.new_jOsiClpSolverInterface() ◦ jCbc.assignSolver(jCbcModel A,jOsiClpSolverInterface B) jCoinModel ◦ SWIGTYPE_p_CoinModel Model = jCbc.new_jCoinModel() ◦ faster to define variables, bounds and constraints in a jCoinModel object and then add them at once from this object to jCbcModel jCbc Objects

Constraints jCbcModel Variables

bounds

jCoinModel jOsiClpSolverInterface jCbc variables

SWIGTYPE_p_double ◦ swig pointer for doubles jarray_double ◦ JNI wrapped object equivalent to array of doubles in Java to pass information to objects. ◦ SWIGTYPE_p_double A = jCbc.new_jarray_double(n) ◦ jCbc.jarray_double_setitem(jarray_double A,i,k) ◦ jCbc.jarray_double_getitem(jarray_double A,i) SWIGTYPE_p_int ◦ swig pointer for integers jCbc Functions

SWIGTYPE_p_double getRowActivity(jCbcModel A) ◦ Get row activity levels from a jCbcModel object in the form of a pointer of doubles. SWIGTYPE_p_double getReducedCost(jCbcModel A) ◦ Get reduced costs from a jCbcModel object in the form of a pointer of doubles. double getObjValue(jOsiClpSolverInterface A) ◦ Get objective value of the current solution. double getObjValue(jCbcModel A) ◦ Get objective value of the current solution.