Jcbc: Calsim and Callite Solver
Total Page:16
File Type:pdf, Size:1020Kb
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.