Rapid Mathematical Programming vorgelegt von Diplom-Mathematiker Thorsten Koch Flensburg Fakultät II – Mathematik und Naturwissenschaften der Technischen Universität Berlin zur Erlangung des akademischen Grades Doktor der Naturwissenschaften genehmigte Dissertation Promotionsausschuß Vorsitzender Prof. Dr. Fredi Tröltzsch Berichter/Gutachter Prof. Dr. Martin Grötschel Berichter/Gutachter Prof. Dr. Alexander Martin Tag der wissenschaftlichen Aussprache: 6. Dezember 2004 Berlin 2004 D83 Rapid Mathematical Programming Thorsten Koch Copyright © 2004 by Thorsten Koch All rights reserved. This book was typeset with TEX using LATEX and many further formatting packages. The pictures were prepared using pstricks, xfig, gnuplot and gmt. All numerals in this text are recycled. Für meine Eltern Preface Avoid reality at all costs — fortune(6) As the inclined reader will find out soon enough, this thesis is not about deeply involved mathematics as a mean in itself, but about how to apply mathematics to solve real-world problems. We will show how to shape, forge, and yield our tool of choice to rapidly answer questions of concern to people outside the world of mathematics. But there is more to it. Our tool of choice is software. This is not unusual, since it has become standard practice in science to use software as part of experiments and sometimes even for proofs. But in order to call an experiment scientific it must be reproducible. Is this the case? Regarding software experiments, we have first to distinguish between reproducing and repeating results. The latter means that given the same data and the same programs, running on a similar computer, the results are identical. Reproducing results means to use the same data, but diVerent programs and an arbitrary computer. Today we can reproduce experiments conducted by Leonardo da Vinci in the fif- teenth century. But can we expect even to repeat an experiment that involves a 20-year- old (commercial) program? Or in case we try to reproduce it, using diVerent software and get dissenting results, can we make any conclusions why the results diVer? Software is getting more complex all the time. And by no means it is usually possible to prove the correctness of a specific implementation even if the algorithm employed is known to be correct. But what can we do if the source code of the program is not available at all? How could we assert what the program is really doing? Science is about using the work of fellows. If a proof or experiment is published anybody can use it as part of their work, assumed due credit is given to the author. But how can we build on software that is not freely available? The same questions can be asked for the input data. Without the precise data, com- putational experiments can neither be repeated nor reproduced. Surely part of the prob- lem is that there is no accepted or even adequate way to publish software and data for review in the same way as articles are published. While this thesis by no means gives answers to the above questions1, considerable eVorts were taken to set a good example regarding the correctness of the software and to improve the possibilities for the reader to repeat or reproduce the results shown. Acknowledgements I am deeply indebted to all my friends and colleagues at zib, who supported me in writing this thesis. They showed me that teamwork does not mean to work in a crowd, but to improve the quality of the work by combining the knowledge of many people. I would especially like to thank my supervisor Prof. Martin Grötschel, who started his work in Berlin just at the right time to attract me to combinatorics and optimization. 1 For more information on these topics, see Borwein and Bailey (2004), Greve (2003), Johnson (2002). The environment and challenges he has provided me are the most fertile and stimulating I have encountered so far. This thesis would not have happened without Prof. Alexander Martin, who re- cruited me two times and taught me much of what I know about optimization. Many thanks go to my brave proof readers Monica Ahuna, Andreas Eisenblätter, Sven Krumke, Roland Wessäly and especially Tobias Achterberg, Volkmar Gronau, Syl- wia Markwardt, and Tuomo Takkula. And last but not least, I would like to thank Ines for her inexhaustible support and Keiken for inexhaustibly trying to distract me. Berlin, October 2004 Thorsten Koch Contents 1 Introduction 1 1.1 Three steps to solve a problem . 2 1.1.1 Mathematical workbench . 3 1.1.2 Modeling Language with out-of-the-box solver . 4 1.1.3 Framework . 4 1.1.4 Doing it all yourself . 5 1.2 What's next? . 5 I Design and Implementation 7 2 The Zimpl Modeling Language 9 2.1 Introduction . 9 2.2 Invocation . 16 2.3 Format . 17 2.3.1 Expressions . 17 2.3.2 Sets . 19 2.3.3 Parameters . 21 2.3.4 Variables . 22 2.3.5 Objective . 23 2.3.6 Constraints . 23 2.3.7 Details on sum and forall . 23 2.3.8 Details on if in constraints . 24 2.3.9 Initializing sets and parameters from a file . 24 2.3.10 Function definitions . 26 2.3.11 Extended constraints . 26 2.3.12 Extended functions . 27 2.3.13 The do print and do check commands . 27 2.4 Modeling examples . 27 2.4.1 The diet problem . 28 2.4.2 The traveling salesman problem . 29 2.4.3 The capacitated facility location problem . 30 ix x 2.4.4 The n-queens problem . 32 2.5 Further developments . 36 3 Implementing Zimpl 37 3.1 Notes on software engineering . 37 3.2 Zimpl overview . 40 3.3 The parser . 41 3.3.1 BISON as parser generator . 41 3.3.2 Reserved words . 43 3.3.3 Type checking . 43 3.4 Implementation of sets . 44 3.5 Implementation of hashing . 47 3.6 Arithmetic . 48 3.6.1 Floating-point arithmetic . 48 3.6.2 Rational arithmetic . 51 3.7 Extended modeling . 52 3.7.1 Boolean operations on binary variables . 54 3.7.2 Conditional execution . 54 3.8 The history of Zimpl . 55 3.9 Quality assurance and testing . 56 3.9.1 Regression tests . 56 3.9.2 Software metrics . 58 3.9.3 Statistics . 59 3.9.4 Program checking tools . 59 II Applications 63 4 Facility Location Problems in Telecommunications 65 4.1 TraYc . 66 4.1.1 Erlang linearization . 67 4.1.2 Switching network vs. transport network . 68 4.2 A linear mixed integer model for hierarchical multicommodity capacitated facility location problems . 69 4.3 Planning the access network for the G-WiN . 72 4.4 Planning mobile switching center locations . 78 4.5 Planning fixed network switching center locations . 82 4.5.1 Demands and capacities . 83 4.5.2 Costs . 84 4.5.3 Model . 86 4.5.4 Results . 87 4.6 Conclusion . 93 xi 5 MOMENTUM 95 5.1 UMTS radio interface planning . 95 5.2 Coverage or how to predict pathloss . 97 5.2.1 How much freedom do the choices give us? . 100 5.3 Capacity or how to cope with interference . 102 5.3.1 The CIR inequality . 103 5.3.2 Assumptions and simplifications . 105 5.3.3 Cell load . 105 5.3.4 Pathloss revisited . 106 5.3.5 Assessment . 107 5.4 Models . 109 5.4.1 Site selection . 109 5.4.2 Azimuth (and a little tilting) . 111 5.4.3 Snapshots . 114 5.5 Practice . 118 5.5.1 Conclusion . 122 5.5.2 Acknowledgements . 122 6 Steiner Tree Packing Revisited 123 6.1 Introduction . 123 6.2 Integer programming models . 127 6.2.1 Undirected partitioning formulation . 127 6.2.2 Multicommodity flow formulation . 128 6.2.3 Comparison of formulations . 130 6.3 Valid inequalities . 131 6.4 Computational results . 133 6.4.1 Choosing the right LP solver algorithm . 133 6.4.2 Results for the Knock-knee one-layer model . 135 6.4.3 Results for the node disjoint multi-aligned-layer model . 137 6.5 Outlook . 141 7 Perspectives 147 Appendix 149 A Notation 149 A.1 Decibel explained . 150 B Zimpl Internals 151 B.1 The grammar of the Zimpl parser . 151 B.2 Detailed function statistics . 159 xii C Zimpl Programs 177 C.1 Facility location model with discrete link capacities . 177 C.2 Facility location model with configurations . 178 C.3 UMTS site selection . 179 C.4 UMTS azimuth setting . 180 C.5 UMTS snapshot model . 180.