Scippy

SCIP

Solving Constraint Integer Programs

xternal.c
Go to the documentation of this file.
1 /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2 /* */
3 /* this file is part of the program and library */
4 /* SCIP --- Solving Constraint Integer Programs */
5 /* */
6 /* 2002-2014 Konrad-Zuse-Zentrum */
7 /* fuer Informationstechnik Berlin */
8 /* */
9 /* SCIP is distributed under the terms of the ZIB Academic License. */
10 /* */
11 /* You should have received a copy of the ZIB Academic License */
12 /* along with SCIP; see the file COPYING. If not email to scip@zib.de. */
13 /* */
14 /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
15 
16 /**@file xternal.c
17  * @brief main document page
18  * @author Tobias Achterberg
19  * @author Timo Berthold
20  * @author Gerald Gamrath
21  * @author Stefan Heinz
22  * @author Gregor Hendel
23  * @author Mathias Kinder
24  * @author Marc Pfetsch
25  * @author Stefan Vigerske
26  * @author Robert Waniek
27  * @author Kati Wolter
28  * @author Michael Winkler
29  */
30 
31 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
32 
33 /**@mainpage Overview (\OTHERDOCU)
34  *
35  * \OTHERDOCUTEXT
36  *
37  *
38  *
39  * @section WHATISSCIP What is SCIP?
40  *
41  * SCIP is a framework to solve constraint integer programs (CIPs). In particular,
42  *
43  * - SCIP is a branch-and-cut-and-price framework,
44  * - incorporates a full-scale mixed integer programming (MIP) solver, and
45  * - incorporates a full-scale mixed integer quadratically constrained programming (MIQCP) solver.
46  *
47  * See the web site of <a href="http://scip.zib.de">SCIP</a> for more information about licensing and to download SCIP.
48  *
49  * SCIP is developed together with <a href="http://www3.mathematik.tu-darmstadt.de/ags/optimierung/research/discrete-optimization.html">TU Darmstadt</a> and
50  * <a href="http://www.am.uni-erlangen.de/wima/">University of Erlangen-N&uuml;rnberg (Chair of EDOM)</a>
51  * and has more than 500,000 lines of C code.
52  *
53  * @section GETTINGSTARTED Getting started
54  *
55  * - \ref MAKE "Installation information / Makefiles"
56  * - \ref LICENSE "License"
57  *
58  * - \ref SHELL "Tutorial: the interactive shell"
59  * - \ref FILEREADERS "Readable file formats"
60  * - \ref START "How to start a new project"
61  * - \ref EXAMPLES "Examples"
62  *
63  * @section FURTHERINFORMATION References
64  *
65  * - \ref PUBLICMETHODS "List of callable functions"
66  * - \ref PARAMETERS "List of all SCIP parameters"
67  *
68  * - \ref DOC "How to search the documentation for interface methods"
69  * - \ref FAQ "Frequently asked questions (FAQ)"
70  * - \ref TEST "How to run automated tests with SCIP"
71  * - \ref COUNTER "How to use SCIP to count feasible solutions"
72  *
73  *
74  * @section PROGRAMMING Programming with SCIP
75  *
76  * @subsection CODINGBASICS Coding basics for SCIP
77  *
78  * - \ref CODE "Coding style guidelines"
79  * - \ref OBJ "Creating, capturing, releasing, and adding data objects"
80  * - \ref DEBUG "Debugging"
81  *
82  * @subsection HOWTOADD How to add ...
83  * - \ref CONS "Constraint handlers"
84  * - \ref PRICER "Variable pricers"
85  * - \ref PRESOL "Presolvers"
86  * - \ref SEPA "Separators"
87  * - \ref PROP "Propagators"
88  * - \ref BRANCH "Branching rules"
89  * - \ref NODESEL "Node selectors"
90  * - \ref HEUR "Primal heuristics"
91  * - \ref RELAX "Relaxation handlers"
92  * - \ref READER "File readers"
93  * - \ref DIALOG "Dialogs"
94  * - \ref DISP "Display columns"
95  * - \ref EVENT "Event handler"
96  * - \ref NLPI "Interfaces to NLP solvers"
97  * - \ref EXPRINT "Interfaces to expression interpreters"
98  * - \ref CONF "Conflict analysis"
99  * - \ref PARAM "additional user parameters"
100  *
101  *
102  * @section FURTHERINFO Further information
103  *
104  * @subsection CHG Changes between different versions of SCIP
105  * - \ref CHANGELOG "Change log"
106  * - \ref RELEASENOTES "Release notes"
107  * - \ref CHG7 "Interface changes between version 3.0 and 3.1"
108  * - \ref CHG6 "Interface changes between version 2.1 and 3.0"
109  * - \ref CHG5 "Interface changes between version 2.0 and 2.1"
110  * - \ref CHG4 "Interface changes between version 1.2 and 2.0"
111  * - \ref CHG3 "Interface changes between version 1.1 and 1.2"
112  * - \ref CHG2 "Interface changes between version 1.0 and 1.1"
113  * - \ref CHG1 "Interface changes between version 0.9 and 1.0"
114  *
115  * @subsection AUTHORS SCIP Authors
116  * - <a class="el" href="http://scip.zib.de/#developers">Developers</a>
117  *
118  * @version 3.1.0
119  *
120  * \image html scippy.png
121  *
122  */
123 
124 /** @page EXAMPLES Examples projects
125  *
126  * SCIP contains several examples that demonstrate its usage. They are contained in the &quot;examples&quot; directory
127  * in the source code distribution.
128  *
129  * @section BRANCHANDPRICE Branch-and-price
130  *
131  * <table>
132  * <tr>
133  * <td>
134  * <a href="http://scip.zib.de/doc/examples/Binpacking"><b>Binpacking</b></a>
135  * </td>
136  * <td>
137  * An implementation of the column generation approach for the binpacking problem. It includes a customized reader,
138  * Ryan/Foster branching rule, (global) problem data, variable data, and constraint handler.
139  * </td>
140  * </tr>
141  * <tr>
142  * <td>
143  * <a href="http://scip.zib.de/doc/examples/Coloring"><b>Coloring</b></a>
144  * </td>
145  * <td>
146  * An implemenation of the column generation approach for graph coloring of Mehrotra and Trick.
147  * </td>
148  * </tr>
149  * <tr>
150  * <td>
151  * <a href="http://scip.zib.de/doc/examples/VRP"><b>VRP</b></a>
152  * </td>
153  * <td>
154  * A solver for a simple capacity-constrained vehicle routing problem, which is based on pricing tours via a dynamic
155  * programming algorithm.
156  * </td>
157  * </tr>
158  * </table>
159  *
160  * @section BRANCHANDCUT Branch-and-cut
161  *
162  * <table>
163  * <tr>
164  * <td>
165  * <a href="http://scip.zib.de/doc/examples/LOP"><b>LOP</b></a>
166  * </td>
167  * <td>
168  * An example for implementing a constraint handler.
169  * </td>
170  * </tr>
171  * <tr>
172  * <td>
173  * <a href="http://scip.zib.de/doc/examples/TSP"><b>TSP</b></a>
174  * </td>
175  * <td>
176  * A short implementations of a constraint handler, two easy combinatorial heuristics, a file reader, etc. which
177  * demonstrate the usage of SCIP as a branch-and-cut-framework for solving traveling salesman problem instances.
178  * </td>
179  * </tr>
180  * </table>
181  *
182  * @section CALLABLELIBRARY Callable library
183  *
184  * <table>
185  * <tr>
186  * <td>
187  * <a href="http://scip.zib.de/doc/examples/CallableLibrary"><b>CallableLibrary</b></a>
188  * </td>
189  * <td>
190  * An example showing how to setup constraints (esp. nonlinear ones) when using SCIP as callable library.
191  * </td>
192  * </tr>
193  * <tr>
194  * <td>
195  * <a href="http://scip.zib.de/doc/examples/MIPSolver"><b>MIPSolver</b></a>
196  * </td>
197  * <td>
198  * A minimal implementation for using SCIP included into another source code
199  * </td>
200  * </tr>
201  * <tr>
202  * <td>
203  * <a href="http://scip.zib.de/doc/examples/Queen/scip_intro.pdf"><b>Queen</b></a>
204  * </td>
205  * <td>
206  * An example showing the use of SCIP as callable library.
207  * </td>
208  * </tr>
209  * </table>
210  *
211  *
212  * @section OTHERPLUGINS Other plugins
213  *
214  * <table>
215  * <tr>
216  * <td>
217  * <a href="http://scip.zib.de/doc/examples/Eventhdlr"><b>Eventhdlr</b></a>
218  * </td>
219  * <td>
220  * A small example illustrating the use of an event handler.
221  * </td>
222  * </tr>
223  * <tr>
224  * <td>
225  * <a href="http://scip.zib.de/doc/examples/Scheduler"><b>Scheduler</b></a>
226  * </td>
227  * <td>
228  * An example containing three readers and one primal heuristic for scheduling problems.
229  * </td>
230  * </tr>
231  * <tr>
232  * <td>
233  * <a href="http://scip.zib.de/doc/examples/GMI"><b>GMI</b></a>
234  * </td>
235  * <td>
236  * An example about Gomory mixed-integer cuts.
237  * </td>
238  * </tr>
239  * </table>
240  *
241  */
242 
243 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
244 /**@page CODE Coding style guidelines
245  *
246  * We follow the following coding style guidelines and recommend them for all developers.
247  *
248  * - Indentation is 3 spaces. No tabs anywhere in the code.
249  * - Always only one declaration in a line.
250  * - Braces are on a new line and not indented.
251  * - Spaces around all operators.
252  * - No spaces between control structure keywords like "if", "for", "while", "switch" and the corresponding brackets.
253  * - No spaces between a function name and the parenthesis in both the definition and function calls.
254  * - Use assert() to show preconditions for the parameters, invariants and postconditions.
255  * - All global functions start with "SCIP". In the usual naming scheme this is followed by the object and a method name
256  * like in SCIPlpAddRow(). Functions return TRUE or FALSE should be named like SCIPisFeasEQ().
257  * - Make all functions that are not used outside the module 'static'. Naming should start with a lower case letter.
258  * - Variable names should be all lower case.
259  * - For each structure there is a typedef with the name in all upper case.
260  * - Defines should be named all upper case.
261  * - Document functions, parameters, and variables in a doxygen conformed way.
262  *
263  * As an example, have a look at tree.c and see the examples below. We also provide settings for
264  * \ref XEMACS "(x)emacs" and \ref ECLIPSE "eclipse".
265  *
266  * @section CODEEXAMPLES Examples
267  *
268  * In this section we state a few examples illustrating the \SCIP code style.
269  *
270  * \code
271  * #ifdef __cplusplus
272  * extern "C" {
273  * #endif
274  *
275  * /** SCIP operation stage */
276  * enum SCIP_Stage
277  * {
278  * SCIP_STAGE_INIT = 0, /**< SCIP datastructures are initialized, no problem exists */
279  * SCIP_STAGE_PROBLEM = 1, /**< the problem is being created and modified */
280  * SCIP_STAGE_TRANSFORMING = 2, /**< the problem is being transformed into solving data space */
281  * SCIP_STAGE_TRANSFORMED = 3, /**< the problem was transformed into solving data space */
282  * SCIP_STAGE_PRESOLVING = 4, /**< the problem is being presolved */
283  * SCIP_STAGE_PRESOLVED = 5, /**< the problem was presolved */
284  * SCIP_STAGE_INITSOLVE = 6, /**< the solving process data is being initialized */
285  * SCIP_STAGE_SOLVING = 7, /**< the problem is being solved */
286  * SCIP_STAGE_SOLVED = 8, /**< the problem was solved */
287  * SCIP_STAGE_FREESOLVE = 9, /**< the solving process data is being freed */
288  * SCIP_STAGE_FREETRANS = 10 /**< the transformed problem is being freed */
289  * };
290  * typedef enum SCIP_Stage SCIP_STAGE;
291  *
292  * /** possible settings for enabling/disabling algorithms and other features */
293  * enum SCIP_Setting
294  * {
295  * SCIP_UNDEFINED = 0, /**< undefined setting */
296  * SCIP_DISABLED = 1, /**< feature is disabled */
297  * SCIP_AUTO = 2, /**< feature is set to automatic mode */
298  * SCIP_ENABLED = 3 /**< feature is enabled */
299  * };
300  * typedef enum SCIP_Setting SCIP_SETTING;
301  *
302  * #ifdef __cplusplus
303  * }
304  * #endif
305  * \endcode
306  *
307  * @section XEMACS Customize (x)emacs
308  *
309  * If you are using (x)emacs, you can use the following customization for the c++-mode. These settings satisfy the
310  * coding guidelines of \SCIP.
311  *
312  * \verbatim
313  (add-hook 'c++-mode-hook
314  (function
315  (lambda ()
316  ;; SCIP customizations for c-mode and c++-mode
317  (setq-default c-basic-offset 3)
318  (c-set-offset 'substatement-open 0)
319  (c-set-offset 'statement-case-open 0)
320  (c-set-offset 'brace-list-open '-)
321  (c-set-offset 'inextern-lang '0)
322  (c-set-offset 'arglist-intro '+)
323  (c-set-offset 'arglist-cont 0)
324  (c-set-offset 'arglist-cont-nonempty '+)
325  (c-set-offset 'arglist-close '+)
326  (set-variable 'fill-column 120)
327  ;; this will make sure spaces are used instead of tabs
328  (setq tab-width 8 indent-tabs-mode nil)
329  )))\endverbatim
330  *
331  * @section ECLIPSE Customize eclipse
332  *
333  *
334  * Eclipse user can use the profile below. This profile does not match the \SCIP coding guideline completely.
335  *
336  * \code
337  *
338  * <?xml version="1.0" encoding="UTF-8" standalone="no"?>
339  * <profiles version="1">
340  * <profile kind="CodeFormatterProfile" name="scip" version="1">
341  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_method_declaration" value="do not insert"/>
342  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_for" value="insert"/>
343  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_in_empty_block" value="insert"/>
344  * <setting id="org.eclipse.cdt.core.formatter.lineSplit" value="124"/>
345  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_base_types" value="do not insert"/>
346  * <setting id="org.eclipse.cdt.core.formatter.keep_else_statement_on_same_line" value="false"/>
347  * <setting id="org.eclipse.cdt.core.formatter.indent_switchstatements_compare_to_switch" value="false"/>
348  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_brace_in_array_initializer" value="insert"/>
349  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_method_declaration_parameters" value="do not insert"/>
350  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_if" value="insert"/>
351  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_exception_specification" value="do not insert"/>
352  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_parenthesized_expression" value="do not insert"/>
353  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_base_types" value="insert"/>
354  * <setting id="org.eclipse.cdt.core.formatter.indent_body_declarations_compare_to_access_specifier" value="true"/>
355  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_exception_specification" value="do not insert"/>
356  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_template_arguments" value="insert"/>
357  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_block" value="insert"/>
358  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_method_declaration" value="do not insert"/>
359  * <setting id="org.eclipse.cdt.core.formatter.use_tabs_only_for_leading_indentations" value="false"/>
360  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_colon_in_labeled_statement" value="do not insert"/>
361  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_colon_in_case" value="insert"/>
362  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_array_initializer" value="insert"/>
363  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_enum_declarations" value="insert"/>
364  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_expressions_in_array_initializer" value="16"/>
365  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_declarator_list" value="insert"/>
366  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_bracket" value="do not insert"/>
367  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_for" value="insert"/>
368  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_prefix_operator" value="do not insert"/>
369  * <setting id="org.eclipse.cdt.core.formatter.tabulation.size" value="3"/>
370  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_before_else_in_if_statement" value="insert"/>
371  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_enumerator_list" value="48"/>
372  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_parenthesized_expression" value="do not insert"/>
373  * <setting id="org.eclipse.cdt.core.formatter.insert_space_between_empty_parens_in_method_declaration" value="do not insert"/>
374  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_declarator_list" value="16"/>
375  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_switch" value="insert"/>
376  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_parenthesized_expression" value="do not insert"/>
377  * <setting id="org.eclipse.cdt.core.formatter.indent_empty_lines" value="false"/>
378  * <setting id="org.eclipse.cdt.core.formatter.indent_switchstatements_compare_to_cases" value="true"/>
379  * <setting id="org.eclipse.cdt.core.formatter.keep_empty_array_initializer_on_one_line" value="false"/>
380  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_method_declaration" value="insert"/>
381  * <setting id="org.eclipse.cdt.core.formatter.put_empty_statement_on_new_line" value="true"/>
382  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_switch" value="do not insert"/>
383  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_cast" value="do not insert"/>
384  * <setting id="org.eclipse.cdt.core.formatter.insert_space_between_empty_braces_in_array_initializer" value="do not insert"/>
385  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_method_declaration" value="next_line"/>
386  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_while" value="insert"/>
387  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_question_in_conditional" value="insert"/>
388  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_semicolon" value="do not insert"/>
389  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_closing_angle_bracket_in_template_arguments" value="insert"/>
390  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_colon_in_base_clause" value="do not insert"/>
391  * <setting id="org.eclipse.cdt.core.formatter.indent_breaks_compare_to_cases" value="true"/>
392  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_unary_operator" value="do not insert"/>
393  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_declarator_list" value="do not insert"/>
394  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_arguments_in_method_invocation" value="16"/>
395  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_while" value="do not insert"/>
396  * <setting id="org.eclipse.cdt.core.formatter.insert_space_between_empty_brackets" value="do not insert"/>
397  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_bracket" value="do not insert"/>
398  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_parameters_in_method_declaration" value="48"/>
399  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_before_closing_brace_in_array_initializer" value="do not insert"/>
400  * <setting id="org.eclipse.cdt.core.formatter.number_of_empty_lines_to_preserve" value="1"/>
401  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_method_invocation" value="do not insert"/>
402  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_brace_in_array_initializer" value="insert"/>
403  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_semicolon_in_for" value="do not insert"/>
404  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_block" value="next_line"/>
405  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_colon_in_conditional" value="insert"/>
406  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_type_declaration" value="next_line"/>
407  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_assignment_operator" value="insert"/>
408  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_angle_bracket_in_template_arguments" value="do not insert"/>
409  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_expression_list" value="do not insert"/>
410  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_angle_bracket_in_template_parameters" value="do not insert"/>
411  * <setting id="org.eclipse.cdt.core.formatter.continuation_indentation" value="1"/>
412  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_expression_list" value="0"/>
413  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_method_declaration" value="do not insert"/>
414  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_template_parameters" value="do not insert"/>
415  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_colon_in_default" value="do not insert"/>
416  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_binary_operator" value="insert"/>
417  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_conditional_expression" value="16"/>
418  * <setting id="org.eclipse.cdt.core.formatter.insert_space_between_empty_parens_in_method_invocation" value="do not insert"/>
419  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_array_initializer" value="do not insert"/>
420  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_if" value="insert"/>
421  * <setting id="org.eclipse.cdt.core.formatter.format_guardian_clause_on_one_line" value="false"/>
422  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_cast" value="do not insert"/>
423  * <setting id="org.eclipse.cdt.core.formatter.indent_access_specifier_compare_to_type_header" value="false"/>
424  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_type_declaration" value="insert"/>
425  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_colon_in_labeled_statement" value="insert"/>
426  * <setting id="org.eclipse.cdt.core.formatter.continuation_indentation_for_array_initializer" value="1"/>
427  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_method_declaration_parameters" value="insert"/>
428  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_semicolon_in_for" value="insert"/>
429  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_method_invocation" value="do not insert"/>
430  * <setting id="org.eclipse.cdt.core.formatter.indent_body_declarations_compare_to_namespace_header" value="false"/>
431  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_closing_brace_in_block" value="insert"/>
432  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_assignment_operator" value="insert"/>
433  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_compact_if" value="0"/>
434  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_array_initializer" value="insert"/>
435  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_at_end_of_file_if_missing" value="do not insert"/>
436  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_template_parameters" value="insert"/>
437  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_expression_list" value="insert"/>
438  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_question_in_conditional" value="insert"/>
439  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_exception_specification" value="insert"/>
440  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_binary_operator" value="insert"/>
441  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_before_identifier_in_function_declaration" value="do not insert"/>
442  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_base_clause_in_type_declaration" value="80"/>
443  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_method_declaration_throws" value="do not insert"/>
444  * <setting id="org.eclipse.cdt.core.formatter.insert_space_between_empty_parens_in_exception_specification" value="do not insert"/>
445  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_method_invocation_arguments" value="do not insert"/>
446  * <setting id="org.eclipse.cdt.core.formatter.indent_declaration_compare_to_template_header" value="false"/>
447  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_unary_operator" value="do not insert"/>
448  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_switch" value="do not insert"/>
449  * <setting id="org.eclipse.cdt.core.formatter.indent_statements_compare_to_body" value="true"/>
450  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_method_declaration_throws" value="insert"/>
451  * <setting id="org.eclipse.cdt.core.formatter.indent_statements_compare_to_block" value="true"/>
452  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_template_arguments" value="do not insert"/>
453  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_before_catch_in_try_statement" value="insert"/>
454  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_throws_clause_in_method_declaration" value="48"/>
455  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_method_invocation" value="do not insert"/>
456  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_closing_paren_in_cast" value="do not insert"/>
457  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_catch" value="insert"/>
458  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_angle_bracket_in_template_parameters" value="do not insert"/>
459  * <setting id="org.eclipse.cdt.core.formatter.tabulation.char" value="space"/>
460  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_angle_bracket_in_template_parameters" value="do not insert"/>
461  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_while" value="insert"/>
462  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_method_invocation_arguments" value="insert"/>
463  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_block_in_case" value="next_line"/>
464  * <setting id="org.eclipse.cdt.core.formatter.compact_else_if" value="true"/>
465  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_postfix_operator" value="do not insert"/>
466  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_colon_in_base_clause" value="insert"/>
467  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_after_template_declaration" value="do not insert"/>
468  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_catch" value="insert"/>
469  * <setting id="org.eclipse.cdt.core.formatter.keep_then_statement_on_same_line" value="false"/>
470  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_switch" value="next_line"/>
471  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_if" value="do not insert"/>
472  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_switch" value="insert"/>
473  * <setting id="org.eclipse.cdt.core.formatter.keep_imple_if_on_one_line" value="false"/>
474  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_after_opening_brace_in_array_initializer" value="do not insert"/>
475  * <setting id="org.eclipse.cdt.core.formatter.indentation.size" value="3"/>
476  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_namespace_declaration" value="end_of_line"/>
477  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_colon_in_conditional" value="insert"/>
478  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_enum_declarations" value="do not insert"/>
479  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_prefix_operator" value="do not insert"/>
480  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_angle_bracket_in_template_arguments" value="do not insert"/>
481  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_array_initializer" value="end_of_line"/>
482  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_colon_in_case" value="do not insert"/>
483  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_catch" value="do not insert"/>
484  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_namespace_declaration" value="insert"/>
485  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_postfix_operator" value="do not insert"/>
486  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_bracket" value="do not insert"/>
487  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_before_while_in_do_statement" value="insert"/>
488  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_for" value="do not insert"/>
489  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_closing_angle_bracket_in_template_parameters" value="insert"/>
490  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_angle_bracket_in_template_arguments" value="do not insert"/>
491  * </profile>
492  * </profiles>
493  * \endcode
494  */
495 
496 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
497 /**@page MAKE Makefiles / Installation information
498  *
499  *
500  * In most cases (LINUX and MAC) it is quite easy to compile and install SCIP. Therefore, reading the section
501  * \ref BRIEFINSTALL "Brief installation description" should usually be enough. If this is not the case you find
502  * \ref DETAILEDINSTALL "Detailed installation description" below as well as \ref EXAMPLE1 "Examples".
503 *
504  * @section BRIEFINSTALL Brief installation description
505  *
506  * The easiest way to install SCIP is to use the SCIP Optimization Suite which contains SCIP, SoPlex, and ZIMPL. For
507  * that we refer to the INSTALL file of the SCIP Optimization Suite (main advantage: there is no need
508  * to specify any directories, the compiling process is fully automated).
509  *
510  * Compiling SCIP directly can be done as follows:
511  *
512  * -# unpack the tarball <code>tar xvf scip-x.y.z.tgz</code>
513  * -# change to the directory <code>cd scip-x.y.z</code>
514  * -# start compiling SCIP by typing <code>make</code>
515  * -# (optional) install the header, libraries, and binary <code>make install INSTALLDIR="/usr/local/</code>
516  *
517  * During your first compilation you will be asked for some soft-link targets,
518  * depending on the LP solver you want to use. Usually, SCIP needs the
519  * following information
520  * -# the directory where the include files of the LP solver lie
521  * -# the library file(s) "lib*.a" or/and "lib*.so"
522  *
523  * Besides that, SCIP needs some soft-link targets, for ZIMPL
524  * -# the directory where the include files of ZIMPL lie
525  * -# the library file(s) "lib*.a" or/and "lib*.so"
526  *
527  * You will need either the .a or the .so files and can skip the others by
528  * just pressing return.
529  *
530  * The most common compiling issue is that some libraries are missing
531  * on your system or that they are outdated. SCIP per default requires
532  * zlib, gmp and readline. Try compiling with: <code> make ZLIB=false
533  * READLINE=false ZIMPL=false</code> or, better, install them. Note
534  * that under Linux-based systems, you need to install the
535  * developer-versions of gmp/zlib/readline, in order to also have the
536  * header-files available.
537  *
538  @section DETAILEDINSTALL Detailed installation description
539  *
540  * In this section we describe the use, and a few features, of the SCIP Makefile. We also give two examples for how to install
541  * SCIP. The \ref EXAMPLE1 "first example" illustrates the default installation. This means, with SoPleX and ZIMPL. The
542  * \ref EXAMPLE2 "second example" shows how to get CPLEX linked to SCIP without ZIMPL. This is followed by a section which
543  * gives some hints on what to do if the \ref COMPILERPROBLEMS "compilation throws an error". We give some comments on
544  * how to install SCIP under \ref WINDOWS "WINDOWS" and show \ref RUN "how to start SCIP".
545  *
546  * If you experience any problems during the installation, you will find help in the \ref INSTALL "INSTALL" file.
547  *
548  * SCIP contains a makefile system, which allows the individual setting of several parameters. For
549  * instance, the following settings are supported:
550  *
551  * - <code>OPT=<dbg|opt|opt-gccold></code> Here <code>dbg</code> turns on the debug mode of SCIP. This enables asserts
552  * and avoids macros for several function in order to ease debugging. The default is <code>opt</code>, which enables
553  * the optimized mode. The third option <code>opt-gccold</code> will work with older GCC compilers before version
554  * 4.2. We recommend using newer GCC versions.
555  *
556  * - <code>LPS=<clp|cpx|grb|msk|qso|spx|xprs|none></code> This determines the LP-solver, which should have been
557  * installed separately from SCIP. The options are the following:
558  * - <code>clp</code>: COIN-OR Clp LP-solver
559  * - <code>cpx</code>: CPLEX LP-solver
560  * - <code>grb</code>: Gurobi LP-solver (interface is in beta stage)
561  * - <code>msk</code>: Mosek LP-solver
562  * - <code>qso</code>: QSopt LP-solver
563  * - <code>spx</code>: SoPlex LP-solver (default)
564  * - <code>xprs</code>: XPress LP-solver
565  * - <code>none</code>: no LP-solver (you should set the parameter <lp/solvefreq> to <-1> to avoid solving LPs)
566  *
567  * - <code>LPSOPT=<dbg|opt|opt-gccold></code> Chooses the debug or optimized version (or old GCC optimized) version of
568  * the LP-solver. (currently only available for SoPlex and CLP)
569  *
570  * - <code>ZIMPL=<true|false></code> Turns direct support of ZIMPL in SCIP on (default) or off, respectively.
571  * - <code>ZIMPLOPT=<dbg|opt|opt-gccold></code> Chooses the debug or optimized (default) (or old GCC optimized)
572  * version of ZIMPL, if ZIMPL support is enabled. \n
573  * If the ZIMPL-support is disabled, the GMP-library is no longer needed for SCIP and therefore not linked to SCIP.
574  *
575  * - <code>READLINE=<true|false></code> Turns support via the readline library on (default) or off, respectively.
576  *
577  * - <code>IPOPT=<true|false></code> to enable or disable (default) IPOPT interface (needs IPOPT)
578  *
579  * - <code>EXPRINT=<cppad|none></code> to use CppAD as expressions interpreter (default) or no expressions interpreter
580  *
581  * - <code>GAMS=<true|false></code> to enable or disable (default) reading functionality in GAMS reader (needs GAMS)
582  *
583  * There are additional parameters for Linux/Gnu compilers:
584  *
585  * - <code>OPT=noblkmem</code> turns off the internal SCIP memory. This way the code can be checked by valgrind or
586  * similar tools.
587  * - <code>OPT=opt-shared</code> generates a shared object of the SCIP libraries. (The binary uses these shared
588  * libraries as well.)
589  * - <code>OPT=prf</code> generates a profiling version of SCIP providing a detailed statistic of the time usage of
590  * every method of SCIP.
591  *
592  * You can use other compilers - depending on the system:
593  *
594  * - <code>COMP=intel</code> Uses of the Intel compiler which is only available with the main optimization flags
595  * <code>OPT=<dbg|opt></code>. (Default is gcc/g++ represented through <code>COMP=gnu</code>.)
596  *
597  * There is the possibility to watch the compilation more precisely:
598  *
599  * - <code>VERBOSE=<true|false></code> Turns the extensive output on or off (default).
600  *
601  * The SCIP makefile supports several targets (used via <code>make ... "target"</code>):
602  *
603  * - <code>links</code> Reconfigures the links in the "lib" directory.
604  * - <code>doc</code> Creates documentation in the "doc" directory.
605  * - <code>clean</code> Removes all object files.
606  * - <code>depend</code> Creates dependencies files. This is only needed if you add files to SCIP.
607  * - <code>check</code> Runs the check script, see \ref TEST.
608  *
609  * The SCIP makefiles are structured as follows.
610  *
611  * - <code>Makefile</code> This is the basic makefile in the SCIP root directory. It loads
612  * additional makefile information depending on the parameters set.
613  * - <code>make/make.project</code> This file contains definitions that are useful for all codes
614  * that use SCIP, for instance, the examples.
615  * - <code>make.<sys>.<machine>.<compiler>.<dbg|opt|prf|opt-gccold></code> These file contain system/compiler specific
616  * definitions. If you have an unsupported compiler, you can copy one of these and modify it
617  * accordingly.
618  *
619  * If your platform or compiler is not supported by SCIP you might try and copy one of the existing
620  * makefiles in the <code>make</code> directory and modify it. If you succeed, we are always
621  * interested in including more Makefiles into the system.
622  *
623  *
624  * @section EXAMPLE1 Example 1 (defaults: SoPlex, with ZIMPL support):
625  *
626  * Typing <code>make</code> uses SoPlex as LP solver and includes support for the modeling language ZIMPL. You will be asked the
627  * following questions on the first call to "make" (example answers are already given):
628  *
629  * \verbatim
630  > make
631  make[1]: Entering directory `scip-1.2'
632 
633  - Current settings: LPS=spx OSTYPE=linux ARCH=x86_64 COMP=gnu SUFFIX= ZIMPL=true ZIMPLOPT=opt IPOPT=false IPOPTOPT=opt
634 
635  * SCIP needs some softlinks to external programs, in particular, LP-solvers.
636  * Please insert the paths to the corresponding directories/libraries below.
637  * The links will be installed in the 'lib' directory.
638  * For more information and if you experience problems see the INSTALL file.
639 
640  -> "spxinc" is the path to the SoPlex "src" directory, e.g., "../../soplex/src".
641  -> "libsoplex.*" is the path to the SoPlex library, e.g., "../../soplex/lib/libsoplex.linux.x86.gnu.opt.a"
642  -> "zimplinc" is a directory containing the path to the ZIMPL "src" directory, e.g., "../../zimpl/src".
643  -> "libzimpl.*" is the path to the ZIMPL library, e.g., "../../zimpl/lib/libzimpl.linux.x86.gnu.opt.a"
644 
645  - preparing missing soft-link "lib/spxinc":
646  > Enter soft-link target file or directory for "lib/spxinc" (return if not needed):
647  > ../../soplex/src/
648  -> creating softlink "lib/spxinc" -> "../../soplex/src"
649 
650 
651  - preparing missing soft-link "lib/libsoplex.linux.x86_64.gnu.opt.a":
652  > Enter soft-link target file or directory for "lib/libsoplex.linux.x86_64.gnu.opt.a" (return if not needed):
653  > ../../soplex/lib/libsoplex.linux.x86_64.gnu.opt.a
654  -> creating softlink "lib/libsoplex.linux.x86_64.gnu.opt.a" -> "../../soplex/lib/libsoplex.linux.x86_64.gnu.opt.a"
655 
656 
657  - preparing missing soft-link "lib/libsoplex.linux.x86_64.gnu.opt.so":
658  * this soft-link is not necessarily needed since "lib/libsoplex.linux.x86_64.gnu.opt.a" already exists - press return to skip
659  > Enter soft-link target file or directory for "lib/libsoplex.linux.x86_64.gnu.opt.so" (return if not needed):
660  >
661  * skipped creation of softlink "lib/libsoplex.linux.x86_64.gnu.opt.so". Call "make links" if needed later.
662 
663 
664  - preparing missing soft-link "lib/zimplinc/zimpl":
665  > Enter soft-link target file or directory for "lib/zimplinc/zimpl" (return if not needed):
666  ../../zimpl/src/
667  creating softlink "lib/zimplinc/zimpl" -> "../../zimpl/src"
668 
669 
670  - preparing missing soft-link "lib/libzimpl.linux.x86_64.gnu.opt.a":
671  > Enter soft-link target file or directory for "lib/libzimpl.linux.x86_64.gnu.opt.a" (return if not needed):
672  > ../../zimpl/lib/libzimpl.linux.x86_64.gnu.opt.a
673  -> creating softlink "lib/libzimpl.linux.x86_64.gnu.opt.a" -> "../../zimpl/lib/libzimpl.linux.x86_64.gnu.opt.a"
674 
675 
676  - preparing missing soft-link "lib/libzimpl.linux.x86_64.gnu.opt.so":
677  * this soft-link is not necessarily needed since "lib/libzimpl.linux.x86_64.gnu.opt.a" already exists - press return to skip
678  > Enter soft-link target file or directory for "lib/libzimpl.linux.x86_64.gnu.opt.so" (return if not needed):
679  >
680  * skipped creation of softlink "lib/libzimpl.linux.x86_64.gnu.opt.so". Call "make links" if needed later.
681 
682  ...
683 
684  -> generating library lib/libobjscip-1.2.0.linux.x86_64.gnu.opt.a
685  -> generating library lib/liblpispx-1.2.0.linux.x86_64.gnu.opt.a
686  -> generating library lib/libscip-1.2.0.linux.x86_64.gnu.opt.a
687  -> linking bin/scip-1.2.0.linux.x86_64.gnu.opt.spx
688 
689  \endverbatim
690  *
691  * @section EXAMPLE2 Example 2 (CPLEX, with no ZIMPL support):
692  *
693  * Typing <code>make LPS=cpx ZIMPL=false</code> uses CPLEX as LP solver. You will be asked the following questions on
694  * the first call to "make" (example answers are already given):
695  *
696  * \verbatim
697  > make LPS=cpx ZIMPL=false
698  make[1]: Entering directory `scip-1.2'
699 
700  - Current settings: LPS=cpx OSTYPE=linux ARCH=x86_64 COMP=gnu SUFFIX= ZIMPL=false ZIMPLOPT=opt IPOPT=false IPOPTOPT=opt
701 
702  * SCIP needs some softlinks to external programs, in particular, LP-solvers.
703  * Please insert the paths to the corresponding directories/libraries below.
704  * The links will be installed in the 'lib' directory.
705  * For more information and if you experience problems see the INSTALL file.
706 
707  -> "cpxinc" is the path to the CPLEX "include" directory, e.g., "<CPLEX-path>/include/ilcplex".
708  -> "libcplex.*" is the path to the CPLEX library, e.g., "<CPLEX-path>/lib/x86_rhel4.0_3.4/static_pic/libcplex.a"
709 
710  - preparing missing soft-link "lib/cpxinc":
711  > Enter soft-link target file or directory for "lib/cpxinc" (return if not needed):
712  > ../../cplex121/include
713  -> creating softlink "lib/cpxinc" -> "../../cplex121/include"
714 
715 
716  - preparing missing soft-link "lib/libcplex.linux.x86_64.gnu.a":
717  > Enter soft-link target file or directory for "lib/libcplex.linux.x86_64.gnu.a" (return if not needed):
718  > ../../cplex121/lib/x86-64_sles9.0_3.3/static_pic/libcplex.a
719  -> creating softlink "lib/libcplex.linux.x86_64.gnu.a" -> "../../../../adm_cple/cplex121/lib/x86-64_sles9.0_3.3/static_pic/libcplex.a"
720 
721 
722  - preparing missing soft-link "lib/libcplex.linux.x86_64.gnu.so":
723  > Enter soft-link target file or directory for "lib/libcplex.linux.x86_64.gnu.so" (return if not needed):
724  >
725  * skipped creation of softlink "lib/libcplex.linux.x86_64.gnu.so". Call "make links" if needed later.
726 
727  ...
728 
729  -> generating library lib/libobjscip-1.2.0.linux.x86_64.gnu.opt.a
730  -> generating library lib/liblpicpx-1.2.0.linux.x86_64.gnu.opt.a
731  -> generating library lib/libscip-1.2.0.linux.x86_64.gnu.opt.a
732  -> linking bin/scip-1.2.0.linux.x86_64.gnu.opt.cpx
733 
734  \endverbatim
735  *
736  * @section COMPILERPROBLEMS Compilation problems:
737  *
738  * - If the soft-link query script does not work on your machine, read step 2 in the \ref INSTALL "INSTALL" file for
739  * instructions on manually creating the soft-links.
740  *
741  * - If you get an error message of the type\n
742  * <code>make: *** No rule to make target `lib/???', needed by `obj/O.linux.x86.gnu.opt/lib/scip/???.o'. Stop.</code>\n
743  * the corresponding soft-link was not created or points to a wrong location. Check the soft-link targets in the "lib/"
744  * subdirectory. Try to delete all soft-links from the "lib/" directory\n and call "make links" to generate them
745  * again. If this still fails, read step 2 for instructions on manually\n creating the soft-links.
746  *
747  * - If you get an error message of the type\n
748  * <code>make: *** No rule to make target `make/make.?.?.?.?.?'. Stop.</code>,\n
749  * the corresponding machine dependent makefile for your architecture and compiler is missing.\n Create one of the given
750  * name in the "make/" subdirectory. You may take\n "make/make.linux.x86.gnu.opt" or any other file in the make
751  * subdirectory as example.\n
752  *
753  * - The readline library seems to differ slightly on different OS distributions. Some versions do
754  * not support the <code>remove_history()</code> call. In this case, you have to either add
755  * <code>-DNO_REMOVE_HISTORY</code> to the FLAGS in the appropriate "make/make.*" file, or to
756  * compile with <code>make USRFLAGS=-DNO_REMOVE_HISTORY</code>. Make sure, the file
757  * "src/scip/dialog.c" is recompiled. If this doesn't work either, disable the readline library
758  * with <code>make READLINE=false</code>.
759  *
760  * - On some systems, the <code>sigaction()</code> method is not available. In this case, you have
761  * to either add <code>-DNO_SIGACTION</code> to the FLAGS in the appropriate "make/make.*" file, or
762  * to compile with <code>make USRFLAGS=-DNO_SIGACTION</code>. Make sure, the file
763  * "src/scip/interrupt.c" is recompiled.
764  *
765  * - On some systems, the <code>rand_r()</code> method is not available. In this case, you have to either add
766  * <code>-DNO_RAND_R</code> to the FLAGS in the appropriate "make/make.*" file, or to compile with
767  * <code>make USRFLAGS=-DNO_RAND_R</code>. Make sure, the file "src/scip/misc.c" is recompiled.
768  *
769  * - On some systems, the <code>strtok_r()</code> method is not available. In this case, you have
770  * to either add <code>-DNO_STRTOK_R</code> to the FLAGS in the appropriate make/make.* file, or to
771  * compile with <code>make USRFLAGS=-DNO_STRTOK_R</code>. Make sure, the file "src/scip/misc.c" is
772  * recompiled.
773  *
774  * - On some systems, the <code>strerror_r()</code> method is not available. In this case, you have
775  * to either add <code>-DNO_STRERROR_R</code> to the FLAGS in the appropriate "make/make.*" file, or
776  * to compile with <code>make USRFLAGS=-DNO_STRERROR_R</code>. Make sure, the file
777  * "src/scip/misc.c" is recompiled.
778  *
779  * - On some systems, the option [-e] is not available for the read command. You have to compile with READ=read.
780  *
781  * - If you encounter other compiler or linker errors, you should recompile with <code>make
782  * VERBOSE=true ...</code> in order to get the full compiler invocation. This might help to fix the
783  * corresponding machine dependent makefile in the make subdirectory.
784  *
785  * @section WINDOWS Remarks on Installing under Windows using MinGW
786  *
787  * To build your own windows binaries under windows we recommend using the MinGW-Compiler with MSYS
788  * from <a href="http://www.mingw.org">www.mingw.org</a> .
789  *
790  * First install MSYS, then MinGW to the mingw folder inside the msys folder.
791  * Now you need to install the following packages to the mingw folder:
792  * - zlib (or use ZLIB=false)
793  * - pcre (here suffices the pcre7.0-lib.zip (or equivalent) to be extracted into the mingw-folder)
794  *
795  * After calling <code>make clean</code> in the ZIMPL folder you will also need flex and bison to
796  * remake ZIMPL. We recommend NOT to use <code>"make clean"</code> inside the ZIMPL-folder if you do
797  * not have these packages installed.
798  *
799  * You can download these additional packages from <a href="http://gnuwin32.sourceforge.net/packages.html">here</a>
800  * or compile the source on your own from their homepages.
801  *
802  * Second you need to copy the file <code>sh.exe</code> to <code>bash.exe</code> otherwise various
803  * scripts (including makefiles) will not work. Normally <code>unistd.h</code> covers also the
804  * getopt-options, but for mingw you need to add the entry <code>\#include <getopt.h></code> into
805  * "/mingw/include/unistd.h" after the other include-entries (if not present).
806  *
807  * Finally, there is one package you need to compile if you want to use ZIMPL and ZIMPL-support in
808  * SCIP (otherwise use <code>ZIMPL=false</code> as parameter with the make-call): the
809  * <code>gmplib</code> from <a href="http://www.gmplib.org">gmplib.org</a>. The command
810  * <code>./configure --prefix=/mingw ; make ; make install</code> should succeed without problems
811  * and installs the gmplib to the mingw folder.
812  *
813  * Now <code>make READLINE=false</code> should be compiling without errors. Please note that we
814  * do NOT support creating the doxygen documentation and readline-usage under windows.
815  *
816  *
817  * @section RUN How to run SCIP after successfully compiling SCIP
818  *
819  * To run the program, enter <code>bin/scip</code> for the last compiled version. If you have more than one compiled
820  * binary (i. e., one in debug and one in optimized mode) and wish to specify the binary, type
821  * <code>bin/scip.\$(OSTYPE).\$(ARCH).\$(COMP).\$(OPT).\$(LPS)</code>
822  * (e.g. <code>bin/scip.linux.x86_64.gnu.opt.spx</code>).
823  *
824  */
825 
826 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
827 /**@page START How to start a new project
828  *
829  * Once you succeeded installing SCIP together with an LP-solver on your system,
830  * you have a powerful tool for solving MIPs, MIQCPs,
831  * MINLPs, etc... at hand. SCIP can also be customized to the type of problems you
832  * are working on by additional plugins.
833  * Instructions on how to write a new plugin and include it in SCIP can be found in the corresponding
834  * \ref HOWTOADD "How to add ... pages".
835  *
836  * SCIP can also be used for writing your own branch-and-cut or branch-and-cut-and-price code. SCIP already
837  * provides a number of existing code examples which we suggest as both reference and starting point
838  * for these kinds of projects.
839  * Below, you find some hints of how to start such a project.
840  *
841  * The example should be chosen
842  * depending on the programming language (<b>C</b> or <b>C++</b>) and the purpose
843  * (<b>branch-and-cut</b> or <b>branch-and-cut-and-price</b>) of your project.
844  *
845  * We suggest the use one of the following examples:
846  * - The <a href="http://scip.zib.de/doc/examples/VRP"><b>VRP</b></a>-example is a <b>branch-and-cut-and-price</b> (column generation)-code
847  * in <b>C++</b>.
848  * - The <a href="http://scip.zib.de/doc/examples/Coloring"><b>Coloring</b></a>
849  * and the <a href="http://scip.zib.de/doc/examples/Binpacking"><b>Binpacking</b></a>-example are
850  * <b>branch-and-cut-and-price</b> (column generation)-codes in <b>C</b>.
851  * - The <a href="http://scip.zib.de/doc/examples/TSP"><b>TSP</b></a>-example
852  * is a <b>branch-and-cut</b>-code in <b>C++</b>.
853  * - The <a href="http://scip.zib.de/doc/examples/LOP"><b>LOP</b></a>-example
854  * is a <b>branch-and-cut</b>-code in <b>C</b>.
855  *
856  * - Copy one of the examples in the <code>examples</code> directory (in the SCIP root
857  * directory). For instance, type
858  * \verbatim
859  > cp -r examples/Coloring/ ../SCIPProject/ ; cd ../SCIPProject
860  \endverbatim
861  *
862  * from the SCIP root directory for copying the content of the <code>Coloring</code>-example into a fresh
863  * directory named SCIPProject in the parent directory of the SCIP root directory and jumping to
864  * the new SCIPProject directory rightafter.
865  *
866  * - Open the <code>Makefile</code> via
867  * \verbatim
868  > kate Makefile
869  \endverbatim
870  *
871  * and edit the following variables at the top to have a compilable code:
872  *
873  * - specify a correct path to the SCIP root (<code>SCIPDIR</code>)
874  * - rename the targets name (<code>MAINNAME</code>)
875  * - adjust the source file names (<code>MAINOBJ</code>).
876  *
877  * - Once you have edited the makefile, you can use all the flags that can be used in SCIP to
878  * compile your code, see \ref MAKE.
879  * Note that you need to update the dependency files before compiling your project via <code>make depend</code>.
880  *
881  *
882  *
883  *
884  */
885 
886 
887 /**@page SHELL Tutorial: the interactive shell
888  *
889  * If are using SCIP as a black box solver, here you will find some tips and tricks what you can do.
890  *
891  * First of all, we need a SCIP binary and an example problem file to work with. Therefore, you can either download the
892  * SCIP standard distribution (which includes problem files) and compile it on your own or you can download a
893  * precompiled binary and an example problem separately. SCIP can read files in LP, MPS, ZPL, WBO, FZN, PIP, OSiL, and other formats (see \ref FILEREADERS).
894  *
895  * If you want to download the source code of the SCIP standard distribution, we recommend to go to the <a
896  * href="http://scip.zib.de/#download">SCIP download section</a>, download the latest release (version 3.0 as
897  * of this writing), inflate the tarball (e.g., with "tar xzf scipoptsuite-[version].tgz"), and follow the instructions
898  * in the INSTALL file. The instance stein27, which will serve as an example in this tutorial, can be found under
899  * scipoptsuite-[version]/scip-[version]/check/instances/MIP/stein27.mps.
900  *
901  * If you want to download a precompiled binary, go to the <a href="http://scip.zib.de/#download">SCIP download
902  * section</a> and download an appropriate binary for your operating system. To follow this tutorial, we recommend downloading the instance
903  * <a href="http://miplib.zib.de/miplib3/miplib3/stein27.mps.gz">stein27</a> from
904  * the <a href="http://miplib.zib.de/miplib3/miplib.html">MIPLIB 3.0</a> homepage.
905  *
906  * Now start your binary, without any arguments. This opens the interactive shell, which should look somehow like this:
907  *
908  * \code
909  * SCIP version 2.0.1 [precision: 8 byte] [memory: block] [mode: optimized] [LP solver: SoPlex 1.5.0]
910  * Copyright (c) 2002-2014 Konrad-Zuse-Zentrum fuer Informationstechnik Berlin (ZIB)
911  *
912  * External codes:
913  * SoPlex 1.5.0 Linear Programming Solver developed at Zuse Institute Berlin (soplex.zib.de)
914  * ZIMPL 3.1.0 Zuse Institute Mathematical Programming Language developed by T. Koch (zimpl.zib.de)
915  *
916  * user parameter file <scip.set> not found - using default parameters
917  *
918  * SCIP>
919  * \endcode
920  *
921  * First of all "help" shows you a list of all available shell commands. Brackets indicate a submenu with further options.
922  * \code
923  * SCIP> help
924 
925  * <display> display information
926  * <set> load/save/change parameters
927  * ...
928  * read read a problem
929  * \endcode
930  *
931  * Okay, let's solve some MIPs... use "read <path/to/file>" to parse a problem file, "optimize" to solve it and "display
932  * solution" to show the nonzero variables of the best found solution.
933 
934  * \code
935  * SCIP> read check/instances/MIP/stein27.mps
936  * original problem has 27 variables (27 bin, 0 int, 0 impl, 0 cont) and 118 constraints
937  * SCIP> optimize
938  *
939  * feasible solution found by trivial heuristic, objective value 2.700000e+01
940  * presolving:
941  * (round 1) 0 del vars, 0 del conss, 0 chg bounds, 0 chg sides, 0 chg coeffs, 118 upgd conss, 0 impls, 0 clqs
942  * presolving (2 rounds):
943  * 0 deleted vars, 0 deleted constraints, 0 tightened bounds, 0 added holes, 0 changed sides, 0 changed coefficients
944  * 0 implications, 0 cliques
945  * presolved problem has 27 variables (27 bin, 0 int, 0 impl, 0 cont) and 118 constraints
946  * 1 constraints of type <knapsack>
947  * 117 constraints of type <logicor>
948  * transformed objective value is always integral (scale: 1)
949  * Presolving Time: 0.00
950  *
951  * time | node | left |LP iter|LP it/n| mem |mdpt |frac |vars |cons |cols |rows |cuts |confs|strbr| dualbound | primalbound | gap
952  * t 0.0s| 1 | 0 | 34 | - | 337k| 0 | 21 | 27 | 118 | 27 | 118 | 0 | 0 | 0 | 1.300000e+01 | 2.700000e+01 | 107.69%
953  * R 0.0s| 1 | 0 | 34 | - | 338k| 0 | 21 | 27 | 118 | 27 | 118 | 0 | 0 | 0 | 1.300000e+01 | 2.600000e+01 | 100.00%
954  * s 0.0s| 1 | 0 | 34 | - | 339k| 0 | 21 | 27 | 118 | 27 | 118 | 0 | 0 | 0 | 1.300000e+01 | 2.500000e+01 | 92.31%
955  * 0.0s| 1 | 0 | 44 | - | 392k| 0 | 21 | 27 | 118 | 27 | 120 | 2 | 0 | 0 | 1.300000e+01 | 2.500000e+01 | 92.31%
956  * b 0.0s| 1 | 0 | 44 | - | 393k| 0 | 21 | 27 | 118 | 27 | 120 | 2 | 0 | 0 | 1.300000e+01 | 1.900000e+01 | 46.15%
957  * ...
958  * 0.1s| 1 | 2 | 107 | - | 920k| 0 | 24 | 27 | 118 | 27 | 131 | 13 | 0 | 24 | 1.300000e+01 | 1.900000e+01 | 46.15%
959  * R 0.1s| 14 | 10 | 203 | 7.4 | 935k| 13 | - | 27 | 118 | 27 | 124 | 13 | 0 | 164 | 1.300000e+01 | 1.800000e+01 | 38.46%
960  * 0.1s| 100 | 54 | 688 | 5.9 | 994k| 13 | 20 | 27 | 118 | 27 | 124 | 13 | 0 | 206 | 1.300000e+01 | 1.800000e+01 | 38.46%
961  * 0.1s| 200 | 86 | 1195 | 5.5 |1012k| 13 | - | 27 | 119 | 27 | 124 | 13 | 1 | 207 | 1.300000e+01 | 1.800000e+01 | 38.46%
962  * time | node | left |LP iter|LP it/n| mem |mdpt |frac |vars |cons |cols |rows |cuts |confs|strbr| dualbound | primalbound | gap
963  * 0.2s| 300 | 106 | 1686 | 5.3 |1024k| 13 | - | 27 | 119 | 27 | 124 | 13 | 1 | 207 | 1.350000e+01 | 1.800000e+01 | 33.33%
964  * ...
965  * 0.7s| 4100 | 50 | 18328 | 4.4 |1033k| 16 | 8 | 27 | 119 | 27 | 124 | 13 | 15 | 207 | 1.650000e+01 | 1.800000e+01 | 9.09%
966  *
967  * SCIP Status : problem is solved [optimal solution found]
968  * Solving Time (sec) : 0.73
969  * Solving Nodes : 4192
970  * Primal Bound : +1.80000000000000e+01 (283 solutions)
971  * Dual Bound : +1.80000000000000e+01
972  * Gap : 0.00 %
973  *
974  * SCIP> display solution
975  *
976  * objective value: 18
977  * x0001 1 (obj:1)
978  * x0003 1 (obj:1)
979  * ...
980  * x0027 1 (obj:1)
981  *
982  * SCIP>
983  * \endcode
984  *
985  * What do we see here? After "optimize", SCIP first goes into presolving. Not much is happening for this instance, just
986  * the linear constraints get upgraded to more specific types. Each round of presolving will be displayed in a single
987  * line, with a short summary at the end. Here, there has only been one round with actual changes, the second round did
988  * not bring any further reductions. Thus, it is not displayed and presolving is stopped. Then, we see the actual
989  * solving process. The first three output lines indicate that new incumbent solutions were found by the primal
990  * heuristics with display characters "t", "R", and "s"; see, how the "primalbound" column goes down from 27 to 25. In
991  * the fourth line, two "cuts" are added. Up to here, we needed 44 "LP iter"ations (34 for the first LP and 10 more to
992  * resolve after adding cuts). Little later, the root node processing is finished. We see that there are now two open
993  * nodes in the "left" column. From now on, we will see an output line every hundredth node or whenever a new incumbent
994  * is found (e.g. at node 14 in the above output). After some more nodes, the "dualbound" starts moving, too. At one
995  * point, both will be the same, and the solving process terminates, showing us some wrap-up information.
996  *
997  * The exact performance varies amongst different architectures, operating systems, and so on. Do not be worried if
998  * your installation needs more or less time or nodes to solve. Also, this instance has more than 2000 different optimal
999  * solutions. The optimal objective value always has to be 18, but the solution vector may differ. If you are interested
1000  * in this behavior, which is called "performance variability", you may have a look at the MIPLIB2010 paper.
1001  *
1002  * We might want to have some more information now. Which were the heuristics that found the solutions? What plugins
1003  * were called during the solutions process and how much time did they spend? How did the instance that we were solving
1004  * look? Information on certain plugin types (e.g., heuristics, branching rules, separators) we get by
1005  * "display <plugin-type>", information on the solution process, we get by "display statistics", and "display problem"
1006  * shows us the current instance.
1007  *
1008  \code
1009  * SCIP> display heuristics
1010  * primal heuristic c priority freq ofs description
1011  * ---------------- - -------- ---- --- -----------
1012  * trivial t 10000 0 0 start heuristic which tries some trivial solutions
1013  * ...
1014  * rounding R -1000 1 0 LP rounding heuristic with infeasibility recovering
1015  * shifting s -5000 10 0 LP rounding heuristic with infeasibility recovering also using continuous variables
1016  * ...
1017  * SCIP> display statistics
1018  * ...
1019  * gomory : 0.02 6 0 0 461 0
1020  * cgmip : 0.00 0 0 0 0 0
1021  * strongcg : 0.01 6 0 0 598 0
1022  * ...
1023  * oneopt : 0.01 4 1
1024  * coefdiving : 0.02 57 0
1025  * ...
1026  * primal LP : 0.00 0 0 0.00 -
1027  * dual LP : 0.20 4187 14351 3.43 71755.00
1028  * ...
1029  * \endcode
1030  *
1031  * We see that rounding and shifting were the heuristics producing the solutions in the beginning. Rounding is called at
1032  * every node, shifting only at every tenth level of the tree. The statistics are quite comprehensive, thus, we just
1033  * explain a few lines here. We get information for all types of plugins and for the overall solving process. Besides
1034  * others, we see that in six calls, the gomory cut separator and the strong Chv&aacute;tal-Gomory separator each produced
1035  * several hundred cuts (of which only a few entered the LP). The oneopt heuristic found one solution in 4 calls,
1036  * whereas coefdiving failed all 57 times it was called. All the LPs have been solved with the dual simplex algorithm, which
1037  * took about 0.2 seconds of the 0.7 seconds overall solving time.
1038  *
1039  * Now, we can start playing around with parameters. Rounding and shifting seem to be quite successful on this instance,
1040  * wondering what happens if we disable them? Or what happens, if we are even more rigorous and disable all heuristics?
1041  * Or if we do the opposite and use aggressive heuristics?
1042  *
1043  * \code
1044  * SCIP> set
1045  *
1046  * <branching> change parameters for branching rules
1047  * ...
1048  * <heuristics> change parameters for primal heuristics
1049  *
1050  * SCIP/set> heuristics
1051  *
1052  * <actconsdiving> LP diving heuristic that chooses fixings w.r.t. the active constraints
1053  * ...
1054  * <shifting> LP rounding heuristic with infeasibility recovering also using continuous variables
1055  * ...
1056  *
1057  * SCIP/set/heuristics> shifting
1058  *
1059  * <advanced> advanced parameters
1060  * freq frequency for calling primal heuristic <shifting> (-1: never, 0: only at depth freqofs) [10]
1061  * freqofs frequency offset for calling primal heuristic <shifting> [0]
1062  *
1063  * SCIP/set/heuristics/shifting> freq
1064  * current value: 10, new value [-1,2147483647]: -1
1065  * heuristics/shifting/freq = -1
1066  *
1067  * SCIP> se he rou freq -1
1068  * heuristics/rounding/freq = -1
1069  *
1070  * SCIP> re check/instances/MIP/stein27.mps
1071  * original problem has 27 variables (27 bin, 0 int, 0 impl, 0 cont) and 118 constraints
1072  * SCIP> o
1073  *
1074  * feasible solution found by trivial heuristic, objective value 2.700000e+01
1075  * ...
1076  * z 0.1s| 3 | 4 | 140 | 10.5 |1060k| 2 | 22 | 27 | 118 | 27 | 123 | 14 | 0 | 66 | 1.300000e+01 | 1.900000e+01 | 46.15%
1077  * z 0.1s| 6 | 7 | 176 | 11.4 |1063k| 5 | 18 | 27 | 118 | 27 | 123 | 14 | 0 | 118 | 1.300000e+01 | 1.900000e+01 | 46.15%
1078  * * 0.1s| 39 | 28 | 386 | 7.0 |1092k| 14 | - | 27 | 118 | 27 | 123 | 14 | 0 | 199 | 1.300000e+01 | 1.800000e+01 | 38.46%
1079  * ...
1080  * SCIP Status : problem is solved [optimal solution found]
1081  * Solving Time (sec) : 0.75
1082  * Solving Nodes : 4253
1083  * Primal Bound : +1.80000000000000e+01 (287 solutions)
1084  * Dual Bound : +1.80000000000000e+01
1085  * Gap : 0.00 %
1086  *
1087  * SCIP>
1088  * \endcode
1089  *
1090  * We can navigate through the menus step-by-step and get a list of available options and submenus. Thus, we select
1091  * "set" to change settings, "heuristics" to change settings of primal heuristics, "shifting" for that particular
1092  * heuristic. Then we see a list of parameters (and yet another submenu for advanced parameters), and disable this
1093  * heuristic by setting its calling frequency to -1. If we already know the path to a certain setting, we can directly
1094  * type it (as for the rounding heuristic in the above example). Note that we do not have to use the full names, but we
1095  * may use short versions, as long as they are unique.
1096  *
1097  * To solve a problem a second time, we have to read it and start the optimization process again.
1098  *
1099  * \code
1100  * SCIP> set default
1101  * reset parameters to their default values
1102  * SCIP> set heuristics emphasis
1103  *
1104  * aggressive sets heuristics <aggressive>
1105  * fast sets heuristics <fast>
1106  * off turns <off> all heuristics
1107  *
1108  * SCIP/set/heuristics/emphasis> aggr
1109  * heuristics/veclendiving/freq = 5
1110  * ...
1111  * heuristics/crossover/minfixingrate = 0.5
1112  * SCIP> read check/instances/MIP/stein27.mps
1113  * original problem has 27 variables (27 bin, 0 int, 0 impl, 0 cont) and 118 constraints
1114 
1115  * SCIP> opt
1116  * ...
1117  * D 0.1s| 1 | 0 | 107 | - | 971k| 0 | 24 | 27 | 122 | 27 | 131 | 13 | 4 | 0 | 1.300000e+01 | 1.800000e+01 | 38.46%
1118  * 0.1s| 1 | 0 | 107 | - | 971k| 0 | 24 | 27 | 122 | 27 | 131 | 13 | 4 | 0 | 1.300000e+01 | 1.800000e+01 | 38.46%
1119  * 0.1s| 1 | 0 | 119 | - |1111k| 0 | 24 | 27 | 122 | 27 | 132 | 14 | 4 | 0 | 1.300000e+01 | 1.800000e+01 | 38.46%
1120  * 0.1s| 1 | 2 | 119 | - |1112k| 0 | 24 | 27 | 122 | 27 | 132 | 14 | 4 | 24 | 1.300000e+01 | 1.800000e+01 | 38.46%
1121  * time | node | left |LP iter|LP it/n| mem |mdpt |frac |vars |cons |cols |rows |cuts |confs|strbr| dualbound | primalbound | gap
1122  * 0.2s| 100 | 59 | 698 | 5.8 |1138k| 14 | 11 | 27 | 122 | 27 | 123 | 14 | 4 | 204 | 1.300000e+01 | 1.800000e+01 | 38.46%
1123  * 0.2s| 200 | 91 | 1226 | 5.6 |1155k| 14 | - | 27 | 122 | 27 | 123 | 14 | 4 | 207 | 1.300000e+01 | 1.800000e+01 | 38.46%
1124  * ^Cpressed CTRL-C 1 times (5 times for forcing termination)
1125  *
1126  * SCIP Status : solving was interrupted [user interrupt]
1127  * Solving Time (sec) : 0.32
1128  * Solving Nodes : 216
1129  * Primal Bound : +1.80000000000000e+01 (283 solutions)
1130  * Dual Bound : +1.30000000000000e+01
1131  * Gap : 38.46 %
1132  *
1133  * SCIP>
1134  * \endcode
1135  *
1136  * Okay, what happened here? First, we reset all parameters to their default values, using "set default". Next, we
1137  * loaded some meta-parameter settings (also see <a href="http://scip.zib.de/#faq">the FAQ</a>), to apply primal heuristics
1138  * more aggressively. SCIP shows us, which single parameters it changed therefor. Now, the optimal solution is already
1139  * found at the root node, by a heuristic which is deactivated by default. Then, after node 200, the user pressed
1140  * CTRL-C which interrupts the solving process, We see that now in the short status report, primal and dual bound are
1141  * different, thus, the problem is not solved yet. Nevertheless, we could access statistics, see the current incumbent
1142  * solution, change parameters and so on. Entering "optimize" we continue the solving process from the point on at which
1143  * it has been interrupted.
1144  *
1145  * SCIP can also write information to files. E.g., we could store the incumbent solution to a file, or output the
1146  * problem instance in another file format (the LP format is much more human readable than the MPS format, for example).
1147  *
1148  * \code
1149  * SCIP> write solution stein27.sol
1150  *
1151  * written solution information to file <stein27.sol>
1152  *
1153  * SCIP> write problem stein27.lp
1154  * written original problem to file <stein27.lp>
1155  *
1156  * SCIP> q
1157  * ...
1158  * \endcode
1159  *
1160  * We hope this tutorial gave you an overview of what is possible using the SCIP interactive shell. Please also read our
1161  * \ref FAQ, in particular the section <a href="http://scip.zib.de/#faq">Using SCIP as a standalone MIP/MINLP-Solver</a>.
1162  */
1163 
1164 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
1165 /**@page DOC How to search the documentation for interface methods
1166  *
1167  * If you are looking for a method in order to perform a specific task, there are usually two places to look at:
1168  * - The file "scip.h" in the file list.
1169  * In this main header file, you find all methods that perform "complex" operations that affect or need data from
1170  * different components of SCIP.
1171  * For these methods, you always have to provide the SCIP pointer that is created by SCIPcreate().
1172  * The documentation of "scip.h" is grouped into several blocks, each dealing with methods for a specific kind of
1173  * object.
1174  * For example, all methods operating on variables are grouped together.
1175 
1176  * - The files \ref PUBLICMETHODS "pub_<...>.h" contain methods that perform "easy" operations that only
1177  * affect the corresponding objects.
1178  * Usually, with these methods you can access the data of the object.
1179  * For example, in "pub_var.h" you find methods to get information about a variable.
1180  *
1181  * The file "pub_misc.h" contains methods for data structures like priority queues, hash tables, and hash maps,
1182  * as well as methods for sorting, numerics, random numbers, string operations, and file operations.
1183  *
1184  * If you are looking for a description of a callback method of a plugin that you want to implement, you have to
1185  * look at the corresponding \ref TYPEDEFINITIONS "type_<...>.h".
1186  */
1187 
1188 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
1189 /**@page CONS How to add constraint handlers
1190  *
1191  * A constraint handler defines the semantics and the algorithms to process constraints of a certain class. A single
1192  * constraint handler is responsible for all constraints belonging to its constraint class. For example, there is
1193  * one \ref cons_knapsack.h "knapsack constraint handler" that ensures solutions are only accepted if they satisfy all
1194  * knapsack constraints in the model. \n A complete list of all constraint handlers contained in this release can be
1195  * found \ref CONSHDLRS "here".
1196  *
1197  * We now explain how users can add their own constraint handlers.
1198  * For an example, look into the subtour constraint handler (examples/TSP/src/ConshdlrSubtour.cpp) of the
1199  * <a href="http://scip.zib.de/doc/examples/TSP">TSP </a> example project.
1200  * The example is written in C++ and uses the C++ wrapper classes.
1201  * However, we will explain the implementation of a constraint handler using the C interface.
1202  * It is very easy to transfer the C explanation to C++; whenever a method should be implemented using the
1203  * SCIP_DECL_CONS... notion, reimplement the corresponding virtual member function of the abstract scip::ObjConshdlr
1204  * base class.
1205  *
1206  * Additional documentation for the callback methods of a constraint handler can be found in the file
1207  * type_cons.h.
1208  *
1209  * Here is what you have to do (assuming your constraint handler should be named "subtour"):
1210  * -# Copy the template files src/scip/cons_xyz.c and src/scip/cons_xyz.h into files "cons_subtour.c"
1211  * and "cons_subtour.h".
1212  * \n
1213  * Make sure to <b>adjust your Makefile</b> such that these files are compiled and linked to your project.
1214  * -# Use SCIPincludeConsSubtour() in order to include the constraint handler into your SCIP instance,
1215  * e.g., in the main file of your project (see, e.g., src/cppmain.cpp in the TSP example).
1216  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "subtour".
1217  * -# Adjust the \ref CONS_PROPERTIES "properties of the constraint handler".
1218  * -# Define the \ref CONS_DATA "constraint data and the constraint handler data". This is optional.
1219  * -# Implement the \ref CONS_INTERFACE "interface methods".
1220  * -# Implement the \ref CONS_FUNDAMENTALCALLBACKS "fundamental callback methods".
1221  * -# Implement the \ref CONS_ADDITIONALCALLBACKS "additional callback methods". This is optional.
1222  *
1223  *
1224  * @section CONS_PROPERTIES Properties of a Constraint Handler
1225  *
1226  * At the top of the new file "cons_subtour.c" you can find the constraint handler properties.
1227  * These are given as compiler defines. Some of them are optional, as, e.g., separation-related properties,
1228  * which only have to be defined if the constraint handler supports the related callbacks.
1229  * In the C++ wrapper class, you have to provide the constraint handler properties by calling the constructor
1230  * of the abstract base class scip::ObjConshdlr from within your constructor (see the TSP example).
1231  * The properties you have to set have the following meaning:
1232  *
1233  * @subsection CONS_FUNDAMENTALPROPERTIES Fundamental Constraint Handler properties
1234  *
1235  * \par CONSHDLR_NAME: the name of the constraint handler.
1236  * This name is used in the interactive shell to address the constraint handler.
1237  * Additionally, if you are searching for a constraint handler with SCIPfindConshdlr(), this name is looked up.
1238  * Names have to be unique: no two constraint handlers may have the same name.
1239  *
1240  * \par CONSHDLR_DESC: the description of the constraint handler.
1241  * This string is printed as a description of the constraint handler in the interactive shell of SCIP.
1242  *
1243  * \par CONSHDLR_ENFOPRIORITY: the priority of the constraint handler for constraint enforcing.
1244  * Like the separation priority, the enforcement priorities define the order in which the different constraint handlers
1245  * are called in the constraint enforcement step of the subproblem processing.
1246  * The constraint enforcement is called after the price-and-cut loop is executed (in the case that the LP is solved
1247  * at the current subproblem).
1248  * \n
1249  * The integrality constraint handler has an enforcement priority of 0.
1250  * That means, if a constraint handler has negative enforcement priority, it only has to deal with integral solutions
1251  * in its enforcement methods, because for fractional solutions, the integrality constraint handler would have
1252  * created a branching, thereby aborting the enforcement step.
1253  * If you want to implement a constraint-depending branching rule (for example, SOS branching on special ordered
1254  * set constraints), you have to assign a positive enforcement priority to your constraint handler.
1255  * In this case, you have to be able to deal with fractional solutions.
1256  * \n
1257  * See \ref CONSENFOLP and \ref CONSENFOPS for further details of the separation callback.
1258  *
1259  * \par CONSHDLR_CHECKPRIORITY: the priority of the constraint handler for checking feasibility.
1260  * Like the separation priority, the checking priorities define the order in which the different constraint handlers
1261  * are called to check the feasibility of a given primal solution candidate.
1262  * The integrality constraint handler has a checking priority of 0.
1263  * That means, constraint handlers with negative checking priorities only have to deal with integral solutions.
1264  *
1265  * \par CONSHDLR_EAGERFREQ: the default frequency for using all instead of only the useful constraints in separation, propagation and enforcement.
1266  * If \em constraint \em aging is activated, some constraints that were not useful in the past for propagation or
1267  * separation are marked to be \em obsolete.
1268  * Usually, the obsolete constraints are not presented to the separation and propagation methods of the constraint
1269  * handlers, such that the constraint handlers only process the non-obsolete constraints.
1270  * However, every n'th call, with n being the EAGERFREQ of the constraint handler, all constraints are presented to the
1271  * separation and propagation methods of the constraint handler.
1272  * This gives obsolete constraints the chance of becoming non-obsolete again.
1273  * \n
1274  * If the eager evaluation frequency is set to -1, obsolete constraints are never presented to the separation and
1275  * propagation methods.
1276  * A frequency of 0 means, that obsolete constraints are only used in the first call of each method.
1277  *
1278  * \par CONSHDLR_NEEDSCONS: indicates whether the constraint handler should be skipped, if no constraints are available.
1279  * Usually, a constraint handler is only executed if there are constraints of its corresponding class in the model.
1280  * For those constraint handlers, the NEEDSCONS flag should be set to TRUE.
1281  * However, some constraint handlers must be called without having a constraint of the class in the model, because
1282  * the constraint is only implicitly available.
1283  * For example, the integrality constraint handler has the NEEDSCONS flag set to FALSE, because there is no explicit
1284  * integrality constraint in the model.
1285  * The integrality conditions are attached to the variables, and the integrality constraint handler has to check
1286  * all variables that are marked to be integer for integral values.
1287  *
1288  * @subsection CONS_ADDITIONALPROPERTIES Optional Constraint Handler properties
1289  *
1290  * The following properties are optional and only need to be defined if the constraint handlers support
1291  * separation, presolving, propagation, and/or upgrade functionality.
1292  *
1293  * \par LINCONSUPGD_PRIORITY: priority of the constraint handler for upgrading of linear constraints
1294  * This property is only needed if a certain linear constraint can be upgraded to a more specific one. In one of
1295  * the first presolving rounds SCIP tries to upgrade linear constraints to more specialized constraints, such as
1296  * knapsack constraints. The upgrading calls are processed in the order of decreasing priority.
1297  *
1298  * \par NONLINCONSUPGD_PRIORITY: priority of the constraint handler for upgrading of nonlinear constraints
1299  * This property has the same effect as the LINCONSUPGD_PRIORITY parameter, see above, and should be set whenever
1300  * an upgrade functionality from a general nonlinear constraint to the more specific one is defined.
1301  *
1302  * \par CONSHDLR_SEPAFREQ: the default frequency for separating cuts.
1303  * The separation frequency defines the depth levels at which the constraint handler's separation methods \ref CONSSEPALP
1304  * and \ref CONSSEPASOL are called.
1305  * For example, a separation frequency of 7 means, that the separation callback is executed for subproblems that are
1306  * in depth 0, 7, 14, ... of the branching tree.
1307  * A separation frequency of 0 means, that the separation method is only called at the root node.
1308  * A separation frequency of -1 disables the separation method of the constraint handler.
1309  * \n
1310  * The separation frequency can be adjusted by the user.
1311  * This property of the constraint handler only defines the default value of the frequency.
1312  * If you want to have a more flexible control of when to execute the separation algorithm, you have to assign
1313  * a separation frequency of 1 and implement a check at the beginning of your separation algorithm whether you really
1314  * want to execute the separator or not.
1315  * If you do not want to execute the method, set the result code to SCIP_DIDNOTRUN.
1316  *
1317  * \par CONSHDLR_SEPAPRIORITY: the priority of the constraint handler for separation. (optional: to be set only if the constraint handler supports separation)
1318  * In each separation round during the price-and-cut loop of the subproblem processing or during the separation loop
1319  * of the primal solution separation, the separators and separation methods of the constraint handlers are called in
1320  * a predefined order, which is given by the priorities of the separators and the separation priorities of the
1321  * constraint handlers.
1322  * First, the separators with non-negative priority are called in the order of decreasing priority.
1323  * Next, the separation methods of the different constraint handlers are called in the order of decreasing separation
1324  * priority.
1325  * Finally, the separators with negative priority are called in the order of decreasing priority.
1326  * \n
1327  * The separation priority of the constraint handler should be set according to the complexity of the cut separation
1328  * algorithm and the impact of the resulting cuts:
1329  * Constraint handlers that provide fast algorithms that usually have a high impact (i.e., cut off a large portion of
1330  * the LP relaxation) should have a high priority.
1331  * See \ref CONSSEPALP and \ref CONSSEPASOL for further details of the separation callbacks.
1332  *
1333  * \par CONSHDLR_DELAYSEPA: the default for whether the separation method should be delayed, if other separators found cuts.
1334  * If the constraint handler's separation method is marked to be delayed, it is only executed after no other separator
1335  * or constraint handler found a cut during the price-and-cut loop.
1336  * If the separation method of the constraint handler is very expensive, you may want to mark it to be delayed until all
1337  * cheap separation methods have been executed.
1338  *
1339  * \par CONSHDLR_PROPFREQ: the default frequency for propagating domains.
1340  * This default frequency has the same meaning as the CONSHDLR_SEPAFREQ with respect to the domain propagation
1341  * callback of the constraint handler.
1342  * A propagation frequency of 0 means that propagation is only applied in preprocessing and at the root node.
1343  * A propagation frequency of -1 disables the propagation method of the constraint handler.
1344  *
1345  * \par CONSHDLR_DELAYPROP: the default for whether the propagation method should be delayed, if other propagators found reductions.
1346  * This property is analogous to the DELAYSEPA flag, but deals with the propagation method of the constraint handler.
1347  *
1348  * \par CONSHDLR_PROP_TIMING: the propagation timing mask of the constraint handler.
1349  * SCIP calls the domain propagation routines at different places in the node processing loop.
1350  * This property indicates at which places the propagation routine of the constraint handler is called.
1351  * Possible values are defined in type_timing.h and can be concatenated, e.g., as in SCIP_PROPTIMING_ALWAYS.
1352  *
1353  * \par CONSHDLR_MAXPREROUNDS: the default maximal number of presolving rounds the constraint handler participates in.
1354  * The preprocessing is executed in rounds.
1355  * If enough changes have been applied to the model, an additional preprocessing round is performed.
1356  * The MAXPREROUNDS parameter of a constraint handler denotes the maximal number of preprocessing rounds the constraint
1357  * handler participates in.
1358  * A value of -1 means that there is no limit on the number of rounds.
1359  * A value of 0 means the preprocessing callback of the constraint handler is disabled.
1360  *
1361  * \par CONSHDLR_DELAYPRESOL: the default for whether the presolving method should be delayed, if other presolvers found reductions.
1362  * This property is analogous to the DELAYSEPA flag, but deals with the preprocessing method of the constraint handler.
1363  *
1364  *
1365  *
1366  * @section CONS_DATA Constraint Data and Constraint Handler Data
1367  *
1368  * Below the header "Data structures" you can find two structs called "struct SCIP_ConsData" and
1369  * "struct SCIP_ConshdlrData".
1370  * If you are using C++, you only need to define the "struct SCIP_ConsData".
1371  * The constraint handler data must be implemented as member variables of your constraint handler class.
1372  * \n
1373  * The constraint data are the information that is needed to define a single constraint of the constraint handler's
1374  * constraint class.
1375  * For example, the data of a knapsack constraint would consist of a list of variables, a list of weights, and
1376  * the capacity of the knapsack.
1377  * The data of a subtour constraint consists of the graph on which the problem is defined.
1378  * In the graph, each edge should be linked to the corresponding binary problem variable.
1379  * \n
1380  * The constraint handler data are additional variables, that belong to the constraint handler itself and which are
1381  * not specific to a single constraint.
1382  * For example, you can use these data to store parameters of the constraint handler or statistical information.
1383  * The constraint handler data are optional.
1384  * You can leave the struct empty.
1385  *
1386  *
1387  * @section CONS_INTERFACE Interface Methods
1388  *
1389  * At the bottom of "cons_subtour.c" you can find three interface methods, that also appear in "cons_subtour.h".
1390  * These are SCIPincludeConshdlrSubtour(), SCIPcreateConsSubtour(), and SCIPcreateConsSubtourBasic().
1391  * \n
1392  * The method SCIPincludeConshdlrSubtour() only has to be adjusted slightly.
1393  * It is responsible for notifying SCIP of the presence of the constraint handler by calling the method
1394  * SCIPincludeConshdlr().
1395  * It is called by the user, if (s)he wants to include the constraint handler, i.e., if (s)he wants to make
1396  * the constraint handler available to the model, and looks like this:
1397  * -# If you are using constraint handler data, you have to <b>allocate the memory for the data</b> at this point.
1398  * You also have to initialize the fields in struct SCIP_ConshdlrData afterwards.
1399  * \code
1400  * SCIP_RETCODE SCIPincludeConshdlrKnapsack(
1401  * ...
1402  * )
1403  * {
1404  * SCIP_EVENTHDLRDATA* eventhdlrdata;
1405  * SCIP_CONSHDLRDATA* conshdlrdata;
1406  * SCIP_CONSHDLR* conshdlr;
1407  *
1408  * SCIP_CALL( SCIPallocMemory(scip, &conshdlrdata) );
1409  * ...
1410  * \endcode
1411  * -# Now, <b>SCIP gets notified</b> of the presence of the constraint handler together with its \ref CONS_FUNDAMENTALCALLBACKS "basic callbacks".
1412  * \code
1413  * SCIP_CALL( SCIPincludeConshdlrBasic(scip, &conshdlr, CONSHDLR_NAME, CONSHDLR_DESC,
1414  * CONSHDLR_ENFOPRIORITY, CONSHDLR_CHECKPRIORITY, CONSHDLR_EAGERFREQ, CONSHDLR_NEEDSCONS,
1415  * consEnfolpKnapsack, consEnfopsKnapsack, consCheckKnapsack, consLockKnapsack,
1416  * conshdlrdata) );
1417  * assert(conshdlr != NULL);
1418  * \endcode
1419  * -# All \ref CONS_ADDITIONALCALLBACKS "additional callbacks" are added via their setter functions.
1420  * \code
1421  * SCIP_CALL( SCIPsetConshdlrCopy(scip, conshdlr, conshdlrCopyKnapsack, consCopyKnapsack) );
1422  * SCIP_CALL( SCIPsetConshdlrTrans(scip, conshdlr, consTransKnapsack) );
1423  * \endcode
1424  * -# If the constraint handler is a specialization of a general linear or nonlinear constraint, we want to include an <b>automatic
1425  * upgrading mechanism</b> by calling the interface method
1426  * \code
1427  * if( SCIPfindConshdlr(scip,"linear") != NULL )
1428  * {
1429  * SCIP_CALL( SCIPincludeLinconsUpgrade(scip, linconsUpgdKnapsack, LINCONSUPGD_PRIORITY, CONSHDLR_NAME) );
1430  * }
1431  * \endcode
1432  * or
1433  * \code
1434  * SCIP_CALL( SCIPincludeNonlinconsUpgrade(scip, nonlinconsUpgdSubtour, NULL, NONLINCONSUPGD_PRIORITY, TRUE, CONSHDLR_NAME) );
1435  * \endcode
1436  * in the nonlinear case.
1437  * See also cons_nonlinear.h for further information about the general upgrade procedure in the nonlinear case.
1438  * -# You may also add <b>user parameters</b> for your constraint handler.
1439  * Some parameters which are important to play with are added to every constraint automatically, as, e.g.,
1440  * propagation or separation frequency.
1441  * \code
1442  * SCIP_CALL( SCIPaddIntParam(scip,
1443  * "constraints/knapsack/sepacardfreq",
1444  * "multiplier on separation frequency, how often knapsack cuts are separated (-1: never, 0: only at root)",
1445  * &conshdlrdata->sepacardfreq, TRUE, DEFAULT_SEPACARDFREQ, -1, INT_MAX, NULL, NULL) );
1446  * ...
1447  * return SCIP_OKAY;
1448  * }
1449  * \endcode
1450  *
1451  *
1452  *
1453  *
1454  * The methods SCIPcreateConsSubtour() and SCIPcreateConsSubtourBasic() are called to create a single constraint of the constraint
1455  * handler's constraint class.
1456  * It should allocate and fill the constraint data, and call SCIPcreateCons().
1457  * Take a look at the following example from the \ref cons_knapsack.h "knapsack constraint handler":
1458  *
1459  * \code
1460  * SCIP_RETCODE SCIPcreateConsKnapsack(
1461  * SCIP* scip,
1462  * SCIP_CONS** cons,
1463  * const char* name,
1464  * int nvars,
1465  * SCIP_VAR** vars,
1466  * SCIP_Longint* weights,
1467  * SCIP_Longint capacity,
1468  * SCIP_Bool initial,
1469  * SCIP_Bool separate,
1470  * SCIP_Bool enforce,
1471  * SCIP_Bool check,
1472  * SCIP_Bool propagate,
1473  * SCIP_Bool local,
1474  * SCIP_Bool modifiable,
1475  * SCIP_Bool dynamic,
1476  * SCIP_Bool removable,
1477  * SCIP_Bool stickingatnode
1478  * )
1479  * {
1480  * SCIP_CONSHDLRDATA* conshdlrdata;
1481  * SCIP_CONSHDLR* conshdlr;
1482  * SCIP_CONSDATA* consdata;
1483  *
1484  * conshdlr = SCIPfindConshdlr(scip, CONSHDLR_NAME);
1485  * if( conshdlr == NULL )
1486  * {
1487  * SCIPerrorMessage("knapsack constraint handler not found\n");
1488  * return SCIP_PLUGINNOTFOUND;
1489  * }
1490  *
1491  * conshdlrdata = SCIPconshdlrGetData(conshdlr);
1492  * assert(conshdlrdata != NULL);
1493  * assert(conshdlrdata->eventhdlr != NULL);
1494  *
1495  * SCIP_CALL( consdataCreate(scip, &consdata, conshdlrdata->eventhdlr, nvars, vars, weights, capacity) );
1496  *
1497  * SCIP_CALL( SCIPcreateCons(scip, cons, name, conshdlr, consdata, initial, separate, enforce, check, propagate,
1498  * local, modifiable, dynamic, removable, stickingatnode) );
1499  *
1500  * return SCIP_OKAY;
1501  * }
1502  * \endcode
1503  *
1504  * In this example, consdataCreate() is a local method that allocates memory for the given consdata
1505  * and fills the data with the given <code>vars</code> array. For allocating memory for the constraint data, you
1506  * can use SCIP memory allocation:
1507  * \code
1508  * SCIP_CALL( SCIPallocBlockMemory(scip, consdata) );
1509  * \endcode
1510  *
1511  *
1512  * @section CONS_CALLBACKS Callback methods of Constraint handlers
1513  *
1514  * Besides the various functions which you will implement inside your constraint handler there exists a number
1515  * of <b> callback methods </b> associated with your constraint handler. Callback methods can be regarded as
1516  * tasks which your constraint handler is able to provide to the solver. They are grouped into two
1517  * categories:
1518  *
1519  * \ref CONS_FUNDAMENTALCALLBACKS "Fundamental Callback methods" are mandatory to implement
1520  * such that your code will work. For example, every constraint handler has to provide the
1521  * functionality to state whether all of its constraints are
1522  * fulfilled by a given variable assignment. Hence, the \ref CONSCHECK "CONSCHECK" callback is
1523  * one of the fundamental (or \a basic) callbacks of a constraint handler.
1524  *
1525  * Callbacks which are not necessarily implemented are grouped together as
1526  * \ref CONS_ADDITIONALCALLBACKS "additional callbacks". Such callbacks can be used to allocate and free memory
1527  * at different stages of the solving process. Although not mandatory, it might be useful to implement
1528  * some of these callbacks, e.g., to extend your constraint handler by a
1529  * \ref CONSSEPALP "separation" or \ref CONSPRESOL "presolving" functionality.
1530  *
1531  * All callbacks should be passed to SCIP during the SCIPinclude<PLUGINTYPE><PLUGINNAME> method
1532  * (e.g., SCIPincludeConshdlrKnapsack() for the \ref cons_knapsack.h "knapsack constraint handler").
1533  * Since SCIP version 3.0, two ways of setting callbacks can be used, either via SCIPincludeConshdlr()
1534  * (all at once, as it always was), or via SCIPincludeConshdlrBasic() and setter functions for additional callbacks.
1535  * Since the basic inclusion methods are very unlikely to change and will thus
1536  * make your code more stable towards future versions of SCIP with more callbacks,
1537  * we recommend the latter choice, as explained in the \ref CONS_INTERFACE "interface" section.
1538  *
1539  * @section CONS_FUNDAMENTALCALLBACKS Fundamental Callback Methods
1540  *
1541  * By implementing the fundamental callbacks, you define the semantics of the constraint class the constraint handler
1542  * deals with.
1543  * If these methods are implemented, the resulting code is already correct and finds the optimal solution to the
1544  * given problem instance.
1545  * However, it might be very slow because the additional features, like cut separation and domain propagation, are
1546  * missing.
1547  * In the C++ wrapper class scip::ObjConshdlr, the fundamental callback methods are virtual abstract member functions.
1548  * You have to implement them in order to be able to construct an object of your constraint handler class.
1549  *
1550  * There are three fundamental callback methods that are all dealing with the feasibility of a given solution.
1551  * They are called at different places in the algorithm and have slightly different meaning.
1552  * However, it is usually reasonable to implement a single local method that is called by all of the three callback
1553  * methods with slightly modified parameters.
1554  * The fourth method provides dual information that is used for example in preprocessing.
1555  *
1556  * Additional documentation for the callback methods can be found in type_cons.h.
1557  *
1558  * @subsection CONSCHECK
1559  *
1560  * The CONSCHECK callback gets a primal solution candidate in a SCIP_SOL* data structure
1561  * and has to check this solution for global feasibility.
1562  * It has to return a result SCIP_FEASIBLE, if the solution satisfies all the constraints of the constraint handler,
1563  * and a result SCIP_INFEASIBLE if there is at least one constraint that is violated.
1564  * The callback is used by primal heuristics to check a constructed solution for feasibility.
1565  * That means, the constraint handler has to deal with arbitrary solutions that do not necessarily satisfy the bounds
1566  * and constraints of the local subproblem.
1567  *
1568  * The value of a variable \em var in the given solution \em sol can be accessed by calling
1569  * \code
1570  * SCIPgetSolVal(scip, sol, var)
1571  * \endcode
1572  *
1573  * For example, the \ref cons_knapsack.h "knapsack constraint handler" loops over its constraints and
1574  * calculates the scalar product \f$w^T x\f$ of weights \f$w\f$ with the solution vector \f$x\f$.
1575  * This scalar product is compared with the capacity of the knapsack constraint.
1576  * If it exceeds the capacity, the CONSCHECK method is immediately aborted with the result SCIP_INFEASIBLE.
1577  * If all knapsack constraints are satisfied, a result SCIP_FEASIBLE is returned.
1578  *
1579  * @subsection CONSENFOLP
1580  *
1581  * The CONSENFOLP method is called after the price-and-cut loop was finished and an LP solution is available.
1582  * Like the CHECK call, the ENFOLP method should return a result SCIP_FEASIBLE, if the solution satisfies all the
1583  * constraints.
1584  * However, the behavior should be different, if the solution violates some of the associated constraints.
1585  * The constraint handler may return a result SCIP_INFEASIBLE in this situation, but this is not the best what
1586  * one can do.
1587  * The ENFOLP method has the possibility of \em resolving the infeasibility by
1588  * - stating that the current subproblem is infeasible (result SCIP_CUTOFF),
1589  * - adding an additional constraint that resolves the infeasibility (result SCIP_CONSADDED),
1590  * - reducing the domain of a variable (result SCIP_REDUCEDDOM),
1591  * - adding a cutting plane (result SCIP_SEPARATED),
1592  * - performing a branching (result SCIP_BRANCHED).
1593  *
1594  * However, the solution is not given as a SCIP_SOL* data structure.
1595  *
1596  * The value of a variable <code>var</code> in the LP solution can be accessed by calling
1597  * \code
1598  * SCIPgetVarSol(scip, var)
1599  * \endcode
1600  * or by
1601  * \code
1602  * SCIPgetSolVal(scip, NULL, var)
1603  * \endcode
1604  * By using the latter method, you can have a single local method to check a solution for feasibility by passing
1605  * the given <code>sol</code> to the CONSCHECK call and by passing a NULL pointer as <code>sol</code> to
1606  * the CONSENFOLP and CONSENFOPS calls.
1607  *
1608  *
1609  * @subsection CONSENFOPS
1610  *
1611  * The CONSENFOPS callback is similar to the CONSENFOLP callback, but deals with \em pseudo \em solutions instead
1612  * of LP solutions.
1613  *
1614  * If the LP was not solved at the current subproblem (either because the user did not want to solve it, or because
1615  * numerical difficulties in the LP solving process were detected) no LP solution is available.
1616  * In this situation, the pseudo solution is used instead.
1617  * In this solution, the variables are set to the local bound which is best with respect to the objective function.
1618  * You can think of the pseudo solution as solution to the LP relaxation with all constraints except the bounds
1619  * being removed.
1620  *
1621  * Like the ENFOLP callback, the ENFOPS callback has to check whether the pseudo solution satisfies all the constraints
1622  * of the constraint handler.
1623  * The pseudo solution can be accessed by the same methods as the LP solution (SCIP knows, if the LP was solved at the
1624  * current subproblem, and returns either the LP solution or the pseudo solution).
1625  *
1626  * Unlike the ENFOLP callback, the ENFOPS callback must not add cuts and cannot return the result SCIP_SEPARATED.
1627  * It is, however, possible to force the solving of the LP by returning the result SCIP_SOLVELP.
1628  * For example, the infeasibility of a linear constraint that contains continuous variables cannot be resolved,
1629  * if all integer variables in the constraint are already fixed.
1630  * In this case, the LP has to be solved in order to get a solution that satisfies the linear constraint.
1631  *
1632  * @subsection CONSLOCK
1633  *
1634  * The CONSLOCK callback provides dual information for a single constraint.
1635  * It has to tell SCIP, which variables are existing in the given constraint, and in which way modifications of these
1636  * variables may affect the feasibility of the constraint.
1637  *
1638  * For each variable that is affected by the constraint, the callback should call SCIPaddVarLocks():
1639  * - If the constraint may become violated by decreasing the value of a variable, it should call
1640  * SCIPaddVarLocks(scip, var, nlockspos, nlocksneg), saying that rounding down is potentially rendering the
1641  * (positive) constraint infeasible and rounding up is potentially rendering the negation of the constraint
1642  * infeasible.
1643  * - If the constraint may become violated by increasing the value of a variable, it should call
1644  * SCIPaddVarLocks(scip, var, nlocksneg, nlockspos), saying that rounding up is potentially rendering the
1645  * constraint's negation infeasible and rounding down is potentially rendering the constraint itself
1646  * infeasible.
1647  * - If the constraint may become violated by changing the variable in any direction, it should call
1648  * SCIPaddVarLocks(scip, var, nlockspos + nlocksneg, nlockspos + nlocksneg).
1649  *
1650  * <b>Note:</b> You do not have to worry about nlockspos and nlocksneg. These integer values are given as
1651  * parameter of the CONSLOCK callback (see type_cons.h). Just use these variables in the above described
1652  * fashion <b>without</b> adding or subtracting anything to them. In case of the knapsack constraints this
1653  * method looks like this.
1654  *
1655  * \code
1656  * static
1657  * SCIP_DECL_CONSLOCK(consLockKnapsack)
1658  * {
1659  * SCIP_CONSDATA* consdata;
1660  * int i;
1661  *
1662  * consdata = SCIPconsGetData(cons);
1663  * assert(consdata != NULL);
1664  *
1665  * for( i = 0; i < consdata->nvars; i++)
1666  * {
1667  * SCIP_CALL( SCIPaddVarLocks(scip, consdata->vars[i], nlocksneg, nlockspos) );
1668  * }
1669  *
1670  * return SCIP_OKAY;
1671  * }
1672  * \endcode
1673  *
1674  * To give same more intuition, consider the linear constraint \f$3x -5y +2z \leq 7\f$ as an example.
1675  * The CONSLOCK callback method of the linear constraint handler should call
1676  * SCIPaddVarLocks(scip, x, nlocksneg, nlockspos), SCIPaddVarLocks(scip, y, nlockspos, nlocksneg),
1677  * and SCIPaddVarLocks(scip, z, nlocksneg, nlockspos) to tell SCIP, that rounding up of \f$x\f$
1678  * and \f$z\f$ and rounding down of \f$y\f$ can destroy the feasibility of the constraint, while rounding
1679  * down of \f$x\f$ and \f$z\f$ and rounding up of \f$y\f$ can destroy the feasibility of the
1680  * constraint's negation \f$3x -5y +2z > 7\f$.
1681  * \n
1682  * A linear constraint \f$2 \leq 3x -5y +2z \leq 7\f$ should call
1683  * SCIPaddVarLocks(scip, ..., nlockspos + nlocksneg, nlockspos + nlocksneg) on all variables,
1684  * since rounding in both directions of each variable can destroy both the feasibility of the
1685  * constraint and it's negation \f$3x -5y +2z < 2\f$ or \f$3x -5y +2z > 7\f$.
1686  *
1687  *
1688  * @section CONS_ADDITIONALCALLBACKS Additional Callback Methods
1689  *
1690  * The additional callback methods do not need to be implemented in every case, but provide useful functionality
1691  * for many applications. They can be added to your constraint handler via setter functions, see
1692  * \ref CONS_INTERFACE "here".
1693  *
1694  * @subsection CONSFREE
1695  *
1696  * If you are using constraint handler data, you have to implement this method in order to free the
1697  * constraint handler data. This can be done by the following procedure (which is taken from the
1698  * \ref cons_knapsack.h "knapsack constraint handler"):
1699  *
1700  * \code
1701  * static
1702  * SCIP_DECL_CONSFREE(consFreeKnapsack)
1703  * {
1704  * SCIP_CONSHDLRDATA* conshdlrdata;
1705  *
1706  * conshdlrdata = SCIPconshdlrGetData(conshdlr);
1707  * assert(conshdlrdata != NULL);
1708  *
1709  * SCIPfreeMemory(scip, &conshdlrdata);
1710  *
1711  * SCIPconshdlrSetData(conshdlr, NULL);
1712  *
1713  * return SCIP_OKAY;
1714  * }
1715  * \endcode
1716  *
1717  * If you have allocated memory for fields in your constraint handler data, remember to free this memory
1718  * before freeing the constraint handler data itself.
1719  * If you are using the C++ wrapper class, this method is not available.
1720  * Instead, just use the destructor of your class to free the member variables of your class.
1721  *
1722  * @subsection CONSHDLRCOPY
1723  *
1724  * The CONSHDLRCOPY callback is executed when the SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this
1725  * callback as <code>NULL</code> the user disables the inclusion of the specified constraint handler into all copied SCIP
1726  * instances. This may deteriorate the performance of primal heuristics solving sub-SCIPs, since these constitute only
1727  * relaxations of the original problem if constraint handlers are missing.
1728  *
1729  * A usual implementation just
1730  * calls the interface method which includes the constraint handler to the model. For example, this callback is
1731  * implemented for the knapsack constraint handler as follows:
1732  *
1733  * \code
1734  * static
1735  * SCIP_DECL_CONSHDLRCOPY(conshdlrCopyKnapsack)
1736  * {
1737  * assert(scip != NULL);
1738  * assert(conshdlr != NULL);
1739  * assert(strcmp(SCIPconshdlrGetName(conshdlr), CONSHDLR_NAME) == 0);
1740  *
1741  * SCIP_CALL( SCIPincludeConshdlrKnapsack(scip) );
1742  *
1743  * *valid = TRUE;
1744  *
1745  * return SCIP_OKAY;
1746  * }
1747  * \endcode
1748  *
1749  * <b>Note:</b> If you implement this callback, take care when setting the valid pointer. The valid pointer should be
1750  * set to TRUE if (and only if!) you can make sure that all necessary data of the constraint handler are copied
1751  * correctly. If the complete problem is validly copied, i.e. if the copy methods of all problem defining plugins
1752  * (constraint handlers and pricers) return <code>*valid = TRUE</code>, then dual reductions found for the copied problem can be
1753  * transferred to the original SCIP instance. Thus, if the valid pointer is wrongly set to TRUE, it might happen that
1754  * optimal solutions are cut off.
1755  *
1756  * <b>Note:</b> If you implement this callback and the constraint handler needs constraints (see CONSHDLR_NEEDSCONS),
1757  * then you also need to implement the callback \ref CONSCOPY.
1758  *
1759  * @subsection CONSINIT
1760  *
1761  * The CONSINIT callback is executed after the problem is transformed.
1762  * The constraint handler may, e.g., use this call to replace the original variables in its constraints by transformed
1763  * variables, or to initialize its statistical constraint handler data.
1764  *
1765  * @subsection CONSEXIT
1766  *
1767  * The CONSEXIT callback is executed before the transformed problem is freed.
1768  * In this method, the constraint handler should free all resources that were allocated for the solving process.
1769  *
1770  * @subsection CONSINITPRE
1771  *
1772  * The CONSINITPRE callback is executed before the preprocessing is started, even if presolving is turned off.
1773  * The constraint handler may use this call to initialize its presolving data, or to modify its constraints
1774  * before the presolving process begins.
1775  * Necessary constraint modifications that have to be performed even if presolving is turned off should be done here
1776  * or in the presolving deinitialization call.
1777  *
1778  * @subsection CONSEXITPRE
1779  *
1780  * The CONSEXITPRE callback is executed after the preprocessing has been finished, even if presolving is turned off.
1781  * The constraint handler may use this call e.g. to clean up its presolving data, or to finally modify its constraints
1782  * before the branch-and-bound process begins.
1783  * Necessary constraint modifications that have to be performed even if presolving is turned off should be done here
1784  * or in the presolving initialization call.
1785  * Besides necessary modifications and clean up, no time consuming operations should be done.
1786  *
1787  * @subsection CONSINITSOL
1788  *
1789  * The CONSINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
1790  * begin.
1791  * The constraint handler may use this call to initialize its branch-and-bound specific data.
1792  *
1793  * @subsection CONSEXITSOL
1794  *
1795  * The CONSEXITSOL callback is executed before the branch-and-bound process is freed.
1796  * The constraint handler should use this call to clean up its branch-and-bound data, in particular to release
1797  * all LP rows that it has created or captured.
1798  *
1799  * @subsection CONSDELETE
1800  *
1801  * The CONSDELETE callback is executed if a constraint should be freed.
1802  * You can think of it as the destructor of a single constraint.
1803  * In the callback, you have to free the given constraint data.
1804  * The CONSDELETE callback is therefore the counterpart of the SCIPcreateCons...() interface method and the CONSTRANS
1805  * method.
1806  *
1807  * @subsection CONSTRANS
1808  *
1809  * The CONSTRANS method is called for each constraint of the constraint handler, when the user starts the solving
1810  * process.
1811  * It has to copy the original constraint data of the constraint to the memory for the transformed problem.
1812  * You can think of it as a copy constructor for a single constraint.
1813  *
1814  * The original model is copied in order to protect it from transformations that are applied during the solving process,
1815  * in particular during preprocessing.
1816  * Preprocessing and solving always operates on the transformed problem.
1817  * If the solving process data are freed, the original data still exist and the user can, e.g., modify the problem and
1818  * restart the solving process.
1819  *
1820  * If you do not implement the CONSTRANS method, a transformed constraint is created with the same flags and the
1821  * same constraint data pointer.
1822  * That means, the transformed constraint points to the original constraint data.
1823  * This is okay, as long as the constraint data is not changed during the solving process.
1824  * If you want to implement preprocessing methods or other methods that modify the constraint data, you have to
1825  * implement the CONSTRANS method and create a copy of the constraint data.
1826  *
1827  * Here is an example, which is taken from the \ref cons_knapsack.h "knapsack constraint handler":
1828  * \code
1829  * static
1830  * SCIP_DECL_CONSTRANS(consTransKnapsack)
1831  * {
1832  * SCIP_CONSHDLRDATA* conshdlrdata;
1833  * SCIP_CONSDATA* sourcedata;
1834  * SCIP_CONSDATA* targetdata;
1835  *
1836  * assert(conshdlr != NULL);
1837  * assert(strcmp(SCIPconshdlrGetName(conshdlr), CONSHDLR_NAME) == 0);
1838  * assert(SCIPgetStage(scip) == SCIP_STAGE_TRANSFORMING);
1839  * assert(sourcecons != NULL);
1840  * assert(targetcons != NULL);
1841  *
1842  * sourcedata = SCIPconsGetData(sourcecons);
1843  * assert(sourcedata != NULL);
1844  * assert(sourcedata->row == NULL);
1845  *
1846  * conshdlrdata = SCIPconshdlrGetData(conshdlr);
1847  * assert(conshdlrdata != NULL);
1848  * assert(conshdlrdata->eventhdlr != NULL);
1849  *
1850  * SCIP_CALL( consdataCreate(scip, &targetdata, conshdlrdata->eventhdlr,
1851  * sourcedata->nvars, sourcedata->vars, sourcedata->weights, sourcedata->capacity) );
1852  *
1853  * SCIP_CALL( SCIPcreateCons(scip, targetcons, SCIPconsGetName(sourcecons), conshdlr, targetdata,
1854  * SCIPconsIsInitial(sourcecons), SCIPconsIsSeparated(sourcecons), SCIPconsIsEnforced(sourcecons),
1855  * SCIPconsIsChecked(sourcecons), SCIPconsIsPropagated(sourcecons),
1856  * SCIPconsIsLocal(sourcecons), SCIPconsIsModifiable(sourcecons),
1857  * SCIPconsIsDynamic(sourcecons), SCIPconsIsRemovable(sourcecons), SCIPconsIsStickingAtNode(sourcecons)) );
1858  *
1859  * return SCIP_OKAY;
1860  * }
1861  * \endcode
1862  *
1863  * @subsection CONSINITLP
1864  *
1865  * The CONSINITLP callback is executed before the first LP relaxation is solved.
1866  * It should add the LP relaxations of all "initial" constraints to the LP. The method should scan the constraints
1867  * array for constraints that are marked initial via calls to SCIPconsIsInitial() and put the LP relaxation
1868  * of all initial constraints to the LP with calls to SCIPaddCut().
1869  *
1870  * @subsection CONSSEPALP
1871  *
1872  * The CONSSEPALP callback is executed during the price-and-cut loop of the subproblem processing.
1873  * It should try to generate cutting planes for the constraints of the constraint handler in order to separate
1874  * the current LP solution.
1875  * The method is called in the LP solution loop, which means that a valid LP solution exists.
1876  *
1877  * Usually, a separation callback searches and produces cuts, that are added with a call to SCIPaddCut().
1878  * If the cut should be remembered in the global cut pool, it may also call SCIPaddPoolCut().
1879  * However, the callback may also produce domain reductions or add other constraints.
1880  *
1881  * The CONSSEPALP callback has the following options:
1882  * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
1883  * - adding an additional constraint (result SCIP_CONSADDED)
1884  * - reducing a variable's domain (result SCIP_REDUCEDDOM)
1885  * - adding a cutting plane to the LP (result SCIP_SEPARATED)
1886  * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
1887  * (result SCIP_DIDNOTFIND)
1888  * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
1889  * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
1890  * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
1891  *
1892  * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1893  * CONSHDLR_SEPAFREQ, CONSHDLR_SEPAPRIORITY, and CONSHDLR_DELAYSEPA, which influence the behaviour of SCIP
1894  * calling CONSSEPALP.
1895  *
1896  * @subsection CONSSEPASOL
1897  *
1898  * The CONSSEPASOL callback is executed during separation loop on arbitrary primal solutions.
1899  * It should try to generate cutting planes for the constraints of the constraint handler in order to separate
1900  * the given primal solution.
1901  * The method is not called in the LP solution loop, which means that there is no valid LP solution.
1902  *
1903  * Usually, a separation callback searches and produces cuts, that are added with a call to SCIPaddCut().
1904  * If the cut should be remembered in the global cut pool, it may also call SCIPaddPoolCut().
1905  * However, the callback may also produce domain reductions or add other constraints.
1906  *
1907  * The CONSSEPASOL callback has the following options:
1908  * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
1909  * - adding an additional constraint (result SCIP_CONSADDED)
1910  * - reducing a variable's domain (result SCIP_REDUCEDDOM)
1911  * - adding a cutting plane to the LP (result SCIP_SEPARATED)
1912  * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
1913  * (result SCIP_DIDNOTFIND)
1914  * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
1915  * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
1916  * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
1917  *
1918  * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1919  * CONSHDLR_SEPAFREQ, CONSHDLR_SEPAPRIORITY, and CONSHDLR_DELAYSEPA, which influence the behaviour of SCIP
1920  * calling CONSSEPASOL.
1921  *
1922  * @subsection CONSPROP
1923  *
1924  * The CONSPROP callback is called during the subproblem processing.
1925  * It should propagate the constraints, which means that it should infer reductions in the variables' local bounds
1926  * from the current local bounds.
1927  * This technique, which is the main workhorse of constraint programming, is called "node preprocessing" in the
1928  * Integer Programming community.
1929  *
1930  * The CONSPROP callback has the following options:
1931  * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
1932  * - reducing a variable's domain (result SCIP_REDUCEDDOM)
1933  * - stating that the propagator searched, but did not find domain reductions, cutting planes, or cut constraints
1934  * (result SCIP_DIDNOTFIND)
1935  * - stating that the propagator was skipped (result SCIP_DIDNOTRUN)
1936  * - stating that the propagator was skipped, but should be called again (result SCIP_DELAYED)
1937  *
1938  * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1939  * CONSHDLR_PROPFREQ, CONSHDLR_DELAYPROP, and CONSHDLR_PROP_TIMING, which influence the behaviour of SCIP
1940  * calling CONSPROP.
1941  *
1942  * @subsection CONSRESPROP
1943  *
1944  * If the constraint handler should support \ref CONF "conflict analysis", it has to supply a CONSRESPROP method.
1945  * It also should call SCIPinferVarLbCons() or SCIPinferVarUbCons() in domain propagation instead of SCIPchgVarLb() or
1946  * SCIPchgVarUb() in order to deduce bound changes on variables.
1947  * In the SCIPinferVarLbCons() and SCIPinferVarUbCons() calls, the handler provides the constraint that deduced the
1948  * variable's bound change, and an integer value <code>inferinfo</code> that can be arbitrarily chosen.
1949  *
1950  * The propagation conflict resolving method CONSRESPROP must then be implemented to provide the "reasons" for the bound
1951  * changes, i.e., the bounds of variables at the time of the propagation, which forced the constraint to set the
1952  * conflict variable's bound to its current value. It can use the <code>inferinfo</code> tag to identify its own propagation rule
1953  * and thus identify the "reason" bounds. The bounds that form the reason of the assignment must then be provided by
1954  * calls to SCIPaddConflictLb() and SCIPaddConflictUb() in the propagation conflict resolving method.
1955  *
1956  * <b>Note:</b> The fact that <code>inferinfo</code> is an integer, as opposed to an arbitrary data object, is a compromise between space and speed. Sometimes a propagator would
1957  * need more information to efficiently infer the original propagation steps that lead to the conflict. This would,
1958  * however, require too much space. In the extreme, the original propagation steps have to be repeated.
1959  *
1960  * For example, the \ref cons_logicor.h "logicor constraint" \f$c = x \vee y \vee z\f$ fixes variable \f$z\f$ to TRUE (i.e., changes the lower
1961  * bound of \f$z\f$ to 1.0), if both, \f$x\f$ and \f$y\f$, are assigned to FALSE (i.e., if the upper bounds of these
1962  * variables are 0.0). It uses <code>SCIPinferVarLbCons(scip, z, 1.0, c, 0)</code> to apply this assignment (an
1963  * inference information tag is not needed by the constraint handler and is set to 0). In the conflict analysis, the
1964  * constraint handler may be asked to resolve the lower bound change on \f$z\f$ with constraint \f$c\f$, that was
1965  * applied at a time given by a bound change index "bdchgidx". With a call to <code>SCIPvarGetLbAtIndex(z,
1966  * bdchgidx)</code>, the handler can find out, that the lower bound of variable \f$z\f$ was set to 1.0 at the given
1967  * point of time, and should call <code>SCIPaddConflictUb(scip, x, bdchgidx)</code> and <code>SCIPaddConflictUb(scip, y,
1968  * bdchgidx)</code> to tell SCIP, that the upper bounds of \f$x\f$ and \f$y\f$ at this point of time were the reason for
1969  * the deduction of the lower bound of \f$z\f$.
1970  *
1971  * If conflict analysis should not be supported, the method has to set the result code to SCIP_DIDNOTFIND. Although
1972  * this is a viable approach to circumvent the implementation of the usually rather complex conflict resolving method, it
1973  * will make the conflict analysis less effective. We suggest to first omit the conflict resolving method and check how
1974  * effective the \ref CONSPROP "propagation method" is. If it produces a lot of propagations for your application, you definitely should
1975  * consider implementing the conflict resolving method.
1976  *
1977  * @subsection CONSPRESOL
1978  *
1979  * The CONSPRESOL callback is called during preprocessing.
1980  * It should try to tighten the domains of the variables, tighten the coefficients of the constraints of the constraint
1981  * handler, delete redundant constraints, aggregate and fix variables if possible, and upgrade constraints to more
1982  * specific types.
1983  *
1984  * If the CONSPRESOL callback applies changes to the constraint data, you also have to implement the \ref CONSTRANS callback
1985  * in order to copy the constraint data to the transformed problem space and protect the original problem from the
1986  * preprocessing changes.
1987  *
1988  * To inform SCIP that the presolving method found a reduction the result pointer has to be set in a proper way.
1989  * The following options are possible:
1990  *
1991  * - SCIP_UNBOUNDED : at least one variable is not bounded by any constraint in objective direction
1992  * - SCIP_CUTOFF : at least one constraint is infeasible in the variable's bounds
1993  * - SCIP_SUCCESS : the presolver found a reduction
1994  * - SCIP_DIDNOTFIND : the presolver searched, but did not find a presolving change
1995  * - SCIP_DIDNOTRUN : the presolver was skipped
1996  * - SCIP_DELAYED : the presolver was skipped, but should be called again
1997  *
1998  * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1999  * CONSHDLR_MAXPREROUNDS and CONSHDLR_DELAYPRESOL, which influence the behaviour of SCIP
2000  * calling CONSPRESOL.
2001  *
2002  * @subsection CONSACTIVE
2003  *
2004  * The CONSACTIVE callback method is called each time a constraint of the constraint handler is activated.
2005  * For example, if a constraint is added locally to a subproblem, the CONSACTIVE callback is called whenever the
2006  * search enters the subtree where the constraint exists.
2007  *
2008  * @subsection CONSDEACTIVE
2009  *
2010  * The CONSDEACTIVE callback method is called each time a constraint of the constraint handler is deactivated.
2011  * For example, if a constraint is added locally to a subproblem, the CONSDEACTIVE callback is called whenever the
2012  * search leaves the subtree where the constraint exists.
2013  *
2014  * @subsection CONSENABLE
2015  *
2016  * The CONSENABLE callback method is called each time a constraint of the constraint handler is enabled.
2017  * Constraints might be active without being enabled. In this case, only the feasibility checks are executed,
2018  * but domain propagation and separation is skipped.
2019  *
2020  * @subsection CONSDISABLE
2021  *
2022  * The CONSDISABLE callback method is called each time a constraint of the constraint handler is disabled.
2023  *
2024  * @subsection CONSPRINT
2025  *
2026  * The CONSPRINT callback method is called, when the user asks SCIP to display the problem to the screen
2027  * or save the problem into a file. This is, however, only the case if the user requested the CIP format.
2028  * For more details about reading and writing with SCIP we refer to the \ref READER "file readers". In this
2029  * callback method the constraint handler should display the data of the constraint in an appropriate form.
2030  * The output format that is defined by the CONSPRINT callbacks is called CIP format.
2031  * In later versions of SCIP, the constraint handlers should also be able to parse (i.e., read) constraints
2032  * which are given in CIP format.
2033  *
2034  * @subsection CONSCOPY
2035  *
2036  * The CONSCOPY callback method is used whenever constraints should be copied from one SCIP instance into another SCIP
2037  * instance. This method comes with the necessary parameters to do so, most importantly with a mapping of the variables of the
2038  * source SCIP instance to the corresponding variables of the target SCIP instance, and a mapping for the constraints
2039  * in the same way. For a complete list of all arguments of this callback method see type_cons.h.
2040  *
2041  * To get the corresponding target variable of a given source variable, you can use the variable map directly:
2042  *
2043  * \code
2044  * targetvar = (SCIP_VAR*) (size_t) SCIPhashmapGetImage(varmap, sourcevar);
2045  * \endcode
2046  *
2047  * We recommend, however, to use the method SCIPgetVarCopy() which gets besides others the variable map and the constraint map as input
2048  * and returns the requested target variable. The advantage of using SCIPgetVarCopy() is that in the case
2049  * the required variable does not yet exist, it is created and added to the copy automatically:
2050  *
2051  * \code
2052  * SCIP_CALL( SCIPgetVarCopy(sourcescip, scip, sourcevar, &targetvar, varmap, consmap, global) );
2053  * \endcode
2054  *
2055  * Finally, the result pointer <code>valid</code> has to be set to TRUE if (and only if!) the copy process was successful.
2056  *
2057  * <b>Note:</b> Be careful when setting the valid pointer. If you set the valid pointer to TRUE, but the constraint was
2058  * not copied one-to-one, then optimal solutions might be cut off during the search (see section
2059  * CONSHDLRCOPY above).
2060  *
2061  * For an example implementation we refer to cons_linear.h. Additional documentation and the complete list of all
2062  * parameters can be found in the file in type_cons.h.
2063  *
2064  * @subsection CONSPARSE
2065  *
2066  * This method is the counter part to CONSPRINT. The ideal idea is that a constraint handler is able to parse the output
2067  * which it generated via the CONSPRINT method and creates the corresponding constraint. If the parsing was successfully
2068  * the result pointer success should be set to TRUE. An example implementation can be found in the \ref cons_linear.h
2069  * "linear constraint handler".
2070  *
2071  * @subsection CONSDELVARS
2072  *
2073  * This method should iterate over the given constraints and delete all variables that were marked for deletion by SCIPdelVar().
2074  * Variable deletion is especially interesting for branch-cut-and-price applications. If your constraint handler allows
2075  * the addition of variables during the solving process (see "modifiable" attribute of constraints), then you might also want to
2076  * implement this callback. This would allow you to not only create variables during solving, but also remove them dynamically
2077  * from the problem to reduce memory consumption in case they are no longer necessary.
2078  * During presolving, SCIP may also find that some variables are not needed anymore and then try
2079  * to delete them. Thus, if you do not implement this callback, the constraint handler should capture its variables via
2080  * SCIPcaptureVar() to prevent SCIP from erroneously deleting them.
2081  *
2082  * Additional documentation and the complete list of all parameters can be found in the file type_cons.h.
2083  *
2084  * @subsection CONSGETVARS
2085  *
2086  * The CONSGETVARS callback of a constraint handler can be implemented to give access to the constraint variables
2087  * as array, independently from the internal data structure of the constraint. The buffer array
2088  * is already passed, together with its length. Consider implementing @ref CONSGETNVARS, too, to have
2089  * information about the number of variables in this constraint.
2090  *
2091  * @subsection CONSGETNVARS
2092  *
2093  * This callback can be implemented to return the number of variables involved into a particular constraint.
2094  * In order to have access to the variable pointers, consider implementing @ref CONSGETVARS.
2095  *
2096  * @section CONS_FURTHERINFO Further documentation
2097  *
2098  * Further documentation can be found in @ref type_cons.h for callback descriptions and a complete
2099  * list of all callback parameters, or in @ref scip.h
2100  * for globally available functions.
2101  */
2102 
2103 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
2104 /**@page PRICER How to add variable pricers
2105  *
2106  * A pricer performs the dynamic generation of new variables in a column generation algorithm.
2107  * It is an algorithmic representation of a (usually exponential) number of variables.
2108  * The \ref PRICERREDCOST and \ref PRICERFARKAS methods are called after each LP solve to generate additional
2109  * variables which may improve the objective value or decrease the LP infeasibility, respectively.
2110  * \n
2111  * A complete list of all pricers contained in this release can be found \ref PRICERS "here".
2112  *
2113  * If the pricer finds one or more variables with negative reduced costs or negative Farkas value, it should
2114  * call SCIPcreateVar() and SCIPaddPricedVar() to create and add the variable to the problem. Additionally,
2115  * the pricer has to add the variable to all constraints in which it appears. Therefore, a pricer needs to
2116  * know the constraints of the model and their meaning. Note that all constraints for which additional variables
2117  * are generated by a pricer have to be flagged as "modifiable" in the SCIPcreateCons() call.
2118  *
2119  * We now explain how users can add their own pricers.
2120  * For example, look into the stable set pricer for the coloring problem (examples/Coloring/src/pricer_coloring.c) of the
2121  * Coloring example project.
2122  * The example is written in C. C++ users can easily adapt the code by using the scip::scip::ObjPricer wrapper base class and
2123  * implement the scip_...() virtual methods instead of the SCIP_DECL_PRICER... callback methods.
2124  *
2125  * Additional documentation for the callback methods of a pricer can be found in the file
2126  * type_pricer.h.
2127  *
2128  * Notice that if your pricer cannot cope with variable bounds other than 0 and infinity, you have to mark
2129  * all constraints containing priced variables as modifiable, and you may have to disable reduced cost
2130  * strengthening by setting propagating/rootredcost/freq to -1.
2131  *
2132  * Here is what you have to do to implement a pricer:
2133  * -# Copy the template files src/scip/pricer_xyz.c and src/scip/pricer_xyz.h into files "pricer_mypricer.c"
2134  * and "pricer_mypricer.h".
2135  * \n
2136  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2137  * -# Use SCIPincludePricerMypricer() in order to include the pricer into your SCIP instance,
2138  * e.g., in the main file of your project (see, e.g., src/main.c in the Coloring example).
2139  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mypricer".
2140  * -# Adjust the properties of the pricer (see \ref PRICER_PROPERTIES).
2141  * -# Define the pricer data (see \ref PRICER_DATA). This is optional.
2142  * -# Implement the interface methods (see \ref PRICER_INTERFACE).
2143  * -# Implement the fundamental callback methods (see \ref PRICER_FUNDAMENTALCALLBACKS).
2144  * -# Implement the additional callback methods (see \ref PRICER_ADDITIONALCALLBACKS). This is optional.
2145  *
2146  *
2147  * @section PRICER_PROPERTIES Properties of a Pricer
2148  *
2149  * At the top of the new file "pricer_mypricer.c" you can find the pricer properties.
2150  * These are given as compiler defines.
2151  * In the C++ wrapper class, you have to provide the pricer properties by calling the constructor
2152  * of the abstract base class scip::ObjPricer from within your constructor.
2153  * The properties you have to set have the following meaning:
2154  *
2155  * \par PRICER_NAME: the name of the pricer.
2156  * This name is used in the interactive shell to address the pricer.
2157  * Additionally, if you are searching for a pricer with SCIPfindPricer(), this name is looked up.
2158  * Names have to be unique: no two pricers may have the same name.
2159  *
2160  * \par PRICER_DESC: the description of the pricer.
2161  * This string is printed as a description of the pricer in the interactive shell.
2162  *
2163  * \par PRICER_PRIORITY: the priority of the pricer.
2164  * In each pricing round during the price-and-cut loop of the subproblem processing, the included pricers are
2165  * called in a predefined order, which is given by the priorities of the pricers.
2166  * The higher the priority, the earlier the pricer is called.
2167  * Usually, you will have only one pricer in your application and the priority is therefore irrelevant.
2168  *
2169  * \par PRICER_DELAY: the default for whether the pricer should be delayed, if other variables with negative reduced
2170  * costs have already been found in the current pricing round.
2171  * Variables may be declared to be "removable" in the SCIPcreateVar() call. This means that SCIP may remove the variable
2172  * from the LP if it was inactive (i.e., sitting at zero) for a number of LP solves. Nevertheless, after the removal of the
2173  * column from the LP, the variable still exists, and SCIP can calculate reduced costs and add it to the LP again if
2174  * necessary.
2175  * \n
2176  * If the PRICER_DELAY flag is set to TRUE (which is the common setting), all those existing variables with negative reduced costs
2177  * are added to the LP, and the LP is resolved before the pricer is called. Thus, the pricer can assume that all existing variables
2178  * have non-negative reduced costs if the \ref PRICERREDCOST method is called or non-positive Farkas value if the \ref PRICERFARKAS
2179  * method is called.
2180  * \n
2181  * In some applications, this inner pricing loop on the already existing variables can significantly slow down the solving process,
2182  * since it may lead to the addition of only very few variables in each pricing round. If this is an issue in your application,
2183  * you should consider setting the PRICER_DELAY flag to FALSE. You must, however, be aware of the fact that there may be already
2184  * existing variables with negative reduced costs. For example, this may lead to the issue that your pricer generates the same
2185  * variable twice. In some models, this is not critical because an optimal solution would choose only one of the two identical
2186  * variables anyway, but for other models this can lead to wrong results because the duplication of a variable essentially doubles
2187  * the upper bound of the variable.
2188  *
2189  *
2190  * @section PRICER_DATA Pricer Data
2191  *
2192  * Below the header "Data structures" you can find a struct which is called "struct SCIP_PricerData".
2193  * In this data structure, you can store the data of your pricer. For example, it may be convenient to store pointers to the
2194  * constraints of the problem instance here, because the pricer has to add variables to those constraints.
2195  * If you are using C++, you can add pricer data, as usual, as object variables to your class.
2196  * \n
2197  * Defining pricer data is optional. You can leave the struct empty.
2198  *
2199  *
2200  * @section PRICER_INTERFACE Interface Methods
2201  *
2202  * At the bottom of "pricer_mypricer.c" you can find the interface method SCIPincludePricerMypricer(), which also appears in "pricer_mypricer.h".
2203  * It is called by the user, if (s)he wants to include the pricer, i.e., if (s)he wants to solve a model for which variables should
2204  * be generated by this pricer.
2205  *
2206  * This method only has to be adjusted slightly.
2207  * It is responsible for notifying SCIP of the presence of the pricer. For this, you can either call SCIPincludePricer(),
2208  * or SCIPincludePricerBasic() since SCIP version 3.0. In the latter variant, \ref PRICER_ADDITIONALCALLBACKS "additional callbacks"
2209  * must be added via setter functions as, e.g., SCIPsetPricerCopy(). We recommend this latter variant because
2210  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
2211  * variant must be manually adjusted with every SCIP release containing new callbacks for pricers in order to compile.
2212  *
2213  *
2214  * In addition, the pricer has to be activated before the solution process starts, like it is done
2215  * in the reader of the Coloring example (examples/Coloring/src/reader_col.c) by calling
2216  * \code
2217  * SCIP_CALL( SCIPactivatePricer(scip, SCIPfindPricer(scip, "coloring")) );
2218  * \endcode
2219  *
2220  * If you are using pricer data, you have to allocate the memory for the data at this point.
2221  * You can do this by calling:
2222  * \code
2223  * SCIP_CALL( SCIPallocMemory(scip, &pricerdata) );
2224  * \endcode
2225  * You also have to initialize the fields in struct SCIP_PricerData afterwards.
2226  *
2227  * You may also add user parameters for your pricer, see the method SCIPincludePricerColoring() in the pricer of the Coloring example
2228  * for an example of how to add user parameters.
2229  *
2230  *
2231  * @section PRICER_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Pricer
2232  *
2233  * The fundamental callback methods have to be implemented in order to obtain an operational algorithm.
2234  * They are passed together with the pricer itself to SCIP using SCIPincludePricer() or SCIPincludePricerBasic(),
2235  * see @ref PRICER_INTERFACE.
2236  *
2237  * In the case of a pricer, there are two fundamental callback methods, namely the @ref PRICERREDCOST and the
2238  * @ref PRICERFARKAS callbacks, which both search for new variables and add them to the problem.
2239  * These methods have to be implemented for every pricer; the other callback methods are optional.
2240  * In the C++ wrapper class scip::ObjPricer, the scip_redcost() method (which corresponds to the PRICERREDCOST callback)
2241  * is a virtual abstract member function. You have to implement it in order to be able to construct an object of your
2242  * pricer class.
2243  *
2244  * Additional documentation for the callback methods can be found in type_pricer.h.
2245  *
2246  * @subsection PRICERREDCOST
2247  *
2248  * The PRICERREDCOST callback is called inside the price-and-cut loop of the subproblem solving process if the current LP relaxation
2249  * is feasible.
2250  * It should search for additional variables that can contribute to improve the current LP's solution value.
2251  * In standard branch-and-price, these are variables with negative dual feasibility, that is negative
2252  * reduced costs for non-negative variables, positive reduced costs for non-positive variables,
2253  * and non-zero reduced costs for variables that can be negative and positive.
2254  *
2255  * Whenever the pricer finds a variable with negative dual feasibility, it should call SCIPcreateVar()
2256  * and SCIPaddPricedVar() to add the variable to the problem. Furthermore, it should call the appropriate
2257  * methods of the constraint handlers to add the necessary variable entries to the constraints, see pub_cons.h.
2258  *
2259  * In the usual case that the pricer either adds a new variable or ensures that there are no further variables with negative dual feasibility,
2260  * the result pointer should be set to SCIP_SUCCESS. Only if the pricer aborts pricing without creating a new variable, but
2261  * there might exist additional variables with negative dual feasibility, the result pointer should be set to SCIP_DIDNOTRUN.
2262  * In this case, which sometimes is referred to as "early branching", the LP solution will not be used as a lower bound.
2263  * The pricer can, however, store a valid lower bound in the <code>lowerbound</code> pointer.
2264  *
2265  * Pricers usually need the dual LP solution as input for the pricing algorithm.
2266  * Since SCIP does not know the semantics of the individual constraints in the problem, the dual solution
2267  * has to be provided by the constraint handlers.
2268  * For example, the \ref cons_setppc.h "setppc constraint handler", which deals with set partitioning, packing, and covering constraints, provides
2269  * the method SCIPgetDualsolSetppc() to access the dual solution value for a single constraint.
2270  * Similarly, the dual solution of a linear constraint can be queried with the method SCIPgetDualsolLinear() of cons_linear.h.
2271  * The reduced costs of the existing variables can be accessed with the method SCIPgetVarRedcost().
2272  *
2273  * @subsection PRICERFARKAS
2274  *
2275  * If the current LP relaxation is infeasible, it is the task of the pricer to generate additional variables that can
2276  * potentially render the LP feasible again. In standard branch-and-price, these are variables with positive Farkas values,
2277  * and the PRICERFARKAS method should identify those variables.
2278  *
2279  * If the LP was proven to be infeasible, we have an infeasibility proof by the dual Farkas multipliers \f$y\f$.
2280  * With the values of \f$y\f$, an implicit inequality \f$y^T A x \ge y^T b\f$ is associated, with \f$b\f$ given
2281  * by the sides of the LP rows and the sign of \f$y\f$:
2282  * - if \f$y_i\f$ is positive, \f$b_i\f$ is the left hand side of the row,
2283  * - if \f$y_i\f$ is negative, \f$b_i\f$ is the right hand side of the row.
2284  *
2285  * \f$y\f$ is chosen in a way, such that the valid inequality \f$y^T A x \ge y^T b\f$ is violated by all \f$x\f$,
2286  * especially by the (for this inequality least infeasible solution) \f$x'\f$ defined by
2287  * - \f$x'_i := ub_i\f$, if \f$y^T A_i \ge 0\f$
2288  * - \f$x'_i := lb_i\f$, if \f$y^T A_i < 0\f$.
2289  * Pricing in this case means to add variables \f$i\f$ with positive Farkas value, i.e., \f$y^T A_i x'_i > 0\f$.
2290  *
2291  * To apply Farkas pricing, the pricer needs to know the Farkas values of the constraints. Like the dual solution values for
2292  * feasible LP solutions, the dual Farkas values for infeasible solutions can be obtained by constraint handler interface
2293  * methods such as the SCIPgetDualfarkasLinear() method of the linear constraint handler.
2294  * The Farkas values for the bounds of the variables are just the regular reduced costs and can be accessed with SCIPgetVarRedcost().
2295  *
2296  * It is useful to note that Farkas pricing is the same as the regular pricing with a zero objective function.
2297  * Therefore, a typical implementation of a pricer would consist of a generic pricing algorithm that gets a dual solution and an
2298  * objective function vector as input and generates variables by calling SCIPcreateVar() and SCIPaddPricedVar().
2299  * The PRICERREDCOST callback would call this function with the regular objective function and the regular dual solution vector,
2300  * while the PRICERFARKAS callback would call this function with a zero objective function and the Farkas vector.
2301  * From a practical point of view, it is usually the simplest approach to provide just one Boolean flag to the generic pricing
2302  * algorithm in order to identify whether it is reduced cost or Farkas pricing. Then, the algorithm would just call the appropriate
2303  * methods to access the dual solution or objective function, depending on the Boolean flag.
2304  *
2305  * @section PRICER_ADDITIONALCALLBACKS Additional Callback Methods of a Pricer
2306  *
2307  * The additional callback methods do not need to be implemented in every case.
2308  * However, some of them have to be implemented for most applications. They can either be passed directly with
2309  * SCIPincludePricer() to SCIP or via specific <b>setter functions</b> after a call of SCIPincludePricerBasic(),
2310  * see also @ref PRICER_INTERFACE.
2311  *
2312  * @subsection PRICERFREE
2313  *
2314  * If you are using pricer data, you have to implement this method in order to free the pricer data.
2315  * This can be done by the following procedure:
2316  * \code
2317  * static
2318  * SCIP_DECL_PRICERFREE(pricerFreeMypricer)
2319  * {
2320  * SCIP_PRICERDATA* pricerdata;
2321  *
2322  * pricerdata = SCIPpricerGetData(pricer);
2323  * assert(pricerdata != NULL);
2324  *
2325  * SCIPfreeMemory(scip, &pricerdata);
2326  *
2327  * SCIPpricerSetData(pricer, NULL);
2328  *
2329  * return SCIP_OKAY;
2330  * }
2331  * \endcode
2332  * If you have allocated memory for fields in your pricer data, remember to free this memory
2333  * before freeing the pricer data itself.
2334  * If you are using the C++ wrapper class, this method is not available.
2335  * Instead, just use the destructor of your class to free the member variables of your class.
2336  *
2337  * @subsection PRICERCOPY
2338  *
2339  * The PRICERCOPY callback is executed when the SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this
2340  * callback as <code>NULL</code> the user disables the inclusion of the pricer into all copied SCIP
2341  * instances. This means that primal heuristics will work on a sub-SCIP that contains only a part of the variables
2342  * and no variables are priced in during the solving process of the sub-SCIP. Therefore, primal solutions found in the
2343  * copied problem are typically still valid for the original problem and used for its solving process,
2344  * but dual reductions cannot be transferred to the original problem.
2345  *
2346  * <b>Note:</b> If you implement this callback, be careful when setting the valid pointer. The valid pointer should be
2347  * set to TRUE if (and only if!) you can make sure that all necessary data of the pricer are copied
2348  * correctly. If the complete problem is validly copied, i.e. if the copy methods of all problem defining plugins
2349  * (constraint handlers and pricers) return <code>*valid = TRUE</code>, then dual reductions found for the copied problem can be
2350  * transferred to the original SCIP instance. Thus, if the valid pointer is wrongly set to TRUE, it might happen that
2351  * optimal solutions are cut off.
2352  *
2353  * @subsection PRICERINIT
2354  *
2355  * The PRICERINIT callback is executed after the problem is transformed.
2356  * The pricer may, e.g., use this call to replace the original constraints stored in its pricer data by transformed
2357  * constraints, or to initialize other elements of its pricer data.
2358  *
2359  * @subsection PRICEREXIT
2360  *
2361  * The PRICEREXIT callback is executed before the transformed problem is freed.
2362  * In this method, the pricer should free all resources that have been allocated for the solving process in PRICERINIT.
2363  *
2364  * @subsection PRICERINITSOL
2365  *
2366  * The PRICERINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to begin.
2367  * The pricer may use this call to initialize its branch-and-bound specific data.
2368  *
2369  * @subsection PRICEREXITSOL
2370  *
2371  * The PRICEREXITSOL callback is executed before the branch-and-bound process is freed.
2372  * The pricer should use this call to clean up its branch-and-bound data, which was allocated in PRICERINITSOL.
2373  *
2374  * @section PRICER_REMARKS Further remarks
2375  *
2376  * If you use your own branching rule (e.g., to branch on constraints), make sure that it is able to branch on \a "pseudo solutions".
2377  * Otherwise, SCIP will use its default branching rules, if necessary (which all branch on variables). This
2378  * could disturb the pricing problem or branching might not even be possible, e.g., if all variables created thus far have already been fixed.
2379  *
2380  * Note that if the original problem is a maximization problem, SCIP will transform the problem into a minimization
2381  * problem by multiplying the objective function by -1. The pricer has to take care of this by multiplying
2382  * the original objective function value of all variables created during the solving process by -1.
2383  *
2384  * In some cases, bounds on variables are implicitly enforced by constraints of the problem and the objective function.
2385  * Therefore, these bounds do not need to be added to the LP explicitly, which has the advantage that the pricing routine does not need to
2386  * care about the corresponding dual values.
2387  * We call these bounds lazy bounds, they may be set by SCIPchgVarLbLazy() and SCIPchgVarUbLazy() for upper or lower bounds, respectively.
2388  * If the lazy bound is tighter than the local bound, the corresponding bound is not put into the LP.
2389  * In diving mode, lazy bounds are explicitly put into the LP, because changing the objective (which is only possible in diving)
2390  * might reverse the implicitly given bounds. When diving is finished, the bounds are again removed from the LP.
2391  */
2392 
2393 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
2394 /**@page PRESOL How to add presolvers
2395  *
2396  * Presolvers are used to reduce the size of the model by removing irrelevant information like redundant constraints,
2397  * to strengthen the LP relaxation by exploiting integrality information, and to extract useful information in the
2398  * presolving step.
2399  * Constraint based presolving is done in the CONSPRESOL callback methods of the constraint handlers, see \ref CONSPRESOL.
2400  * The presolver plugins complement the constraint based presolving by additional, usually optimality based, presolving
2401  * reductions.
2402  * \n
2403  * A complete list of all presolvers contained in this release can be found \ref PRESOLVERS "here".
2404  *
2405  * We now explain how users can add their own presolvers.
2406  * Take the dual fixing presolver (src/scip/presol_dualfix.c) as an example.
2407  * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjPresol wrapper
2408  * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_PRESOL... callback methods.
2409  *
2410  * Additional documentation for the callback methods of a presolver, in particular for their input parameters,
2411  * can be found in the file type_presol.h.
2412  *
2413  * Here is what you have to do to implement a presolver:
2414  * -# Copy the template files src/scip/presol_xyz.c and src/scip/presol_xyz.h into files named "presol_mypresolver.c"
2415  * and "presol_mypresolver.h".
2416  * \n
2417  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2418  * -# Use SCIPincludePresolMypresolver() in order to include the presolver into your SCIP instance,
2419  * e.g., in the main file of your project (see, e.g., src/main.c in the Coloring example).
2420  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mypresolver".
2421  * -# Adjust the properties of the presolver (see \ref PRESOL_PROPERTIES).
2422  * -# Define the presolver data (see \ref PRESOL_DATA). This is optional.
2423  * -# Implement the interface methods (see \ref PRESOL_INTERFACE).
2424  * -# Implement the fundamental callback methods (see \ref PRESOL_FUNDAMENTALCALLBACKS).
2425  * -# Implement the additional callback methods (see \ref PRESOL_ADDITIONALCALLBACKS). This is optional.
2426  *
2427  *
2428  * @section PRESOL_PROPERTIES Properties of a Presolver
2429  *
2430  * At the top of the new file "presol_mypresolver.c", you can find the presolver properties.
2431  * These are given as compiler defines.
2432  * In the C++ wrapper class, you have to provide the presolver properties by calling the constructor
2433  * of the abstract base class scip::ObjPresol from within your constructor.
2434  * The properties you have to set have the following meaning:
2435  *
2436  * \par PRESOL_NAME: the name of the presolver.
2437  * This name is used in the interactive shell to address the presolver.
2438  * Additionally, if you are searching for a presolver with SCIPfindPresol(), this name is looked up.
2439  * Names have to be <b>unique</b>: no two presolvers may have the same name.
2440  *
2441  * \par PRESOL_DESC: the description of the presolver.
2442  * This string is printed as a description of the presolver in the interactive shell.
2443  *
2444  * \par PRESOL_PRIORITY: the priority of the presolver.
2445  * In each presolving round, the presolvers and presolving methods of the constraint handlers are called in
2446  * a predefined order, which is given by the priorities of the presolvers and the check priorities of the
2447  * constraint handlers, see \ref CONS_PROPERTIES.
2448  * First, the presolvers with non-negative priority are called in the order of decreasing priority.
2449  * Next, the presolving methods of the different constraint handlers are called in the order of decreasing check
2450  * priority.
2451  * Finally, the presolvers with negative priority are called in the order of decreasing priority.
2452  * \n
2453  * The priority of the presolver should be set according to the complexity of the presolving algorithm and the impact of the reduction:
2454  * presolvers that provide fast algorithms that usually have a high impact (i.e., remove lots of variables or tighten
2455  * bounds of many variables) should have a high priority. An easy way to list the
2456  * priorities of all presolvers and constraint handlers is to type "display presolvers" and "display conshdlrs" in
2457  * the interactive shell of SCIP.
2458  *
2459  * \par PRESOL_MAXROUNDS: the default maximal number of rounds the presolver participates in.
2460  * The presolving is conducted in rounds: the presolvers and presolving methods of the constraint handlers
2461  * are called iteratively until no more reductions have been found or some other abort criterion applies.
2462  * The "maxrounds" parameter of a presolver imposes a limit on the number of presolving rounds in which the
2463  * presolver is called. The PRESOL_MAXROUNDS property specifies the default value for this parameter.
2464  * A value of -1 represents an unlimited number of rounds.
2465  *
2466  * \par PRESOL_DELAY: the default for whether the presolver should be delayed, if other presolvers found reductions.
2467  * If the presolver is marked to be delayed, it is only executed if no other presolvers found a reduction during the current
2468  * presolving round.
2469  * If the presolver is very expensive, you may want to mark it to be delayed until all cheap presolving methods have been executed.
2470  *
2471  *
2472  * @section PRESOL_DATA Presolver Data
2473  *
2474  * Below the header "Data structures" you can find a struct which is called "struct SCIP_PresolData".
2475  * In this data structure, you can store the data of your presolver. For example, you should store the adjustable parameters
2476  * of the presolver in this data structure.
2477  * If you are using C++, you can add presolver data as usual as object variables to your class.
2478  * \n
2479  * Defining presolver data is optional. You can leave this struct empty.
2480  *
2481  *
2482  * @section PRESOL_INTERFACE Interface Methods
2483  *
2484  * At the bottom of "presol_mypresolver.c", you can find the interface method SCIPincludePresolMypresolver(),
2485  * which also appears in "presol_mypresolver.h"
2486  * SCIPincludePresolMypresolver() is called by the user, if (s)he wants to include the presolver,
2487  * i.e., if (s)he wants to use the presolver in his/her application.
2488  *
2489  * This method only has to be adjusted slightly.
2490  * It is responsible for notifying SCIP of the presence of the presolver. For this, you can either call SCIPincludePresol(),
2491  * or SCIPincludePresolBasic() since SCIP version 3.0. In the latter variant, \ref PRESOL_ADDITIONALCALLBACKS "additional callbacks"
2492  * must be added via setter functions as, e.g., SCIPsetPresolCopy(). We recommend this latter variant because
2493  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
2494  * variant must be manually adjusted with every SCIP release containing new callbacks for presolvers in order to compile.
2495  *
2496  * If you are using presolver data, you have to allocate the memory for the data at this point.
2497  * You can do this by calling:
2498  * \code
2499  * SCIP_CALL( SCIPallocMemory(scip, &presoldata) );
2500  * \endcode
2501  * You also have to initialize the fields in struct SCIP_PresolData afterwards. For freeing the
2502  * presolver data, see \ref PRESOLFREE.
2503  *
2504  * You may also add user parameters for your presolver, see \ref PARAM for how to add user parameters and
2505  * the method SCIPincludePresolTrivial() in src/scip/presol_trivial.c for an example.
2506  *
2507  *
2508  * @section PRESOL_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Presolver
2509  *
2510  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
2511  * an operational algorithm.
2512  * They are passed together with the presolver itself to SCIP using SCIPincludePresol() or SCIPincludePresolBasic(),
2513  * see @ref PRESOL_INTERFACE.
2514  *
2515  * Presolver plugins have only one fundamental callback method, namely the @ref PRESOLEXEC method.
2516  * This method has to be implemented for every presolver; the other callback methods are optional.
2517  * In the C++ wrapper class scip::ObjPresol, the scip_exec() method (which corresponds to the PRESOLEXEC callback) is a virtual
2518  * abstract member function.
2519  * You have to implement it in order to be able to construct an object of your presolver class.
2520  *
2521  * Additional documentation for the callback methods, in particular to their input parameters,
2522  * can be found in type_presol.h.
2523  *
2524  * @subsection PRESOLEXEC
2525  *
2526  * The PRESOLEXEC callback is called inside the presolving loop and should perform the actual presolving reductions.
2527  * It should inspect the problem instance at hand and simplify it by tightening bounds of variables, aggregating or fixing
2528  * variables, changing the type of variables, modifying the graph that represents the instance of your application, and
2529  * the like.
2530  *
2531  * Typical methods called by a presolver are, for example, SCIPchgVarType(), SCIPfixVar(), SCIPaggregateVars(), SCIPtightenVarLb(),
2532  * and SCIPtightenVarUb().
2533  *
2534  *
2535  * @section PRESOL_ADDITIONALCALLBACKS Additional Callback Methods of a Presolver
2536  *
2537  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
2538  * implemented for most applications, they can be used, for example, to initialize and free private data.
2539  * Additional callbacks can either be passed directly with SCIPincludePresol() to SCIP or via specific
2540  * <b>setter functions</b> after a call of SCIPincludePresolBasic(), see also @ref PRESOL_INTERFACE.
2541  *
2542  * @subsection PRESOLFREE
2543  *
2544  * If you are using presolver data (see \ref PRESOL_DATA and \ref PRESOL_INTERFACE), you have to implement this method in order to free the presolver data.
2545  * This can be done by the following procedure:
2546  * \code
2547  * static
2548  * SCIP_DECL_PRESOLFREE(presolFreeMypresolver)
2549  * {
2550  * SCIP_PRESOLDATA* presoldata;
2551  *
2552  * presoldata = SCIPpresolGetData(presol);
2553  * assert(presoldata != NULL);
2554  *
2555  * SCIPfreeMemory(scip, &presoldata);
2556  *
2557  * SCIPpresolSetData(presol, NULL);
2558  *
2559  * return SCIP_OKAY;
2560  * }
2561  * \endcode
2562  * If you have allocated memory for fields in your presolver data, remember to free this memory
2563  * before freeing the presolver data itself.
2564  * If you are using the C++ wrapper class, this method is not available.
2565  * Instead, just use the destructor of your class to free the member variables of your class.
2566  *
2567  * @subsection PRESOLINIT
2568  *
2569  * The PRESOLINIT callback is executed after the problem is transformed.
2570  * The presolver may, e.g., use this call to initialize its presolver data.
2571  * The difference between the original and the transformed problem is explained in
2572  * "What is this thing with the original and the transformed problem about?" on \ref FAQ.
2573  *
2574  * @subsection PRESOLCOPY
2575  *
2576  * The PRESOLCOPY callback is executed when a SCIP instance is copied, e.g. to
2577  * solve a sub-SCIP. By
2578  * defining this callback as
2579  * <code>NULL</code> the user disables the execution of the specified
2580  * presolver for all copied SCIP instances. This may deteriorate the performance
2581  * of primal heuristics using sub-SCIPs.
2582  *
2583  * @subsection PRESOLEXIT
2584  *
2585  * The PRESOLEXIT callback is executed before the transformed problem is freed.
2586  * In this method, the presolver should free all resources that have been allocated for the solving process in PRESOLINIT.
2587  *
2588  * @subsection PRESOLINITPRE
2589  *
2590  * The PRESOLINITPRE callback is executed when the presolving is about to begin.
2591  * The presolver may use this call to initialize its presolving data which only need to exist during the presolving stage.
2592  *
2593  * @subsection PRESOLEXITPRE
2594  *
2595  * The PRESOLEXITPRE callback is executed after presolving finishes and before the branch-and-bound process begins.
2596  * The presolver should use this call to clean up its presolving data, which was allocated in PRESOLINITPRE.
2597  */
2598 
2599 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
2600 /**@page SEPA How to add separators
2601  *
2602  * Separators are used to generate general purpose cutting planes.
2603  * Constraint based cutting planes, the second type of cutting planes in SCIP, are separated in the CONSSEPALP and
2604  * CONSSEPASOL callback methods of the constraint handlers, see \ref CONSSEPALP and \ref CONSSEPASOL. These cuts are
2605  * valid inequalities or even facets of the polyhedron described by a single constraint or a subset of the constraints of
2606  * a single constraint class. In contrast, general purpose cuts do not require or exploit any knowledge about the
2607  * underlying problem structure but use only the current LP relaxation and the integrality conditions. See also
2608  * "When should I implement a constraint handler, when should I implement a separator?" on \ref FAQ.
2609  * \n
2610  * A complete list of all separators contained in this release can be found \ref SEPARATORS "here".
2611  *
2612  * We now explain how users can add their own separators.
2613  * Take the separator for the class of Gomory mixed integer inequalities (src/scip/sepa_gomory.c) as an example.
2614  * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjSepa wrapper
2615  * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_SEPA... callback methods.
2616  *
2617  * Additional documentation for the callback methods of a separator, in particular for the input parameters,
2618  * can be found in the file type_sepa.h.
2619  *
2620  * Here is what you have to do to implement a separator:
2621  * -# Copy the template files src/scip/sepa_xyz.c and src/scip/sepa_xyz.h into files "sepa_myseparator.c"
2622  * and "sepa_myseparator.h".
2623  \n
2624  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2625  * -# Use SCIPincludeSepaMyseparator() in order to include the separator into your SCIP instance,
2626  * e.g., in the main file of your project (see, e.g., src/main.c in the Coloring example).
2627  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "myseparator".
2628  * -# Adjust the properties of the separator (see \ref SEPA_PROPERTIES).
2629  * -# Define the separator data (see \ref SEPA_DATA). This is optional.
2630  * -# Implement the interface methods (see \ref SEPA_INTERFACE).
2631  * -# Implement the fundamental callback methods (see \ref SEPA_FUNDAMENTALCALLBACKS).
2632  * -# Implement the additional callback methods (see \ref SEPA_ADDITIONALCALLBACKS). This is optional.
2633  *
2634  *
2635  * @section SEPA_PROPERTIES Properties of a Separator
2636  *
2637  * At the top of the new file "sepa_myseparator.c", you can find the separator properties.
2638  * These are given as compiler defines.
2639  * In the C++ wrapper class, you have to provide the separator properties by calling the constructor
2640  * of the abstract base class scip::ObjSepa from within your constructor.
2641  * The properties you have to set have the following meaning:
2642  *
2643  * \par SEPA_NAME: the name of the separator.
2644  * This name is used in the interactive shell to address the separator.
2645  * Additionally, if you are searching for a separator with SCIPfindSepa(), this name is looked up.
2646  * Names have to be unique: no two separators may have the same name.
2647  *
2648  * \par SEPA_DESC: the description of the separator.
2649  * This string is printed as a description of the separator in the interactive shell.
2650  *
2651  * \par SEPA_PRIORITY: the priority of the separator.
2652  * In each separation round during the price-and-cut loop of the subproblem processing or the separation loop
2653  * of the primal solution separation, the separators and separation methods of the constraint handlers are called in
2654  * a predefined order, which is given by the priorities of the separators and the separation priorities
2655  * of the constraint handlers (see \ref CONS_PROPERTIES).
2656  * First, the separators with non-negative priority are called in the order of decreasing priority.
2657  * Next, the separation methods of the constraint handlers are called in the order of decreasing separation
2658  * priority.
2659  * Finally, the separators with negative priority are called in the order of decreasing priority. An easy way to list the
2660  * priorities of all separators and constraint handlers is to type "display separators" and "display conshdlrs" in
2661  * the interactive shell.
2662  * \n
2663  * The priority of the separator should be set according to the complexity of the cut separation algorithm and the
2664  * impact of the resulting cuts: separators that provide fast algorithms that usually have a high impact (i.e., cut off
2665  * a large portion of the LP relaxation) should have a high priority.
2666  * See \ref SEPAEXECLP and \ref SEPAEXECSOL for further details of the separation callbacks.
2667  *
2668  * \par SEPA_FREQ: the default frequency for separating cuts.
2669  * The frequency defines the depth levels at which the separation methods \ref SEPAEXECLP and \ref SEPAEXECSOL are called.
2670  * For example, a frequency of 7 means, that the separation callback is executed for subproblems that are in depth
2671  * 0, 7, 14, ... of the branching tree. A frequency of 0 means, that the separation method is only called at the root node.
2672  * A frequency of -1 disables the separator.
2673  * \n
2674  * The frequency can be adjusted by the user. This property of the separator only defines the default value of the frequency.
2675  * If you want to have a more flexible control of when to execute the separation algorithm, you have to assign
2676  * a frequency of 1 and implement a check at the beginning of your separation methods whether you really want to execute
2677  * the separation or not. If you do not want to execute it, set the result code of
2678  * \ref SEPAEXECLP and \ref SEPAEXECSOL to SCIP_DIDNOTRUN.
2679  *
2680  * \par SEPA_MAXBOUNDDIST: the default maximal relative distance from the current node's dual bound to primal bound compared to best node's dual bound for applying separation.
2681  * At the current branch-and-bound node, the relative distance from its dual bound (local dual bound)
2682  * to the primal bound compared to the best node's dual bound (global dual bound) is considered. The separation method
2683  * of the separator will only be applied at the current node if this relative distance does not exceed SEPA_MAXBOUNDDIST.
2684  * \n
2685  * For example, if the global dual bound is 50 and the primal bound is 60, SEPA_MAXBOUNDDIST = 0.25 means that separation
2686  * is only applied if the current node's dual bound is in the first quarter of the interval [50,60], i.e., if it is less
2687  * than or equal to 52.5.
2688  * \n
2689  * In particular, the values 0.0 and 1.0 mean that separation is applied at the current best node only or at all
2690  * nodes, respectively. Since separation seems to be most important to apply at nodes that define to the global
2691  * dual bound, 0.0 is probably a good choice for SEPA_MAXBOUNDDIST.
2692  * Note that separators with a frequency of SEPA_FREQ = 0 are only applied at the root node.
2693  * Obviously, at the root node the local dual bound is equal to the global dual bound and thus, the separator is called
2694  * for any value of SEPA_MAXBOUNDDIST.
2695  *
2696  * \par SEPA_USESSUBSCIP: Does the separator use a secondary SCIP instance?
2697  * Some heuristics and separators solve MIPs or SAT problems and use a secondary SCIP instance. Examples are
2698  * Large Neighborhood Search heuristics such as RINS and Local Branching or the CGMIP separator. To avoid recursion,
2699  * these plugins usually deactivate all other plugins that solve MIPs. If a separator uses a secondary SCIP instance,
2700  * this parameter has to be TRUE and it is recommended to call SCIPsetSubscipsOff() for the secondary SCIP instance.
2701  *
2702  * \par SEPA_DELAY: the default for whether the separation method should be delayed, if other separators or constraint handlers found cuts.
2703  * If the separator's separation method is marked to be delayed, it is only executed after no other separator
2704  * or constraint handler found a cut during the price-and-cut loop.
2705  * If the separation method of the separator is very expensive, you may want to mark it to be delayed until all cheap
2706  * separation methods have been executed.
2707  *
2708  * @section SEPA_DATA Separator Data
2709  *
2710  * Below the header "Data structures" you can find a struct which is called "struct SCIP_SepaData".
2711  * In this data structure, you can store the data of your separator. For example, you should store the adjustable
2712  * parameters of the separator in this data structure. In a separator, user parameters for the maximal number of
2713  * separation rounds per node and for the maximal number of cuts separated per separation round might be useful.
2714  * If you are using C++, you can add separator data as usual as object variables to your class.
2715  * \n
2716  * Defining separator data is optional. You can leave the struct empty.
2717  *
2718  * @section SEPA_INTERFACE Interface Methods
2719  *
2720  * At the bottom of "sepa_myseparator.c", you can find the interface method SCIPincludeSepaMyseparator(),
2721  * which also appears in "sepa_myseparator.h"
2722  * SCIPincludeSepaMyseparator() is called by the user, if (s)he wants to include the separator,
2723  * i.e., if (s)he wants to use the separator in his/her application.
2724  *
2725  * This method only has to be adjusted slightly.
2726  * It is responsible for notifying SCIP of the presence of the separator. For this, you can either call SCIPincludeSepa(),
2727  * or SCIPincludeSepaBasic() since SCIP version 3.0. In the latter variant, \ref SEPA_ADDITIONALCALLBACKS "additional callbacks"
2728  * must be added via setter functions as, e.g., SCIPsetSepaCopy(). We recommend this latter variant because
2729  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
2730  * variant must be manually adjusted with every SCIP release containing new callbacks for separators in order to compile.
2731  *
2732  * If you are using separator data, you have to allocate the memory
2733  * for the data at this point. You can do this by calling:
2734  * \code
2735  * SCIP_CALL( SCIPallocMemory(scip, &sepadata) );
2736  * \endcode
2737  * You also have to initialize the fields in "struct SCIP_SepaData" afterwards. For freeing the
2738  * separator data, see \ref SEPAFREE.
2739  *
2740  * You may also add user parameters for your separator, see \ref PARAM for how to add user parameters and
2741  * the method SCIPincludeSepaGomory() in src/scip/sepa_gomory.c for an example.
2742  *
2743  *
2744  * @section SEPA_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Separator
2745  *
2746  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
2747  * an operational algorithm.
2748  * They are passed together with the separator itself to SCIP using SCIPincludeSepa() or SCIPincludeSepaBasic(),
2749  * see @ref SEPA_INTERFACE.
2750  *
2751  * Separator plugins have two callbacks, @ref SEPAEXECLP and @ref SEPAEXECSOL, of which at least one must be implemented.
2752  *
2753  * Additional documentation for the callback methods, in particular to their input parameters,
2754  * can be found in type_sepa.h.
2755  *
2756  * @subsection SEPAEXECLP
2757  *
2758  * The SEPAEXECLP callback is executed during the price-and-cut loop of the subproblem processing.
2759  * It should try to generate general purpose cutting planes in order to separate the current LP solution.
2760  * The method is called in the LP solution loop, which means that a valid LP solution exists.
2761  *
2762  * Usually, the callback searches and produces cuts, that are added with a call to SCIPaddCut().
2763  * If the cut should be added to the global cut pool, it calls SCIPaddPoolCut().
2764  * In addition to LP rows, the callback may also produce domain reductions or add additional constraints.
2765  *
2766  * Overall, the SEPAEXECLP callback has the following options, which is indicated by the possible return values of
2767  * the 'result' variable (see type_sepa.h):
2768  * - detecting that the node is infeasible in the variable's bounds and can be cut off (result SCIP_CUTOFF)
2769  * - adding an additional constraint (result SCIP_CONSADDED)
2770  * - reducing a variable's domain (result SCIP_REDUCEDDOM)
2771  * - adding a cutting plane to the LP (result SCIP_SEPARATED)
2772  * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
2773  * (result SCIP_DIDNOTFIND)
2774  * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
2775  * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
2776  * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
2777  *
2778  * @subsection SEPAEXECSOL
2779  *
2780  * The SEPAEXECSOL callback is executed during the separation loop on arbitrary primal solutions.
2781  * It should try to generate general purpose cutting planes in order to separate the given primal solution.
2782  * The method is not called in the LP solution loop, which means that there is no valid LP solution.
2783  *
2784  * In the standard SCIP environment, the SEPAEXECSOL callback is not used because only LP solutions are
2785  * separated. The SEPAEXECSOL callback provides means to support external relaxation handlers like semidefinite
2786  * relaxations that want to separate an intermediate primal solution vector. Thus, if you do not want to support
2787  * such external plugins, you do not need to implement this callback method.
2788  *
2789  * Usually, the callback searches and produces cuts, that are added with a call to SCIPaddCut().
2790  * If the cut should be added to the global cut pool, it calls SCIPaddPoolCut().
2791  * In addition to LP rows, the callback may also produce domain reductions or add other constraints.
2792  *
2793  * Overall, the SEPAEXECSOL callback has the following options, which is indicated by the possible return values of
2794  * the 'result' variable (see type_sepa.h):
2795  * - detecting that the node is infeasible in the variable's bounds and can be cut off (result SCIP_CUTOFF)
2796  * - adding an additional constraint (result SCIP_CONSADDED)
2797  * - reducing a variable's domain (result SCIP_REDUCEDDOM)
2798  * - adding a cutting plane to the LP (result SCIP_SEPARATED)
2799  * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
2800  * (result SCIP_DIDNOTFIND)
2801  * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
2802  * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
2803  * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
2804  *
2805  *
2806  * @section SEPA_ADDITIONALCALLBACKS Additional Callback Methods of a Separator
2807  *
2808  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
2809  * implemented for most applications, they can be used, for example, to initialize and free private data.
2810  * Additional callbacks can either be passed directly with SCIPincludeSepa() to SCIP or via specific
2811  * <b>setter functions</b> after a call of SCIPincludeSepaBasic(), see also @ref SEPA_INTERFACE.
2812  *
2813  * @subsection SEPAFREE
2814  *
2815  * If you are using separator data (see \ref SEPA_DATA and \ref SEPA_INTERFACE), you have to implement this method
2816  * in order to free the separator data. This can be done by the following procedure:
2817  * \code
2818  * static
2819  * SCIP_DECL_SEPAFREE(sepaFreeMyseparator)
2820  * {
2821  * SCIP_SEPADATA* sepadata;
2822  *
2823  * sepadata = SCIPsepaGetData(sepa);
2824  * assert(sepadata != NULL);
2825  *
2826  * SCIPfreeMemory(scip, &sepadata);
2827  *
2828  * SCIPsepaSetData(sepa, NULL);
2829  *
2830  * return SCIP_OKAY;
2831  * }
2832  * \endcode
2833  * If you have allocated memory for fields in your separator data, remember to free this memory
2834  * before freeing the separator data itself.
2835  * If you are using the C++ wrapper class, this method is not available.
2836  * Instead, just use the destructor of your class to free the member variables of your class.
2837  *
2838  * @subsection SEPACOPY
2839  *
2840  * The SEPACOPY callback is executed when a SCIP instance is copied, e.g. to
2841  * solve a sub-SCIP. By
2842  * defining this callback as
2843  * <code>NULL</code> the user disables the execution of the specified
2844  * separator for all copied SCIP instances. This may deteriorate the performance
2845  * of primal heuristics using sub-SCIPs.
2846  *
2847  * @subsection SEPAINIT
2848  *
2849  * The SEPAINIT callback is executed after the problem is transformed.
2850  * The separator may, e.g., use this call to initialize its separator data.
2851  * The difference between the original and the transformed problem is explained in
2852  * "What is this thing with the original and the transformed problem about?" on \ref FAQ.
2853  *
2854  * @subsection SEPAEXIT
2855  *
2856  * The SEPAEXIT callback is executed before the transformed problem is freed.
2857  * In this method, the separator should free all resources that have been allocated for the solving process in SEPAINIT.
2858  *
2859  * @subsection SEPAINITSOL
2860  *
2861  * The SEPAINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
2862  * begin. The separator may use this call to initialize its branch-and-bound specific data.
2863  *
2864  * @subsection SEPAEXITSOL
2865  *
2866  * The SEPAEXITSOL callback is executed before the branch-and-bound process is freed. The separator should use this call
2867  * to clean up its branch-and-bound data, in particular to release all LP rows that it has created or captured.
2868  */
2869 
2870 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
2871 /**@page PROP How to add propagators
2872  *
2873  * Propagators are used to tighten the domains of the variables. Like for cutting planes, there are two different types
2874  * of domain propagations. Constraint based (primal) domain propagation algorithms are part of the corresponding
2875  * constraint handlers, see \ref CONSPROP. In contrast, domain propagators usually provide dual propagations, i.e.,
2876  * propagations that can be applied using the objective function and the current best known primal solution. This
2877  * section deals with such propagators.
2878  *
2879  * A complete list of all propagators contained in this release can be found \ref PROPAGATORS "here".
2880  *
2881  * We now explain how users can add their own propagators. Take the pseudo objective function propagator
2882  * (src/scip/prop_pseudoobj.c) as an example. As all other default plugins, it is written in C. C++ users can easily
2883  * adapt the code by using the scip::ObjProp wrapper base class and implement the @c scip_...() virtual methods instead
2884  * of the @c SCIP_DECL_PROP... callback methods.
2885  *
2886  * Additional documentation for the callback methods of a propagator can be found in the file type_prop.h.
2887  *
2888  * Here is what you have to do to implement a propagator:
2889  * -# Copy the template files src/scip/prop_xyz.c and src/scip/prop_xyz.h into files named "prop_mypropagator.c"
2890  * and "prop_mypropagator.h".
2891  * \n
2892  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2893  * -# Use SCIPincludePropMypropagator() in order to include the propagator into your SCIP instance,
2894  * e.g., in the main file of your project (see, e.g., src/main.c in the Coloring example).
2895  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mypropagator".
2896  * -# Adjust the properties of the propagator (see \ref PROP_PROPERTIES).
2897  * -# Define the propagator data (see \ref PROP_DATA). This is optional.
2898  * -# Implement the interface methods (see \ref PROP_INTERFACE).
2899  * -# Implement the fundamental callback methods (see \ref PROP_FUNDAMENTALCALLBACKS).
2900  * -# Implement the additional callback methods (see \ref PROP_ADDITIONALCALLBACKS). This is optional.
2901  *
2902  * @section PROP_PROPERTIES Properties of a Propagator
2903  *
2904  * At the top of the new file "prop_mypropagator.c" you can find the propagator properties. These are given as compiler
2905  * defines. The presolving-related properties are optional,
2906  * they only have to be defined if the propagator supports presolving routines.
2907  * In the C++ wrapper class, you have to provide the propagator properties by calling the constructor of the
2908  * abstract base class scip::ObjProp from within your constructor. The properties you have the following meaning:
2909  *
2910  * @subsection PROP_FUNDAMENTALPROPERTIES Fundamental properties of a propagator
2911  *
2912  * \par PROP_NAME: the name of the propagator.
2913  * This name is used in the interactive shell to address the propagator. Additionally, if you are searching for a
2914  * propagator with SCIPfindProp(), this name is searched for. Names have to be unique: no two propagators may have the
2915  * same name.
2916  *
2917  * \par PROP_DESC: the description of the propagator.
2918  * This string is printed as a description of the propagator in the interactive shell.
2919  *
2920  * \par PROP_PRIORITY: the priority of the propagator.
2921  * In each propagation round, the propagators and propagation methods of the constraint handlers are called in a
2922  * predefined order, which is given by the priorities of the propagators and the check priorities of the constraint
2923  * handlers. First, the propagators with non-negative priority are called in order of decreasing priority. Next, the
2924  * propagation methods of the different constraint handlers are called in order of decreasing check priority. Finally,
2925  * the propagators with negative priority are called in order of decreasing priority. \n The priority of the
2926  * propagators should be set according to the complexity of the propagation algorithm and the impact of the domain
2927  * propagations: propagators providing fast algorithms that usually have a high impact (i.e., tighten many bounds)
2928  * should have a high priority.
2929  *
2930  * \par PROP_FREQ: the default frequency for propagating domains.
2931  * The frequency defines the depth levels at which the propagation method \ref PROPEXEC is called. For example, a
2932  * frequency of 7 means, that the propagation callback is executed for subproblems that are in depth 0, 7, 14, ... of
2933  * the branching tree. A frequency of 0 means that propagation is only applied in preprocessing and at the root node. A
2934  * frequency of -1 disables the propagator.
2935  * \n
2936  * The frequency can be adjusted by the user. This property of the propagator only defines the default value of the
2937  * frequency.\n
2938  * <b>Note:</b> If you want to have a more flexible control of when to execute the propagation algorithm, you have to
2939  * assign a frequency of 1 and implement a check at the beginning of your propagation algorithm whether you really want
2940  * to execute the domain propagation or not. If you do not want to execute it, set the result code to SCIP_DIDNOTRUN.
2941  *
2942  * \par PROP_DELAY: the default for whether the propagation method should be delayed, if other propagators or constraint handlers found domain reductions.
2943  * If the propagator's propagation method is marked to be delayed, it is only executed after no other propagator or
2944  * constraint handler found a domain reduction in the current iteration of the domain propagation loop. If the
2945  * propagation method of the propagator is very expensive, you may want to mark it to be delayed until all cheap
2946  * propagation methods have been executed.
2947  *
2948  * \par PROP_TIMING: the timing mask of the propagator.
2949  * SCIP calls the domain propagation routines at different places in the node processing loop.
2950  * This property indicates at which places the propagator is called.
2951  * Possible values are defined in type_timing.h and can be concatenated, e.g., as in SCIP_PROPTIMING_ALWAYS.
2952  *
2953  * @subsection PROP_ADDITIONALPROPERTIES Optional propagator properties
2954  *
2955  * The following properties are optional and only need to be defined if the propagator supports
2956  * presolving, that is, if the \ref PROPPRESOL "presolving callback" is implemented.
2957  *
2958  * \par PROP_PRESOL_PRIORITY: the priority of the presolving method.
2959  * This attribute is analogous to the PROP_PRIORITY flag, but deals with the preprocessing method of the presolver.
2960  *
2961  * \par PROP_PRESOL_MAXROUNDS: the default maximal number of presolving rounds the propagator participates in.
2962  * The preprocessing is executed in rounds.
2963  * If enough changes have been applied to the model, an additional preprocessing round is performed.
2964  * The MAXROUNDS parameter of a propagator denotes the maximal number of preprocessing rounds, the propagator
2965  * participates in.
2966  * A value of -1 means, that there is no limit on the number of rounds.
2967  * A value of 0 means, the preprocessing callback of the propagator is disabled.
2968  *
2969  * \par PROP_PRESOL_DELAY: the default for whether the presolving method should be delayed, if other propagators or constraint handlers found presolving reductions.
2970  * This property is analogous to the PROP_DELAY flag, but deals with the preprocessing method of the propagator.
2971  *
2972  * @section PROP_DATA Propagator Data
2973  *
2974  * Below the title "Data structures" you can find a struct called <code>struct SCIP_PropData</code>. In this data
2975  * structure, you can store the data of your propagator. For example, you should store the adjustable parameters of the
2976  * propagator in this data structure. If you are using C++, you can add propagator data as object variables to your
2977  * class as usual .
2978  * \n
2979  * Defining propagator data is optional. You can leave the struct empty.
2980  *
2981  *
2982  * @section PROP_INTERFACE Interface Methods
2983  *
2984  * At the bottom of "prop_mypropagator.c", you can find the interface method SCIPincludeSepaMypropagator(),
2985  * which also appears in "prop_mypropagator.h"
2986  * SCIPincludePropMypropagator() is called by the user, if (s)he wants to include the propagator,
2987  * i.e., if (s)he wants to use the propagator in his/her application.
2988  *
2989  * This method only has to be adjusted slightly.
2990  * It is responsible for notifying SCIP of the presence of the propagator. For this, you can either call SCIPincludeProp(),
2991  * or SCIPincludePropBasic() since SCIP version 3.0. In the latter variant, \ref PROP_ADDITIONALCALLBACKS "additional callbacks"
2992  * must be added via setter functions as, e.g., SCIPsetPropCopy(). We recommend this latter variant because
2993  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
2994  * variant must be manually adjusted with every SCIP release containing new callbacks for separators in order to compile.
2995  *
2996  *
2997  * If you are using propagator data, you have to allocate the memory for the data at this point. You can do this by
2998  * calling
2999  * \code
3000  * SCIP_CALL( SCIPallocMemory(scip, &propdata) );
3001  * \endcode
3002  * You also have to initialize the fields in <code>struct SCIP_PropData</code> afterwards.
3003  *
3004  * You may also add user parameters for your propagator, see the method SCIPincludePropPseudoobj() in
3005  * src/scip/prop_pseudoobj.c for an example.
3006  *
3007  *
3008  * @section PROP_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Propagator
3009  *
3010  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
3011  * an operational algorithm.
3012  * They are passed together with the propagator itself to SCIP using SCIPincludeProp() or SCIPincludePropBasic(),
3013  * see @ref PROP_INTERFACE.
3014  *
3015  * Propagator plugins have one fundamental callback method, namely the \ref PROPEXEC method
3016  * method. This method has to be implemented for every propagator; the other callback methods are optional. In the
3017  * C++ wrapper class scip::ObjProp, the scip_exec() method (which corresponds to the \ref PROPEXEC
3018  * callback) is a virtual abstract member function. You have to
3019  * implement it in order to be able to construct an object of your propagator class.
3020  *
3021  * Additional documentation for the callback methods can be found in type_prop.h.
3022  *
3023  * @subsection PROPEXEC
3024  *
3025  * The PROPEXEC callback is called during presolving and during the subproblem processing. It should perform the actual
3026  * domain propagation, which means that it should tighten the variables' bounds. The technique of domain propagation,
3027  * which is the main workhorse of constraint programming, is called "node preprocessing" in the Integer Programming
3028  * community.
3029  *
3030  * The PROPEXEC callback has the following options:
3031  * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
3032  * - reducing (i.e, tightening) the domains of some variables (result SCIP_REDUCEDDOM)
3033  * - stating that the propagator searched, but did not find domain reductions, cutting planes, or cut constraints
3034  * (result SCIP_DIDNOTFIND)
3035  * - stating that the propagator was skipped (result SCIP_DIDNOTRUN)
3036  * - stating that the propagator was skipped, but should be called again (result SCIP_DELAYED)
3037  *
3038  *
3039  *
3040  * @section PROP_ADDITIONALCALLBACKS Additional Callback Methods of a Propagator
3041  *
3042  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
3043  * implemented for most applications, they can be used, for example, to initialize and free private data.
3044  * Additional callbacks can either be passed directly with SCIPincludeProp() to SCIP or via specific
3045  * <b>setter functions</b> after a call of SCIPincludePropBasic(), see also @ref PROP_INTERFACE.
3046  *
3047  * @subsection PROPRESPROP
3048  *
3049  * If the propagator wants to support \ref CONF "conflict analysis", it has to supply the PROPRESPROP method. It also should call
3050  * SCIPinferVarLbProp() or SCIPinferVarUbProp() in the domain propagation instead of SCIPchgVarLb() or SCIPchgVarUb() in
3051  * order to deduce bound changes on variables. In the SCIPinferVarLbProp() and SCIPinferVarUbProp() calls, the
3052  * propagator provides a pointer to itself and an integer value "inferinfo" that can be arbitrarily chosen.
3053  *
3054  * The propagation conflict resolving method PROPRESPROP must then be implemented to provide the "reasons" for the bound
3055  * changes, i.e., the bounds of variables at the time of the propagation, which forced the propagator to set the
3056  * conflict variable's bound to its current value. It can use the "inferinfo" tag to identify its own propagation rule
3057  * and thus identify the "reason" bounds. The bounds that form the reason of the assignment must then be provided by
3058  * calls to SCIPaddConflictLb() and SCIPaddConflictUb() in the propagation conflict resolving method.
3059  *
3060  * See the description of the propagation conflict resolving method \ref CONSRESPROP of constraint handlers for
3061  * further details.
3062  *
3063  * Omitting the PROPRESPROP callback circumvents the implementation of the usually rather complex conflict resolving method.
3064  * Yet, it
3065  * will make the conflict analysis less effective. We suggest to first omit the conflict resolving method and check how
3066  * effective the propagation method is. If it produces a lot of propagations for your application, you definitely should
3067  * consider implementing the conflict resolving method.
3068  *
3069  *
3070  * @subsection PROPFREE
3071  *
3072  * If you are using propagator data, you have to implement this method in order to free the propagator data.
3073  * This can be done by the following procedure:
3074  * \code
3075  * static
3076  * SCIP_DECL_PROPFREE(propFreeMypropagator)
3077  * {
3078  * SCIP_PROPDATA* propdata;
3079  *
3080  * propdata = SCIPpropGetData(prop);
3081  * assert(propdata != NULL);
3082  *
3083  * SCIPfreeMemory(scip, &propdata);
3084  *
3085  * SCIPpropSetData(prop, NULL);
3086  *
3087  * return SCIP_OKAY;
3088  * }
3089  * \endcode
3090  * If you have allocated memory for fields in your propagator data, remember to free this memory
3091  * before freeing the propagator data itself.
3092  * If you are using the C++ wrapper class, this method is not available.
3093  * Instead, just use the destructor of your class to free the member variables of your class.
3094  *
3095  * @subsection PROPINIT
3096  *
3097  * The PROPINIT callback is executed after the problem is transformed. The propagator may, e.g., use this call to
3098  * initialize its propagator data.
3099  *
3100  * @subsection PROPCOPY
3101  *
3102  * The PROPCOPY callback is executed when a SCIP instance is copied, e.g. to
3103  * solve a sub-SCIP. By
3104  * defining this callback as
3105  * <code>NULL</code> the user disables the execution of the specified
3106  * propagator for all copied SCIP instances. This may deteriorate the performance
3107  * of primal heuristics using sub-SCIPs.
3108  *
3109  * @subsection PROPEXIT
3110  *
3111  * The PROPEXIT callback is executed before the transformed problem is freed.
3112  * In this method, the propagator should free all resources that have been allocated for the solving process in PROPINIT.
3113  *
3114  * @subsection PROPINITPRE
3115  *
3116  * The PROPINITPRE callback is executed before the preprocessing is started, even if presolving is turned off.
3117  * The propagator may use this call to initialize its presolving data before the presolving process begins.
3118  *
3119  * @subsection PROPEXITPRE
3120  *
3121  * The PROPEXITPRE callback is executed after the preprocessing has been finished, even if presolving is turned off.
3122  * The propagator may use this call, e.g., to clean up its presolving data.
3123  * Besides clean up, no time consuming operations should be done.
3124  *
3125  * @subsection PROPINITSOL
3126  *
3127  * The PROPINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
3128  * begin.
3129  * The propagator may use this call to initialize its branch-and-bound specific data.
3130  *
3131  * @subsection PROPEXITSOL
3132  *
3133  * The PROPEXITSOL callback is executed before the branch-and-bound process is freed.
3134  * The propagator should use this call to clean up its branch-and-bound data.
3135  *
3136  * @subsection PROPPRESOL
3137  *
3138  * Seaches for domain propagations, analogous to the \ref PROPEXEC callback.
3139  * However, this callback is called during preprocessing.
3140  *
3141  * To inform SCIP that the presolving method found a reduction the result pointer has to be set in a proper way.
3142  * The following options are possible:
3143  *
3144  * - SCIP_UNBOUNDED : at least one variable is not bounded by any constraint in objective direction
3145  * - SCIP_CUTOFF : at least one domain reduction that renders the problem infeasible has been found
3146  * - SCIP_SUCCESS : the presolver found a domain reduction
3147  * - SCIP_DIDNOTFIND : the presolver searched, but did not find a presolving change
3148  * - SCIP_DIDNOTRUN : the presolver was skipped
3149  * - SCIP_DELAYED : the presolver was skipped, but should be called again
3150  *
3151  *
3152  * Please see also the @ref PROP_ADDITIONALPROPERTIES section to learn about the properties
3153  * PROP_PRESOL_PRIORITY, PROP_PRESOL_MAXROUNDS, and PROP_PRESOL_DELAY, which influence the behaviour of SCIP
3154  * calling PROPPRESOL.
3155  *
3156  */
3157 
3158 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
3159 /**@page BRANCH How to add branching rules
3160  *
3161  * Branching rules are used to split the problem at the current node into smaller subproblems. Branching rules can be called at three
3162  * different occasions, which is why they have three different execution methods (see \ref
3163  * BRANCHRULE_ADDITIONALCALLBACKS). Branching is performed if:
3164  * - the LP solution of the current problem is fractional. In this case, the integrality constraint handler calls the
3165  * \ref BRANCHEXECLP methods of the branching rules.
3166  * - the list of external branching candidates is not empty. This will only be the case if branching candidates were added
3167  * by a user's \ref RELAX "relaxation handler" or \ref CONS "constraint handler" plugin, calling SCIPaddExternBranchCand().
3168  * These branching candidates should be processed by the \ref BRANCHEXECEXT method.
3169  * - if an integral solution violates one or more constraints and this infeasibility could not be resolved in the callback methods
3170  * \ref CONSENFOLP and \ref CONSENFOPS of the corresponding constraint handlers. In this case, the \ref BRANCHEXECPS method will be called. This is the
3171  * standard case, if you use SCIP as a pure CP or SAT solver. If the LP or any other type of relaxation is used, then
3172  * branching on pseudo solutions works as a last resort.
3173  *
3174  * The idea of branching rules is to take a global view on the problem. In contrast, branching paradigms which are
3175  * specific to one type of constraint are best implemented within the enforcement callbacks of your constraint handler.
3176  * See, e.g., the constraint specific branching rules provided by the constraint handlers for special ordered sets
3177  * (src/scip/cons_sos{1,2}.c)).
3178  * \n
3179  * All branching rules that come with the default distribution of SCIP create two subproblems by splitting a single
3180  * variable's domain. It is, however, fully supported to implement much more general branching schemes, for example by
3181  * creating more than two subproblems, or by adding additional constraints to the subproblems instead of tightening the
3182  * domains of the variables.
3183  * \n
3184  * A complete list of all branching rules contained in this release can be found \ref BRANCHINGRULES "here".
3185  *
3186  * We now explain how users can add their own branching rules. Take the most infeasible LP branching rule
3187  * (src/scip/branch_mostinf.c) as an example. As all other default plugins, it is written in C. C++ users can easily
3188  * adapt the code by using the scip::ObjBranchrule wrapper base class and implement the scip_...() virtual methods instead of
3189  * the SCIP_DECL_BRANCH... callback methods.
3190  *
3191  * Additional documentation for the callback methods of a branching rule can be found in the file type_branch.h.
3192  *
3193  * Here is what you have to do to implement a branching rule:
3194  * -# Copy the template files src/scip/branch_xyz.c and src/scip/branch_xyz.h into files named
3195  * "branch_mybranchingrule.c" and "branch_mybranchingrule.h".
3196  * \n
3197  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
3198  * -# Use SCIPincludeBranchruleMybranchingrule() in order to include the branching rule into your SCIP instance,
3199  * e.g., in the main file of your project (see, e.g., src/main.c in the Coloring example).
3200  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mybranchingrule".
3201  * -# Adjust the properties of the branching rule (see \ref BRANCHRULE_PROPERTIES).
3202  * -# Define the branching rule data (see \ref BRANCHRULE_DATA). This is optional.
3203  * -# Implement the interface methods (see \ref BRANCHRULE_INTERFACE).
3204  * -# Implement the fundamental callback methods (see \ref BRANCHRULE_FUNDAMENTALCALLBACKS).
3205  * -# Implement the additional callback methods (see \ref BRANCHRULE_ADDITIONALCALLBACKS). This is optional.
3206  *
3207  *
3208  * @section BRANCHRULE_PROPERTIES Properties of a Branching Rule
3209  *
3210  * At the top of the new file "branch_mybranchingrule.c" you can find the branching rule properties.
3211  * These are given as compiler defines.
3212  * In the C++ wrapper class, you have to provide the branching rule properties by calling the constructor
3213  * of the abstract base class scip::ObjBranchrule from within your constructor.
3214  * The properties you have to set have the following meaning:
3215  *
3216  * \par BRANCHRULE_NAME: the name of the branching rule.
3217  * This name is used in the interactive shell to address the branching rule.
3218  * Additionally, if you are searching for a branching rule with SCIPfindBranchrule(), this name is looked up.
3219  * Names have to be unique: no two branching rules may have the same name.
3220  *
3221  * \par BRANCHRULE_DESC: the description of the branching rule.
3222  * This string is printed as a description of the branching rule in the interactive shell.
3223  *
3224  * \par BRANCHRULE_PRIORITY: the default value for the priority of the branching rule.
3225  * In the subproblem processing, the branching rules are called in decreasing order of their priority until
3226  * one succeeded to branch. Since most branching rules are able to generate a branching in all situations,
3227  * only the rule of highest priority is used. In combination with the BRANCHRULE_MAXDEPTH and
3228  * BRANCHRULE_MAXBOUNDDIST settings, however, interesting strategies can be easily employed. For example,
3229  * the user can set the priority of the "full strong branching" strategy to the highest value and assign the
3230  * second highest value to the "reliable pseudo cost" rule. If (s)he also sets the maximal depth for the
3231  * "full strong branching" to 5, in the top 5 depth levels of the search tree the "full strong branching" is
3232  * applied, while in the deeper levels "reliable pseudo cost branching" is used.
3233  * \n
3234  * Note that the BRANCHRULE_PRIORITY property only specifies the default value of the priority. The user can
3235  * change this value arbitrarily.
3236  *
3237  * \par BRANCHRULE_MAXDEPTH: the default value for the maximal depth level of the branching rule.
3238  * This parameter denotes the maximal depth level in the branch-and-bound tree up to which the branching method of the
3239  * branching rule will be applied. Use -1 for no limit.
3240  * \n
3241  * Note that this property only specifies the default value. The user can change this value arbitrarily.
3242  *
3243  * \par BRANCHRULE_MAXBOUNDDIST: the default value for the maximal relative distance from current node's dual bound to primal bound compared to best node's dual bound for applying branching.
3244  * At the current branch-and-bound node, the relative distance from its dual bound (local dual bound)
3245  * to the primal bound compared to the best node's dual bound (global dual bound) is considered. The branching method of
3246  * the branching rule will only be applied at the node if this relative distance does not exceed BRANCHRULE_MAXBOUNDDIST.
3247  * \n
3248  * For example, if the global dual bound is 50 and the primal bound is 60, BRANCHRULE_MAXBOUNDDIST = 0.25 means that
3249  * branching is only applied if the current node's dual bound is in the first quarter of the interval [50,60], i.e., if it
3250  * is less than or equal to 52.5. In particular, the values 0.0 and 1.0 mean that the branching rule is applied at the
3251  * current best node only or at all nodes, respectively.
3252  * \n
3253  * Note that the BRANCHRULE_MAXBOUNDDIST property only specifies the default value of the maximal bound distance.
3254  * The user can change this value arbitrarily.
3255  *
3256  *
3257  * @section BRANCHRULE_DATA Branching Rule Data
3258  *
3259  * Below the header "Data structures" you can find a struct which is called "struct SCIP_BranchruleData".
3260  * In this data structure, you can store the data of your branching rule. For example, you should store the adjustable
3261  * parameters of the branching rule in this data structure.
3262  * If you are using C++, you can add branching rule data as usual as object variables to your class.
3263  * \n
3264  * Defining branching rule data is optional. You can leave the struct empty.
3265  *
3266  *
3267  * @section BRANCHRULE_INTERFACE Interface Methods
3268  *
3269  * At the bottom of "branch_mybranchingrule.c", you can find the interface method SCIPincludeBranchruleMybranchingrule(),
3270  * which also appears in "branch_mybranchingrule.h"
3271  * SCIPincludeBranchruleMybranchingrule() is called by the user, if (s)he wants to include the branching rule,
3272  * i.e., if (s)he wants to use the branching rule in his/her application.
3273  *
3274  * This method only has to be adjusted slightly.
3275  * It is responsible for notifying SCIP of the presence of the branching rule. For this, you can either call
3276  * SCIPincludeBranchrule(),
3277  * or SCIPincludeBranchruleBasic() since SCIP version 3.0. In the latter variant, \ref BRANCHRULE_ADDITIONALCALLBACKS "additional callbacks"
3278  * must be added via setter functions as, e.g., SCIPsetBranchruleCopy(). We recommend this latter variant because
3279  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
3280  * variant must be manually adjusted with every SCIP release containing new callbacks for branchrule in order to compile.
3281  *
3282  *
3283  * If you are using branching rule data, you have to allocate the memory for the data at this point.
3284  * You can do this by calling:
3285  * \code
3286  * SCIP_CALL( SCIPallocMemory(scip, &branchruledata) );
3287  * \endcode
3288  * You also have to initialize the fields in struct SCIP_BranchruleData afterwards.
3289  *
3290  * You may also add user parameters for your branching rule, see the method SCIPincludeBranchruleRelpscost() in
3291  * src/scip/branch_relpscost.c for an example.
3292  *
3293  *
3294  * @section BRANCHRULE_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Branching Rule
3295  *
3296  * Branching rules do not have any fundamental callback methods, i.e., all callback methods are optional.
3297  * In most cases, however, you want to implement the \ref BRANCHEXECLP method and sometimes the \ref BRANCHEXECPS method.
3298  *
3299  *
3300  * @section BRANCHRULE_ADDITIONALCALLBACKS Additional Callback Methods of a Branching Rule
3301  *
3302  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
3303  * implemented for most applications, they can be used, for example, to initialize and free private data.
3304  * Additional callbacks can either be passed directly with SCIPincludeBranchrule() to SCIP or via specific
3305  * <b>setter functions</b> after a call of SCIPincludeBranchruleBasic(), see also @ref BRANCHRULE_INTERFACE.
3306  *
3307  * The most important callback methods are the \ref BRANCHEXECLP, \ref BRANCHEXECEXT,
3308  * and \ref BRANCHEXECPS methods, which perform the actual task of generating a branching.
3309  *
3310  * Additional documentation for the callback methods can be found in type_branch.h.
3311  *
3312  * @subsection BRANCHEXECLP
3313  *
3314  * The BRANCHEXECLP callback is executed during node processing if a fractional LP solution is available. It should
3315  * split the current problem into smaller subproblems. Usually, the branching is done in a way such that the current
3316  * fractional LP solution is no longer feasible in the relaxation of the subproblems. It is, however, possible to
3317  * create a child node for which the fractional LP solution is still feasible in the relaxation, for example, by
3318  * branching on a variable with integral LP value. In every case, you have to make sure that each subproblem is a
3319  * proper restriction of the current problem. Otherwise, you risk to produce an infinite path in the search tree.
3320  *
3321  * The user gains access to the branching candidates, i.e., to the fractional variables, and their LP solution values by
3322  * calling the method SCIPgetLPBranchCands(). Furthermore, SCIP provides two methods for performing the actual
3323  * branching, namely SCIPbranchVar() and SCIPcreateChild().
3324  *
3325  * Given an integral variable \f$x\f$ with fractional LP solution value \f$x^*\f$, the method SCIPbranchVar() creates
3326  * two child nodes; one contains the bound \f$x \le \lfloor x^* \rfloor\f$ and the other one contains the bound \f$x \ge
3327  * \lceil x^* \rceil\f$, see the BRANCHEXECLP callback in src/scip/branch_mostinf.c for an example. In addition, if a
3328  * proven lower objective bound of a created child node is known, like after strong branching has been applied, the user
3329  * may call the method SCIPupdateNodeLowerbound() in order to update the child node's lower bound.
3330  *
3331  * Please also see the \ref BRANCHEXEC "further information for the three execution methods".
3332  *
3333  * @subsection BRANCHEXECEXT
3334  *
3335  * The BRANCHEXECEXT callback is executed during node processing if no LP solution is available and the list of
3336  * external branching candidates is not empty. It should split the current problem into smaller subproblems. If you
3337  * do not use relaxation handlers or constraints handlers that provide external branching candidates, you do not need to
3338  * implement this callback.
3339  *
3340  * In contrast to the LP branching candidates and the pseudo branching candidates, the list of external branching
3341  * candidates will not be generated automatically. The user has to add all variables to the list by calling
3342  * SCIPaddExternBranchCand() for each of them. Usually, this will happen in the execution method of a relaxation handler or in the
3343  * enforcement methods of a constraint handler.
3344  *
3345  * The user gains access to these branching candidates by calling the method SCIPgetExternBranchCands(). Furthermore,
3346  * SCIP provides two methods for performing the actual branching with a given solution value, namely SCIPbranchVarVal()
3347  * and SCIPcreateChild(). SCIPbranchVarVal() allows users to specify the branching point for a variable in contrast to
3348  * SCIPbranchVar(), which will always use the current LP or pseudo solution.
3349  *
3350  * This paragraph contains additional information regarding how the method SCIPbranchVarVal() works. For external branching candidates,
3351  * there are three principle possibilities:
3352  * - Given a continuous variable \f$x\f$ with solution value \f$x^*\f$, the method SCIPbranchVarVal() creates
3353  * two child nodes; one contains the bound \f$x \le x^* \f$ and the other one contains the bound \f$x \ge x^* \f$.
3354  * - Given an integer variable \f$x\f$ with fractional solution value \f$x^*\f$, the method
3355  * SCIPbranchVarVal() creates two child nodes; one contains the bound \f$x \le \lfloor x^* \rfloor\f$ and the other
3356  * one contains the bound \f$x \ge \lceil x^* \rceil\f$.
3357  * - Given an integer variable \f$x\f$ with integral solution value \f$x^*\f$, the method SCIPbranchVarVal()
3358  * creates three child nodes; one contains the bound \f$x \le x^* -1\f$, one contains the bound \f$x \ge x^* +1\f$,
3359  * one contains the fixing \f$x = x^*\f$.
3360  *
3361  * See the BRANCHEXECEXT callback in src/scip/branch_random.c for an example. In addition, if a proven lower bound of a
3362  * created child node is known the user may call the method SCIPupdateNodeLowerbound() in order to update the child
3363  * node's lower bound.
3364  *
3365  * Please also see the \ref BRANCHEXEC "further information for the three execution methods".
3366  *
3367  * @subsection BRANCHEXECPS
3368  *
3369  * The BRANCHEXECPS callback is executed during node processing if no LP solution is available and at least one of the
3370  * integer variables is not yet fixed. It should split the current problem into smaller subproblems. PS stands for
3371  * pseudo solution which is the vector of all variables set to their locally best (w.r.t. the objective function)
3372  * bounds.
3373  *
3374  * The user gains access to the branching candidates, i.e., to the non-fixed integer variables, by calling the method
3375  * SCIPgetPseudoBranchCands(). Furthermore, SCIP provides two methods for performing the actual branching, namely
3376  * SCIPbranchVar() and SCIPcreateChild().
3377  *
3378  * Given an integer variable \f$x\f$ with bounds \f$[l,u]\f$ and not having solved the LP, the method SCIPbranchVar()
3379  * creates two child nodes:
3380  * - If both bounds are finite, then the two children will contain the domain reductions \f$x \le x^*\f$, and \f$x \ge
3381  * x^*+1\f$ with \f$x^* = \lfloor \frac{l + u}{2}\rfloor\f$. The current pseudo solution will remain feasible in one
3382  * of the branches, but the hope is that halving the domain's size leads to good propagations.
3383  * - If only one of the bounds is finite, the variable will be fixed to that bound in one of the child nodes. In the
3384  * other child node, the bound will be shifted by one.
3385  * - If both bounds are infinite, three children will be created: \f$x \le 1\f$, \f$x \ge 1\f$, and \f$x = 0\f$.
3386 
3387  *
3388  * See the BRANCHEXECPS callback in src/scip/branch_random.c for an example. In addition, if a proven lower bound of a
3389  * created child node is known, the user may call the method SCIPupdateNodeLowerbound() in order to update the child
3390  * node's lower bound.
3391  *
3392  * Please also see the \ref BRANCHEXEC "further information for the three execution methods".
3393  *
3394  * @subsection BRANCHEXEC Further information for the three execution methods
3395  *
3396  * In order to apply more general branching schemes, one should use the method SCIPcreateChild().
3397  * After having created a child node, the additional restrictions of the child node have to be added with calls to
3398  * SCIPaddConsNode(), SCIPchgVarLbNode(), or SCIPchgVarUbNode().
3399  * \n
3400  * In the method SCIPcreateChild(), the branching rule has to assign two values to the new nodes: a node selection
3401  * priority for each node and an estimate for the objective value of the best feasible solution contained in the subtree
3402  * after applying the branching. If the method SCIPbranchVar() is used, these values are automatically assigned. For
3403  * variable based branching schemes, one might use the methods SCIPcalcNodeselPriority() and the method
3404  * SCIPcalcChildEstimate().
3405  *
3406  * In some cases, the branching rule can tighten the current subproblem instead of producing a branching. For example,
3407  * strong branching might have proven that rounding up a variable would lead to an infeasible LP relaxation and thus,
3408  * the variable must be rounded down. Therefore, the BRANCHEXECLP, BRANCHEXECPS and BRANCHEXECREL callbacks may also
3409  * produce domain reductions or add additional constraints to the current subproblem.
3410  *
3411  * The execution callbacks have the following options:
3412  * - detecting that the node is infeasible and can be cut off (result SCIP_CUTOFF)
3413  * - adding an additional constraint (e.g. a conflict constraint) (result SCIP_CONSADDED; note that this action
3414  * must not be performed if the input "allowaddcons" is FALSE)
3415  * - reducing the domain of a variable such that the current LP solution becomes infeasible (result SCIP_REDUCEDDOM)
3416  * - applying a branching (result SCIP_BRANCHED)
3417  * - stating that the branching rule was skipped (result SCIP_DIDNOTRUN).
3418  *
3419  * Only the BRANCHEXECLP callback has the possibility to add a cutting plane to the LP (result SCIP_SEPARATED).
3420  *
3421  * @subsection BRANCHFREE
3422  *
3423  * If you are using branching rule data, you have to implement this method in order to free the branching rule data.
3424  * This can be done by the following procedure:
3425  * \code
3426  * static
3427  * SCIP_DECL_BRANCHFREE(branchFreeMybranchingrule)
3428  * {
3429  * SCIP_BRANCHRULEDATA* branchruledata;
3430  *
3431  * branchruledata = SCIPbranchruleGetData(branchrule);
3432  * assert(branchruledata != NULL);
3433  *
3434  * SCIPfreeMemory(scip, &branchruledata);
3435  *
3436  * SCIPbranchruleSetData(branchrule, NULL);
3437  *
3438  * return SCIP_OKAY;
3439  * }
3440  * \endcode
3441  * If you have allocated memory for fields in your branching rule data, remember to free this memory
3442  * before freeing the branching rule data itself.
3443  * If you are using the C++ wrapper class, this method is not available.
3444  * Instead, just use the destructor of your class to free the member variables of your class.
3445  *
3446  * @subsection BRANCHINIT
3447  *
3448  * The BRANCHINIT callback is executed after the problem is transformed.
3449  * The branching rule may, e.g., use this call to initialize its branching rule data.
3450  *
3451  * @subsection BRANCHCOPY
3452  *
3453  * The BRANCHCOPY callback is executed when a SCIP instance is copied, e.g. to
3454  * solve a sub-SCIP. By
3455  * defining this callback as
3456  * <code>NULL</code> the user disables the execution of the specified
3457  * branching rule for all copied SCIP instances. This may deteriorate the performance
3458  * of primal heuristics using sub-SCIPs.
3459  *
3460  * @subsection BRANCHEXIT
3461  *
3462  * The BRANCHEXIT callback is executed before the transformed problem is freed.
3463  * In this method, the branching rule should free all resources that have been allocated for the solving process in
3464  * BRANCHINIT.
3465  *
3466  * @subsection BRANCHINITSOL
3467  *
3468  * The BRANCHINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
3469  * begin.
3470  * The branching rule may use this call to initialize its branch-and-bound specific data.
3471  *
3472  * @subsection BRANCHEXITSOL
3473  *
3474  * The BRANCHEXITSOL callback is executed before the branch-and-bound process is freed.
3475  * The branching rule should use this call to clean up its branch-and-bound data.
3476  */
3477 
3478 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
3479 /**@page NODESEL How to add node selectors
3480  *
3481  * Node selectors are used to decide which of the leaves in the current branching tree is selected as next subproblem
3482  * to be processed. The ordering relation of the tree's leaves for storing them in the leaf priority queue is also
3483  * defined by the node selectors.
3484  * \n
3485  * A complete list of all node selectors contained in this release can be found \ref NODESELECTORS "here".
3486  *
3487  * We now explain how users can add their own node selectors.
3488  * Take the node selector for depth first search (src/scip/nodesel_dfs.c) as an example.
3489  * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjNodesel wrapper
3490  * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_NODESEL... callback methods.
3491  *
3492  * Additional documentation for the callback methods of a node selector can be found in the file type_nodesel.h.
3493  *
3494  * Here is what you have to do to implement a node selector:
3495  * -# Copy the template files src/scip/nodesel_xyz.c and src/scip/nodesel_xyz.h into files named "nodesel_mynodeselector.c"
3496  * and "nodesel_mynodeselector.h".
3497  * \n
3498  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
3499  * -# Use SCIPincludeNodeselMynodeselector() in oder to include the node selector into your SCIP instance,
3500  * e.g., in the main file of your project (see, e.g., src/main.c in the Coloring example).
3501  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mynodeselector".
3502  * -# Adjust the properties of the node selector (see \ref NODESEL_PROPERTIES).
3503  * -# Define the node selector data (see \ref NODESEL_DATA). This is optional.
3504  * -# Implement the interface methods (see \ref NODESEL_INTERFACE).
3505  * -# Implement the fundamental callback methods (see \ref NODESEL_FUNDAMENTALCALLBACKS).
3506  * -# Implement the additional callback methods (see \ref NODESEL_ADDITIONALCALLBACKS). This is optional.
3507  *
3508  *
3509  * @section NODESEL_PROPERTIES Properties of a Node Selector
3510  *
3511  * At the top of the new file "nodesel_mynodeselector.c" you can find the node selector properties.
3512  * These are given as compiler defines.
3513  * In the C++ wrapper class, you have to provide the node selector properties by calling the constructor
3514  * of the abstract base class scip::ObjNodesel from within your constructor.
3515  * The properties you have to set have the following meaning:
3516  *
3517  * \par NODESEL_NAME: the name of the node selector.
3518  * This name is used in the interactive shell to address the node selector.
3519  * Additionally, if you are searching for a node selector with SCIPfindNodesel(), this name is looked up.
3520  * Names have to be unique: no two node selectors may have the same name.
3521  *
3522  * \par NODESEL_DESC: the description of the node selector.
3523  * This string is printed as a description of the node selector in the interactive shell.
3524  *
3525  * \par NODESEL_STDPRIORITY: the default priority of the node selector in the standard mode.
3526  * The first step of each iteration of the main solving loop is the selection of the next subproblem to be processed.
3527  * The node selector of highest priority (the active node selector) is called to do this selection.
3528  * In particular, if you implemented your own node selector plugin which you want to be applied, you should choose a priority
3529  * which is greater then all priorities of the SCIP default node selectors.
3530  * Note that SCIP has two different operation modes: the standard mode and the memory saving mode. If the memory
3531  * limit - given as a parameter by the user - is almost reached, SCIP switches from the standard mode to the memory saving
3532  * mode in which different priorities for the node selectors are applied. NODESEL_STDPRIORITY is the priority of the
3533  * node selector used in the standard mode.
3534  * \n
3535  * Note that this property only defines the default value of the priority. The user may change this value arbitrarily by
3536  * adjusting the corresponding parameter setting.
3537  *
3538  * \par NODESEL_MEMSAVEPRIORITY: the default priority of the node selector in the memory saving mode.
3539  * The priority NODESEL_MEMSAVEPRIORITY of the node selector has the same meaning as the priority NODESEL_STDPRIORITY, but
3540  * is used in the memory saving mode.
3541  * Usually, you want the best performing node selector, for example best estimate search, to have maximal
3542  * standard priority, while you want a node selector which tends to keep the growth of the search tree limited, for example
3543  * depth first search, to have maximal memory saving priority.
3544  * \n
3545  * Note that this property only defines the default value of the priority. The user may change this value arbitrarily by
3546  * adjusting the corresponding parameter setting.
3547  *
3548  *
3549  * @section NODESEL_DATA Node Selector Data
3550  *
3551  * Below the header "Data structures" you can find a struct which is called "struct SCIP_NodeselData".
3552  * In this data structure, you can store the data of your node selector. For example, you should store the adjustable
3553  * parameters of the node selector in this data structure.
3554  * If you are using C++, you can add node selector data as usual as object variables to your class.
3555  * \n
3556  * Defining node selector data is optional. You can leave the struct empty.
3557  *
3558  *
3559  * @section NODESEL_INTERFACE Interface Methods
3560  *
3561  * At the bottom of "nodesel_mynodeselector.c", you can find the interface method SCIPincludeNodeselMynodeselector(),
3562  * which also appears in "nodesel_mynodeselector.h"
3563  * SCIPincludeNodeselMynodeselector() is called by the user, if (s)he wants to include the node selector,
3564  * i.e., if (s)he wants to use the node selector in his/her application.
3565  *
3566  * This method only has to be adjusted slightly.
3567  * It is responsible for notifying SCIP of the presence of the node selector. For this, you can either call
3568  * SCIPincludeNodesel(),
3569  * or SCIPincludeNodeselBasic() since SCIP version 3.0. In the latter variant, \ref NODESEL_ADDITIONALCALLBACKS "additional callbacks"
3570  * must be added via setter functions as, e.g., SCIPsetNodeselCopy(). We recommend this latter variant because
3571  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
3572  * variant must be manually adjusted with every SCIP release containing new callbacks for node selectors in order to compile.
3573  *
3574  *
3575  * If you are using node selector data, you have to allocate the memory for the data at this point.
3576  * You can do this by calling:
3577  * \code
3578  * SCIP_CALL( SCIPallocMemory(scip, &nodeseldata) );
3579  * \endcode
3580  * You also have to initialize the fields in struct SCIP_NodeselData afterwards.
3581  *
3582  * You may also add user parameters for your node selector, see the method SCIPincludeNodeselRestartdfs() in
3583  * src/scip/nodesel_restartdfs.c for an example.
3584  *
3585  *
3586  * @section NODESEL_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Node Selector
3587  *
3588  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
3589  * an operational algorithm.
3590  * They are passed together with the node selector itself to SCIP using SCIPincludeNodesel() or SCIPincludeNodeselBasic(),
3591  * see @ref NODESEL_INTERFACE.
3592  *
3593  * Node selector plugins have two fundamental callback methods, namely the NODESELSELECT method and the NODESELCOMP method.
3594  * These methods have to be implemented for every node selector; the other callback methods are optional.
3595  * They implement the two requirements every node selector has to fulfill: Selecting a node from the queue to be processed
3596  * next and, given two nodes, deciding which of both is favored by the node selector's selection rule. The first
3597  * task is implemented in the NODESELSELECT callback, the second one in the NODESELCOMP callback.
3598  * In the C++ wrapper class scip::ObjNodesel, the scip_select() method and the scip_comp() method (which correspond to the
3599  * NODESELSELECT callback and the NODESELCOMP callback, respectively) are virtual abstract member functions.
3600  * You have to implement them in order to be able to construct an object of your node selector class.
3601  *
3602  * Additional documentation for the callback methods can be found in type_nodesel.h.
3603  *
3604  * @subsection NODESELSELECT
3605  *
3606  * The NODESELSELECT callback is the first method called in each iteration in the main solving loop. It should decide
3607  * which of the leaves in the current branching tree is selected as the next subproblem to be processed.
3608  * It can arbitrarily decide between all leaves stored in the tree, but for performance reasons,
3609  * the current node's children and siblings are often treated different from the remaining leaves.
3610  * This is mainly due to the warm start capabilities of the simplex algorithm and the expectation that the bases of
3611  * neighboring vertices in the branching tree very similar.
3612  * The node selector's choice of the next node to process can
3613  * have a large impact on the solver's performance, because it influences the finding of feasible solutions and the
3614  * development of the global dual bound.
3615  *
3616  * Besides the ranking of the node selector, every node gets assigned a node selection priority by the branching rule
3617  * that created the node. See the \ref BRANCHEXECLP and \ref BRANCHEXECPS callbacks of the branching rules for details.
3618  * For example, the node where the branching went in the same way as the deviation from the branching variable's
3619  * root solution could be assigned a higher priority than the node where the branching went in the opposite direction.
3620  *
3621  * The following methods provide access to the various types of leaf nodes:
3622  * - SCIPgetPrioChild() returns the child of the current node with the largest node selection priority, as assigned by the
3623  * branching rule.
3624  * If no child is available (for example, because the current node was pruned), a NULL pointer is returned.
3625  * - SCIPgetBestChild() returns the best child of the current node with respect to the node selector's ordering relation as
3626  * defined by the \ref NODESELCOMP callback. If no child is available, a NULL pointer is returned.
3627  * - SCIPgetPrioSibling() returns the sibling of the current node with the largest node selection priority.
3628  * If no sibling is available (for example, because all siblings of the current node have already been processed), a NULL
3629  * pointer is returned.
3630  * Note that in binary branching every node has at most one sibling, but since SCIP supports arbitrary branching rules,
3631  * this might not always be the case.
3632  * - SCIPgetBestSibling() returns the best sibling of the current node with respect to the node selector's ordering relation
3633  * as defined by the \ref NODESELCOMP callback. If no sibling is available, a NULL pointer is returned.
3634  * - SCIPgetBestNode() returns the best leaf from the tree (children, siblings, or other leaves) with respect to the node
3635  * selector's ordering relation as defined by the \ref NODESELCOMP callback. If no open leaf exists, a NULL pointer is
3636  * returned. In this case, the optimization is finished, and the node selector should return a NULL pointer as 'selnode'.
3637  * - SCIPgetBestboundNode() returns a leaf from the tree (children, siblings, or other leaves) with the smallest lower (dual)
3638  * objective bound. If the queue is empty, a NULL pointer is returned. In this case, the optimization is finished, and the
3639  * node selector should return a NULL pointer as 'selnode'.
3640  *
3641  *
3642  * @subsection NODESELCOMP
3643  *
3644  * The NODESELCOMP callback is called to compare two leaves of the current branching tree (say node 1 and node 2)
3645  * regarding their ordering relation.
3646  *
3647  * The NODESELCOMP should return the following values:
3648  * - value < 0, if node 1 comes before (is better than) node 2
3649  * - value = 0, if both nodes are equally good
3650  * - value > 0, if node 1 comes after (is worse than) node 2.
3651  *
3652  * @section NODESEL_ADDITIONALCALLBACKS Additional Callback Methods of a Node Selector
3653  *
3654  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
3655  * implemented for most applications, they can be used, for example, to initialize and free private data.
3656  * Additional callbacks can either be passed directly with SCIPincludeNodesel() to SCIP or via specific
3657  * <b>setter functions</b> after a call of SCIPincludeNodeselBasic(), see also @ref NODESEL_INTERFACE.
3658  *
3659  * @subsection NODESELFREE
3660  *
3661  * If you are using node selector data, you have to implement this method in order to free the node selector data.
3662  * This can be done by the following procedure:
3663  * \code
3664  * static
3665  * SCIP_DECL_NODESELFREE(nodeselFreeMynodeselector)
3666  * {
3667  * SCIP_NODESELDATA* nodeseldata;
3668  *
3669  * nodeseldata = SCIPnodeselGetData(nodesel);
3670  * assert(nodeseldata != NULL);
3671  *
3672  * SCIPfreeMemory(scip, &nodeseldata);
3673  *
3674  * SCIPnodeselSetData(nodesel, NULL);
3675  *
3676  * return SCIP_OKAY;
3677  * }
3678  * \endcode
3679  * If you have allocated memory for fields in your node selector data, remember to free this memory
3680  * before freeing the node selector data itself.
3681  * If you are using the C++ wrapper class, this method is not available.
3682  * Instead, just use the destructor of your class to free the member variables of your class.
3683  *
3684  * @subsection NODESELINIT
3685  *
3686  * The NODESELINIT callback is executed after the problem is transformed.
3687  * The node selector may, e.g., use this call to initialize its node selector data.
3688  *
3689  * @subsection NODESELCOPY
3690  *
3691  * The NODESELCOPY callback is executed when a SCIP instance is copied, e.g. to
3692  * solve a sub-SCIP. By
3693  * defining this callback as
3694  * <code>NULL</code> the user disables the execution of the specified
3695  * node selector for all copied SCIP instances. This may deteriorate the performance
3696  * of primal heuristics using sub-SCIPs.
3697  *
3698  * @subsection NODESELEXIT
3699  *
3700  * The NODESELEXIT callback is executed before the transformed problem is freed.
3701  * In this method, the node selector should free all resources that have been allocated for the solving process
3702  * in NODESELINIT.
3703  *
3704  * @subsection NODESELINITSOL
3705  *
3706  * The NODESELINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
3707  * begin.
3708  * The node selector may use this call to initialize its branch-and-bound specific data.
3709  *
3710  * @subsection NODESELEXITSOL
3711  *
3712  * The NODESELEXITSOL callback is executed before the branch-and-bound process is freed.
3713  * The node selector should use this call to clean up its branch-and-bound data.
3714  */
3715 
3716 
3717 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
3718 /**@page HEUR How to add primal heuristics
3719  *
3720  * Feasible solutions can be found in two different ways during the traversal of the branch-and-bound tree. On one
3721  * hand, the solution of a node's relaxation may be feasible with respect to the constraints (including the integrality).
3722  * On the other hand, feasible solutions can be discovered by primal heuristics.
3723  * \n
3724  * A complete list of all primal heuristics contained in this release can be found \ref PRIMALHEURISTICS "here".
3725  *
3726  * We now explain how users can add their own primal heuristics.
3727  * Take the simple and fast LP rounding heuristic (src/scip/heur_simplerounding.c) as an example.
3728  * The idea of simple rounding is to iterate over all fractional variables of an LP solution and round them down,
3729  * if the variables appears only with nonnegative coefficients in the system Ax <= b and round them up if
3730  * the variables appears only with nonpositive coefficients.
3731  * If one of both conditions applies for each of the fractional variables, this will give a feasible solution.
3732  * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjHeur wrapper
3733  * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_HEUR... callback methods.
3734  *
3735  * Additional documentation for the callback methods of a primal heuristic can be found in the file type_heur.h.
3736  *
3737  * Here is what you have to do to implement a primal heuristic:
3738  * -# Copy the template files src/scip/heur_xyz.c and src/scip/heur_xyz.h into files named "heur_myheuristic.c"
3739  * and "heur_myheuristic.h".
3740  * \n
3741  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
3742  * -# Use SCIPincludeHeurMyheuristic() in order to include the heuristic into your SCIP instance,
3743  * e.g., in the main file of your project (see, e.g., src/main.c in the Coloring example).
3744  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "myheuristic".
3745  * -# Adjust the properties of the primal heuristic (see \ref HEUR_PROPERTIES).
3746  * -# Define the primal heuristic data (see \ref HEUR_DATA). This is optional.
3747  * -# Implement the interface methods (see \ref HEUR_INTERFACE).
3748  * -# Implement the fundamental callback methods (see \ref HEUR_FUNDAMENTALCALLBACKS).
3749  * -# Implement the additional callback methods (see \ref HEUR_ADDITIONALCALLBACKS). This is optional.
3750  *
3751  *
3752  * @section HEUR_PROPERTIES Properties of a Primal Heuristic
3753  *
3754  * At the top of the new file "heur_myheuristic.c" you can find the primal heuristic properties.
3755  * These are given as compiler defines.
3756  * In the C++ wrapper class, you have to provide the primal heuristic properties by calling the constructor
3757  * of the abstract base class scip::ObjHeur from within your constructor.
3758  * Of course, all of them are of relevant, but the most important ones for controlling the performance
3759  * are usually HEUR_FREQ and HEUR_TIMING.
3760  * The properties you have to set have the following meaning:
3761  *
3762  * \par HEUR_NAME: the name of the primal heuristic.
3763  * This name is used in the interactive shell to address the primal heuristic.
3764  * Additionally, if you are searching for a primal heuristic with SCIPfindHeur(), this name is looked up.
3765  * Names have to be unique: no two primal heuristics may have the same name.
3766  *
3767  * \par HEUR_DESC: the description of the primal heuristic.
3768  * This string is printed as a description of the primal heuristic in the interactive shell when you call "display heuristics".
3769  *
3770  * \par HEUR_DISPCHAR: the display character of the primal heuristic.
3771  * In the interactive shell, this character is printed in the first column of a status information row, if the primal
3772  * heuristic found the feasible solution belonging to the primal bound. Note that a star '*' stands for an integral
3773  * LP-relaxation.
3774  * In order to avoid confusion, display characters should be unique: no two primal heuristics should have the same display character.
3775  * You can get a list of all primal heuristics along with their display characters by entering "display heuristics" in the
3776  * SCIP interactive shell.
3777  *
3778  * \par HEUR_PRIORITY: the priority of the primal heuristic.
3779  * At each of the different entry points of the primal heuristics during the solving process (see HEUR_TIMING), they are
3780  * called in decreasing order of their priority.
3781  * \n
3782  * The priority of a primal heuristic should be set according to the complexity of the heuristic and the likelihood to find
3783  * feasible solutions: primal heuristics that provide fast algorithms that often succeed in finding a feasible solution should have
3784  * a high priority (like simple rounding). In addition, the interaction between different types of primal heuristics should be taken into account.
3785  * For example, improvement heuristics, which try to generate improved solutions by inspecting one or more of the feasible
3786  * solutions that have already been found, should have a low priority (like Crossover which by default needs at least 3 feasible solutions).
3787  *
3788  * \par HEUR_FREQ: the default frequency for executing the primal heuristic.
3789  * The frequency together with the frequency offset (see HEUR_FREQOFS) defines the depth levels at which the execution
3790  * method of the primal heuristic \ref HEUREXEC is called. For example, a frequency of 7 together with a frequency offset
3791  * of 5 means, that the \ref HEUREXEC callback is executed for subproblems that are in depth 5, 12, 19, ... of the branching tree. A
3792  * frequency of 0 together with a frequency offset of 3 means, that the execution method is only called at those nodes that are in
3793  * depth level 3 (i.e., at most for \f$2^3 = 8\f$ nodes if binary branching is applied).
3794  * Typical cases are: A frequency of 0 and an offset of 0 which means that
3795  * the heuristic is only called at the root node and a frequency of -1 which disables the heuristic.
3796  * \n
3797  * The frequency can be adjusted by the user. This property of the primal heuristic only defines the default value of the
3798  * frequency. If you want to have a more flexible control of when to execute the primal heuristic, you have to assign
3799  * a frequency of 1 and implement a check at the beginning of your execution method whether you really want to search for feasible
3800  * solutions or not. If you do not want to execute the method, set the result code to SCIP_DIDNOTRUN.
3801  *
3802  * \par HEUR_FREQOFS: the frequency offset for executing the primal heuristic.
3803  * The frequency offset defines the depth of the branching tree at which the primal heuristic is executed for the first
3804  * time. For example, a frequency of 7 (see HEUR_FREQ) together with a frequency offset of 10 means, that the
3805  * callback is executed for subproblems that are in depth 10, 17, 24, ... of the branching tree. In particular, assigning
3806  * different offset values to heuristics of the same type, like diving heuristics, can be useful for evenly spreading the
3807  * application of these heuristics across the branch-and-bound tree.
3808  * Note that if the frequency is equal to 1, the heuristic is applied for all nodes with depth level larger or equal to
3809  * the frequency offset.
3810  *
3811  * \par HEUR_MAXDEPTH: the maximal depth level for executing the primal heuristic.
3812  * This parameter denotes the maximal depth level in the branching tree up to which the execution method of the primal
3813  * heuristic is called. Use -1 for no limit (a usual case).
3814  *
3815  * \par HEUR_TIMING: the execution timing of the primal heuristic.
3816  * Primal heuristics have different entry points during the solving process and the execution timing parameter defines the
3817  * entry point at which the primal heuristic is executed first.
3818  * \n
3819  * The primal heuristic can be called first:
3820  * - before the processing of the node starts (SCIP_HEURTIMING_BEFORENODE)
3821  * - after each LP solve during the cut-and-price loop (SCIP_HEURTIMING_DURINGLPLOOP)
3822  * - after the cut-and-price loop was finished (SCIP_HEURTIMING_AFTERLPLOOP)
3823  * - after the processing of a node <em>with solved LP</em> was finished (SCIP_HEURTIMING_AFTERLPNODE)
3824  * - after the processing of a node <em>without solved LP</em> was finished (SCIP_HEURTIMING_AFTERPSEUDONODE)
3825  * - after the processing of the last node in the current plunge was finished, <em>and only if the LP was solved for
3826  * this node</em> (SCIP_HEURTIMING_AFTERLPPLUNGE)
3827  * - after the processing of the last node in the current plunge was finished, <em>and only if the LP was not solved
3828  * for this node</em> (SCIP_HEURTIMING_AFTERPSEUDOPLUNGE).
3829  * \par
3830  * A plunge is the successive solving of child and sibling nodes in the search tree.
3831  * The flags listed above can be combined to call the heuristic at multiple times by concatenating them with a bitwise OR.
3832  * Two useful combinations are already predefined:
3833  * - after the processing of a node was finished (SCIP_HEURTIMING_AFTERNODE; combines SCIP_HEURTIMING_AFTERLPNODE and
3834  * SCIP_HEURTIMING_AFTERPSEUDONODE)
3835  * - after the processing of the last node in the current plunge was finished (SCIP_HEURTIMING_AFTERPLUNGE; combines
3836  * SCIP_HEURTIMING_AFTERLPPLUNGE and SCIP_HEURTIMING_AFTERPSEUDOPLUNGE)
3837  * \par
3838  * Calling a primal heuristic "before the processing of the node starts" is particularly useful for heuristics
3839  * that do not need to access the LP solution of the current node. If such a heuristic finds a feasible solution, the
3840  * leaves of the branching tree exceeding the new primal bound are pruned. It may happen that even the current node can
3841  * be cut off without solving the LP relaxation. Combinatorial heuristics, like the farthest insert heuristic for the TSP
3842  * (see examples/TSP/src/HeurFarthestInsert.cpp), are often applicable at this point.
3843  * \n
3844  * Very fast primal heuristics that require an LP solution can also be called "after each LP solve during the
3845  * cut-and-price loop". Rounding heuristics, like the simple and fast LP rounding heuristic
3846  * (src/scip/heur_simplerounding.c), belong to this group of primal heuristics.
3847  * \n
3848  * Most heuristics, however, are called either after a node was completely processed
3849  * (e.g. expensive rounding heuristics like RENS), or even only after a full plunge was finished (e.g., diving heuristics).
3850  *
3851  * \par HEUR_USESSUBSCIP: Does the heuristic use a secondary SCIP instance?
3852  * Some heuristics and separators solve MIPs or SAT problems using a secondary SCIP instance. Examples are
3853  * Large Neighborhood Search heuristics such as RINS and Local Branching or the CGMIP separator. To avoid recursion,
3854  * these plugins usually deactivate all other plugins that solve MIPs. If a heuristic uses a secondary SCIP instance,
3855  * this parameter has to be TRUE and it is recommended to call SCIPsetSubscipsOff() for the secondary SCIP instance.
3856  *
3857  * Computational experiments indicate that for the overall performance of a MIP solver, it is important to evenly
3858  * spread the application of the heuristics across the branch-and-bound tree. Thus, the assignment of the parameters
3859  * HEUR_FREQ, HEUR_FREQOFS, and HEUR_TIMING should contribute to this aim.
3860  *
3861  * Note that all diving heuristics in the SCIP distribution (see, e.g., src/scip/heur_guideddiving.c) check whether other diving
3862  * heuristics have already been called at the current node. This can be done by comparing SCIPgetLastDivenode(scip) and
3863  * SCIPgetNNodes(scip). If the two are equal, and if the current node is not the root node (SCIPgetDepth(scip) > 0), diving
3864  * heuristics should be delayed by returning the result code 'SCIP_DELAYED'. This is an additional contribution to the goal of
3865  * not calling multiple similar heuristics at the same node.
3866  *
3867  *
3868  * @section HEUR_DATA Primal Heuristic Data
3869  *
3870  * Below the header "Data structures" you can find a struct which is called "struct SCIP_HeurData".
3871  * In this data structure, you can store the data of your primal heuristic. For example, you should store the adjustable
3872  * parameters of the primal heuristic or a working solution in this data structure.
3873  * If you are using C++, you can add primal heuristic data as usual as object variables to your class.
3874  * \n
3875  * Defining primal heuristic data is optional. You can leave the struct empty.
3876  *
3877  *
3878  * @section HEUR_INTERFACE Interface Methods
3879  *
3880  * At the bottom of "heur_myheuristic.c", you can find the interface method SCIPincludeHeurMyheuristic(),
3881  * which also appears in "heur_myheuristic.h"
3882  * SCIPincludeHeurMyheuristic() is called by the user, if (s)he wants to include the heuristic,
3883  * i.e., if (s)he wants to use the heuristic in his/her application.
3884  *
3885  * This method only has to be adjusted slightly.
3886  * It is responsible for notifying SCIP of the presence of the heuristic. For this, you can either call
3887  * SCIPincludeHeur(),
3888  * or SCIPincludeHeurBasic() since SCIP version 3.0. In the latter variant, \ref HEUR_ADDITIONALCALLBACKS "additional callbacks"
3889  * must be added via setter functions as, e.g., SCIPsetHeurCopy(). We recommend this latter variant because
3890  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
3891  * variant must be manually adjusted with every SCIP release containing new callbacks for heuristics in order to compile.
3892  *
3893  * If you are using primal heuristic data, you have to allocate the memory for the data at this point.
3894  * You can do this by calling:
3895  * \code
3896  * SCIP_CALL( SCIPallocMemory(scip, &heurdata) );
3897  * \endcode
3898  * You also have to initialize the fields in struct SCIP_HeurData afterwards.
3899  *
3900  * You may also add user parameters for your primal heuristic, see the method SCIPincludeHeurFeaspump() in
3901  * src/scip/heur_oneopt.c for an example where a single Boolean parameter is added.
3902  *
3903  *
3904  * @section HEUR_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Primal Heuristic
3905  *
3906  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
3907  * an operational algorithm.
3908  * They are passed together with the primal heuristic itself to SCIP using SCIPincludeHeur() or SCIPincludeHeurBasic(),
3909  * see @ref HEUR_INTERFACE.
3910  *
3911  *
3912  * Primal heuristic plugins have only one fundamental callback method, namely the HEUREXEC method.
3913  * This method has to be implemented for every primal heuristic; the other callback methods are optional.
3914  * In the C++ wrapper class scip::ObjHeur, the scip_exec() method (which corresponds to the HEUREXEC callback) is a virtual
3915  * abstract member function. You have to implement it in order to be able to construct an object of your primal heuristic
3916  * class.
3917  *
3918  * Additional documentation for the callback methods can be found in type_heur.h.
3919  *
3920  * @subsection HEUREXEC
3921  *
3922  * The HEUREXEC callback is called at different positions during the node processing loop, see HEUR_TIMING. It should
3923  * search for feasible solutions and add them to the solution pool. For creating a new feasible solution, the
3924  * methods SCIPcreateSol() and SCIPsetSolVal() can be used. Afterwards, the solution can be added to the storage by
3925  * calling the method SCIPtrySolFree() (or SCIPtrySol() and SCIPfreeSol()).
3926  *
3927  * The HEUREXEC callback gets a SCIP pointer, a pointer to the heuristic itself, the current point in the
3928  * solve loop and a result pointer as input (see type_heur.h).
3929  *
3930  * The heuristic has to set the result pointer appropriately!
3931  * Therefore it has the following options:
3932  * - finding at least one feasible solution (result SCIP_FOUNDSOL)
3933  * - stating that the primal heuristic searched, but did not find a feasible solution (result SCIP_DIDNOTFIND)
3934  * - stating that the primal heuristic was skipped (result SCIP_DIDNOTRUN)
3935  * - stating that the primal heuristic was skipped, but should be called again (result SCIP_DELAYED).
3936  *
3937  *
3938  * @section HEUR_ADDITIONALCALLBACKS Additional Callback Methods of a Primal Heuristic
3939  *
3940  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
3941  * implemented for most applications, they can be used, for example, to initialize and free private data.
3942  * Additional callbacks can either be passed directly with SCIPincludeHeur() to SCIP or via specific
3943  * <b>setter functions</b> after a call of SCIPincludeHeurBasic(), see also @ref HEUR_INTERFACE.
3944  *
3945  * @subsection HEURFREE
3946  *
3947  * If you are using primal heuristic data, you have to implement this method in order to free the primal heuristic data.
3948  * This can be done by the following procedure:
3949  * \code
3950  * static
3951  * SCIP_DECL_HEURFREE(heurFreeMyheuristic)
3952  * {
3953  * SCIP_HEURDATA* heurdata;
3954  *
3955  * heurdata = SCIPheurGetData(heur);
3956  * assert(heurdata != NULL);
3957  *
3958  * SCIPfreeMemory(scip, &heurdata);
3959  *
3960  * SCIPheurSetData(heur, NULL);
3961  *
3962  * return SCIP_OKAY;
3963  * }
3964  * \endcode
3965  * If you have allocated memory for fields in your primal heuristic data, remember to free this memory
3966  * before freeing the primal heuristic data itself.
3967  * If you are using the C++ wrapper class, this method is not available.
3968  * Instead, just use the destructor of your class to free the member variables of your class.
3969  *
3970  * @subsection HEURINIT
3971  *
3972  * The HEURINIT callback is executed after the problem is transformed.
3973  * The primal heuristic may, e.g., use this call to initialize its primal heuristic data.
3974  *
3975  * @subsection HEURCOPY
3976  *
3977  * The HEURCOPY callback is executed when a SCIP instance is copied, e.g. to
3978  * solve a sub-SCIP. By
3979  * defining this callback as
3980  * <code>NULL</code> the user disables the execution of the specified
3981  * heuristic for all copied SCIP instances. This may deteriorate the performance
3982  * of primal heuristics using sub-SCIPs.
3983  *
3984  * @subsection HEUREXIT
3985  *
3986  * The HEUREXIT callback is executed before the transformed problem is freed.
3987  * In this method, the primal heuristic should free all resources that have been allocated for the solving process in
3988  * HEURINIT.
3989  *
3990  * @subsection HEURINITSOL
3991  *
3992  * The HEURINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
3993  * begin. The primal heuristic may use this call to initialize its branch-and-bound specific data.
3994  *
3995  * @subsection HEUREXITSOL
3996  *
3997  * The HEUREXITSOL callback is executed before the branch-and-bound process is freed. The primal heuristic should use this
3998  * call to clean up its branch-and-bound data, which was allocated in HEURINITSOL.
3999  */
4000 
4001 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
4002 /**@page RELAX How to add relaxation handlers
4003  *
4004  * SCIP provides specific support for LP relaxations of constraint integer programs. In addition, relaxation handlers,
4005  * also called relaxators, can be used to include other relaxations, e.g. Lagrange relaxations or semidefinite
4006  * relaxations. The relaxation handler manages the necessary data structures and calls the relaxation solver to generate dual
4007  * bounds and primal solution candidates.
4008  * \n
4009  * However, the data to define a single relaxation must either be extracted by the relaxation handler itself (e.g., from
4010  * the user defined problem data, the LP information, or the integrality conditions), or be provided by the constraint
4011  * handlers. In the latter case, the constraint handlers have to be extended to support this specific relaxation.
4012  * \n
4013  *
4014  * We now explain how users can add their own relaxation handlers using the C interface. It is very easy to
4015  * transfer the C explanation to C++: whenever a method should be implemented using the SCIP_DECL_RELAX... notion,
4016  * reimplement the corresponding virtual member function of the abstract scip::ObjRelax wrapper base class.
4017  * Unfortunately, SCIP does not contain a default relaxation handler plugin, which could be used as an example.
4018  *
4019  * Additional documentation for the callback methods of a relaxation handler can be found in the file type_relax.h.
4020  *
4021  * Here is what you have to do to implement a relaxation handler:
4022  * -# Copy the template files src/scip/relax_xyz.c and src/scip/relax_xyz.h into files named "relax_myrelaxator.c"
4023  * and "relax_myrelaxator.h".
4024  * \n
4025  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
4026  * -# Use SCIPincludeRelaxMyrelaxator() in order to include the relaxation handler into your SCIP instance,
4027  * e.g, in the main file of your project (see, e.g., src/main.c in the Coloring example).
4028  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "myrelaxator".
4029  * -# Adjust the properties of the relaxation handler (see \ref RELAX_PROPERTIES).
4030  * -# Define the relaxation handler data (see \ref RELAX_DATA). This is optional.
4031  * -# Implement the interface methods (see \ref RELAX_INTERFACE).
4032  * -# Implement the fundamental callback methods (see \ref RELAX_FUNDAMENTALCALLBACKS).
4033  * -# Implement the additional callback methods (see \ref RELAX_ADDITIONALCALLBACKS). This is optional.
4034  *
4035  *
4036  * @section RELAX_PROPERTIES Properties of a Relaxation Handler
4037  *
4038  * At the top of the new file "relax_myrelaxator.c" you can find the relaxation handler properties.
4039  * These are given as compiler defines.
4040  * In the C++ wrapper class, you have to provide the relaxation handler properties by calling the constructor
4041  * of the abstract base class scip::ObjRelax from within your constructor.
4042  * The properties you have to set have the following meaning:
4043  *
4044  * \par RELAX_NAME: the name of the relaxation handler.
4045  * This name is used in the interactive shell to address the relaxation handler.
4046  * Additionally, if you are searching for a relaxation handler with SCIPfindRelax(), this name is looked up.
4047  * Names have to be unique: no two relaxation handlers may have the same name.
4048  *
4049  * \par RELAX_DESC: the description of the relaxation handler.
4050  * This string is printed as a description of the relaxation handler in the interactive shell.
4051  *
4052  * \par RELAX_PRIORITY: the priority of the relaxation handler.
4053  * During each relaxation solving round, the included relaxation handlers and the
4054  * price-and-cut loop for solving the LP relaxation are called in a predefined order, which is given by the priorities
4055  * of the relaxation handlers.
4056  * First, the relaxation handlers with non-negative priority are called in the order of decreasing priority.
4057  * Next, the price-and-cut loop for solving the LP relaxation is executed.
4058  * Finally, the relaxation handlers with negative priority are called in the order of decreasing priority.
4059  * \n
4060  * Usually, you will have only one relaxation handler in your application and thus only have to decide whether it should
4061  * be called before or after solving the LP relaxation. For this decision you should consider the complexity of
4062  * the relaxation solving algorithm and the impact of the resulting solution: if your relaxation handler provides a fast
4063  * algorithm that usually has a high impact (i.e. the relaxation is a good approximation of the
4064  * feasible region of the subproblem and the solution severely improves the dual bound), it should have a non-negative
4065  * priority.
4066  * \n
4067  * Note that for certain applications, it is useful to disable the LP relaxation and only use your custom relaxation.
4068  * This can easily be achieved by setting the "lp/solvefreq" parameter to -1.
4069  *
4070  * \par RELAX_FREQ: the default frequency for solving the relaxation.
4071  * The frequency defines the depth levels at which the relaxation solving method \ref RELAXEXEC is called.
4072  * For example, a frequency of 7 means, that the relaxation solving callback is executed for subproblems that are in depth
4073  * 0, 7, 14, ... of the branching tree. A frequency of 0 means that the callback is only executed at the root node, i.e.,
4074  * only the relaxation of the root problem is solved. A frequency of -1 disables the relaxation handler.
4075  *
4076  *
4077  * @section RELAX_DATA Relaxation Handler Data
4078  *
4079  * Below the header "Data structures" you can find a struct which is called "struct SCIP_RelaxData".
4080  * In this data structure, you can store the data of your relaxation handler. For example, you should store the adjustable
4081  * parameters of the relaxation handler in this data structure.
4082  * If you are using C++, you can add relaxation handler data as usual as object variables to your class.
4083  * \n
4084  * Defining relaxation handler data is optional. You can leave the struct empty.
4085  *
4086  *
4087  * @section RELAX_INTERFACE Interface Methods
4088  *
4089  * At the bottom of "relax_myrelaxator.c", you can find the interface method SCIPincludeRelaxMyrelaxator(),
4090  * which also appears in "relax_myrelaxator.h".
4091  * SCIPincludeRelaxMyrelaxator() is called by the user, if (s)he wants to include the relaxation handler,
4092  * i.e., if (s)he wants to use the relaxation handler in his/her application.
4093  *
4094  * This method only has to be adjusted slightly.
4095  * It is responsible for notifying SCIP of the presence of the relaxation handler. For this, you can either call
4096  * SCIPincludeRelax(),
4097  * or SCIPincludeRelaxBasic() since SCIP version 3.0. In the latter variant, \ref RELAX_ADDITIONALCALLBACKS "additional callbacks"
4098  * must be added via setter functions as, e.g., SCIPsetRelaxCopy(). We recommend this latter variant because
4099  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
4100  * variant must be manually adjusted with every SCIP release containing new callbacks for relaxation handlers in order to compile.
4101  *
4102  * If you are using relaxation handler data, you have to allocate the memory for the data at this point.
4103  * You can do this by calling:
4104  * \code
4105  * SCIP_CALL( SCIPallocMemory(scip, &relaxdata) );
4106  * \endcode
4107  * You also have to initialize the fields in struct SCIP_RelaxData afterwards.
4108  *
4109  * You may also add user parameters for your relaxation handler, see the method SCIPincludeConshdlrKnapsack() in
4110  * the \ref cons_knapsack.h "knapsack constraint handler" for an example of how to add user parameters.
4111  *
4112  *
4113  * @section RELAX_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Relaxation Handler
4114  *
4115  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
4116  * an operational algorithm.
4117  * They are passed together with the relaxation handler itself to SCIP using SCIPincludeRelax() or SCIPincludeRelaxBasic(),
4118  * see @ref RELAX_INTERFACE.
4119  *
4120  *
4121  * Relaxation handler plugins have only one fundamental callback method, namely the \ref RELAXEXEC method.
4122  * This method has to be implemented for every relaxation handler; the other callback methods are optional.
4123  * In the C++ wrapper class scip::ObjRelax, the scip_exec() method (which corresponds to the \ref RELAXEXEC callback) is a virtual
4124  * abstract member function.
4125  * You have to implement it in order to be able to construct an object of your relaxation handler class.
4126  *
4127  * Additional documentation for the callback methods can be found in type_relax.h.
4128  *
4129  * @subsection RELAXEXEC
4130  * The RELAXEXEC is called in each relaxation solving round. It should solve the current
4131  * subproblem's relaxation.
4132  *
4133  * Note that, like the LP relaxation, the relaxation handler should only operate on variables for which the corresponding
4134  * column exists in the transformed problem. Typical methods called by a relaxation handler are SCIPconstructLP() and SCIPflushLP() to
4135  * make sure that the LP of the current node is constructed and its data can be accessed via calls to SCIPgetLPRowsData()
4136  * and SCIPgetLPColsData(), SCIPseparateSol() to call the cutting plane separators for a given primal solution, and
4137  * SCIPupdateLocalLowerbound() to update the current node's dual bound after having solved the relaxation.
4138  * In addition, you may want to call SCIPtrySolFree() if you think that you have found a feasible primal solution.
4139  *
4140  * The primal solution of the relaxation can be stored inside the data structures of SCIP with
4141  * <code>SCIPsetRelaxSolVal()</code> and <code>SCIPsetRelaxSolVals()</code> and later accessed by
4142  * <code>SCIPgetRelaxSolVal()</code>.
4143  * Furthermore, there is a list of external branching candidates, that can be filled by relaxation handlers and constraint handlers,
4144  * allowing branching rules to take these candidates as a guide on how to split the problem into subproblems.
4145  * Relaxation handlers should store appropriate candidates in this list using the method <code>SCIPaddExternBranchCand()</code>.
4146  *
4147  * Usually, the RELAXEXEC callback only solves the relaxation and provides a lower (dual) bound with a call to
4148  * SCIPupdateLocalLowerbound().
4149  * However, it may also produce domain reductions, add additional constraints or generate cutting planes. It has the
4150  * following options:
4151  * - detecting that the node is infeasible in the variable's bounds and can be cut off (result SCIP_CUTOFF)
4152  * - adding an additional constraint and stating that the relaxation handler should not be called again on the same
4153  * relaxation (result SCIP_CONSADDED)
4154  * - reducing a variable's domain and stating that the relaxation handler should not be called again on the same
4155  * relaxation (result SCIP_REDUCEDDOM)
4156  * - adding a cutting plane to the LP and stating that the relaxation handler should not be called again on the same
4157  * relaxation (result SCIP_SEPARATED)
4158  * - stating that the relaxation handler solved the relaxation and should not be called again on the same relaxation
4159  * (result SCIP_SUCCESS)
4160  * - interrupting the solving process to wait for additional input, e.g., cutting planes (result SCIP_SUSPENDED)
4161  * - stating that the separator was skipped (result SCIP_DIDNOTRUN).
4162  *
4163  * In the above criteria, "the same relaxation" means that the LP relaxation stayed unmodified. This means in particular
4164  * that no row has been added and no bounds have been modified. For example, changing the bounds of a variable will, as
4165  * long as it was a COLUMN variable, lead to a modification in the LP such that the relaxation handler is called again
4166  * after it returned with the result code SCIP_REDUCEDDOM.
4167  *
4168  *
4169  * @section RELAX_ADDITIONALCALLBACKS Additional Callback Methods of a Relaxation Handler
4170  *
4171  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
4172  * implemented for most applications, they can be used, for example, to initialize and free private data.
4173  * Additional callbacks can either be passed directly with SCIPincludeRelax() to SCIP or via specific
4174  * <b>setter functions</b> after a call of SCIPincludeRelaxBasic(), see also @ref RELAX_INTERFACE.
4175  *
4176  * @subsection RELAXFREE
4177  *
4178  * If you are using relaxation handler data, you have to implement this method in order to free the relaxation handler
4179  * data. This can be done by the following procedure:
4180  * \code
4181  * static
4182  * SCIP_DECL_RELAXFREE(relaxFreeMyrelaxator)
4183  * {
4184  * SCIP_RELAXDATA* relaxdata;
4185  *
4186  * relaxdata = SCIPrelaxGetData(relax);
4187  * assert(relaxdata != NULL);
4188  *
4189  * SCIPfreeMemory(scip, &relaxdata);
4190  *
4191  * SCIPrelaxSetData(relax, NULL);
4192  *
4193  * return SCIP_OKAY;
4194  * }
4195  * \endcode
4196  * If you have allocated memory for fields in your relaxation handler data, remember to free this memory
4197  * before freeing the relaxation handler data itself.
4198  * If you are using the C++ wrapper class, this method is not available.
4199  * Instead, just use the destructor of your class to free the member variables of your class.
4200  *
4201  * @subsection RELAXINIT
4202  *
4203  * The RELAXINIT callback is executed after the problem is transformed.
4204  * The relaxation handler may, e.g., use this call to initialize its relaxation handler data.
4205  *
4206  * @subsection RELAXCOPY
4207  *
4208  * The RELAXCOPY callback is executed when a SCIP instance is copied, e.g. to
4209  * solve a sub-SCIP. By
4210  * defining this callback as
4211  * <code>NULL</code> the user disables the execution of the specified
4212  * relaxation handler for all copied SCIP instances. This may deteriorate the performance
4213  * of primal heuristics using sub-SCIPs.
4214  *
4215  * @subsection RELAXEXIT
4216  *
4217  * The RELAXEXIT callback is executed before the transformed problem is freed.
4218  * In this method, the relaxation handler should free all resources that have been allocated for the solving process in
4219  * RELAXINIT.
4220  *
4221  * @subsection RELAXINITSOL
4222  *
4223  * The RELAXINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
4224  * begin. The relaxation handler may use this call to initialize its branch-and-bound specific data.
4225  *
4226  * @subsection REALXEXITSOL
4227  *
4228  * The RELAXEXITSOL callback is executed before the branch-and-bound process is freed.
4229  * The relaxation handler should use this call to clean up its branch-and-bound data.
4230  */
4231 
4232 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
4233 /**@page READER How to add file readers
4234  *
4235  * Mainly, file readers are called to parse an input file and generate a constraint integer programming model. They
4236  * create constraints and variables and activate variable pricers if necessary. However, they can also be called, for
4237  * example, to parse an input file containing information about a primal solution or fixing of variables. Besides that
4238  * it is possible to use some of them for writing (exporting) the problem in a specific format. \n A complete list of
4239  * all file readers contained in this release can be found \ref FILEREADERS "here".
4240  *
4241  * Since a file reader is also responsible for writing a file, the user may
4242  * ask why the readers have not the name "filehandler". This name would
4243  * represent this plugin much better than the used one.
4244  * \n
4245  * The used name "readers" is historically grown. In the beginning of SCIP
4246  * there was no need to write/export problems. Therefore, the the plugin
4247  * name "readers" was best fitting for this plugin since only reading was essential.
4248  * It turned out, however, that it is quite nice to write/export certain subproblem during
4249  * the solving process mainly for debugging. Therefore, a writing callback
4250  * was added to the "readers" plugin.
4251  *
4252  * We now explain how users can add their own file readers.
4253  * Take the file reader for MIPs in IBM's Mathematical Programming System format (src/scip/reader_mps.c) as an example.
4254  * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjReader wrapper
4255  * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_READER... callback methods.
4256  *
4257  * Additional documentation for the callback methods of a file reader can be found in the file type_reader.h.
4258  *
4259  * Here is what you have to do to implement a file reader named "myreader" in C:
4260  * -# Copy the template files src/scip/reader_xyz.c and src/scip/reader_xyz.h into files named
4261  * "reader_myreader.c" and "reader_myreader.h".
4262  * \n
4263  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
4264  * -# Use SCIPincludeReaderMyreader() in order to include the file reader into your SCIP instance,
4265  * e.g., in the main file of your project (see, e.g., src/main.c in the Coloring example).
4266  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "myreader".
4267  * -# Adjust the \ref READER_PROPERTIES "properties of the file reader".
4268  * -# Define the \ref READER_DATA "file reader data". This is optional.
4269  * -# Implement the \ref READER_INTERFACE "interface methods".
4270  * -# Implement the \ref READER_FUNDAMENTALCALLBACKS "fundamental callback methods".
4271  * -# Implement the \ref READER_ADDITIONALCALLBACKS "additional callback methods". This is optional.
4272  *
4273  *
4274  * @section READER_PROPERTIES Properties of a File Reader
4275  *
4276  * At the top of the new file "reader_myreader.c" you can find the file reader properties.
4277  * These are given as compiler defines.
4278  * In the C++ wrapper class, you have to provide the file reader properties by calling the constructor
4279  * of the abstract base class scip::ObjReader from within your constructor.
4280  * The properties you have to set have the following meaning:
4281  *
4282  * \par READER_NAME: the name of the file reader.
4283  * This name is used in the interactive shell to address the file reader.
4284  * Additionally, if you are searching for a file reader with SCIPfindReader(), this name is looked up.
4285  * Names have to be unique: no two file readers may have the same name.
4286  *
4287  * \par READER_DESC: the description of the file reader.
4288  * This string is printed as a description of the file reader in the interactive shell.
4289  *
4290  * \par READER_EXTENSION: the file name extension of the file reader.
4291  * Each file reader is hooked to a single file name extension. It is automatically called if the user wants to read in a
4292  * file of corresponding name. The extensions of the different file readers have to be unique.
4293  * Note that the additional extension '.gz', '.z', or '.Z' (indicating a gzip compressed file) are ignored for assigning
4294  * an input file to a reader.
4295  * \n
4296  * It is not possible to hook up a (single) file reader with more than one file extension.
4297  * It is, however, not necessary to implement the same (parsing/writing) methods more than once, if you want to
4298  * support several file extension with the same parser. To do so look at the files reader_lp.c
4299  * and reader_rlp.c. Both support the LP format.
4300  *
4301  *
4302  * @section READER_DATA File Reader Data
4303  *
4304  * Below the header "Data structures" you can find a struct which is called "struct SCIP_ReaderData".
4305  * In this data structure, you can store the data of your file reader. For example, you should store the adjustable
4306  * parameters of the file reader in this data structure.
4307  * If you are using C++, you can add file reader data as usual as object variables to your class.
4308  * \n
4309  * Defining file reader data is optional. You can leave the struct empty.
4310  *
4311  *
4312  * @section READER_INTERFACE Interface Methods
4313  *
4314  * At the bottom of "reader_myreader.c", you can find the interface method SCIPincludeReaderMyreader(),
4315  * which also appears in "reader_myreader.h".
4316  * SCIPincludeReaderMyreader() is called by the user, if (s)he wants to include the reader,
4317  * i.e., if (s)he wants to use the reader in his/her application.
4318  *
4319  * This method only has to be adjusted slightly.
4320  * It is responsible for notifying SCIP of the presence of the reader. For this, you can either call
4321  * SCIPincludeReader(),
4322  * or SCIPincludeReaderBasic() since SCIP version 3.0. In the latter variant, \ref READER_ADDITIONALCALLBACKS "additional callbacks"
4323  * must be added via setter functions as, e.g., SCIPsetReaderCopy(). We recommend this latter variant because
4324  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
4325  * variant must be manually adjusted with every SCIP release containing new callbacks for readers in order to compile.
4326  *
4327  * If you are using file reader data, you have to allocate the memory for the data at this point.
4328  * You can do this by calling:
4329  * \code
4330  * SCIP_CALL( SCIPallocMemory(scip, &readerdata) );
4331  * \endcode
4332  * You also have to initialize the fields in struct SCIP_ReaderData afterwards.
4333  *
4334  * You may also add user parameters for your file reader, see the method SCIPincludeReaderLp() in
4335  * src/scip/reader_lp.c for an example.
4336  *
4337  *
4338  * @section READER_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a File Reader
4339  *
4340  * File reader plugins have no fundamental callback methods. This is due to
4341  * the fact that a file reader can be used for reading and/or writing a
4342  * file. A file reader is only useful if the reader method \ref READERREAD
4343  * and/or the writing method \ref READERWRITE is implemented. One of these
4344  * methods should be implemented for every file reader; the other callback
4345  * methods \ref READERCOPY and \ref READERFREE are optional. In the C++ wrapper class scip::ObjReader, the
4346  * scip_read() and scip_write() methods (which corresponds to the \ref
4347  * READERREAD and \ref READERWRITE callback) are virtual member
4348  * functions. At least one of them should be implemented.
4349  *
4350  * Additional documentation for the callback methods can be found in type_reader.h.
4351  *
4352  *
4353  * @section READER_ADDITIONALCALLBACKS Additional Callback Methods of a File Reader
4354  *
4355  * Additional callbacks can either be passed directly with SCIPincludeReader() to SCIP or via specific
4356  * <b>setter functions</b> after a call of SCIPincludeReaderBasic(), see also @ref READER_INTERFACE.
4357  *
4358  *
4359  * File reader plugins contain only additional callback methods, namely the methods \ref READERREAD,
4360  * \ref READERWRITE, \ref READERFREE, and \ref READERCOPY. Therefore, these are not needed to be implemented. However,
4361  * at least \ref READERREAD and/or \ref READERWRITE should be implemented (see notes
4362  * \ref READER_FUNDAMENTALCALLBACKS "above").
4363  *
4364  *
4365  * @subsection READERREAD
4366  *
4367  * The READERREAD callback is called when the user invokes SCIP to read in a file with file name extension
4368  * corresponding to the READER_EXTENSION property of the file reader. This is usually triggered by a call to the method
4369  * SCIPreadProb() or by an interactive shell command.
4370  * The READERREAD callback should parse the input file and perform the desired action, which usually means
4371  * generating a constraint integer programming model, adding a primal solution, fixing variables
4372  * in an existing model.
4373  * \n
4374  * Typical methods called by a file reader that is used to read/generate constraint
4375  * integer programming models are, for example,
4376  *
4377  * - creating an empty problem: SCIPcreateProb()
4378  * - creating the variables: SCIPcreateVar(), SCIPchgVarType(), SCIPchgVarLb(), SCIPchgVarUb(), SCIPaddVar(), and
4379  * SCIPreleaseVar()
4380  * - modifying the objective function: SCIPchgVarObj() and SCIPsetObjsense().
4381  * - creating the constraints: SCIPcreateConsLinear(), SCIPaddCoefLinear(), SCIPchgLhsLinear(), SCIPchgRhsLinear(),
4382  * SCIPaddCons(), and SCIPreleaseCons()
4383  *
4384  * Primal solutions can only be created for the transformed problem. Therefore, the user has to call SCIPtransformProb()
4385  * before (s)he reads in the file containing the solution and adds it to the solution pool via the method SCIPreadSol().
4386  *
4387  *
4388  * @subsection READERWRITE
4389  *
4390  * The READERWRITE callback is called when the user invokes SCIP to write a problem (original or transformed)
4391  * in the format the reader supports. This is only possible if this callback is implemented. To write the problem
4392  * all necessary information is given through the parameters of this callback method (see type_reader.h). This
4393  * information should be used to output the problem in the requested format. This callback method is usually
4394  * triggered by the call of the methods SCIPwriteOrigProblem(), SCIPwriteTransProblem(), SCIPprintOrigProblem(),
4395  * or SCIPprintTransProblem().
4396  * \n
4397  * A typical method called by a file reader which is used to write/export a constraint
4398  * integer programming model is SCIPinfoMessage(). This method outputs a given string into a file
4399  * or into stdout.
4400  * \n
4401  * For an example we refer to the writing method of the MPS reader (see reader_mps.c).
4402  *
4403  *
4404  * @subsection READERCOPY
4405  *
4406  * The READERCOPY callback is executed when a SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this
4407  * callback as <code>NULL</code> the user disables the execution of the specified reader for all copied SCIP
4408  * instances. The question might arise why to copy that plugin. In case of debugging it is nice to be able to
4409  * write/display the copied instances. Since the reader is in charge of that, you might want to copy the plugin. Below
4410  * you see a standard implementation.
4411  *
4412  * \code
4413  * static
4414  * SCIP_DECL_READERCOPY(readerCopyMyreader)
4415  * {
4416  * assert(scip != NULL);
4417  * assert(reader != NULL);
4418  * assert(strcmp(SCIPreaderGetName(reader), READER_NAME) == 0);
4419  *
4420  * SCIP_CALL( SCIPincludeReaderMyreader(scip) );
4421  *
4422  * return SCIP_OKAY;
4423  * }
4424  * \endcode
4425  *
4426  * @subsection READERFREE
4427  *
4428  * If you are using file reader data, you have to implement this method in order to free the file reader data.
4429  * This can be done by the following procedure:
4430  * \code
4431  * static
4432  * SCIP_DECL_READERFREE(readerFreeMyreader)
4433  * {
4434  * SCIP_READERDATA* readerdata;
4435  *
4436  * readerdata = SCIPreaderGetData(reader);
4437  * assert(readerdata != NULL);
4438  *
4439  * SCIPfreeMemory(scip, &readerdata);
4440  *
4441  * SCIPreaderSetData(reader, NULL);
4442  *
4443  * return SCIP_OKAY;
4444  * }
4445  * \endcode
4446  * If you have allocated memory for fields in your file reader data, remember to free this memory
4447  * before freeing the file reader data itself.
4448  * If you are using the C++ wrapper class, this method is not available.
4449  * Instead, just use the destructor of your class to free the member variables of your class.
4450  *
4451  */
4452 
4453 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
4454 /**@page DIALOG How to add dialogs
4455  *
4456  * SCIP comes with a command line shell which allows the user to read in problem instances, modify the solver's
4457  * parameters, initiate the optimization and display certain statistics and solution information. This shell consists
4458  * of dialogs, which are organized as a tree in SCIP. A node of this tree which is not a leaf represents a menu in
4459  * the shell and the children of this node correspond to the entries of this menu (which can again be menus). All
4460  * different dialogs are managed by a dialog handler, which, in particular, is responsible for executing the dialog
4461  * corresponding to the user's command in the shell. The concept of a dialog handler is different to that
4462  * of a constraint handler, which is used to manage objects of the same structure, see \ref CONS. In particular, SCIP
4463  * features only one dialog handler (dialog_default.h), whereas there may exist different constraint handlers.
4464  * \n
4465  * A complete list of all dialogs contained in this release can be found \ref DIALOGS "here".
4466  *
4467  * We now explain how users can extend the interactive shell by adding their own dialog.
4468  * We give the explanation for creating your own source file for each additional dialog. Of course, you can collect
4469  * different dialogs in one source file. Take src/scip/dialog_default.c, where all default dialog plugins are collected, as an
4470  * example.
4471  * As all other default plugins, the default dialog plugin and the template dialog are written in C. C++ users can easily
4472  * adapt the code by using the scip::ObjDialog wrapper base class and implement the scip_...() virtual methods instead of the
4473  * SCIP_DECL_DIALOG... callback methods.
4474  *
4475  * Additional documentation for the callback methods of a dialog can be found in the file type_dialog.h.
4476  *
4477  * Here is what you have to do to add a dialog (assuming your dialog is named "mydialog"):
4478  * -# Copy the template files src/scip/dialog_xyz.c and src/scip/dialog_xyz.h into files named "dialog_mydialog.c"
4479  * and "dialog_mydialog.h".
4480  * \n
4481  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
4482  * -# Use SCIPincludeDialogMydialog() in order to include the dialog handler into your SCIP instance,
4483  * e.g., in the main file of your project (see, e.g., src/main.c in the Coloring example).
4484  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mydialog".
4485  * -# Adjust the \ref DIALOG_PROPERTIES "properties of the dialog".
4486  * -# Define the \ref DIALOG_DATA "dialog data". This is optional.
4487  * -# Implement the \ref DIALOG_INTERFACE "interface methods".
4488  * -# Implement the \ref DIALOG_FUNDAMENTALCALLBACKS "fundamental callback methods".
4489  * -# Implement the \ref DIALOG_ADDITIONALCALLBACKS "additional callback methods". This is optional.
4490  *
4491  *
4492  * @section DIALOG_PROPERTIES Properties of a Dialog
4493  *
4494  * At the top of the new file "dialog_mydialog.c" you can find the dialog properties.
4495  * These are given as compiler defines.
4496  * In the C++ wrapper class, you have to provide the dialog properties by calling the constructor
4497  * of the abstract base class scip::ObjDialog from within your constructor.
4498  * The properties you have to set have the following meaning:
4499  *
4500  * \par DIALOG_NAME: the name of the dialog.
4501  * In the interactive shell, this name appears as the command name of the dialog in the parent dialog.
4502  * Additionally, if you are searching an entry in a menu with SCIPdialogFindEntry(), this name is looked up.
4503  * Names within one menu have to be unique: no two dialogs in the same menu may have the same name.
4504  *
4505  * \par DIALOG_DESC: the description of the dialog.
4506  * This string is printed as a description of the dialog in the interactive shell if the additional
4507  * callback method \ref DIALOGDESC is not implemented.
4508  *
4509  * \par DIALOG_ISSUBMENU: whether the dialog is a (sub)menu.
4510  * This parameter states whether the dialog is a menu in the interactive shell, i.e., is the parent of further
4511  * dialogs.
4512  *
4513  *
4514  * @section DIALOG_DATA Dialog Data
4515  *
4516  * Below the header "Data structures" you can find a struct which is called "struct SCIP_DialogData".
4517  * In this data structure, you can store the data of your dialog.
4518  * If you are using C++, you can add dialog data as usual as object variables to your class.
4519  * \n
4520  * Defining dialog data is optional. You can leave the struct empty.
4521  *
4522  *
4523  * @section DIALOG_INTERFACE Interface Methods
4524  *
4525  * At the bottom of "dialog_mydialog.c" you can find the interface method SCIPincludeDialogMydialog(), which also appears
4526  * in "dialog_mydialog.h".
4527  * \n
4528  * This method only has to be adjusted slightly.
4529  * It is responsible for notifying SCIP of the presence of the dialog, which can be done by the following lines of code:
4530  * \code
4531  * if( !SCIPdialogHasEntry(parentdialog, DIALOG_NAME) )
4532  * {
4533  * SCIP_CALL( SCIPcreateDialog(scip, &dialog, dialogExecMydialog, dialogDescMydialog, dialogFreeMydialog,
4534  * DIALOG_NAME, DIALOG_DESC, DIALOG_ISSUBMENU, dialogdata) );
4535  *
4536  * SCIP_CALL( SCIPaddDialogEntry(scip, parentdialog, dialog) );
4537  *
4538  * SCIP_CALL( SCIPreleaseDialog(scip, &dialog) );
4539  * }
4540  * \endcode
4541  * Here "parentdialog" has to be an existing dialog which is defined to be a menu (see DIALOG_ISSUBMENU), e.g.,
4542  * the default root dialog. The method SCIPgetRootDialog() returns the root dialog.
4543  *
4544  * The interface method is called by the user, if (s)he wants to include the dialog, i.e., if (s)he wants to use the dialog in
4545  * his/her application.
4546  * Note that in order to be able to link the new dialog to an existing default dialog
4547  * (except the root dialog) it has to be included <b>after the
4548  * default dialogs plugin</b>, i.e., the SCIPincludeDialogMydialog() call has to occur after the
4549  * SCIPincludeDialogDefault() call. The SCIPincludeDialogDefault() method is called from within the SCIPincludeDefaultPlugins()
4550  * method. Therefore, it suffices to include your dialog plugins after you have called SCIPincludeDefaultPlugins().
4551  * In case you want to add a dialog to the <b>root dialog</b>, you just use the following
4552  * lines of code to get/create the root dialog.
4553  *
4554  * \code
4555  * SCIP_DIALOG* root;
4556  *
4557  * root = SCIPgetRootDialog(scip);
4558  * if( root == NULL )
4559  * {
4560  * SCIP_CALL( SCIPcreateRootDialog(scip, &root) );
4561  * }
4562  * assert( root != NULL );
4563  * \endcode
4564  *
4565  * Therefore, in this case you do not have to worry about the calls of
4566  * SCIPincludeDialogDefault() and SCIPincludeDefaultPlugins() .
4567  *
4568  * If you are using dialog data, you have to allocate the memory for the data at this point.
4569  * You can do this by calling:
4570  * \code
4571  * SCIP_CALL( SCIPallocMemory(scip, &dialogdata) );
4572  * \endcode
4573  * You also have to initialize the fields in struct SCIP_DialogData afterwards.
4574  *
4575  * Consider the following example. The user wants to add a "drawgraph" command to the root menu of SCIP.
4576  * (S)he copies the "dialog_xyz.c" and "dialog_xyz.h" files into files "dialog_drawgraph.c" and "dialog_drawgraph.h", respectively.
4577  * Then, (s)he puts the following code into the SCIPincludeDialogDrawgraph() method, compare SCIPincludeDialogDefault() in
4578  * src/scip/dialog_default.c:
4579  * \code
4580  * SCIP_RETCODE SCIPincludeDialogDrawgraph(
4581  * SCIP* scip
4582  * )
4583  * {
4584  * SCIP_DIALOG* root;
4585  * SCIP_DIALOG* dialog;
4586  *
4587  * root = SCIPgetRootDialog(scip);
4588  * if( root == NULL )
4589  * {
4590  * SCIP_CALL( SCIPcreateRootDialog(scip, &root) );
4591  * }
4592  * assert( root != NULL );
4593  *
4594  * if( !SCIPdialogHasEntry(root, "drawgraph") )
4595  * {
4596  * SCIP_CALL( SCIPcreateDialog(scip, &dialog, SCIPdialogExecDrawgraph, NULL, NULL,
4597  * "drawgraph", "draws the graph for the current problem instance", FALSE, NULL) );
4598  * SCIP_CALL( SCIPaddDialogEntry(scip, root, dialog) );
4599  * SCIP_CALL( SCIPreleaseDialog(scip, &dialog) );
4600  * }
4601  *
4602  * return SCIP_OKAY;
4603  * }
4604  * \endcode
4605  *
4606  * Using this code, it is even possible to call SCIPincludeDialogDrawgraph() before including the default dialog plugins,
4607  * and you can also call it multiple times without causing inconsistencies in the dialog structure.
4608  *
4609  *
4610  * @section DIALOG_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Dialog
4611  *
4612  * Dialogs have only one fundamental callback method, namely the \ref DIALOGEXEC method.
4613  * This method has to be implemented for every dialog; the other callback methods are optional.
4614  * In the C++ wrapper class scip::ObjDialog, the scip_exec() method (which corresponds to the \ref DIALOGEXEC callback) is a virtual
4615  * abstract member function.
4616  * You have to implement it in order to be able to construct an object of your dialog class.
4617  *
4618  * Additional documentation for the callback methods can be found in type_dialog.h.
4619  *
4620  * @subsection DIALOGEXEC
4621  *
4622  * The DIALOGEXEC method is invoked, if the user selected the dialog's command name in the parent's menu. It should
4623  * execute what is stated in DIALOG_DESC, e.g., the display constraint handlers dialog should display information about
4624  * the constraint handlers included in SCIP, see src/scip/dialog_default.c.
4625  *
4626  * For typical methods called by the execution method, have a look at src/scip/dialog_default.c.
4627  *
4628  * The callback has to return which dialog should be processed next. This can be, for example, the root dialog
4629  * (SCIPdialoghdlrGetRoot()), the parent dialog (SCIPdialogGetParent()) or NULL, which stands for closing the interactive
4630  * shell.
4631  *
4632  *
4633  * @section DIALOG_ADDITIONALCALLBACKS Additional Callback Methods of a Dialog
4634  *
4635  * The additional callback methods do not need to be implemented in every case.
4636  * They can be used, for example, to free private data.
4637  *
4638  * @subsection DIALOGPFREE
4639  *
4640  * If you are using dialog data, you have to implement this method in order to free the dialog data.
4641  * This can be done by the following procedure:
4642  * \code
4643  * static
4644  * SCIP_DECL_DIALOGFREE(dialogFreeMydialog)
4645  * {
4646  * SCIP_DIALOGDATA* dialogdata;
4647  *
4648  * dialogdata = SCIPdialogGetData(dialog);
4649  * assert(dialogdata != NULL);
4650  *
4651  * SCIPfreeMemory(scip, &dialogdata);
4652  *
4653  * SCIPdialogSetData(dialog, NULL);
4654  *
4655  * return SCIP_OKAY;
4656  * }
4657  * \endcode
4658  * If you have allocated memory for fields in your dialog data, remember to free this memory
4659  * before freeing the dialog data itself.
4660  * If you are using the C++ wrapper class, this method is not available.
4661  * Instead, just use the destructor of your class to free the member variables of your class.
4662  *
4663  * @subsection DIALOGDESC
4664  *
4665  * This method is called when the help menu of the parent is displayed. It should output (usually a single line of)
4666  * information describing the meaning of the dialog.
4667  * \n
4668  * If this callback is not implemented, the description string of the dialog (DIALOG_DESC) is displayed instead.
4669  *
4670  * @subsection DIALOGCOPY
4671  *
4672  * The DIALOGCOPY callback is executed when a SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this
4673  * callback as <code>NULL</code> the user disables the execution of this dialog for all copied SCIP instances. In
4674  * general there is no need to copy any dialog since it is most unlikely to start the interactive shell of the copied
4675  * instances.
4676  *
4677  */
4678 
4679 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
4680 /**@page DISP How to add display columns
4681  *
4682  * While solving a constraint integer program, SCIP displays status information in a column-like fashion. The current
4683  * number of processed branching tree nodes, the solving time, and the relative gap between primal and dual bound are
4684  * examples of such display columns. There already exists a wide variety of display columns which can be activated or
4685  * deactivated on demand, see src/scip/disp_default.c. Additionally, the user can implement his/her own display columns
4686  * in order to track problem or algorithm specific values.
4687  * \n
4688  * A complete list of all displays contained in this release can be found \ref DISPLAYS "here".
4689  *
4690  * We now explain users can add their own display columns.
4691  * We give the explanation for creating your own source file for each additional display column. Of course, you can collect
4692  * different additional display columns in one source file.
4693  * Take src/scip/disp_default.c, where all default display columns are collected, as an example.
4694  * As all other default plugins, the default display column plugins and the display column template are written in C.
4695  * C++ users can easily adapt the code by using the scip::ObjDisp wrapper base class and implement the scip_...() virtual methods
4696  * instead of the SCIP_DECL_DISP... callback methods.
4697  *
4698  *
4699  * Additional documentation for the callback methods of a display column can be found in the file type_disp.h.
4700  *
4701  * Here is what you have to do to implement a display column (assuming your display column is named "mydisplaycolumn"):
4702  * -# Copy the template files src/scip/disp_xyz.c and src/scip/disp_xyz.h into files named "disp_mydisplaycolumn.c"
4703  * and "disp_mydisplaycolumn.h".
4704  \n
4705  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
4706  * -# Use SCIPincludeDispMydisplaycolumn() in order to include the display column into your SCIP instance,
4707  * e.g., in the main file of your project (see, e.g., src/main.c in the Coloring example).
4708  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mydisplaycolumn".
4709  * -# Adjust the \ref DISP_PROPERTIES "properties of the display column".
4710  * -# Define the \ref DISP_DATA "display column data". This is optional.
4711  * -# Implement the \ref DISP_INTERFACE "interface methods".
4712  * -# Implement the \ref DISP_FUNDAMENTALCALLBACKS "fundamental callback methods".
4713  * -# Implement the \ref DISP_ADDITIONALCALLBACKS "additional callback methods". This is optional.
4714  *
4715  *
4716  * @section DISP_PROPERTIES Properties of a Display Column
4717  *
4718  * At the top of the new file "disp_mydisplaycolumn.c" you can find the display column properties.
4719  * These are given as compiler defines.
4720  * In the C++ wrapper class, you have to provide the display column properties by calling the constructor
4721  * of the abstract base class scip::ObjDisp from within your constructor.
4722  * The properties you have to set have the following meaning:
4723  *
4724  * \par DISP_NAME: the name of the display column.
4725  * This name is used in the interactive shell to address the display column.
4726  * Additionally, if you are searching for a display column with SCIPfindDisp(), this name is looked up.
4727  * Names have to be unique: no two display columns may have the same name.
4728  *
4729  * \par DISP_DESC: the description of the display column.
4730  * This string is printed as a description of the display column in the interactive shell.
4731  *
4732  * \par DISP_HEADER: the header of the display column.
4733  * This string is printed as the header of the display column in the status information display.
4734  *
4735  * \par DISP_WIDTH: the width of the display column.
4736  * This parameter defines the width (number of characters) of the display column. The value of the parameter has to be
4737  * greater than or equal to the number of characters in the header string.
4738  *
4739  * \par DISP_PRIORITY: the priority of the display column.
4740  * The total width of status information lines is bounded by the parameter "display width". The display columns actually contained
4741  * in the status information display are selected in decreasing order of their priority. Furthermore, the user can force
4742  * columns to be displayed or not to be displayed in the status information display. For that, (s)he has to switch the value
4743  * of the display column's parameter "active" from "auto" (its default value) to "on" or "off", respectively.
4744  *
4745  * \par DISP_POSITION: the relative position of the display column.
4746  * In the status information display, the display columns are arranged from left to right in increasing order of their
4747  * relative position.
4748  *
4749  * \par DISP_STRIPLINE: the default for whether the display column should be separated with a line from its right neighbor.
4750  * This parameter states whether the display column should be separated with the string "|" from its right neighbor. In so
4751  * doing, the clearness of the status information display may improve.
4752  *
4753  * @section DISP_DATA Display Column Data
4754  *
4755  * Below the header "Data structures" you can find a struct which is called "struct SCIP_DispData".
4756  * In this data structure, you can store the data of your display column. For example, you should store the adjustable
4757  * parameters of the display column in this data structure.
4758  * If you are using C++, you can add display column data as usual as object variables to your class.
4759  * \n
4760  * Defining display column data is optional. You can leave the struct empty.
4761  *
4762  *
4763  * @section DISP_INTERFACE Interface Methods
4764  *
4765  * At the bottom of "disp_mydisplaycolumn.c" you can find the interface method SCIPincludeDispMydisplaycolumn(), which also
4766  * appears in "disp_mydisplaycolumn.h".
4767  * \n
4768  * This method only has to be adjusted slightly.
4769  * It is responsible for notifying SCIP of the presence of the display column by calling the method
4770  * SCIPincludeDisp().
4771  *
4772  * The interface method is called by the user, if (s)he wants to include the display column, i.e., if (s)he wants to use the display column in his
4773  * application.
4774  *
4775  * If you are using display column data, you have to allocate the memory for the data at this point.
4776  * You can do this by calling:
4777  * \code
4778  * SCIP_CALL( SCIPallocMemory(scip, &dispdata) );
4779  * \endcode
4780  * You also have to initialize the fields in struct SCIP_DispData afterwards.
4781  *
4782  * Although this is very uncommon, you may also add user parameters for your display column, see the method
4783  * SCIPincludeConshdlrKnapsack() in the \ref cons_knapsack.h "knapsack constraint handler" for an example.
4784  *
4785  *
4786  * @section DISP_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Display Column
4787  *
4788  * Display column plugins have only one fundamental callback method, namely the \ref DISPOUTPUT method.
4789  * This method has to be implemented for every display column; the other callback methods are optional.
4790  * In the C++ wrapper class scip::ObjDisp, the scip_output() method (which corresponds to the \ref DISPOUTPUT callback) is a virtual
4791  * abstract member function.
4792  * You have to implement it in order to be able to construct an object of your display column class.
4793  *
4794  * Additional documentation for the callback methods can be found in type_disp.h.
4795  *
4796  * @subsection DISPOUTPUT
4797  *
4798  * The DISPOUTPUT callback is called after each pricing loop during node processing and after a node has been processed.
4799  * In addition, at the root node, the callback is executed after each iteration of the price-and-cut loop.
4800  * It should write the display column information for the current node to a given output file stream.
4801  *
4802  * Typical methods called by a display column are, for example, SCIPdispLongint(), SCIPdispInt(), SCIPdispTime(), and
4803  * SCIPinfoMessage().
4804  *
4805  *
4806  * @section DISP_ADDITIONALCALLBACKS Additional Callback Methods of a Display Column
4807  *
4808  * The additional callback methods do not need to be implemented in every case.
4809  * They can be used, for example, to initialize and free private data.
4810  *
4811  * @subsection DISPCOPY
4812  *
4813  * The DISPCOPY callback is executed when a SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this callback
4814  * as <code>NULL</code> the user disables the execution of the specified column. In general it is probably not needed to
4815  * implement that callback since the output of the copied instance is usually suppressed. In the other case or for
4816  * debugging the callback should be implement.
4817  *
4818  *
4819  * @subsection DISPFREE
4820  *
4821  * If you are using display column data, you have to implement this method in order to free the display column data.
4822  * This can be done by the following procedure:
4823  * \code
4824  * static
4825  * SCIP_DECL_DISPFREE(dispFreeMydisplaycolumn)
4826  * {
4827  * SCIP_DISPDATA* dispdata;
4828  *
4829  * dispdata = SCIPdispGetData(disp);
4830  * assert(dispdata != NULL);
4831  *
4832  * SCIPfreeMemory(scip, &dispdata);
4833  *
4834  * SCIPdispSetData(disp, NULL);
4835  *
4836  * return SCIP_OKAY;
4837  * }
4838  * \endcode
4839  * If you have allocated memory for fields in your display column data, remember to free this memory
4840  * before freeing the display column data itself.
4841  * If you are using the C++ wrapper class, this method is not available.
4842  * Instead, just use the destructor of your class to free the member variables of your class.
4843  *
4844  * @subsection DISPINIT
4845  *
4846  * The DISPINIT callback is executed after the problem is transformed.
4847  * The display column may, e.g., use this call to initialize its display column data.
4848  *
4849  * @subsection DISPEXIT
4850  *
4851  * The DISPEXIT callback is executed before the transformed problem is freed.
4852  * In this method, the display column should free all resources that have been allocated for the solving process in
4853  * \ref DISPINIT.
4854  *
4855  * @subsection DISPINITSOL
4856  *
4857  * The DISPINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
4858  * begin. The display column may use this call to initialize its branch-and-bound specific data.
4859  *
4860  * @subsection DISPEXITSOL
4861  *
4862  * The DISPEXITSOL callback is executed before the branch-and-bound process is freed. The display column should use this
4863  * call to clean up its branch-and-bound data specific data.
4864  */
4865 
4866 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
4867 /**@page EVENT How to add event handler
4868  *
4869  * While solving a constraint integer program, SCIP drops thousands of events such as SCIP_EVENTTYPE_VARFIXED (a
4870  * complete list of all events is given in type_event.h). These events can be caught and used to do something after a
4871  * certain event happens. Events can be used to speed up the solution process. For example, the set partitioning
4872  * constraint is only worth propagating if one of the involved variables is fixed. This can be detected by
4873  * catching the event SCIP_EVENTTYPE_VARFIXED. To be able to catch an event it is necessary to write an event handler
4874  * which defines what to do after a certain event was caught.
4875  *
4876  * We now explain how users can add their own event handlers. We give the explanation for creating your own
4877  * source file for each additional event handler. Of course, you can collect different event handlers in one source file
4878  * or you can put the event handler directly into the constraint handler. In a \ref EVENTUSAGE "second step" we discuss
4879  * the usage of an event handler. This means how to catch and drop events. \ref EVENTTYPES "Finally", we give some notes on the existing
4880  * types of events.
4881  *
4882  * Take src/scip/cons_logior.c, where the event handler is directly included into the constraint handler. As all other
4883  * default plugins, the event handlers are written in C. C++ users can easily adapt the code by using the scip::ObjEventhdlr
4884  * wrapper base class and implement the scip_...() virtual methods instead of the SCIP_DECL_EVENT... callback methods.
4885  *
4886  * Additional documentation for the callback methods of an event handler can be found in the file type_event.h. There is
4887  * also an example written in C which deals with an event handler. You find this example in the directory
4888  * "examples/Eventhdlr/". An C++ example can be found within the TSP project (examples/TSP/src/EventhdlrNewSol.cpp).
4889  *
4890  * Here is what you have to do to implement an event handler (assuming your event handler is named "bestsol"):
4891  * -# Copy the template files src/scip/event_xyz.c and src/scip/event_xyz.h into files named "event_bestsol.c"
4892  * and "event_bestsol.h".
4893  \n
4894  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
4895  * -# Use SCIPincludeEventBestsol() in order to include the event handler into your SCIP instance,
4896  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Eventhdlr example).
4897  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "bestsol".
4898  * -# Adjust the \ref EVENTHDLR_PROPERTIES "properties of the event handler".
4899  * -# Implement the \ref EVENT_INTERFACE "interface methods".
4900  * -# Implement the \ref EVENT_FUNDAMENTALCALLBACKS "fundamental callback methods".
4901  * -# Implement the \ref EVENT_ADDITIONALCALLBACKS "additional callback methods". This is optional.
4902  *
4903  *
4904  * @section EVENTHDLR_PROPERTIES Properties of a Event Handler
4905  *
4906  * At the top of the new file "event_bestsol.c" you can find the event handler properties.
4907  * These are given as compiler defines.
4908  * In the C++ wrapper class, you have to provide the event handler properties by calling the constructor
4909  * of the abstract base class scip::ObjEventhdlr from within your constructor.
4910  * The properties you have to set have the following meaning:
4911  *
4912  * \par EVENT_NAME: the name of the event handler.
4913  * This name has to be unique with respect to all other event handlers. If you are searching for an event handler with
4914  * SCIPfindEventhdlr(), this name is looked up.
4915  *
4916  * \par EVENT_DESC: the description of the event handler.
4917  * This string is printed as a description of the event handler.
4918  *
4919  * @section EVENTHDLR_DATA Event Handler Data
4920  *
4921  * Below the header "Data structures" you can find a struct which is called "struct SCIP_EventhdlrData".
4922  * In this data structure, you can store the data of your event handler. For example, you should store the adjustable
4923  * parameters of the event handler in this data structure.
4924  * If you are using C++, you can add event handler data as usual as object variables to your class.
4925  * \n
4926  * Defining event handler data is optional. You can leave the struct empty.
4927  *
4928  *
4929  * @section EVENT_INTERFACE Interface Methods
4930  *
4931  * At the bottom of "event_bestsol.c", you can find the interface method SCIPincludeEventBestsol(),
4932  * which also appears in "event_bestsol.h".
4933  * SCIPincludeEventBestsol() is called by the user, if (s)he wants to include the event handler,
4934  * i.e., if (s)he wants to use the event handler in his/her application.
4935  *
4936  * This method only has to be adjusted slightly.
4937  * It is responsible for notifying SCIP of the presence of the event handler. For this, you can either call
4938  * SCIPincludeEventhdlr(),
4939  * or SCIPincludeEventhdlrBasic() since SCIP version 3.0. In the latter variant, \ref EVENT_ADDITIONALCALLBACKS "additional callbacks"
4940  * must be added via setter functions as, e.g., SCIPsetReaderCopy(). We recommend this latter variant because
4941  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
4942  * variant must be manually adjusted with every SCIP release containing new callbacks for event handlers in order to compile.
4943  *
4944  * If you are using event handler data, you have to allocate the memory for the data at this point.
4945  * You can do this by calling:
4946  * \code
4947  * SCIP_CALL( SCIPallocMemory(scip, &eventhdlrdata) );
4948  * \endcode
4949  * You also have to initialize the fields in struct SCIP_EventhdlrData afterwards.
4950  *
4951  * Although this is very uncommon, you may also add user parameters for your event handler, see the method
4952  * SCIPincludeConshdlrKnapsack() in the \ref cons_knapsack.h "knapsack constraint handler" for an example.
4953  *
4954  *
4955  * @section EVENT_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Event Handler
4956  *
4957  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
4958  * an operational algorithm.
4959  * They are passed together with the event handler itself to SCIP using SCIPincludeEventhdlr() or SCIPincludeEventhdlrBasic(),
4960  * see @ref EVENT_INTERFACE.
4961  *
4962  *
4963  * Event handler plugins have only one fundamental callback method, namely the \ref EVENTEXEC method. This method has
4964  * to be implemented for every event handler; the other callback methods are optional. In the C++ wrapper class
4965  * scip::ObjEventhdlr, the scip_exec() method (which corresponds to the \ref EVENTEXEC callback) is a virtual abstract member
4966  * function. You have to implement it in order to be able to construct an object of your event handler class.
4967  *
4968  * Additional documentation for the callback methods can be found in type_event.h.
4969  *
4970  * @subsection EVENTEXEC
4971  *
4972  * The EVENTEXEC callback is called after the requested event happened. Then the event handler can do some action in
4973  * reaction to the event.
4974  *
4975  * Typical the execution method sets a parameter to TRUE to indicate later in solving process that something happened
4976  * which should be analyzed further. In the \ref cons_knapsack.h "knapsack constraint handler" you find such a typical
4977  * example.
4978  *
4979  * @section EVENT_ADDITIONALCALLBACKS Additional Callback Methods of a Event Handler
4980  *
4981  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
4982  * implemented for most applications, they can be used, for example, to initialize and free private data.
4983  * Additional callbacks can either be passed directly with SCIPincludeEventhdlr() to SCIP or via specific
4984  * <b>setter functions</b> after a call of SCIPincludeEventhdlrBasic(), see also @ref EVENT_INTERFACE.
4985  *
4986  * @subsection EVENTCOPY
4987  *
4988  * The EVENTCOPY callback is executed when a SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this
4989  * callback as <code>NULL</code> the user disables the execution of the specified event handler for all copied SCIP
4990  * instances. Note that in most cases the event handler in the copied instance will be initialize by those objects (such
4991  * as constraint handlers or propagators) which need this event handler (see \ref cons_knapsack.h). In these cases the copy
4992  * callback can be ignored. In case of general events, such as a new best solution being found
4993  * (SCIP_EVENTTYPE_BESTSOLFOUND), you might want to implement that callback. The event handler example which you find
4994  * in the directory "examples/Eventhdlr/" uses that callback.
4995  *
4996  * \code
4997  * static
4998  * SCIP_DECL_EVENTCOPY(eventCopyBestsol)
4999  * {
5000  * assert(scip != NULL);
5001  * assert(eventhdlr != NULL);
5002  * assert(strcmp(SCIPeventhdlrGetName(eventhdlr), EVENTHDLR_NAME) == 0);
5003  *
5004  * SCIP_CALL( SCIPincludeEventHdlrBestsol(scip) );
5005  *
5006  * return SCIP_OKAY;
5007  * }
5008  * \endcode
5009  *
5010  *
5011  * @subsection EVENTFREE
5012  *
5013  * If you are using event handler data, you have to implement this method in order to free the event handler data.
5014  * This can be done by the following procedure:
5015  * \code
5016  * static
5017  * SCIP_DECL_EVENTFREE(eventFreeBestsol)
5018  * {
5019  * SCIP_EVENTHDLRDATA* eventhdlrdata;
5020  *
5021  * eventhdlrdata = SCIPeventhdlrGetData(eventhdlr);
5022  * assert(eventhdlrdata != NULL);
5023  *
5024  * SCIPfreeMemory(scip, &eventhdlrdata);
5025  *
5026  * SCIPeventhdlrSetData(eventhdlr, NULL);
5027  *
5028  * return SCIP_OKAY;
5029  * }
5030  * \endcode
5031  * If you have allocated memory for fields in your event handler data, remember to free this memory
5032  * before freeing the event handler data itself.
5033  * If you are using the C++ wrapper class, this method is not available.
5034  * Instead, just use the destructor of your class to free the member variables of your class.
5035  *
5036  *
5037  * @subsection EVENTINIT
5038  *
5039  * The EVENTINIT callback is executed after the problem is transformed.
5040  * The event handler may, e.g., use this call to initialize its event handler data.
5041  *
5042  * @subsection EVENTEXIT
5043  *
5044  * The EVENTEXIT callback is executed before the transformed problem is freed.
5045  * In this method, the event handler should free all resources that have been allocated for the solving process in
5046  * \ref EVENTINIT.
5047  *
5048  * @subsection EVENTINITSOL
5049  *
5050  * The EVENTINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
5051  * begin. The event handler may use this call to initialize its branch-and-bound specific data.
5052  *
5053  * @subsection EVENTEXITSOL
5054  *
5055  * The EVENTEXITSOL callback is executed before the branch-and-bound process is freed. The event handler should use this
5056  * call to clean up its branch-and-bound data specific data.
5057  *
5058  * @section EVENTUSAGE Catching and Dropping Events
5059  *
5060  * After you have implemented the event handler, you have to tell SCIP for which events this event handler should be
5061  * used. This can be a general events, such as <code>SCIP_EVENTTYPE_BESTSOLFOUND</code>, or a variable event which is the most common
5062  * way.
5063  *
5064  * In case of a general (not variable) event you use the function SCIPcatchEvent() to attach to an event and
5065  * SCIPdropEvent() to release this event later.
5066  *
5067  * \code
5068  * SCIP_CALL( SCIPcatchEvent( scip, SCIP_EVENTTYPE_BESTSOLFOUND, eventhdlr, NULL, NULL) );
5069  * \endcode
5070  *
5071  * \code
5072  * SCIP_CALL( SCIPdropEvent( scip, SCIP_EVENTTYPE_BESTSOLFOUND, eventhdlr, NULL, NULL) );
5073  * \endcode
5074  *
5075  * If you want trigger some variable event, you use the method SCIPcatchVarEvent() to attach the variable event and
5076  * SCIPdropVarEvent() to drop it later.
5077  *
5078  * \code
5079  * SCIP_CALL( SCIPcatchVarEvent( scip, var, SCIP_EVENTTYPE_VARFIXED, eventhdlr, NULL, NULL) );
5080  * \endcode
5081  *
5082  * \code
5083  * SCIP_CALL( SCIPdropVarEvent( scip, var, SCIP_EVENTTYPE_VARFIXED, eventhdlr, NULL, NULL) );
5084  * \endcode
5085  *
5086  * @section EVENTTYPES Event types
5087  *
5088  * All available events are listed in type_event.h. There are atomic events such as <code>SCIP_EVENTTYPE_VARFIXED</code>
5089  * and combined events such as <code>SCIP_EVENTTYPE_VARCHANGED</code>. The events are encoded via bit masks. Each atomic
5090  * event has a unique power of two. This enables combination of the atomic events.
5091  *
5092  * SCIP only throws atomic events. However, an event handler might be interested in bunch of events. Through the
5093  * underlying bit masks it is possible to combine the atomic events. For example, <code>SCIP_EVENTTYPE_VARCHANGED</code>
5094  * is an event which combines the events <code>SCIP_EVENTTYPE_VARFIXED</code>, <code>SCIP_EVENTTYPE_VARUNLOCKED</code>,
5095  * <code>SCIP_EVENTTYPE_OBJCHANGED</code>, <code>SCIP_EVENTTYPE_GBDCHANGED</code>,
5096  * <code>SCIP_EVENTTYPE_DOMCHANGED</code>, and <code>SCIP_EVENTTYPE_IMPLADDED</code>.
5097  *
5098  * \code
5099  * #define SCIP_EVENTTYPE_VARCHANGED (SCIP_EVENTTYPE_VARFIXED | SCIP_EVENTTYPE_VARUNLOCKED | SCIP_EVENTTYPE_OBJCHANGED
5100  * | SCIP_EVENTTYPE_GBDCHANGED | SCIP_EVENTTYPE_DOMCHANGED | SCIP_EVENTTYPE_IMPLADDED)
5101  * \endcode
5102  *
5103  * Depending on the event type, the event offers different information. The methods which can be used to gain
5104  * access to this information are given in pub_event.h.
5105  *
5106  */
5107 
5108 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5109 /**@page NLPI How to add interfaces to nonlinear programming solvers
5110  *
5111  * NLPIs are used to interface a solver for nonlinear programs (NLP).
5112  * It is used, e.g., to solve convex relaxations of the problem or to find locally optimal solutions of
5113  * nonlinear relaxations or subproblems.
5114  * The NLPI has been designed such that it can be used independently from SCIP.
5115  *
5116  * While the NLPI itself corresponds to the solver interface, the NLPIPROBLEM corresponds to the
5117  * (solver specific) representation of a concrete nonlinear program.
5118  * An NLP is specified as a set of indexed variables with variable bounds, an objective function,
5119  * and a set of constraints, where each constraint is specified as a function which is restricted to lie
5120  * between given left and right hand sides (possibly infinite).
5121  * A function consists of a linear, quadratic, and general nonlinear part.
5122  * The linear and quadratic parts are specified via variable indices and coefficients, while the
5123  * general nonlinear part is specified via an expression tree.
5124  * That is, the user of the NLPI does not provide function evaluation callbacks but an algebraic representation of the NLP.
5125  * Interfaces for solvers that require function evaluations can make use of the NLPIORACLE, which
5126  * provides a set of methods to compute functions values, gradients, Jacobians, and Hessians for a given NLP.
5127  * See the interface to Ipopt for an example on how to use the NLPIORACLE.
5128  *
5129  * A complete list of all NLPIs contained in this release can be found \ref NLPIS "here".
5130  *
5131  * We now explain how users can add their own NLP solver interface.
5132  * Take the interface to Ipopt (src/nlpi/nlpi_ipopt.cpp) as an example.
5133  * Unlike most other plugins, it is written in C++.
5134  * Additional documentation for the callback methods of an NLPI, in particular for their input parameters,
5135  * can be found in the file type_nlpi.h.
5136  *
5137  * Here is what you have to do to implement an NLPI:
5138  * -# Copy the template files src/nlpi/nlpi_xyz.c and src/nlpi/nlpi_xyz.h into files named "nlpi_mynlpi.c"
5139  * and "nlpi_mynlpi.h".
5140  * \n
5141  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
5142  * -# Use SCIPcreateNlpSolverMynlpi() in order to include the NLPI into your SCIP instance,
5143  * e.g., in the main file of your project (see, e.g., src/main.c in the Coloring example).
5144  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mynlpi".
5145  * -# Adjust the properties of the nlpi (see \ref NLPI_PROPERTIES).
5146  * -# Define the NLPI and NLPIPROBLEM data (see \ref NLPI_DATA).
5147  * -# Implement the interface methods (see \ref NLPI_INTERFACE).
5148  * -# Implement the fundamental callback methods (see \ref NLPI_FUNDAMENTALCALLBACKS).
5149  *
5150  *
5151  * @section NLPI_PROPERTIES Properties of an NLPI
5152  *
5153  * At the top of the new file "nlpi_mynlpi.c", you can find the NLPI properties.
5154  * These are given as compiler defines.
5155  * The properties you have to set have the following meaning:
5156  *
5157  * \par NLPI_NAME: the name of the NLP solver interface.
5158  * This name is used in the interactive shell to address the NLPI.
5159  * Additionally, if you are searching for an NLPI with SCIPfindNLPI(), this name is looked up.
5160  * Names have to be unique: no two NLPIs may have the same name.
5161  *
5162  * \par NLPI_DESC: the description of the NLPI.
5163  * This string is printed as a description of the NLPI in the interactive shell.
5164  *
5165  * \par NLPI_PRIORITY: the priority of the NLPI.
5166  * If an NLP has to be solved, an NLP solver has to be selected.
5167  * By default, the solver with the NLPI with highest priority is selected.
5168  * The priority of an NLPI should be set according to performance of the solver:
5169  * solvers that provide fast algorithms that are usually successful on a wide range of problems should have a high priority.
5170  * An easy way to list the priorities of all NLPIs is to type "display nlpis" in the interactive shell of SCIP.
5171  *
5172  * @section NLPI_DATA NLPI Data
5173  *
5174  * Below the header "Data structures" you can find structs which are called "struct SCIP_NlpiData" and "struct SCIP_NlpiProblem".
5175  * In this data structure, you can store the data of your solver interface and of a specific NLP problem.
5176  * For example, you could store a pointer to the block memory data structure in the SCIP_NlpiData data structure
5177  * and store a pointer to an NLPIoracle in the SCIP_NlpiProblem data structure.
5178  *
5179  * @section NLPI_INTERFACE Interface Methods
5180  *
5181  * At the bottom of "nlpi_mynlpi.c", you can find the interface method SCIPcreateNlpSolverXyz(),
5182  * which also appears in "nlpi_mynlpi.h".
5183  * \n
5184  * This method only has to be adjusted slightly.
5185  * It is responsible for creating an NLPI that contains all properties and callback methods of your
5186  * solver interface by calling the method SCIPnlpiCreate().
5187  * SCIPcreateNlpSolverXyz() is called by the user (e.g., SCIP), if (s)he wants to use this solver interface in his/her application.
5188  *
5189  * If you are using NLPI data, you have to allocate the memory for the data at this point.
5190  * You can do this by calling:
5191  * \code
5192  * SCIP_CALL( SCIPallocMemory(scip, &nlpidata) );
5193  * \endcode
5194  * You also have to initialize the fields in struct SCIP_NlpiData afterwards. For freeing the
5195  * NLPI data, see \ref NLPIFREE.
5196  *
5197  *
5198  * @section NLPI_FUNDAMENTALCALLBACKS Fundamental Callback Methods of an NLPI
5199  *
5200  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
5201  * an operational algorithm. Currently, all NLPI callbacks are fundamental.
5202  *
5203  * Additional documentation of the callback methods, in particular to their input parameters,
5204  * can be found in type_nlpi.h.
5205  *
5206  * @subsection NLPICOPY
5207  *
5208  * The NLPICOPY callback is executed if the plugin should be copied, e.g., when a SCIP instance is copied.
5209  *
5210  * @subsection NLPIFREE
5211  *
5212  * The NLPIFREE callback is executed if the NLP solver interface data structure should be freed, e.g., when a SCIP instance is freed.
5213  *
5214  * @subsection NLPIGETSOLVERPOINTER
5215  *
5216  * The NLPIGETSOLVERPOINTER callback can be used to pass a pointer to a solver specific data structure to the user.
5217  *
5218  * @subsection NLPICREATEPROBLEM
5219  *
5220  * The NLPICREATEPROBLEM callback is executed if a particular NLP problem is to be created.
5221  * The callback method should initialize a SCIP_NlpiProblem struct here that corresponds to an empty NLP.
5222  *
5223  * @subsection NLPIFREEPROBLEM
5224  *
5225  * The NLPIFREEPROBLEMPOINTER callback is executed if a particular NLP problem is to be freed.
5226  * The callback method should free a SCIP_NlpiProblem struct here.
5227  *
5228  * @subsection NLPIGETPROBLEMPOINTER
5229  *
5230  * The NLPIGETPROBLEMPOINTER callback can be used to pass a pointer to a solver specific data structure of the NLP to the user.
5231  *
5232  * @subsection NLPIADDVARS
5233  *
5234  * The NLPIADDVARS callback is executed if a set of variables with lower and upper bounds and names should be added to a particular NLP.
5235  * The callback method must add the new variables behind the previously added variables, if any.
5236  * If NULL is given for the lower bounds arguments, -infinity is assumed as lower bound for each new variable.
5237  * If NULL is given for the upper bounds arguments, +infinity is assumed as upper bound for each new variable.
5238  * It is also permitted to use NULL for the names argument.
5239  *
5240  * @subsection NLPIADDCONSTRAINTS
5241  *
5242  * The NLPIADDCONSTRAINTS callback is executed if a set of constraints should be added to a particular NLP.
5243  * Constraints are specified by providing left and right hand sides, linear and quadratic coefficients, expression trees, and constraint names.
5244  * All of these arguments are optional, giving NULL for left hand sides corresponds to -infinity, giving NULL for right hand sides corresponds to +infinity.
5245  *
5246  * @subsection NLPISETOBJECTIVE
5247  *
5248  * The NLPISETOBJECTIVE callback is executed to set the objective function of a particular NLP.
5249  *
5250  * @subsection NLPICHGVARBOUNDS
5251  *
5252  * The NLPICHGVARBOUNDS callback is executed to change the bounds on a set of variables of an NLP.
5253  *
5254  * @subsection NLPICHGCONSSIDES
5255  *
5256  * The NLPICHGCONSSIDES callback is executed to change the sides on a set of constraints of an NLP.
5257  *
5258  * @subsection NLPIDELVARSET
5259  *
5260  * The NLPIDELVARSET callback is executed to delete a set of variables from an NLP.
5261  * The caller provides an array in which for each variable it is marked whether it should be deleted.
5262  * In the same array, the method should return the new position of each variable in the NLP, or -1 if it was deleted.
5263  *
5264  * @subsection NLPIDELCONSSET
5265  *
5266  * The NLPIDELCONSSET callback is executed to delete a set of constraints from an NLP.
5267  * The caller provides an array in which for each constraint it is marked whether it should be deleted.
5268  * In the same array, the method should return the new position of each constraint in the NLP, or -1 if it was deleted.
5269  *
5270  * @subsection NLPICHGLINEARCOEFS
5271  *
5272  * The NLPICHGLINEARCOEFS callback is executed to change the coefficients in the linear part of the objective function or a constraint of an NLP.
5273  *
5274  * @subsection NLPICHGQUADCOEFS
5275  *
5276  * The NLPICHGQUADCOEFS callback is executed to change the coefficients in the quadratic part of the objective function or a constraint of an NLP.
5277  *
5278  * @subsection NLPICHGEXPRTREE
5279  *
5280  * The NLPICHGEXPRTREE callback is executed to replace the expression tree of the objective function or a constraint of an NLP.
5281  *
5282  * @subsection NLPICHGNONLINCOEF
5283  *
5284  * The NLPICHGNONLINCOEF callback is executed to change a single parameter in the (parametrized) expression tree of the objective function or a constraint of an NLP.
5285  *
5286  * @subsection NLPICHGOBJCONSTANT
5287  *
5288  * The NLPICHGOBJCONSTANT callback is executed to change the constant offset of the objective function of an NLP.
5289  *
5290  * @subsection NLPISETINITIALGUESS
5291  *
5292  * The NLPISETINITIALGUESS callback is executed to provide primal and dual initial values for the variables and constraints of an NLP.
5293  * For a local solver, these values can be used as a starting point for the search.
5294  * It is possible to pass a NULL pointer for any of the arguments (primal values of variables, dual values of variable bounds, dual values of constraints).
5295  * In this case, the solver should clear previously set starting values and setup its own starting point.
5296  *
5297  * @subsection NLPISOLVE
5298  *
5299  * The NLPISOLVE callback is executed when an NLP should be solved.
5300  * The solver may use the initial guess provided by \ref NLPISETINITIALGUESS as starting point.
5301  * The status of the solving process and solution can be requested by
5302  * \ref NLPIGETSOLSTAT, \ref NLPIGETTERMSTAT, \ref NLPIGETSOLUTION, and \ref NLPIGETSTATISTICS.
5303  *
5304  * @subsection NLPIGETSOLSTAT
5305  *
5306  * The NLPIGETSOLSTAT callback can be used to request the solution status (solved, infeasible, ...) after an NLP has been solved.
5307  *
5308  * @subsection NLPIGETTERMSTAT
5309  *
5310  * The NLPIGETTERMSTAT callback can be used to request the termination reason (normal, iteration limit, ...) after an NLP has been solved.
5311  *
5312  * @subsection NLPIGETSOLUTION
5313  *
5314  * The NLPIGETSOLUTION callback can be used to request the primal and dual solution values after an NLP solve.
5315  * The method should pass pointers to arrays of variable values to the caller.
5316  * It is possible to return only primal values for the variables, but no values for the dual variables, e.g., if a solver does not compute such values.
5317  *
5318  * @subsection NLPIGETSTATISTICS
5319  *
5320  * The NLPIGETSTATISTICS callback can be used to request the statistical values (number of iterations, time, ...) after an NLP solve.
5321  * The method should fill the provided NLPSTATISTICS data structure.
5322  *
5323  * <!-- NLPIGETWARMSTARTSIZE, NLPIGETWARMSTARTMEMO, NLPISETWARMSTARTMEMO are not documented,
5324  since they are currently not used, not implemented, and likely to change with a next version. -->
5325  *
5326  * @subsection NLPIGETINTPAR
5327  *
5328  * The NLPIGETINTPAR callback can be used to request the value of an integer valued NLP parameter.
5329  *
5330  * @subsection NLPISETINTPAR
5331  *
5332  * The NLPISETINTPAR callback is executed to set the value of an integer valued NLP parameter.
5333  *
5334  * @subsection NLPIGETREALPAR
5335  *
5336  * The NLPIGETREALPAR callback can be used to request the value of a real valued NLP parameter.
5337  *
5338  * @subsection NLPISETREALPAR
5339  *
5340  * The NLPISETREALPAR callback is executed to set the value of a real valued NLP parameter.
5341  *
5342  * @subsection NLPIGETSTRINGPAR
5343  *
5344  * The NLPIGETSTRINGPAR callback can be used to request the value of a string valued NLP parameter.
5345  *
5346  * @subsection NLPISETSTRINGPAR
5347  *
5348  * The NLPISETSTRINGPAR callback is executed to set the value of a string valued NLP parameter.
5349  */
5350 
5351 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5352 /**@page EXPRINT How to add interfaces to expression interpreters
5353  *
5354  * An expression interpreter is a tool to compute point-wise and interval-wise the function values, gradients, and
5355  * derivatives of algebraic expressions which are given in the form of an expression tree.
5356  * It is used, e.g., by an NLP solver interface to compute Jacobians and Hessians for the solver.
5357  *
5358  * The expression interpreter interface in SCIP has been implemented similar to those of the LP solver interface (LPI).
5359  * For one binary, exactly one expression interpreter has to be linked.
5360  * The expression interpreter API has been designed such that it can be used independently from SCIP.
5361  *
5362  * A complete list of all expression interpreters contained in this release can be found \ref EXPRINTS "here".
5363  *
5364  * We now explain how users can add their own expression interpreters.
5365  * Take the interface to CppAD (\ref exprinterpret_cppad.cpp) as an example.
5366  * Unlike most other plugins, it is written in C++.
5367  *
5368  * Additional documentation for the callback methods of an expression interpreter, in particular for their input parameters,
5369  * can be found in the file \ref exprinterpret.h
5370  *
5371  * Note that the expression interpreter API has <b>BETA status</b> and thus may change in the next version.
5372  *
5373  * Here is what you have to do to implement an expression interpreter:
5374  * -# Copy the file \ref exprinterpret_none.c into a file named "exprinterpreti_myexprinterpret.c".
5375  * \n
5376  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
5377  * -# Open the new files with a text editor.
5378  * -# Define the expression interpreter data (see \ref EXPRINT_DATA).
5379  * -# Implement the interface methods (see \ref EXPRINT_INTERFACE).
5380  *
5381  *
5382  * @section EXPRINT_DATA Expression Interpreter Data
5383  *
5384  * In "struct SCIP_ExprInt", you can store the general data of your expression interpreter.
5385  * For example, you could store a pointer to the block memory data structure.
5386  *
5387  * @section EXPRINT_INTERFACE Interface Methods
5388  *
5389  * The expression interpreter has to implement a set of interface method.
5390  * In your "exprinterpret_myexprinterpret.c", these methods are mostly dummy methods that return error codes.
5391  *
5392  * @subsection SCIPexprintGetName
5393  *
5394  * The SCIPexprintGetName method should return the name of the expression interpreter.
5395  *
5396  * @subsection SCIPexprintGetDesc
5397  *
5398  * The SCIPexprintGetDesc method should return a short description of the expression interpreter, e.g., the name of the developer of the code.
5399  *
5400  * @subsection SCIPexprintGetCapability
5401  *
5402  * The SCIPexprintGetCapability method should return a bitmask that indicates the capabilities of the expression interpreter,
5403  * i.e., whether it can evaluate gradients, Hessians, or do interval arithmetic.
5404  *
5405  * @subsection SCIPexprintCreate
5406  *
5407  * The SCIPexprintCreate method is called to create an expression interpreter data structure.
5408  * The method should initialize a "struct SCIP_ExprInt" here.
5409  *
5410  * @subsection SCIPexprintFree
5411  *
5412  * The SCIPexprintFree method is called to free an expression interpreter data structure.
5413  * The method should free a "struct SCIP_ExprInt" here.
5414  *
5415  * @subsection SCIPexprintCompile
5416  *
5417  * The SCIPexprintCompile method is called to initialize the data structures that are required to evaluate
5418  * a particular expression tree.
5419  * The expression interpreter can store data that is particular to a given expression tree in the tree by using
5420  * SCIPexprtreeSetInterpreterData().
5421  *
5422  * @subsection SCIPexprintFreeData
5423  *
5424  * The SCIPexprintFreeData method is called when an expression tree is freed.
5425  * The expression interpreter should free the given data structure.
5426  *
5427  * @subsection SCIPexprintNewParametrization
5428  *
5429  * The SCIPexprintNewParametrization method is called when the values of the parameters in a parametrized expression tree have changed.
5430  *
5431  * @subsection SCIPexprintEval
5432  *
5433  * The SCIPexprintEval method is called when the value of an expression represented by an expression tree should be computed for a point.
5434  *
5435  * @subsection SCIPexprintEvalInt
5436  *
5437  * The SCIPexprintEvalInt method is called when an interval that contains the range of an expression represented by an expression tree with respect to intervals for the variables should be computed.
5438  *
5439  * @subsection SCIPexprintGrad
5440  *
5441  * The SCIPexprintGrad method is called when the gradient of an expression represented by an expression tree should be computed for a point.
5442  *
5443  * @subsection SCIPexprintGradInt
5444  *
5445  * The SCIPexprintGradInt method is called when an interval vector that contains the range of the gradients of an expression represented by an expression tree with respect to intervals for the variables should be computed.
5446  *
5447  * @subsection SCIPexprintHessianSparsityDense
5448  *
5449  * The SCIPexprintHessianSparsityDense method is called when the sparsity structure of the Hessian matrix should be computed and returned in dense form.
5450  *
5451  * @subsection SCIPexprintHessianDense
5452  *
5453  * The SCIPexprintHessianDense method is called when the Hessian of an expression represented by an expression tree should be computed for a point.
5454  */
5455 
5456 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5457 /**@page CONF How to use conflict analysis
5458  *
5459  * Conflict analysis is a way to automatically use the information obtained from infeasible nodes
5460  * in the branch-and-bound tree.
5461  *
5462  * Once a node is declared infeasible, SCIP automatically tries to infer a constraint that explains the reason for the
5463  * infeasibility, in order to avoid similar situations later in the search. This explanation essentially consists of a
5464  * constraint stating that at least one of its variables should have a bound different from the current infeasible node,
5465  * because the current setting led to infeasibility. Clearly, all variables that are fixed in the current infeasible
5466  * node would yield such a constraint (since this leads to infeasibility). The key point rather is to infer a "small"
5467  * constraint that does the same job. SCIP handles this by several heuristics. For this, SCIP sets up a
5468  * so-called (directed) conflict graph. The nodes in this graph correspond to bound changes of variables and an arc (@a
5469  * u, @a v) means that the bound change corresponding to @a v is based on the bound change of @a u. In general, a node
5470  * will have several ingoing arcs which represent all bound changes that have been used to infer (propagate) the bound
5471  * change in question. The graph also contains source nodes for each bound that has been changed during branching and an
5472  * artificial target node representing the conflict, i.e., the infeasibility. Essentially, SCIP heuristically constructs
5473  * a cut in this graph that involves few "branching nodes". For details on the techniques that SCIP uses,
5474  * we refer to the paper @par
5475  * Tobias Achterberg, Conflict Analysis in Mixed Integer Programming@n
5476  * Discrete Optimization, 4, 4-20 (2007)
5477  *
5478  * For conflict analysis to work well, the author of a \ref CONS "Constraint Handler" or a
5479  * \ref PROP "Propagator" has to implement three kinds of functionality:
5480  *
5481  * -# If one detects infeasibility, one should initiate conflict analysis, see \ref INITCONFS "below".
5482  * -# During propagation, one should call the right functions to fix variables.
5483  * -# One should implement the <em>so-called reverse propagation</em>.
5484  *
5485  * If this functionality is not implemented, SCIP will still work correctly, but cannot use the information of the constraint
5486  * handler or the propagator for conflict analysis. In this case, each bound reduction performed by the constraint
5487  * handler/propagator will be treated as if it had been a branching decision.
5488  *
5489  * @section INITCONFS Initiating Conflict Analysis
5490  *
5491  * If one detects infeasibility within propagation, one should do the following:
5492  * -# Call SCIPinitConflictAnalysis().
5493  * -# Inform SCIP about the variable bounds that are the reason for the detection of infeasibility
5494  * via the functions SCIPaddConflictLb(), SCIPaddConflictUb(), SCIPaddConflictBd(), or
5495  * SCIPaddConflictBinvar(). If there is more than one valid explanation of infeasibility, either one can be used.
5496  * Typically, smaller explanations tend to be better.
5497  * -# Call SCIPanalyzeConflict() from a propagator or SCIPanalyzeConflictCons() from a constraint
5498  * handler.
5499  *
5500  * This functionality allows SCIP to set up the conflict graph and perform a conflict analysis.
5501  *
5502  * @section Propagation
5503  *
5504  * When propagating variable domains, SCIP needs to be informed that the deduced variable bounds should be
5505  * used in conflict analysis. This can be done by the functions SCIPinferVarLbCons(),
5506  * SCIPinferVarUbCons(), and SCIPinferBinvarCons() for constraint handlers and SCIPinferVarLbProp(),
5507  * SCIPinferVarUbProp(), and SCIPinferBinvarProp() for propagators. You can pass one integer of
5508  * information that should indicate the reason of the propagation and can be used in reverse
5509  * propagation, see the next section.
5510  *
5511  * @section RESPROP Reverse Propagation
5512  *
5513  * Reverse Propagation is used to build up the conflict graph. Essentially, it provides an algorithm to detect the arcs
5514  * leading to a node in the conflict graph, i.e., the bound changes responsible for the new bound change deduced during
5515  * propagation. Reverse Propagation needs to be implemented in the RESPROP callback functions of
5516  * \ref CONSRESPROP "constraint handlers" or \ref PROPRESPROP "propagators".
5517  * These callbacks receive the following information: the variable which is under investigation (@p
5518  * infervar), the corresponding bound change (@p bdchgidx, @p boundtype), and the integer (@p inferinfo) that has been
5519  * supplied during propagation.
5520  *
5521  * One can use SCIPvarGetUbAtIndex() or SCIPvarGetLbAtIndex() to detect the bounds before or after the propagation that
5522  * should be investigated. Then the bounds that were involved should be passed to SCIP via SCIPaddConflictLb() and
5523  * SCIPaddConflictUb(). If there is more than one valid explanation of infeasibility, either one can be used.
5524  * Typically, smaller explanations tend to be better.
5525  *
5526  * Details and (more) examples are given in Sections @ref CONSRESPROP and @ref PROPRESPROP.
5527  *
5528  *
5529  * @section Example
5530  *
5531  * Consider the constraint handler @p cons_linearordering.c in the
5532  * <a href="http://scip.zib.de/doc/examples/LOP"><b>linear ordering example</b></a>
5533  * (see @p example/LOP directory). This constraint handler propagates the equations \f$x_{ij} + x_{ji} =
5534  * 1\f$ and triangle inequalities \f$x_{ij} + x_{jk} + x_{ki} \leq 2\f$.
5535  *
5536  * When propagating the equation and <code>vars[i][j]</code> is fixed to 1, the constraint handler uses
5537  * \code
5538  * SCIP_CALL( SCIPinferBinvarCons(scip, vars[j][i], FALSE, cons, i*n + j, &infeasible, &tightened) );
5539  * \endcode
5540  * Thus, variable <code>vars[j][i]</code> is fixed to 0 (@p FALSE), and it passes <code>i*n + j </code> as @p inferinfo.
5541  *
5542  * When it propagates the triangle inequality and both <code>vars[i][j]</code> and <code>vars[j][k]</code>
5543  * are fixed to 1, the constraint handler uses
5544  * \code
5545  * SCIP_CALL( SCIPinferBinvarCons(scip, vars[k][i], FALSE, cons, n*n + i*n*n + j*n + k, &infeasible, &tightened) );
5546  * \endcode
5547  * Thus, in this case, variable <code>vars[k][i]</code> is fixed to 0 and <code>n*n + i*n*n + j*n + k</code> is
5548  * passed as <code>inferinfo</code>.
5549  *
5550  * In reverse propagation, the two cases can be distinguished by @p inferinfo: if it is less than @p n*n,
5551  * we deal with an equation, otherwise with a triangle inequality. The constraint handler can then extract the
5552  * indices @p i, @p j (and @p k in the second case) from inferinfo.
5553  *
5554  * In the first case, it has to distinguish whether <code>vars[i][j]</code> is fixed to 0 or 1 &ndash;
5555  * by calling SCIPaddConflictLb()
5556  * or SCIPaddConflictUb(), respectively, with variable <code>vars[j][i]</code>. In the second case, it is clear that the only
5557  * possible propagation is to fix <code>vars[i][j]</code> to 0 when both <code>vars[k][i]</code> and <code>vars[j][k]</code>
5558  * are fixed to 1. It then calls
5559  * SCIPaddConflictLb() for both <code>vars[k][i]</code> and <code>vars[j][k]</code>.
5560  */
5561 
5562 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5563 /**@page OBJ Creating, capturing, releasing, and adding data objects
5564  *
5565  * Data objects (variables, constraints, rows, ... ) are subject to reference counting
5566  * to avoid expensive copying operations. This concept is similar to smart pointers.
5567  * Creating such an object (e.g., by calling SCIPcreateVar()) will set the
5568  * reference counter to one. Capturing an object (e.g., by calling SCIPcaptureVar()) increases the reference counter,
5569  * releasing it (e.g., by calling SCIPreleaseVar()) decreases the counter. If the reference counter gets zero, the
5570  * object will be destroyed automatically.
5571  *
5572  * Remember that a created data object is automatically captured. If the user
5573  * doesn't need the object anymore, (s)he has to call the object's release method.
5574  *
5575  * When a data object is added to SCIP (e.g., by calling SCIPaddVar()) , it is captured again, such that a
5576  * release call does not destroy the object. If SCIP doesn't need the object
5577  * anymore, it is automatically released.
5578  *
5579  * E.g., if the user calls
5580  * \code
5581  * SCIPcreateVar(); // reference counter 1
5582  * SCIPaddVar(); // reference counter 2
5583  * SCIPreleaseVar(); // reference counter 1
5584  * \endcode
5585  * the reference counter will be 1 afterwards, and the variable will be destroyed, if SCIP frees the problem.
5586  * If the user wants to use this variable, e.g. for extracting statistics after SCIP was finished, the user must not call
5587  * SCIPreleaseVar() right after adding the variable, but before terminating the program.
5588  */
5589 
5590 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5591 /**@page PARAM How to add additional user parameters
5592  *
5593  * Users may add their own parameters to SCIP by calling SCIPaddXyzParam(). Using
5594  * this method, there are two possibilities for where to store the actual parameter value:
5595  * - If the given valueptr is NULL, SCIP stores the parameter value internally, and
5596  * the user can only access the value with the SCIPgetXyzParam() and
5597  * SCIPsetXyzParam() calls.
5598  * - If the given valueptr is not NULL, SCIP stores the parameter value at the given
5599  * address, and the user can directly manipulate the value at this address.
5600  * (S)he has to be careful with memory management in string parameters: when the
5601  * SCIPaddStringParam() method is called, the given address must hold a char*
5602  * pointer with value NULL. The default value is then copied into this pointer,
5603  * allocating memory with BMSallocMemoryArray(). If the parameter is changed, the
5604  * old string is freed with BMSfreeMemoryArray() and the new one is copied to a new
5605  * memory area allocated with BMSallocMemoryArray(). When the parameter is freed,
5606  * the memory is freed with BMSfreeMemoryArray().
5607  * The user should not interfere with this internal memory management. Accessing
5608  * the string parameter through the given valueptr is okay as long as it does not
5609  * involve reallocating memory for the string.
5610  *
5611  * In some cases, it is necessary to keep track of changes in a parameter.
5612  * If this is the case, the user can define a method by the PARAMCHGD callback and use this method as
5613  * the @c paramchgd parameter of the @c SCIPaddXyzParam() method, also giving a pointer to the data, which is
5614  * needed in this method, as @c paramdata. If this method is not NULL, it is called every time
5615  * the value of the parameter is changed.
5616  */
5617 
5618 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5619 /**@page DEBUG Debugging
5620  *
5621  * If you need to debug your own code that uses SCIP, here are some tips and tricks:
5622  *
5623  * - Use <b>asserts</b> in your code to show preconditions for the parameters, invariants and postconditions.
5624  * Assertions are boolean expressions which inevitably have to evaluate to <code>TRUE</code>. Consider the
5625  * following example, taken from the file src/scip/cons_linear.c:
5626  * \code
5627  * SCIP_RETCODE consdataCatchEvent(
5628  * SCIP* scip, /**< SCIP data structure *\/
5629  * SCIP_CONSDATA* consdata, /**< linear constraint data *\/
5630  * SCIP_EVENTHDLR* eventhdlr, /**< event handler to call for the event processing *\/
5631  * int pos /**< array position of variable to catch bound change events for *\/
5632  * )
5633  * {
5634  * assert(scip != NULL);
5635  * assert(consdata != NULL);
5636  * assert(eventhdlr != NULL);
5637  * assert(0 <= pos && pos < consdata->nvars);
5638  * ...
5639  * }
5640  * \endcode
5641  * As you can see, both pointers and integers are checked for valid values at the beginning of the
5642  * function <code>consdataCatchEvent()</code>. This is particularly important for, e.g., array indices like
5643  * the variable <code>pos</code> in this example, where using the <code>consdata->nvars[pos]</code>
5644  * pointer could result in unexspected behaviour
5645  * if the asserted precondition on <code>pos</code> were not matched and <pos> were an arbitrary index
5646  * outside the array range.
5647  *
5648  * - In order to activate assertions, use the <b>Debug mode</b> by compiling SCIP via
5649  * \code
5650  * make OPT=dbg
5651  * \endcode and run the code. See \ref MAKE for further information about compiler options for SCIP.
5652  *
5653  * - Spending only little extra time on
5654  * asserting preconditions saves most of the time spent on debugging!
5655  *
5656  * - Turn on <b>additional debug output</b> by adding the line
5657  * \code
5658  * #define SCIP_DEBUG
5659  * \endcode
5660  * at the top of SCIP files you want to analyze. This will output messages included in the code using
5661  * <code>SCIPdebugMessage()</code> (see \ref EXAMPLE_1).
5662  * We recommend to also use <code>SCIPdebugMessage()</code> in your own code for being able to activate
5663  * debug output in the same way.
5664  * - If available on your system, we recommend to use a debugger like <code>gdb</code>
5665  * to trace all function calls on the stack,
5666  * display values of certain expressions, manually break the running code, and so forth.
5667  * - If available on your system, you can use software like <a href="http://valgrind.org">valgrind</a> to check for uninitialized
5668  * values or segmentation faults.
5669  * - For checking the usage of SCIP memory, you can use
5670  * <code>SCIPprintMemoryDiagnostic()</code>. This outputs memory that is currently in use,
5671  * which can be useful after a <code>SCIPfree()</code> call.
5672  * - If your code cuts off a feasible solution, but you do not know which component is responsible,
5673  * you can define <code>SCIP_DEBUG_SOLUTION</code> in the file <code>debug.h</code> to be a filename
5674  * containing a solution in SCIP format (see \ref EXAMPLE_2).
5675  * This solution is then read and it is checked for every cut, whether the solution violates the cut.
5676  *
5677  * @section EXAMPLE_1 How to activate debug messages
5678  * For example, if we include a <code>\#define SCIP_DEBUG</code> at the top of \ref heur_oneopt.h, recompile SCIP
5679  * in DBG mode, and run the SCIP interactive shell to solve p0033.mps from the
5680  * <a href="http://miplib.zib.de/miplib3/miplib.html">MIPLIB 3.0</a> , we get some output like:
5681  * \code
5682  * SCIP version 1.1.0 [precision: 8 byte] [memory: block] [mode: debug] [LP solver: SoPlex 1.4.0]
5683  * Copyright (c) 2002-2014 Konrad-Zuse-Zentrum fuer Informationstechnik Berlin (ZIB)
5684  *
5685  * user parameter file <scip.set> not found - using default parameters
5686  *
5687  * SCIP> read check/IP/miplib/p0033.mps
5688  * original problem has 33 variables (33 bin, 0 int, 0 impl, 0 cont) and 16 constraints
5689  * SCIP> optimize
5690  * ...
5691  * 0.1s| 1 | 0 | 132 | 257k| 0 | 14 | 30 | 13 | 13 | 30 | 51 | 39 | 0 | 0 | 3.026472e+03 | 3.347000e+03 | 10.59%
5692  * [src/scip/heur_oneopt.c:332] debug: Row <R122> has activity 110
5693  * [src/scip/heur_oneopt.c:332] debug: Row <R123> has activity 216
5694  * ...
5695  * [src/scip/heur_oneopt.c:101] debug: Try to shift down variable <t_C157> with
5696  * [src/scip/heur_oneopt.c:102] debug: lb:<-0> <= val:<1> <= ub:<1> and obj:<171> by at most: <1>
5697  * [src/scip/heur_oneopt.c:135] debug: -> The shift value had to be reduced to <0>, because of row <R122>.
5698  * [src/scip/heur_oneopt.c:137] debug: lhs:<-1e+20> <= act:<110> <= rhs:<148>, colval:<-60>
5699  * ...
5700  * [src/scip/heur_oneopt.c:383] debug: Only one shiftcand found, var <t_C167>, which is now shifted by<-1.0>
5701  * k 0.1s| 1 | 0 | 132 | 258k| 0 | 14 | 30 | 13 | 13 | 30 | 51 | 39 | 0 | 0 | 3.026472e+03 | 3.164000e+03 | 4.54%
5702  * [src/scip/heur_oneopt.c:436] debug: found feasible shifted solution:
5703  * objective value: 3164.00000000012
5704  * C157 1 (obj:171)
5705  * C163 1 (obj:163)
5706  * C164 1 (obj:69)
5707  * C170 1 (obj:49)
5708  * C172 1 (obj:258)
5709  * C174 1 (obj:250)
5710  * C175 1 (obj:500)
5711  * C179 1 (obj:318)
5712  * C181 1 (obj:318)
5713  * C182 1 (obj:159)
5714  * C183 1.00000000000038 (obj:318)
5715  * C184 1 (obj:159)
5716  * C185 1 (obj:318)
5717  * C186 1 (obj:114)
5718  * [src/scip/heur_oneopt.c:498] debug: Finished 1-opt heuristic
5719  * ...
5720  * \endcode
5721  *
5722  * @section EXAMPLE_2 How to add a debug solution
5723  *
5724  * Continuing the example above, we finish the solving process.
5725  * The optimal solution can now be written to a file:
5726  * \code
5727  * SCIP> display solution
5728  *
5729  * objective value: 3089
5730  * C157 1 (obj:171)
5731  * C163 1 (obj:163)
5732  * C164 1 (obj:69)
5733  * C166 1 (obj:183)
5734  * C170 1 (obj:49)
5735  * C174 1 (obj:250)
5736  * C177 1 (obj:500)
5737  * C179 1 (obj:318)
5738  * C181 1 (obj:318)
5739  * C182 1 (obj:159)
5740  * C183 1 (obj:318)
5741  * C184 1 (obj:159)
5742  * C185 1 (obj:318)
5743  * C186 1 (obj:114)
5744  *
5745  * SCIP> write solution check/p0033.sol
5746  *
5747  * written solution information to file <check/p0033.sol>
5748  * \endcode
5749  *
5750  * If we afterwards use
5751  * <code>\#define SCIP_DEBUG_SOLUTION "check/p0033.sol"</code> in debug.h, recompile and run SCIP,
5752  * it will output:
5753  * \code
5754  * SCIP> read check/IP/miplib/p0033.mps
5755  * original problem has 33 variables (33 bin, 0 int, 0 impl, 0 cont) and 16 constraints
5756  * SCIP> optimize
5757  *
5758  * presolving:
5759  * ***** debug: reading solution file <check/p0033.sol>
5760  * ***** debug: read 15 non-zero entries
5761  * \endcode
5762  * Further debug output would only appear, if the solution was cut off in the solving process.
5763  * Of course, this is not the case! Hopefully...otherwise, please send a bug report ;-)
5764  */
5765 
5766 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5767 /**@page TEST How to run automated tests with SCIP
5768  *
5769  * SCIP comes along with a set of useful tools that allow to perform automated tests. The
5770  * following is a step-by-step guide from setting up the test environment for evaluation and
5771  * customization of test runs.
5772  *
5773  *
5774  * @section SETUP Setting up the test environment
5775  *
5776  * At first you should create a file listing all problem instances that should be part of the test.
5777  * This file has to be located in the the directory <code>scip/check/testset/</code>
5778  * and has to have the file extension <code>.test</code>, e.g., <code>testrun.test</code>,
5779  * in order to be found by the <code>scip/check/check.sh</code> script.
5780  * \n
5781  * All test problems can be listed in the <code>test</code>-file by a relative path,
5782  * e.g., <code>../../problems/instance1.lp</code> or absolute path, e.g., <code>/home/problems/instance2.mps</code>
5783  * in this file. Only one problem should be listed each on line (since the command <code>cat</code> is used to parse this file).
5784  * Note that these problems have to be readable for SCIP in order to solve them.
5785  * However, you can use different file formats.
5786  *
5787  * Optionally, you can provide a solution file in the <code>scip/check/testset/</code> directory containing
5788  * known information about the feasibility and the best known objective values for the test instances.
5789  * SCIP can use these values to verify the results. The file has to have the same basename as the
5790  * <code>.test</code>-file, i.e., in our case <code>testrun.solu</code>. One line can only contain
5791  * information about one test instance. A line has to start with the type of information given:
5792  *
5793  * - <code>=opt=</code> stating that a problem name with an optimal objective value follows
5794  * - <code>=best=</code> stating that a problem name with a best know objective value follows
5795  * - <code>=inf=</code> stating that a problem name follows which is infeasible
5796  *
5797  * With these information types you can encode for an instance named <code>instance1.lp</code> the following
5798  * information:
5799  * - The instance has a known optimal (objective) value of 10.
5800  * \code
5801  * =opt= instance1 10
5802  * \endcode
5803  * - The instance has a best known solution with objective value 15.
5804  * \code
5805  * =best= instance1 15
5806  * \endcode
5807  * - The instance is feasible (but has no objective function or we don't know a solution value)
5808  * \code
5809  * =feas= instance1
5810  * \endcode
5811  * - The instance is infeasible.
5812  * \code
5813  * =inf= instance1
5814  * \endcode
5815  *
5816  * If you don't know whether the instance is feasible or not (so the status is unknown),
5817  * you can omit the instance in the <code>solu</code>-file or write
5818  * \code
5819  * =unkn= instance1
5820  * \endcode
5821  *
5822  * <b>Note that in all lines the file extension of the file name is omitted.</b>
5823  * \n
5824  * See the files <code>scip/check/testset/short.test</code> and <code>scip/check/testset/short.solu</code>
5825  * for an example of a <code>test</code>-file and its corresponding <code>solu</code>-file.
5826  *
5827  *
5828  *
5829  * @section STARTING Starting a test run
5830  *
5831  *
5832  * \code
5833  * make TEST=testrun test
5834  * \endcode
5835  *
5836  * in the SCIP root directory. Note that <code>testrun</code> is exactly the basename of our
5837  * <code>test</code>-file (<code>testrun.test</code>). This will cause SCIP to solve our test instances
5838  * one after another and to create various output files (see \ref EVAL).
5839  *
5840  *
5841  * @section EVAL Evaluating a test run
5842  *
5843  * During computation, SCIP automatically creates the directory <code>scip/check/results/</code>
5844  * (if it does not already exist) and stores the following output files there.
5845  *
5846  * \arg <code>*.out</code> - output of <code>stdout</code>
5847  * \arg <code>*.err</code> - output of <code>stderr</code>
5848  * \arg <code>*.set</code> - copy of the used settings file
5849  *
5850  * \arg <code>*.res</code> - ASCII table containing a summary of the computational results
5851  * \arg <code>*.tex</code> - TeX table containing a summary of the computational results
5852  * \arg <code>*.pav</code> - <a href="http://www.gamsworld.org/performance/paver/">PAVER</a> output
5853  *
5854  * The last three files in the above list, i.e., the files containing a summary of the computational results,
5855  * can also be generated manually. Therefore the user has to call the <code>evalcheck.sh</code> script in the
5856  * @c check directory with the corresponding @c out file as argument. For example, this may be useful if the user stopped the
5857  * test before it was finished, in which case the last three files will not be automatically generated by SCIP.
5858  *
5859  * The last column of the ASCII summary table contains the solver status. We distinguish the following statuses: (in order of priority)
5860  *
5861  * \arg abort: solver broke before returning solution
5862  * \arg fail: solver cut off a known feasible solution (value of the <code>solu</code>-file is beyond the dual bound;
5863  * especially of problem is claimed to be solved but solution is not the optimal solution)
5864  * \arg ok: solver solved problem with the value in solu-file
5865  * \arg solved: solver solved problem which has no (optimal) value in solu-file (since we here cannot detect the direction
5866  * of optimization, it is possible that a solver claims an optimal solution which contradicts a known feasible solution)
5867  * \arg better: solver found solution better than known best solution (or no solution was noted in the <code>solu</code>-file so far)
5868  * \arg gaplimit, sollimit: solver reached gaplimit or limit of number of solutions (at present: only in SCIP)
5869  * \arg timeout: solver reached any other limit (like time or nodes)
5870  * \arg unknown: otherwise
5871  *
5872  * Additionally the <code>evalcheck.sh</code> script can generate a <code>solu</code>-file by calling
5873  * \code
5874  * ./evalcheck.sh writesolufile=1 NEWSOLUFILE=<solu-file> <out-file>
5875  * \endcode
5876  * where <code><solu-file></code> denotes the filename of the new file where the solutions shall be
5877  * (and <code><out-file></code> denotes the output (<code>.out</code>) files to evaluate).
5878  *
5879  * Another feature can be enabled by calling:
5880  * \code
5881  * ./evalcheck.sh printsoltimes=1 ...
5882  * \endcode
5883  * The output has two additional columns containing the solving time until the first and the best solution was found.
5884  *
5885  *
5886  * @b Note: The @em basename of all these files is the same and has the following structure
5887  * which allows us to reconstruct the test run:
5888  *
5889  * \code
5890  * check.<test name>.<binary>.<machine name>.<setting name>
5891  * \endcode
5892  *
5893  * \arg <<code>test name</code>> indicates the name of the the test file, e.g., <code>testrun</code>
5894  * \arg <<code>binary</code>> defines the used binary, e.g., <code>scip-1.1.0.linux.x86.gnu.opt.spx</code>
5895  * \arg <<code>machine name</code>> tells the name of the machine, e.g., <code>mycomputer</code>
5896  * \arg <<code>setting name</code>> denotes the name of the used settings, e.g., <code>default</code>
5897  * means the (SCIP) default settings were used
5898  *
5899  * Using the examples out of the previous listing the six file names would have the name:
5900  *
5901  * \code
5902  * check.testrun.scip-1.1.0.linux.x86.gnu.opt.spx.mycomputer.default.<out,err,set,res,tex,pav>
5903  * \endcode
5904  *
5905  *
5906  * @section USING Using customized setting files
5907  *
5908  * It is possible to use customized settings files for the test run instead of testing SCIP with default settings.
5909  * These have to be placed in the directory <code>scip/settings/</code>.
5910  *
5911  * @b Note: Accessing setting files in subfolders of the @c settings directory is currently not supported.
5912  *
5913  * To run SCIP with a custom settings file, say for example <code>fast.set</code>, we call
5914  *
5915  * \code
5916  * make TEST=testrun SETTINGS=fast test
5917  * \endcode
5918  *
5919  * in the SCIP root directory.
5920  *
5921  *
5922  * @section ADVANCED Advanced options
5923  *
5924  * We can further customize the test run by specifying the following options in the <code>make</code> call:
5925  *
5926  * \arg <code>TIME</code> - time limit for each test instance in seconds [default: 3600]
5927  * \arg <code>NODES</code> - node limit [default: 2100000000]
5928  * \arg <code>MEM</code> - memory limit in MB [default: 1536]
5929  * \arg <code>DISPFREQ</code> - display frequency of the output [default: 10000]
5930  * \arg <code>FEASTOL</code> - LP feasibility tolerance for constraints [default: "default"]
5931  * \arg <code>LOCK</code> - should the test run be locked to prevent other machines from performing the same test run [default: "false"]
5932  * \arg <code>CONTINUE</code> - continue the test run if it was previously aborted [default: "false"]
5933  * \arg <code>VALGRIND</code> - run valgrind on the SCIP binary; errors and memory leaks found by valgrind are reported as fails [default: "false"]
5934  *
5935  *
5936  * @section COMPARE Comparing test runs for different settings
5937  *
5938  * Often test runs are performed on the basis of different settings. In this case, it is useful to
5939  * have a performance comparison. For this purpose, we can use the <code>allcmpres.sh</code> script in
5940  * the @c check directory.
5941  *
5942  * Suppose, we performed our test run with two different settings, say <code>fast.set</code> and
5943  * <code>slow.set</code>. Assuming that all other parameters (including the SCIP binary), were the same,
5944  * we may have the following <code>res</code>-files in the directory <code>scip/check/results/</code>
5945  *
5946  * \code
5947  * check.testrun.scip-1.1.0.linux.x86.gnu.opt.spx.mycomputer.fast.res
5948  * check.testrun.scip-1.1.0.linux.x86.gnu.opt.spx.mycomputer.slow.res
5949  * \endcode
5950  *
5951  * For a comparison of both computations, we simply call
5952  *
5953  * \code
5954  * allcmpres.sh results/check.testrun.scip-1.1.0.linux.x86.gnu.opt.spx.mycomputer.fast.res \
5955  * results/check.testrun.scip-1.1.0.linux.x86.gnu.opt.spx.mycomputer.slow.res
5956  * \endcode
5957  *
5958  * in the @c check directory. This produces an ASCII table on the console that provide a detailed
5959  * performance comparison of both test runs. Note that the first <code>res</code>-file serves as reference
5960  * computation. The following list explains the output.
5961  * (The term "solver" can be considered as the combination of SCIP with a specific setting file.)
5962  *
5963  * \arg <code>Nodes</code> - Number of processed branch-and-bound nodes.
5964  * \arg <code>Time</code> - Computation time in seconds.
5965  * \arg <code>F</code> - If no feasible solution was found, then '#', empty otherwise.
5966  * \arg <code>NodQ</code> - Equals Nodes(i) / Nodes(0), where 'i' denotes the current solver and '0' stands for the reference solver.
5967  * \arg <code>TimQ</code> - Equals Time(i) / Time(0).
5968  * \arg <code>bounds check</code> - Status of the primal and dual bound check.
5969  *
5970  * \arg <code>proc</code> - Number of instances processed.
5971  * \arg <code>eval</code> - Number of instances evaluated (bounds check = "ok", i.e., solved to optimality
5972  * within the time and memory limit and result is correct). Only these instances are used in the calculation
5973  * of the mean values.
5974  * \arg <code>fail</code> - Number of instances with bounds check = "fail".
5975  * \arg <code>time</code> - Number of instances with timeout.
5976  * \arg <code>solv</code> - Number of instances correctly solved within the time limit.
5977  * \arg <code>wins</code> - Number of instances on which the solver won (i.e., the
5978  * solver was at most 10% slower than the fastest solver OR had the best
5979  * primal bound in case the instance was not solved by any solver within
5980  * the time limit).
5981  * \arg <code>bett</code> - Number of instances on which the solver was better than the
5982  * reference solver (i.e., more than 10% faster).
5983  * \arg <code>wors</code> - Number of instances on which the solver was worse than the
5984  * reference solver (i.e., more than 10% slower).
5985  * \arg <code>bobj</code> - Number of instances on which the solver had a better primal
5986  * bound than the reference solver (i.e., a difference larger than 10%).
5987  * \arg <code>wobj</code> - Number of instances on which the solver had a worse primal
5988  * bound than the reference solver (i.e., a difference larger than 10%).
5989  * \arg <code>feas</code> - Number of instances for which a feasible solution was found.
5990  * \arg <code>gnodes</code> - Geometric mean of the processed nodes over all evaluated instances.
5991  * \arg <code>shnodes</code> - Shifted geometric mean of the processed nodes over all evaluated instances.
5992  * \arg <code>gnodesQ</code> - Equals nodes(i) / nodes(0), where 'i' denotes the current
5993  * solver and '0' stands for the reference solver.
5994  * \arg <code>shnodesQ</code> - Equals shnodes(i) / shnodes(0).
5995  * \arg <code>gtime</code> - Geometric mean of the computation time over all evaluated instances.
5996  * \arg <code>shtime</code> - Shifted geometric mean of the computation time over all evaluated instances.
5997  * \arg <code>gtimeQ</code> - Equals time(i) / time(0).
5998  * \arg <code>shtimeQ</code> - Equals shtime(i) / shtime(0).
5999  * \arg <code>score</code> - N/A
6000  *
6001  * \arg <code>all</code> - All solvers.
6002  * \arg <code>optimal auto settings</code> - Theoretical result for a solver that performed 'best of all' for every instance.
6003  * \arg <code>diff</code> - Solvers with instances that differ from the reference solver in the number of
6004  * processed nodes or in the total number of simplex iterations.
6005  * \arg <code>equal</code> - Solvers with instances whose number of processed nodes and total number of
6006  * simplex iterations is equal to the reference solver (including a 10% tolerance) and where no timeout
6007  * occured.
6008  * \arg <code>all optimal</code> - Solvers with instances that could be solved to optimality by
6009  * <em>all</em> solvers; in particular, no timeout occurred.
6010  *
6011  * Since this large amount of information is not always needed, one can generate a narrower table by calling:
6012  * \code
6013  * allcmpres.sh short=1 ...
6014  * \endcode
6015  * where <code>NodQ</code>, <code>TimQ</code> and the additional comparison tables are omitted.
6016  *
6017  * If the <code>res</code>-files were generated with the parameter <code>printsoltimes=1</code>
6018  * we can enable the same feature here as well by calling:
6019  * \code
6020  * allcmpres.sh printsoltimes=1 ...
6021  * \endcode
6022  * As in the evaluation, the output contains the two additional columns of the solving time until the first and the best solution was found.
6023  *
6024  * @section SOLVER Testing and Evaluating for other solvers
6025  *
6026  * Analogously to the target <code>test</code> there are further targets to run automated tests with other MIP solvers.
6027  * These are:
6028  * \arg for <a href="http://www-01.ibm.com/software/integration/optimization/cplex-optimizer/">cplex</a>
6029  * \code
6030  * make testcplex
6031  * \endcode
6032  * \arg for <a href="http://www.gurobi.com/">gurobi</a>
6033  * \code
6034  * make testgurobi
6035  * \endcode
6036  * \arg for <a href="https://projects.coin-or.org/Cbc">cbc</a>
6037  * \code
6038  * make testcbc
6039  * \endcode
6040  * \arg for <a href="http://www.mosek.com/">mosek</a>
6041  * \code
6042  * make testmosek
6043  * \endcode
6044  * \arg for <a href="http://www.gnu.org/software/glpk/">glpk</a>
6045  * \code
6046  * make testglpk
6047  * \endcode
6048  * \arg for <a href="https://projects.coin-or.org/SYMPHONY">symphony</a>
6049  * \code
6050  * make testsymphony
6051  * \endcode
6052  * \arg for <a href="https://projects.coin-or.org/CHiPPS">blis</a>
6053  * \code
6054  * make testblis
6055  * \endcode
6056  * \arg for <a href="http://www.gams.com/">gams</a>
6057  * \code
6058  * make testgams GAMSSOLVER=xyz
6059  * \endcode
6060  * For this target, the option GAMSSOLVER has to be given to specify the name of a GAMS solver to run, e.g. GAMSSOLVER=SCIP.
6061  * Additional advanced options specific to this target are:
6062  * GAMS to specify the GAMS executable (default: gams),
6063  * GAP to specify a gap limit (default: 0.0),
6064  * CLIENTTMPDIR to specify a directory where GAMS should put its scratch files (default: /tmp),
6065  * CONVERTSCIP to specify a SCIP which can be used to convert non-gams files into gams format (default: bin/scip, if existing; set to "no" to disable conversion).
6066  * The following options are NOT supported (and ignored): DISPFREQ, FEASTOL, LOCK.
6067  * A memory limit (MEM option) is only passed as workspace option to GAMS, but not enforced via ulimit (it's up to the solver to regard and obey the limit).
6068  *
6069  * Note: This works only if the referred programs are installed globally on your machine.
6070  *
6071  * The above options like <code>TIME</code> are also available for the other solvers.
6072  *
6073  * For cbc, cplex, gams, and gurobi another advanced option is available:
6074  * \arg <code>THREADS</code> - number of threads used in the solution process
6075  *
6076  * After the testrun there should be an <code>.out</code>, an <code>.err</code> and a <code>.res</code> file
6077  * with the same basename as described above.
6078  *
6079  * Furthermore you can also use the script <code>allcmpres.sh</code> for comparing results of different solvers.
6080  *
6081  */
6082 
6083 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6084 /**@page CHG1 Interface changes between SCIP 0.9 and SCIP 1.0
6085  *
6086  * @section CHGPARAM New parameters
6087  *
6088  * - All functions SCIP<datatype>Param() got a new parameter "isadvanced".
6089  * \n
6090  * This does not influence the performance of SCIP, but the position of the parameter in the settings menu.
6091  * Hence, if you do not care about this, you can assign any value to it.
6092  * You should add the corresponding flag to the SCIP<datatype>Param() calls in your own source code.
6093  *
6094  */
6095 
6096 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6097 /**@page CHG2 Interface changes between SCIP 1.0 and SCIP 1.1
6098  *
6099  * - SCIPcreateChild() has a new last parameter giving an estimate for value of best feasible solution in the subtree to
6100  * be created. One possibility is to use SCIPgetLocalOrigEstimate() for this value.
6101  *
6102  * - The callback \ref CONSCHECK in the constraint handlers now has a new parameter <code>printreason</code> that tells
6103  * a constraint handler to output the reason for a possible infeasibility of the solution to be checked using
6104  * SCIPinfoMessage(). Have a look at one of the constraint handlers implemented in SCIP to see how it works. This
6105  * methodology makes it possible to output the reason of a violation in human readable form, for instance, for the check
6106  * at the end of a SCIP run, where the obtained best solution is checked against the original formulation.\n This change
6107  * often has little effect on C-implementations, since this parameter can be safely ignored with respect to the
6108  * correctness of the code. The corresponding C++ method scip::ObjConshdlr::scip_check(), however, has to be extended
6109  * and will not compile otherwise.
6110  *
6111  * - SCIPcheckSolOrig() is restructured. The last two parameters have changed. They are now bools indicating
6112  * whether the reason for the violation should be printed to the standard output and whether all violations should be
6113  * printed. This reflects the changes in the constraint handlers above, which allow the automation of the feasibility
6114  * test. The pointers to store the constraint handler or constraint are not needed anymore.
6115  *
6116  * - New parameters "extension" and "genericnames" in SCIPprintTransProblem(), SCIPprintOrigProblem(),
6117  * SCIPwriteOrigProblem(), and SCIPwriteTransProblem() defining the requested format or NULL for default CIP format
6118  * and using generic names for the variables and constraints. Examples are
6119  * - <code>SCIPprintTransProblem(scip, NULL, NULL, TRUE)</code> displays the transformed problem in CIP format with
6120  * generic variables and constraint names
6121  * - <code>SCIPprintOrigProblem(scip, NULL, "lp", FALSE)</code> displays the original problem in LP format with
6122  * original variables and constraint names.
6123  *
6124  * - New callback method SCIP_DECL_READERWRITE(x) in type_reader.h; this method is called to write a problem to file
6125  * stream in the format the reader stands for; useful for writing the transformed problem in LP or MPS format. Hence,
6126  * also SCIPincludeReader() has changed.
6127  *
6128  * - New parameter "conshdlrname" in SCIPincludeLinconsUpgrade().
6129  *
6130  * - Added user pointer to callback methods of hash table, see pub_misc.h.
6131  *
6132  * - New parameter "extension" in SCIPreadProb(), defining a desired file format or NULL if file extension should be used.
6133  */
6134 
6135 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6136 /**@page CHG3 Interface changes between SCIP 1.1 and SCIP 1.2
6137  *
6138  *
6139  * @section CHGCALLBACKS New and changed callbacks
6140  *
6141  * - The callback SCIP_DECL_PRICERREDCOST(x) in the \ref PRICER "pricers" has two new parameters:
6142  * - A <code>result</code> pointer determines whether the pricer guarantees that there exist no more variables. This allows for early branching.
6143  * - A pointer for providing a lower bound.
6144  *
6145  * - The \ref CONS "constraint handlers" have two new callback methods (see type_cons.h for more details).
6146  * - SCIP_DECL_CONSCOPY(x) - this method can be used to copy a constraint.
6147  * - SCIP_DECL_CONSPARSE(x) - this method can be used to parse a constraint in CIP format.
6148  *
6149  * @section CHGINTERFUNC New parameters in interface methods
6150  *
6151  * - SCIPcalcMIR() in scip.h has two new parameter "mksetcoefsvalid" and "sol". The parameter "mksetcoefsvalid" stores
6152  * whether the coefficients of the mixed knapsack set ("mksetcoefs") computed in SCIPlpCalcMIR() are valid. If the mixed knapsack constraint obtained after aggregating LP rows
6153  * is empty or contains too many nonzero elements the generation of the <b>c-MIR cut</b> is aborted in SCIPlpCalcMIR() and "mksetcoefs" is not valid.
6154  * The input parameter "sol" can be used to separate a solution different from the LP solution.
6155  *
6156  * - SCIPgetVarClosestVlb() and SCIPgetVarClosestVub() in scip.h have a new parameter "sol". It can be used to obtain the <b>closest variable bound</b> w.r.t. a solution different from the LP solution.
6157  *
6158  * @section MISCELLANEOUS Miscellaneous
6159  *
6160  * - A significant change for <b>C++ users</b> is that all include files of SCIP
6161  * automatically detect C++ mode, i.e., no <code>extern "C"</code> is needed anymore.
6162  *
6163  * For further release notes we refer to the \ref RELEASENOTES "Release notes".
6164  */
6165 
6166 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6167 /**@page CHG4 Interface changes between SCIP 1.2 and SCIP 2.0
6168  *
6169  *
6170  * @section CHGCALLBACKS4 New and changed callbacks
6171  *
6172  *
6173  * - <b>Copying a SCIP instance</b>:
6174  * <br>
6175  * <br>
6176  * - All plugins, like \ref BRANCH "branching rules" and \ref HEUR "primal heuristics", have a new callback method (see, e.g.,
6177  * type_branch.h and type_heur.h for more details):
6178  * - SCIP_DECL_BRANCHCOPY(x), SCIP_DECL_HEURCOPY(x) etc.
6179  * - When copying a SCIP instance, these methods are called to copy the plugins.
6180  * <br>
6181  * <br>
6182  * - Constraint handlers have two new callback methods. One for copying the constraint handler plugins
6183  * SCIP_DECL_CONSHDLRCOPY() and the other for copying a constraint itself, SCIP_DECL_CONSCOPY().
6184  * <br>
6185  * <br>
6186  * - Variables have a new callback method (see type_var.h for more details):
6187  * - SCIP_DECL_VARCOPY(x) - When copying a SCIP instance, this method is called to copy the variables' data.
6188  * <br>
6189  * <br>
6190  * - The main problem has a new callback method (see type_prob.h for more details):
6191  * - SCIP_DECL_PROBCOPY(x) - When copying a SCIP instance, this method is called to copy the problem's data.
6192  * <br>
6193  * <br>
6194  * - The argument success in SCIP_DECL_CONSCOPY has been renamed to valid.
6195  *
6196  * - <b>Branching on externally given candidates</b>:
6197  * <br>
6198  * <br>
6199  * - The \ref BRANCH "branching rules" have a second new callback method (see type_branch.h for more details):
6200  * - SCIP_DECL_BRANCHEXECEXT(x) - This method can be used to branch on external branching candidates,
6201  * which can be added by a user's "relaxation handler" or "constraint handler" plugin, calling <code>SCIPaddExternBranchCand()</code>.
6202  *
6203  * - <b>Restarts</b>:
6204  * <br>
6205  * <br>
6206  * - The callback SCIP_DECL_PROBEXITSOL(x) in the main problem has one new parameter (see type_prob.h for more details):
6207  * - The parameter <code>restart</code> is <code>TRUE</code> if the callback method was triggered by a restart.
6208  *
6209  *
6210  * <br>
6211  * @section CHGINTERFUNC4 Changed interface methods
6212  *
6213  * - <b>Copying a SCIP instance</b>:
6214  * <br>
6215  * <br>
6216  * - Every new callback method resulted in a new parameter of the include function for the corresponding plugin,
6217  * e.g., SCIPincludeBranchrule() has two new parameters <code>SCIP_DECL_BRANCHCOPY((*branchcopy))</code> and
6218  * <code>SCIP_DECL_BRANCHEXECREL((*branchexecrel))</code>. In the same fashion, the new callbacks
6219  * SCIP_DECL_VARCOPY and SCIP_DECL_PROBCOPY led to new parameters in SCIPcreateVar() and SCIPcreateProb() in
6220  * scip.c, respectively.
6221  * <br><br>
6222  * - SCIPincludeHeur() and SCIPincludeSepa() in \ref scip.h, as well as scip::ObjSepa() and scip::ObjHeur(), have a new parameter:
6223  * - <code>usessubscip</code> - It can be used to inform SCIP that the heuristic/separator to be included uses a secondary SCIP instance.
6224  * <br><br>
6225  * - SCIPapplyRens() in \ref heur_rens.h has a new parameter <code>uselprows</code>. It can be used to switch from LP rows
6226  * to constraints as basis of the sub-SCIP constructed in the RENS heuristic.
6227  * <br>
6228  * <br>
6229  * - W.r.t. to copy and the C++ wrapper classes there are two new classes. These are <code>ObjCloneable</code> and
6230  * <code>ObjProbCloneable</code>. The constraint handlers and variables pricers are derived from
6231  * <code>ObjProbCloneable</code> and all other plugin are derived from <code>ObjCloneable</code>. Both
6232  * classes implement the function <code>iscloneable()</code> which return whether a plugin is clone
6233  * able or not. Besides that
6234  * each class has a function named <code>clone()</code> which differ in their signature.
6235  * See objcloneable.h, objprobcloneable.h, and the TSP example for more details.
6236  *
6237  * - <b>Branching</b>:
6238  * <br><br>
6239  * - The method SCIPgetVarStrongbranch() has been replaced by two methods SCIPgetVarStrongbranchFrac() and
6240  * SCIPgetVarStrongbranchInt().
6241  * <br><br>
6242  * - The methods SCIPgetVarPseudocost() and SCIPgetVarPseudocostCurrentRun() in \ref scip.h now return the pseudocost value of
6243  * one branching direction, scaled to a unit interval. The former versions of SCIPgetVarPseudocost() and
6244  * SCIPgetVarPseudocostCurrentRun() are now called SCIPgetVarPseudocostVal() and SCIPgetVarPseudocostValCurrentRun(), respectively.
6245  * <br>
6246  * <br>
6247  * - The methods SCIPgetVarConflictScore() and SCIPgetVarConflictScoreCurrentRun() in \ref scip.h are now called
6248  * SCIPgetVarVSIDS() and SCIPgetVarVSIDSCurrentRun(), respectively.
6249  * <br><br>
6250  * - The methods SCIPvarGetNInferences(), SCIPvarGetNInferencesCurrentRun(), SCIPvarGetNCutoffs(), and
6251  * SCIPvarGetNCutoffsCurrentRun() are now called SCIPvarGetInferenceSum(), SCIPvarGetInferenceSumCurrentRun(),
6252  * SCIPvarGetCutoffSum(), and SCIPvarGetCutoffSumCurrentRun(), respectively. Furthermore, they now return
6253  * <code>SCIP_Real</code> instead of <code>SCIP_Longint</code> values.
6254  *
6255  * - <b>Others</b>:
6256  * <br><br>
6257  * - SCIPcutGenerationHeuristicCmir() in \ref sepa_cmir.h has three new parameters:
6258  * - <code>maxmksetcoefs</code> - If the mixed knapsack constraint obtained after aggregating LP rows contains more
6259  * than <code>maxmksetcoefs</code> nonzero coefficients the generation of the <b>c-MIR cut</b> is aborted.
6260  * - <code>delta</code> - It can be used to obtain the scaling factor which leads to the best c-MIR cut found within
6261  * the cut generation heuristic. If a <code>NULL</code> pointer is passed, the corresponding c-MIR cut will already be
6262  * added to SCIP by SCIPcutGenerationHeuristicCmir(). Otherwise, the user can generate the cut and add it to SCIP
6263  * on demand afterwards.
6264  * - <code>deltavalid</code> - In case, the user wants to know the best scaling factor, i.e., <code>delta</code> passed is not <code>NULL</code>,
6265  * <code>deltavalid</code> will be <code>TRUE</code> if the stored scaling factor <code>delta</code> will lead to a violated c-MIR cut.
6266  * <br>
6267  * <br>
6268  * - All functions for setting <b>user parameters</b> of different types like SCIPparamSetBool(), SCIPparamSetChar(),
6269  * SCIPparamSetInt(), SCIPparamSetLongint(), and SCIPparamSetString() in pub_paramset.h have a new parameter:
6270  * - <code>quiet</code> - It prevents any output during the assign to a new value.
6271  *
6272  * <br>
6273  * @section MISCELLANEOUS4 Miscellaneous
6274  *
6275  * - The NLPI library is now a separate library that is required when linking against the SCIP library.
6276  * This requires changes to Makefiles that use SCIP, see the \ref RELEASENOTES "Release notes" for more details.
6277  *
6278  * - We do not distinguish between <b>block memory</b> for the original and the transformed problem anymore. The same
6279  * block memory is now used in both problem stages.
6280  *
6281  * - The usage of <b>strong branching</b> changed. Now, SCIPstartStrongbranch() and SCIPendStrongbranch() must be
6282  * called before and after strong branching, respectively.
6283  *
6284  * - All <b>C++</b> objects and constructors have a SCIP pointer, now.
6285  *
6286  * - The <b>predefined setting files</b> like "settings/cuts/off.set,aggressive.set,fast.set" have been replaced by
6287  * interface methods like SCIPsetHeuristics(), SCIPsetPresolving(), SCIPsetSeparating(), and SCIPsetEmphasis() in
6288  * \ref scip.h and by user dialogs in the interactive shell like
6289  * <br>
6290  * <br>
6291  * <code>SCIP&gt; set {heuristics|presolving|separating} emphasis {aggressive|fast|off}</code>
6292  * <br>
6293  * <br>
6294  * or
6295  * <br>
6296  * <br>
6297  * <code>SCIP&gt; set emphasis {counter|cpsolver|easycip|feasibility|hardlp|optimality}</code>
6298  *
6299  *
6300  * <br>
6301  * For further release notes we refer to the \ref RELEASENOTES "Release notes".
6302  */
6303 
6304 /* - SCIP now has "lazy bounds", which are useful for column generation - see @ref PRICER_REMARKS "pricer remarks" for an explanation.
6305  *
6306  * - SCIP has rudimentary support to solve quadratic nonlinear integer programs - see \ref cons_quadratic.h.
6307  *
6308  * - There are LP-interfaces to QSopt and Gurobi (rudimentary).
6309  *
6310  * - SCIP can now handle indicator constraints (reading (from LP, ZIMPL), writing, solving, ...) - see \ref cons_indicator.h.
6311  *
6312  * - One can now do "early branching" useful for column generation.
6313  *
6314  * - Can now run a black-box lexicographic dual simplex algorithm.
6315  */
6316 
6317  /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6318  /**@page CHG5 Interface changes between SCIP 2.0 and SCIP 2.1
6319  *
6320  *
6321  * @section CHGCALLBACKS5 New and changed callbacks
6322  *
6323  * - <b>Presolving</b>:
6324  * <br>
6325  * <br>
6326  * - The new parameters "nnewaddconss" and "naddconss" were added to the constraint handler callback method SCIP_DECL_CONSPRESOL()
6327  * and the presolver callback method SCIP_DECL_PRESOLEXEC(). These parameters were also added to corresponding C++ wrapper class methods.
6328  * - Propagators are now also called in during presolving, this is supported by the new callback methods SCIP_DECL_PROPINITPRE(),
6329  * SCIP_DECL_PROPEXITPRE(), and SCIP_DECL_PROPPRESOL().
6330  * - New parameters "isunbounded" and "isinfeasible" for presolving initialization (SCIP_DECL_CONSINITPRE(),
6331  * SCIP_DECL_PRESOLINITPRE(), SCIP_DECL_PROPINITPRE()) and presolving deinitialization (SCIP_DECL_CONSEXITPRE(),
6332  * SCIP_DECL_PRESOLEXITPRE(), SCIP_DECL_PROPEXITPRE()) callbacks of presolvers,
6333  * constraint handlers and propagators, telling the callback whether the problem was already declared to be
6334  * unbounded or infeasible. This allows to avoid expensive steps in these methods in case the problem is already
6335  * solved, anyway.
6336  * <br>
6337  * <br>
6338  * <DIV class="note">
6339  * Note, that the C++ methods
6340  * - scip::ObjConshdlr::scip_presol() corresponding to SCIP_DECL_CONSPRESOL()
6341  * - scip::ObjConshdlr::scip_initpre() corresponding to SCIP_DECL_CONSINITPRE()
6342  * - scip::ObjPresol::scip_initpre() corresponding to SCIP_DECL_PRESOLINITPRE()
6343  * - scip::ObjProp::scip_initpre() corresponding to SCIP_DECL_PROPINITPRE()
6344  * - scip::ObjConshdlr::scip_exitpre() corresponding to SCIP_DECL_CONSEXITPRE()
6345  * - scip::ObjPresol::scip_exitpre() corresponding to SCIP_DECL_PRESOLEXITPRE()
6346  * - scip::ObjProp::scip_exitpre() corresponding to and SCIP_DECL_PROPEXITPRE()
6347  * .
6348  * are virtual functions. That means, if you are not adding the new parameters, your code will still compile, but these methods are not executed.
6349  * </DIV>
6350  *
6351  * - <b>Constraint Handler</b>:
6352  * <br>
6353  * <br>
6354  * - The new constraint handler callback SCIP_DECL_CONSDELVARS() is called after variables were marked for deletion.
6355  * This method is optional and only of interest if you are using SCIP as a branch-and-price framework. That means,
6356  * you are generating new variables during the search. If you are not doing that just define the function pointer
6357  * to be NULL.
6358  * <br>
6359  * If this method gets implemented you should iterate over all constraints of the constraint handler and delete all
6360  * variables that were marked for deletion by SCIPdelVar().
6361  *
6362  * - <b>Problem Data</b>:
6363  * <br>
6364  * <br>
6365  * - The method SCIPcopyProb() and the callback SCIP_DECL_PROBCOPY() got a new parameter "global" to indicate whether the global problem or a local version is copied.
6366  *
6367  * - <b>Conflict Analysis</b>:
6368  * <br>
6369  * <br>
6370  * - Added parameter "separate" to conflict handler callback method SCIP_DECL_CONFLICTEXEC() that defines whether the conflict constraint should be separated or not.
6371  *
6372  * - <b>NLP Solver Interface</b>:
6373  * <br>
6374  * <br>
6375  * - The callbacks SCIP_DECL_NLPIGETSOLUTION() and SCIP_DECL_NLPISETINITIALGUESS() got new parameters to get/set values of dual variables.
6376  * - The callback SCIP_DECL_NLPICOPY() now passes the block memory of the target SCIP as an additional parameter.
6377  *
6378  * <br>
6379  * @section CHGINTERFUNC5 Changed interface methods
6380  *
6381  * - <b>Writing and Parsing constraints</b>:
6382  * <br>
6383  * <br>
6384  * - The methods SCIPwriteVarName(), SCIPwriteVarsList(), and SCIPwriteVarsLinearsum() got a new boolean parameter "type"
6385  * that indicates whether the variable type should be written or not.
6386  * - The method SCIPwriteVarsList() got additionally a new parameter "delimiter" that defines the character which is used for delimitation.
6387  * - The methods SCIPparseVarName() and SCIPparseVarsList() got a new output parameter "endptr" that is filled with the position where the parsing stopped.
6388  *
6389  * - <b>Plugin management</b>:
6390  * <br>
6391  * <br>
6392  * - SCIPincludeProp() got additional parameters to set the timing mask of the propagator and the new callbacks and parameters related to calling the propagator in presolving.
6393  * - SCIPincludeConshdlr() got additional parameters to set the variable deletion callback function and the timing mask for propagation.
6394  *
6395  * - <b>Constraint Handlers</b>:
6396  * <br>
6397  * <br>
6398  * - Method SCIPseparateRelaxedKnapsack() in knapsack constraint handler got new parameter "cutoff", which is a pointer to store whether a cutoff was found.
6399  * - Method SCIPincludeQuadconsUpgrade() of quadratic constraint handler got new parameter "active" to indicate whether the upgrading method is active by default.
6400  *
6401  * - <b>Nonlinear expressions, relaxation, and solver interface</b>:
6402  * <br>
6403  * <br>
6404  * - The methods SCIPexprtreeEvalSol(), SCIPexprtreeEvalIntLocalBounds(), and SCIPexprtreeEvalIntGlobalBounds() have been renamed to SCIPevalExprtreeSol(),
6405  * SCIPevalExprtreeLocalBounds(), and SCIPevalExprtreeGlobalBounds() and are now located in scip.h.
6406  * - Various types and functions dealing with polynomial expressions have been renamed to use the proper terms "monomial" and "polynomial".
6407  * - The methods SCIPnlpGetObjective(), SCIPnlpGetSolVals(), and SCIPnlpGetVarSolVal() have been removed, use SCIPgetNLPObjval(), SCIPvarGetNLPSol()
6408  * and SCIPcreateNLPSol() to retrieve NLP solution values instead.
6409  * - Removed methods SCIPmarkRequireNLP() and SCIPisNLPRequired(), because the NLP is now always constructed if nonlinearities are present.
6410  * - SCIPgetNLP() has been removed and NLP-methods from pub_nlp.h have been moved to scip.h, which resulted in some renamings, too.
6411  * - The functions SCIPnlpiGetSolution() and SCIPnlpiSetInitialGuess() got additional arguments to get/set dual values.
6412  * - The method SCIPgetNLPI() got a new parameter "nlpiproblem", which is a pointer to store the NLP solver interface problem.
6413  *
6414  * - <b>Others</b>:
6415  * <br>
6416  * <br>
6417  * - SCIPgetVarCopy() got a new parameter "success" that will be FALSE if method is called after problem creation stage and no hash map is given or no image for
6418  * the given variable is contained in the given hash map.
6419  * - Removed method SCIPreadSol(); call solution reading via SCIPreadProb() which calls the solution reader for .sol files.
6420  * - SCIPchgVarType() got an extra boolean parameter to store if infeasibility is recognized while upgrading a variable from continuous type to an integer type.
6421  * - SCIPdelVar() got a new parameter "deleted", which stores whether the variable was successfully marked to be deleted.
6422  * - SCIPcalcNodeselPriority() got a new parameter "branchdir", which defines the type of branching that was performed: upwards, downwards, or fixed.
6423  * - The parameters "timelimit" and "memorylimit" were removed from SCIPapplyRens().
6424  *
6425  * <br>
6426  * @section MISCELLANEOUS5 Miscellaneous
6427  *
6428  * - The result value SCIP_NEWROUND has been added, it allows a separator/constraint handler to start a new separation round
6429  * (without previous calls to other separators/conshdlrs).
6430  * - All timing flags are now defined type_timing.h.
6431  * - The variable deletion event is now a variable specific event and not global, anymore.
6432  * - The emphasis setting types now distinguish between plugin-type specific parameter settings (default, aggressive, fast, off), which are changed by
6433  * SCIPsetHeuristics/Presolving/Separating(), and global emphasis settings (default, cpsolver, easycip, feasibility, hardlp, optimality, counter),
6434  * which can be set using SCIPsetEmphasis().
6435  *
6436  * <br>
6437  * For further release notes we refer to the \ref RELEASENOTES "Release notes".
6438  */
6439 
6440  /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6441  /**@page CHG6 Interface changes between SCIP 2.1 and SCIP 3.0
6442  *
6443  *
6444  * @section CHGCALLBACKS6 New and changed callbacks
6445  *
6446  * - <b>Conflict Analysis</b>:
6447  * <br>
6448  * <br>
6449  * - Added parameter "relaxedbds" to conflict handler callback method SCIP_DECL_CONFLICTEXEC(). This array contains
6450  * bounds which are sufficient to create a valid conflict
6451  *
6452  * - <b>Constraint Handler</b>:
6453  * <br>
6454  * <br>
6455  * - New optional callback methods in constraint handlers: SCIP_DECL_CONSGETVARS and SCIP_DECL_CONSGETNVARS.
6456  * These callbacks, if implemented, should return an array of all variables and the number of all variables used
6457  * by the given constraint, respectively. (This method might, e.g., be called by a presolver)
6458  * - Added a propagation timing parameter "proptiming" to SCIP_DECL_CONSPROP(), giving the current timing at which
6459  * this method is called
6460  * - Added a parameter 'restart' to the SCIP_DECL_CONSEXITSOL() callback method, indicating whether this call was
6461  * triggered by a restart.
6462  * - Added a parameter 'relaxedbd' to SCIP_DECL_CONSRESPROP() callback method. If explaining a given bound change
6463  * (index), it is sufficient to explain the reason for reaching the 'relaxedbd' value, see above
6464  * - Removed parameters "isunbounded", "isinfeasible" and "result" from SCIP_DECL_CONSINITPRE() and
6465  * SCIP_DECL_CONSEXITPRE() callback methods. It is not allowed to determine unboundedness or infeasibility in
6466  * these callbacks, anymore.
6467  *
6468  * - <b>Message Handler</b>:
6469  * <br>
6470  * <br>
6471  * - New callback method SCIP_DECL_MESSAGEHDLRFREE() which is called when the message handler is freed.
6472  * - The old callback method SCIP_DECL_MESSAGEERROR() was replaced by the callback method SCIP_DECL_ERRORPRINTING().
6473  *
6474  * - <b>Presolving</b>:
6475  * <br>
6476  * <br>
6477  * - Removed parameters "isunbounded", "isinfeasible" and "result" from SCIP_DECL_PRESOLINITPRE() and
6478  * SCIP_DECL_PRESOLSEXITPRE(). It is not allowed to determine unboundedness or infeasibility in these
6479  * callbacks, anymore.
6480  *
6481  * - <b>Propagator</b>:
6482  * <br>
6483  * <br>
6484  * - Added a propagation timing parameter "proptiming" to SCIP_DECL_PROPEXEC(), giving the
6485  * current timing at which this method is called.
6486  * - Added a parameter 'restart' to SCIP_DECL_PROPEXITSOL() callback method, indicating whether this call was
6487  * triggered by a restart.
6488  * - Added a parameter 'relaxedbd' to SCIP_DECL_PROPRESPROP() callback method. If explaining a given bound change
6489  * (index), it is sufficient to explain the reason for reaching the 'relaxedbd' value.
6490  * - Removed parameters "isunbounded", "isinfeasible" and "result" from SCIP_DECL_PROPINITPRE() and
6491  * SCIP_DECL_PROPEXITPRE() callback methods. It is not allowed to determined unboundedness or infeasibility in
6492  * these callbacks, anymore.
6493  *
6494  * - <b>NLP Solver Interface</b>:
6495  * <br>
6496  * <br>
6497  * - New NLPI callback SCIP_DECL_NLPISETMESSAGEHDLR() to set message handler in NLP solver interfaces.
6498  *
6499  * <br>
6500  * @section CHGINTERFUNC6 Changed interface methods
6501  *
6502  * - <b>Plugin management</b>:
6503  * <br>
6504  * <br>
6505  * - Added basic include methods for almost all plugin types, e.g., SCIPincludeConshdlrBasic();
6506  * these methods should make the usage easier, sparing out optional callbacks and parameters.
6507  * - To extend the basic functionalities, there are setter method to add
6508  * optional callbacks. For example SCIPsetConshdlrParse(), SCIPsetPropCopy() or SCIPsetHeurInitsol().
6509  *
6510  * - <b>Constraint Handlers</b>:
6511  * <br>
6512  * <br>
6513  * - Added basic creation methods for all constraints types, e.g., SCIPcreateConsBasicLinear(); these methods should make the usage easier,
6514  * sparing out optional callbacks and parameters.
6515  * - New methods SCIPgetConsVars() and SCIPgetConsNVars() (corresponding callbacks need to be implemented, see above)
6516  *
6517  * - <b>Problem</b>:
6518  * <br>
6519  * <br>
6520  * - Added basic creation methods SCIPcreateVarBasic() and SCIPcreateProbBasic() and setter functions
6521  * - Added method SCIPisPresolveFinished() which returns whether the presolving process would be stopped after the
6522  * current presolving round, given no further reductions will be found.
6523  * - Forbid problem modifications in SCIP_STAGE_{INIT,EXIT}PRESOLVE (see pre-conditions for corresponding methods in scip.h).
6524  *
6525  * - <b>Variable usage</b>:
6526  * <br>
6527  * <br>
6528  * - Renamed SCIPvarGetBestBound() to SCIPvarGetBestBoundLocal(), SCIPvarGetWorstBound() to
6529  * SCIPvarGetWorstBoundLocal() and added new methods SCIPvarGetBestBoundGlobal() and SCIPvarGetWorstBoundGlobal().
6530  * - Method SCIPvarGetProbvarSum() is not public anymore, use SCIPgetProbvarSum() instead.
6531  * - Replaced method SCIPvarGetRootRedcost() by SCIPvarGetBestRootRedcost().
6532  *
6533  * - <b>Message Handler</b>:
6534  * <br>
6535  * <br>
6536  * - Changed the message handler system within SCIP heavily such that it is thread-safe. SCIPcreateMessagehdlr() in
6537  * scip.{c,h} was replaced by SCIPmessagehdlrCreate() in pub_message.h/message.c with a changed parameter list.
6538  * - Error messages (SCIPerrorMessage()) are not handled via the message handler anymore; per default the error
6539  * message is written to stderr.
6540  *
6541  * - <b>Separation</b>:
6542  * <br>
6543  * <br>
6544  * - New functions SCIPcreateEmptyRowCons(), SCIPcreateEmptyRowSepa(), SCIPcreateRowCons(), and SCIPcreateRowSepa()
6545  * that allow to set the originating constraint handler or separator of a row respectively; this is, for instance,
6546  * needed for statistics on the number of applied cuts. If rows are created outside a constraint handler or separator
6547  * use SCIPcreateRowUnspec() and SCIPcreateEmptyRowUnspec(). The use of SCIPcreateEmptyRow() and SCIPcreateRow() is
6548  * deprecated.
6549  * - New functions SCIProwGetOrigintype(), SCIProwGetOriginCons(), and SCIProwGetOriginSepa() to obtain the originator
6550  * that created a row.
6551  *
6552  * - <b>LP interface</b>:
6553  * <br>
6554  * <br>
6555  * - SCIPlpiCreate() got a new parameter 'messagehdlr'.
6556  * - SoPlex LPI supports setting of SCIP_LPPAR_DUALFEASTOL when using SoPlex version 1.6.0.5 and higher.
6557  *
6558  * - <b>Nonlinear expressions, relaxation, and solver interface</b>:
6559  * <br>
6560  * <br>
6561  * - Renamed SCIPmarkNonlinearitiesPresent() to SCIPenableNLP() and SCIPhasNonlinearitiesPresent() to
6562  * SCIPisNLPEnabled().
6563  * - Method SCIPexprtreeRemoveFixedVars() is not public anymore.
6564  *
6565  * - <b>Counting</b>:
6566  * <br>
6567  * <br>
6568  * - Changed the counting system within SCIP heavily. SPARSESOLUTION was renamed to SCIP_SPARSESOL. New method for
6569  * SCIP_SPARSESOL usage, SCIPsparseSolCreate(), SCIPsparseSolFree(), SCIPsparseSolGetVars(),
6570  * SCIPsparseSolGetNVars(), SCIPsparseSolGetLbs(), SCIPsparseSolGetUbs() in (pub_)misc.{c,h}.
6571  * - Renamed SCIPgetCountedSparseSolutions() to SCIPgetCountedSparseSols() in cons_countsols.{c,h}.
6572  *
6573  * <br>
6574  * @section MISCELLANEOUS6 Miscellaneous
6575  *
6576  * - Replaced SCIPparamSet*() by SCIPchg*Param() (where * is either Bool, Int, Longint, Real, Char, or String).
6577  * - New parameter in SCIPcopy() and SCIPcopyPlugins() to indicate whether the message handler from the source SCIP
6578  * should be passed to the target SCIP (only the pointer is copied and the usage counter of the message handler is
6579  * increased).
6580  * - SCIPprintCons() does not print termination symbol ";\n" anymore; if wanted, use SCIPinfoMessage() to print
6581  * ";\n" manually
6582  * - All objscip *.h file now use the default SCIP interface macros.
6583  * - The methods SCIPsortedvecInsert*() have an additional parameter which can be used to receive the position where
6584  * the new element was inserted.
6585  * - New macro SCIPdebugPrintCons() to print constraint only if SCIP_DEBUG flag is set.
6586  *
6587  * <br>
6588  * For further information we refer to the \ref RELEASENOTES "Release notes" and the \ref CHANGELOG "Changelog".
6589  */
6590 
6591  /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6592  /**@page CHG7 Interface changes between SCIP 3.0 and SCIP 3.1
6593  *
6594  *
6595  * @section CHGCALLBACKS7 New and changed callbacks
6596  *
6597  * - <b>Branching Rules</b>:
6598  * <br>
6599  * <br>
6600  * - new possible return value "SCIP_DIDNOTFIND" for SCIP_DECL_BRANCHEXECLP(), SCIP_DECL_BRANCHEXECPS(), and
6601  * SCIP_DECL_BRANCHEXECEXT() callbacks to state that the branching rule searched, but did not find a branching.
6602  *
6603  * - <b>Domain Propagation</b>:
6604  * <br>
6605  * <br>
6606  * - added parameter "nmarkedconss" to SCIP_DECL_CONSPROP() callback which gives the number of constraints marked
6607  * for propagation (these constraints are listed first in the conss array given as parameter).
6608  *
6609  * - <b>Message Handler</b>:
6610  * <br>
6611  * <br>
6612  * - New generic messagehandler output callback method SCIP_DECL_MESSAGEOUTPUTFUNC().
6613  * - Removed parameter "msglength" from callback method SCIP_DECL_ERRORPRINTING().
6614  *
6615  * - <b>Variable Pricers</b>:
6616  * <br>
6617  * <br>
6618  * - Added parameter "stopearly" to callback method SCIP_DECL_PRICERREDCOST(). This boolean pointer should be used
6619  * by the pricer to state whether early branching should be performed, even if new variables were added in the
6620  * current pricing round.
6621  *
6622  * - <b>Primal Heuristics</b>:
6623  * <br>
6624  * <br>
6625  * - Added parameter "nodeinfeasible" to SCIP_DECL_HEUREXEC() callback which states whether the current subproblem
6626  * was already detected to be infeasible. In this case, the current LP solution might not respect local bounds,
6627  * and the heuristic must not assume that it does.
6628  *
6629  *
6630  * <br>
6631  * @section CHGINTERFUNC7 Changed interface methods
6632  *
6633  * - <b>Branching Rules</b>:
6634  * <br>
6635  * <br>
6636  * - Added parameter "nfracimplvars" to SCIPgetLPBranchCands()
6637  *
6638  * - <b>Constraint Handlers</b>:
6639  * <br>
6640  * <br>
6641  * - New method SCIPconshdlrGetStrongBranchPropTime() which returns the time used for domain propagation methods
6642  * of the constraint handler during strong branching.
6643  * - New method SCIPconsIsMarkedPropagate() which returns whether a constraint is marked for propagation.
6644  * - New methods SCIPconsAddUpgradeLocks() and SCIPconsGetNUpgradeLocks() to increase or get the number of upgrade
6645  * locks of a constraint.
6646  *
6647  * - <b>Domain Propagation</b>:
6648  * <br>
6649  * <br>
6650  * - New method SCIPpropGetStrongBranchPropTime() which returns the time spent by a domain propagator during strong
6651  * branching.
6652  * - New methods SCIPmarkConsPropagate() and SCIPunmarkConsPropagate to (un)mark a constraint for propagation.
6653  *
6654  * - <b>LP and Cutting Planes</b>:
6655  * <br>
6656  * <br>
6657  * - New methods SCIProwChgRank() and SCIProwGetRank() to change and get the rank of a cutting plane, respectively.
6658  * - Added parameter "sidetypes" to SCIPcalcMIR() to specify the specify row side type to be used.
6659  * - Added parameter "cutrank" to SCIPcalcMIR() and SCIPcalcStrongCG() which stores the rank of the returned cut.
6660  * - New method SCIPisCutApplicable() which returns whether a cut is good enough to be applied.
6661  * - Added parameter "infeasible" to SCIPaddCut() which is a pointer to store whether the cut is infeasible for the
6662  * local bounds.
6663  * - delayed cutpool
6664  * - New methods SCIPchgRowLhsDive() and SCIPchgRowRhsDive() to change left and right hand side of a row during diving.
6665  * - Added parameter "cutoff" to SCIPsolveDiveLP(), SCIPsolveProbingLP(), and SCIPsolveProbingLPWithPricing()
6666  * which is a pointer to store whether the diving/probing LP was infeasible or the objective limit was reached.
6667  *
6668  * - <b>Message Handler</b>:
6669  * <br>
6670  * <br>
6671  * - New method SCIPmessageVPrintError() to print an error message.
6672  * - Removed method SCIPmessagePrintWarningHeader().
6673  *
6674  * - <b>Parameters</b>:
6675  * <br>
6676  * <br>
6677  * - New method SCIPparamGetCharAllowedValues() to get the allowed values for a char parameter.
6678  *
6679  * - <b>Variables</b>:
6680  * <br>
6681  * <br>
6682  * - New structure to store value-based branching and inference history (see pub_history.h).
6683  * - New method SCIPvarGetValuehistory() to get the value-based history of a variable.
6684  *
6685  * - <b>Data structures</b>:
6686  * <br>
6687  * <br>
6688  * - New method SCIPgmlWriteNodeWeight() to write a node section including weight to a .gml graph file.
6689  * - New methods SCIPsparseSolGetFirstSol() and SCIPsparseSolGetNextSol() to get the first sparse solution
6690  * or iterate over the sparse solutions, respectively.
6691  * - New methods in pub_misc.h to handle a (circular) queue, e.g., SCIPqueueCreate(), SCIPqueueFree(),
6692  * SCIPqueueInsert(), ...
6693  * - New methods for hash tables: SCIPhashtableRemoveAll(), SCIPhashtableGetNElements(), SCIPhashtableGetLoad()
6694  * - New methods in pub_misc.h to handle a resource activity, e.g., SCIPactivityCreate(), SCIPactivityFree(),
6695  * SCIPactivityGetVar(), SCIPactivityGetDemand() ...
6696  * - New methods for digraphs: SCIPdigraphResize() to resize the graph and SCIPdigraphSetNodeDatas() and
6697  * SCIPdigraphGetNodeDatas() to set and get the data attached to the nodes.
6698  *
6699  * - <b>Misc</b>:
6700  * <br>
6701  * <br>
6702  * - New method SCIPcopyOrig() to copy the original problem. Analoguosly, use SCIPcopyOrigProb(), SCIPcopyOrigVars(),
6703  * and SCIPcopyOrigConss() to copy original problem data, variables, or constraints, respectively.
6704  * - New method SCIPcopyImplicationsCliques() to copy implications and cliques to a copied SCIP instance.
6705  * - New method SCIPgetParam() to get the parameter with a given name.
6706  * - New method SCIPaddOrigObjoffset() to add an offset to the objective function.
6707  * - New method SCIPgetNCheckConss() which returns the number of checked constraints.
6708  * - Added parameter "endptr" to SCIPparseVar() which stores the final string position after parsing.
6709  * - Added parameter "enablepropagation" to SCIPstartStrongbranch(), which can be used to enable strong branching
6710  * with domain propagation.
6711  * - New method SCIPgetVarStrongbranchWithPropagation() which performs strong branching with propagation on a variable.
6712  * - New method SCIPwriteCliqueGraph() to write the clique graph.
6713  * - New method SCIPdoNotMultaggr() which returns whether multi-aggregation was disabled.
6714  * - Added parameter "lazyconss" to SCIPwriteMIP() to swith writing removable rows as lazy constraints.
6715  * - New method SCIPcreateFiniteSolCopy() to create a copy of a solution with infinite fixings removed.
6716  * - New method SCIPadjustImplicitSolVals() which sets implicit integer variables to an integer value in the given
6717  * solution without deteriorating its objective value.
6718  * - New method SCIPprintDualSol() which prints the dual solution for a pure LP (works only with preprocessing disabled).
6719  * - New method SCIPgetOpenNodesData() which returns all unprocessed nodes.
6720  * - New method SCIPgetFirstLPTime() and SCIPgetNRootFirstLPIterations() to return time and iterations for the first
6721  * LP solve and SCIPgetFirstLPDualboundRoot() and SCIPgetFirstLPLowerboundRoot() to return the first root LP dual and
6722  * lower bound.
6723  * - New method SCIPgetNLimSolsFound() returning the number of feasible primal solution respecting the objective limit.
6724  * - Added parameter "endline" to SCIPprintDisplayLine() to switch printing a newline symbol at the end of the line.
6725  *
6726  * <br>
6727  * @section MISCELLANEOUS7 Miscellaneous
6728  *
6729  * - Moved LP solver interfaces to subdirectory src/lpi.
6730  *
6731  * <br>
6732  * For further information we refer to the \ref RELEASENOTES "Release notes" and the \ref CHANGELOG "Changelog".
6733  */
6734 
6735 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6736 /**@page COUNTER How to use SCIP to count/enumerate feasible solutions
6737  *
6738  * SCIP is capable of computing (count or enumerate) the number of feasible solutions of a given constraint integer
6739  * program. In case continuous variables are present, the number of feasible solutions for the projection to the
6740  * integral variables is counted/enumerated. This means, an assignment to the integer variables is counted if the
6741  * remaining problem (this is the one after fixing the integer variables w.r.t. to this assignment) is feasible.
6742  *
6743  * As a first step you have to load or create your problem in the usual way. In case of using the
6744  * interactive shell, you use the <code>read</code> command:
6745  *
6746  * <code>SCIP&gt; read &lt;file name&gt;</code>
6747  *
6748  * Afterwards you can count the number of feasible solution with the command <code>count</code>.
6749  *
6750  * <code>SCIP&gt; count</code>
6751  *
6752  * That means SCIP will count the number of solution but does not store (enumerate) them. If you are interested in that see
6753  * \ref COLLECTALLFEASEBLES.
6754  *
6755  * @note Since SCIP version 2.0.0 you do not have to worry about <tt>dual</tt> reductions anymore. These are
6756  * automatically turned off. The only thing you should switch off are restarts. These restarts can lead to a wrong
6757  * counting process. We recommend using the counting settings which can be set in the interactive shell as follows:
6758  *
6759  * <code>SCIP&gt; set emphasis counter</code>
6760  *
6761  * The SCIP callable library provides an interface method SCIPcount() which allows users to count the number of feasible
6762  * solutions to their problem. The method SCIPsetParamsCountsols(), which is also located in cons_countsols.h, loads the
6763  * predefined counting settings to ensure a safe count. The complete list of all methods that can be used for counting
6764  * via the callable library can be found in cons_countsols.h.
6765  *
6766  *
6767  * @section COUNTLIMIT Limit the number of solutions which should be counted
6768  *
6769  * It is possible to give a (soft) upper bound on the number solutions that should be counted. If this upper bound is
6770  * exceeded, SCIP will be stopped. The name of this parameter is <code>constraints/countsols/sollimit</code>. In
6771  * the interactive shell this parameter can be set as follows:
6772  *
6773  * <code>SCIP&gt; set constraints countsols sollimit 1000</code>
6774  *
6775  * In case you are using the callable library, this upper bound can be assigned by calling SCIPsetLongintParam() as follows:
6776  *
6777  * \code
6778  * SCIP_CALL( SCIPsetLongintParam( scip, "constraints/countsols/sollimit", 1000) );
6779  * \endcode
6780  *
6781  *
6782  * The reason why this upper bound is soft comes from the fact that, by default, SCIP uses a technique called unrestricted
6783  * subtree detection. Using this technique it is possible to detect several solutions at once. Therefore, it can happen
6784  * that the solution limit is exceeded before SCIP is stopped.
6785  *
6786  * @section COLLECTALLFEASEBLES Collect all feasible solution
6787  *
6788  * Per default SCIP only counts all feasible solutions. This means, these solutions are not stored. If you switch the
6789  * parameter <code>constraints/countsols/collect</code> to TRUE (the default value is FALSE) the detected solutions are
6790  * stored. Changing this parameter can be done in the interactive shell
6791  *
6792  * <code>SCIP&gt; set constraints countsols collect TRUE</code>
6793  *
6794  * as well as via the callable library
6795  *
6796  * \code
6797  * SCIP_CALL( SCIPsetBoolParam( scip, "constraints/countsols/collect", TRUE) );
6798  * \endcode
6799  *
6800  * @note The solution which are collected are stored w.r.t. the active variables. These are the variables which got not
6801  * removed during presolving.
6802  *
6803  * In case you are using the interactive shell you can write all collected solutions to a file as follows
6804  *
6805  * <code>SCIP&gt; write allsolutions &lt;file name&gt;</code>
6806  *
6807  * In that case the sparse solutions are unrolled and lifted back into the original variable space.
6808  *
6809  * The callable library provides a method which gives access to all collected sparse solutions. That is,
6810  * SCIPgetCountedSparseSolutions(). The sparse solutions you get are defined w.r.t. active variables. To get solutions
6811  * w.r.t. to the original variables. You have to do two things:
6812  *
6813  * -# unroll each sparse solution
6814  * -# lift each solution into original variable space by extending the solution by those variable which got removed
6815  * during presolving
6816  *
6817  * The get the variables which got removed during presolving, you can use the methods SCIPgetFixedVars() and
6818  * SCIPgetNFixedVars(). The method SCIPgetProbvarLinearSum() transforms given variables, scalars and constant to the
6819  * corresponding active variables, scalars and constant. Using this method for a single variable gives a representation
6820  * for that variable w.r.t. the active variables which can be used to compute the value for the considered solution (which
6821  * is defined w.r.t. active variables).
6822  *
6823  * For that complete procedure you can also check the source code of
6824  * \ref SCIP_DECL_DIALOGEXEC(SCIPdialogExecWriteAllsolutions) "SCIPdialogExecWriteAllsolutions()" cons_countsols.c which
6825  * does exactly that.
6826  *
6827  *
6828  * @section COUNTOPTIMAL Count number of optimal solutions
6829  *
6830  * If you are interested in counting the number of optimal solutions, this can be done with SCIP using the
6831  * <code>count</code> command by applying the following steps:
6832  *
6833  * -# Solve the original problem to optimality and let \f$c^*\f$ be the optimal value
6834  * -# Add the objective function as constraint with left and right hand side equal to \f$c^*\f$
6835  * -# load the adjusted problem into SCIP
6836  * -# use the predefined counting settings
6837  * -# start counting the number of feasible solutions
6838  *
6839  * If you do this, SCIP will collect all optimal solutions of the original problem.
6840  *
6841  */
6842 
6843 /**@page LICENSE License
6844  *
6845  * \verbinclude COPYING
6846  */
6847 
6848 /**@page FAQ Frequently Asked Questions (FAQ)
6849  * \htmlinclude faq.inc
6850  */
6851 
6852 
6853 /**@page AUTHORS SCIP Authors
6854  * \htmlinclude authors.inc
6855  */
6856 
6857 /**@page INSTALL Installation information
6858  * \verbinclude INSTALL
6859  */
6860 
6861 /**@page RELEASENOTES Release notes
6862  *
6863  * \verbinclude SCIP-release-notes-3.1
6864  *
6865  * \verbinclude SCIP-release-notes-3.0.2
6866  *
6867  * \verbinclude SCIP-release-notes-3.0.1
6868  *
6869  * \verbinclude SCIP-release-notes-3.0
6870  *
6871  * \verbinclude SCIP-release-notes-2.1.1
6872  *
6873  * \verbinclude SCIP-release-notes-2.1
6874  *
6875  * \verbinclude SCIP-release-notes-2.0.2
6876  *
6877  * \verbinclude SCIP-release-notes-2.0.1
6878  *
6879  * \verbinclude SCIP-release-notes-2.0
6880  *
6881  * \verbinclude SCIP-release-notes-1.2
6882  *
6883  * \verbinclude SCIP-release-notes-1.1
6884  */
6885 
6886 /**@page CHANGELOG CHANGELOG
6887  *
6888  * \verbinclude CHANGELOG
6889  *
6890  */
6891 
6892 /**@defgroup PUBLICMETHODS Public Methods
6893  *
6894  * This page lists headers containing methods provided by the core of SCIP that can be used via the
6895  * callable library. If you are in the <a href="../html">User's Manual</a> you only find methods that are
6896  * public and, therefore, allowed to be used. The <a href="../html_devel">Developer's Manual</a> includes
6897  * all methods.
6898  *
6899  * All of the headers listed below include functions that are allowed to be called by external users. Besides those
6900  * functions it is also valid to call methods that are listed in one of the headers of the (default) plugins, e.g.,
6901  * cons_linear.h.
6902  *
6903  * If you are looking for information about a particular object of SCIP, such as a variable or a constraint, you should
6904  * first search the corresponding "pub_<...>.h" header. E.g., for constraints, look in pub_cons.h. If you need some
6905  * information about the overall problem, you should start searching in scip.h.
6906  *
6907  * Since there is a huge number of methods in scip.h, these methods are grouped into different categories. These
6908  * categories are:
6909  *
6910  * - Memory Management
6911  * - Miscellaneous Methods
6912  * - General SCIP Methods
6913  * - Message Output Methods
6914  * - Parameter Methods
6915  * - SCIP User Functionality Methods: Managing Plugins
6916  * - User Interactive Dialog Methods
6917  * - Global Problem Methods
6918  * - Local Subproblem Methods
6919  * - Solve Methods
6920  * - Variable Methods
6921  * - Conflict Analysis Methods
6922  * - Constraint Methods
6923  * - LP Methods
6924  * - LP Column Methods
6925  * - LP Row Methods
6926  * - Cutting Plane Methods
6927  * - LP Diving Methods
6928  * - Probing Methods
6929  * - Branching Methods
6930  * - Primal Solution Methods
6931  * - Event Methods
6932  * - Tree Methods
6933  * - Statistic Methods
6934  * - Timing Methods
6935  * - Numerical Methods
6936  * - Dynamic Arrays
6937  *
6938  */
6939 
6940 /**@defgroup TYPEDEFINITIONS Type Definitions
6941  * This page lists headers which contain type definitions of callback methods.
6942  *
6943  * All headers below include the descriptions of callback methods of
6944  * certain plugins. For more detail see the corresponding header.
6945  */
6946 
6947 /**@defgroup BRANCHINGRULES Branching Rules
6948  * @brief This page contains a list of all branching rule which are currently available.
6949  *
6950  * A detailed description what a branching rule does and how to add a branching rule to SCIP can be found
6951  * \ref BRANCH "here".
6952  */
6953 
6954 /**@defgroup CONSHDLRS Constraint Handler
6955  * @brief This page contains a list of all constraint handlers which are currently available.
6956  *
6957  * A detailed description what a constraint handler does and how to add a constraint handler to SCIP can be found
6958  * \ref CONS "here".
6959  */
6960 
6961 /**@defgroup DIALOGS Dialogs
6962  * @brief This page contains a list of all dialogs which are currently available.
6963  *
6964  * A detailed description what a dialog does and how to add a dialog to SCIP can be found
6965  * \ref DIALOG "here".
6966  */
6967 
6968 /**@defgroup DISPLAYS Displays
6969  * @brief This page contains a list of all displays (output columns) which are currently available.
6970  *
6971  * A detailed description what a display does and how to add a display to SCIP can be found
6972  * \ref DISP "here".
6973  *
6974  */
6975 
6976 /**@defgroup EXPRINTS Expression Interpreter
6977  * @brief This page contains a list of all expression interpreter which are currently available.
6978  *
6979  * A detailed description what a expression interpreter does and how to add a expression interpreter to SCIP can be found
6980  * \ref EXPRINT "here".
6981  */
6982 
6983 /**@defgroup FILEREADERS File Readers
6984  * @brief This page contains a list of all file readers which are currently available.
6985  *
6986  * @section AVAILABLEFORMATS List of readable file formats
6987  *
6988  * The \ref SHELL "interactive shell" and the callable library are capable of reading/parsing several different file
6989  * formats.
6990  *
6991  * <table>
6992  * <tr><td>\ref reader_cip.h "CIP format"</td> <td>for SCIP's constraint integer programming format</td></tr>
6993  * <tr><td>\ref reader_cnf.h "CNF format"</td> <td>DIMACS CNF (conjunctive normal form) file format used for example for SAT problems</td></tr>
6994  * <tr><td>\ref reader_fzn.h "FZN format"</td> <td>FlatZinc is a low-level solver input language that is the target language for MiniZinc</td></tr>
6995  * <tr><td>\ref reader_gms.h "GMS format"</td> <td>for mixed-integer nonlinear programs (<a href="http://www.gams.com/docs/document.htm">GAMS</a>) [reading requires compilation with GAMS=true and a working GAMS system]</td></tr>
6996  * <tr><td>\ref reader_lp.h "LP format"</td> <td>for mixed-integer (quadratically constrained quadratic) programs (CPLEX)</td></tr>
6997  * <tr><td>\ref reader_mps.h "MPS format"</td> <td>for mixed-integer (quadratically constrained quadratic) programs</td></tr>
6998  * <tr><td>\ref reader_opb.h "OPB format"</td> <td>for pseudo-Boolean optimization instances</td></tr>
6999  * <tr><td>\ref reader_osil.h "OSiL format"</td> <td>for mixed-integer nonlinear programs</td></tr>
7000  * <tr><td>\ref reader_pip.h "PIP format"</td> <td>for <a href="http://polip.zib.de/pipformat.php">mixed-integer polynomial programming problems</a></td></tr>
7001  * <tr><td>\ref reader_sol.h "SOL format"</td> <td>for solutions; XML-format (read-only) or raw SCIP format</td></tr>
7002  * <tr><td>\ref reader_wbo.h "WBO format"</td> <td>for weighted pseudo-Boolean optimization instances</td></tr>
7003  * <tr><td>\ref reader_zpl.h "ZPL format"</td> <td>for <a href="http://zimpl.zib.de">ZIMPL</a> models, i.e., mixed-integer linear and nonlinear
7004  * programming problems [read only]</td></tr>
7005  * </table>
7006  *
7007  * @section ADDREADER How to add a file reader
7008  *
7009  * A detailed description what a file reader does and how to add a file reader to SCIP can be found
7010  * \ref READER "here".
7011  *
7012  */
7013 
7014 /**@defgroup LPIS LP Solver Interfaces
7015  * @brief This page contains a list of all LP solver interfaces which are currently available.
7016  */
7017 
7018 /**@defgroup NODESELECTORS Node Selectors
7019  * @brief This page contains a list of all node selectors which are currently available.
7020  *
7021  * A detailed description what a node selector does and how to add a node selector to SCIP can be found
7022  * \ref NODESEL "here".
7023  */
7024 
7025 /**@defgroup NLPIS NLP Solver Interfaces
7026  * @brief This page contains a list of all NLP solver interfaces which are currently available.
7027  *
7028  * A detailed description what a NLP solver interface does and how to add a NLP solver interface to SCIP can be found
7029  * \ref NLPI "here".
7030  */
7031 
7032 /**@defgroup PRESOLVERS Presolvers
7033  * @brief This page contains a list of all presolvers which are currently available.
7034  *
7035  * A detailed description what a presolver does and how to add a presolver to SCIP can be found
7036  * \ref PRESOL "here".
7037  */
7038 
7039 /**@defgroup PRICERS Pricers
7040  * @brief This page contains a list of all pricers which are currently available.
7041  *
7042  * Per default there exist no variable pricer. A detailed description what a variable pricer does and how to add a
7043  * variable pricer to SCIP can be found \ref PRICER "here".
7044  */
7045 
7046 /**@defgroup PRIMALHEURISTICS Primal Heuristics
7047  * @brief This page contains a list of all primal heuristics which are currently available.
7048  *
7049  * A detailed description what a primal heuristic does and how to add a primal heuristic to SCIP can be found
7050  * \ref HEUR "here".
7051  */
7052 
7053 /**@defgroup PROPAGATORS Propagators
7054  * @brief This page contains a list of all propagators which are currently available.
7055  *
7056  * A detailed description what a propagator does and how to add a propagator to SCIP can be found
7057  * \ref PROP "here".
7058  */
7059 
7060 /**@defgroup RELAXATORS Relaxation Handlers
7061  * @brief This page contains a list of all relaxation handlers which are currently available.
7062  *
7063  * Note that the linear programming relaxation is not implemented via the relaxation handler plugin. Per default there
7064  * exist no relaxation handler. A detailed description what a variable pricer does and how to add a A detailed
7065  * description what a relaxation handler does and how to add a relaxation handler to SCIP can be found \ref RELAX
7066  * "here".
7067  */
7068 
7069 /**@defgroup SEPARATORS Separators
7070  * @brief This page contains a list of all separators which are currently available.
7071  *
7072  * A detailed description what a separator does and how to add a separator to SCIP can be found
7073  * \ref SEPA "here".
7074  */
7075 
7076 /**@page PARAMETERS List of all SCIP parameters
7077  *
7078  * This page list all parameters of the current SCIP version. This list can
7079  * easily be generated by SCIP via the interactive shell using the following command:
7080  *
7081  * <code>SCIP&gt; set save &lt;file name&gt;</code>
7082  *
7083  * or via the function call:
7084  *
7085  * <code>SCIP_CALL( SCIPwriteParams(scip, &lt;file name&gt;, TRUE, FALSE) );</code>
7086  *
7087  * \verbinclude parameters.set
7088  */
7089 
7090