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-2015 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  * - \ref REOPT "How to use reoptimization in SCIP"
73  * - \ref APPLICATIONS "Extensions of SCIP for specific applications"
74  *
75  *
76  * @section PROGRAMMING Programming with SCIP
77  *
78  * @subsection CODINGBASICS Coding basics for SCIP
79  *
80  * - \ref CODE "Coding style guidelines"
81  * - \ref OBJ "Creating, capturing, releasing, and adding data objects"
82  * - \ref MEMORY "Using the memory functions of SCIP"
83  * - \ref DEBUG "Debugging"
84  *
85  * @subsection HOWTOADD How to add ...
86  * - \ref CONS "Constraint handlers"
87  * - \ref PRICER "Variable pricers"
88  * - \ref PRESOL "Presolvers"
89  * - \ref SEPA "Separators"
90  * - \ref PROP "Propagators"
91  * - \ref BRANCH "Branching rules"
92  * - \ref NODESEL "Node selectors"
93  * - \ref HEUR "Primal heuristics"
94  * + \ref DIVINGHEUR "Diving heuristics"
95  * - \ref RELAX "Relaxation handlers"
96  * - \ref READER "File readers"
97  * - \ref DIALOG "Dialogs"
98  * - \ref DISP "Display columns"
99  * - \ref EVENT "Event handler"
100  * - \ref NLPI "Interfaces to NLP solvers"
101  * - \ref EXPRINT "Interfaces to expression interpreters"
102  * - \ref CONF "Conflict analysis"
103  * - \ref PARAM "additional user parameters"
104  *
105  *
106  * @section FURTHERINFO Further information
107  *
108  * @subsection CHG Changes between different versions of SCIP
109  * - \ref CHANGELOG "Change log"
110  * - \ref RELEASENOTES "Release notes"
111  * - \ref CHG8 "Interface changes between version 3.1 and 3.2"
112  * - \ref CHG7 "Interface changes between version 3.0 and 3.1"
113  * - \ref CHG6 "Interface changes between version 2.1 and 3.0"
114  * - \ref CHG5 "Interface changes between version 2.0 and 2.1"
115  * - \ref CHG4 "Interface changes between version 1.2 and 2.0"
116  * - \ref CHG3 "Interface changes between version 1.1 and 1.2"
117  * - \ref CHG2 "Interface changes between version 1.0 and 1.1"
118  * - \ref CHG1 "Interface changes between version 0.9 and 1.0"
119  *
120  * @subsection AUTHORS SCIP Authors
121  * - <a class="el" href="http://scip.zib.de/#developers">Developers</a>
122  *
123  * @version 3.2.0
124  *
125  * \image html scippy.png
126  *
127  */
128 
129 /** @page EXAMPLES Example projects
130  *
131  * SCIP contains several examples that demonstrate its usage. They are contained in the &quot;examples&quot; directory
132  * in the source code distribution.
133  *
134  * @section BRANCHANDPRICE Branch-and-price
135  *
136  * <table>
137  * <tr>
138  * <td>
139  * <a href="http://scip.zib.de/doc/examples/Binpacking"><b>Binpacking</b></a>
140  * </td>
141  * <td>
142  * An implementation of the column generation approach for the binpacking problem. It includes a customized reader,
143  * Ryan/Foster branching rule, (global) problem data, variable data, and constraint handler.
144  * </td>
145  * </tr>
146  * <tr>
147  * <td>
148  * <a href="http://scip.zib.de/doc/examples/VRP"><b>VRP</b></a>
149  * </td>
150  * <td>
151  * A solver for a simple capacity-constrained vehicle routing problem, which is based on pricing tours via a dynamic
152  * programming algorithm.
153  * </td>
154  * </tr>
155  * </table>
156  *
157  * @section BRANCHANDCUT Branch-and-cut
158  *
159  * <table>
160  * <tr>
161  * <td>
162  * <a href="http://scip.zib.de/doc/examples/LOP"><b>LOP</b></a>
163  * </td>
164  * <td>
165  * An example for implementing a constraint handler.
166  * </td>
167  * </tr>
168  * <tr>
169  * <td>
170  * <a href="http://scip.zib.de/doc/examples/TSP"><b>TSP</b></a>
171  * </td>
172  * <td>
173  * A short implementations of a constraint handler, two easy combinatorial heuristics, a file reader, etc. which
174  * demonstrate the usage of SCIP as a branch-and-cut-framework for solving traveling salesman problem instances.
175  * </td>
176  * </tr>
177  * </table>
178  *
179  * @section CALLABLELIBRARY Callable library
180  *
181  * <table>
182  * <tr>
183  * <td>
184  * <a href="http://scip.zib.de/doc/examples/CallableLibrary"><b>CallableLibrary</b></a>
185  * </td>
186  * <td>
187  * An example showing how to setup constraints (esp. nonlinear ones) when using SCIP as callable library.
188  * </td>
189  * </tr>
190  * <tr>
191  * <td>
192  * <a href="http://scip.zib.de/doc/examples/MIPSolver"><b>MIPSolver</b></a>
193  * </td>
194  * <td>
195  * A minimal implementation for using SCIP included into another source code
196  * </td>
197  * </tr>
198  * <tr>
199  * <td>
200  * <a href="http://scip.zib.de/doc/examples/Queens/scip_intro.pdf"><b>Queen</b></a>
201  * </td>
202  * <td>
203  * An example showing the use of SCIP as callable library.
204  * </td>
205  * </tr>
206  * </table>
207  *
208  *
209  * @section OTHERPLUGINS Other plugins
210  *
211  * <table>
212  * <tr>
213  * <td>
214  * <a href="http://scip.zib.de/doc/examples/Eventhdlr"><b>Eventhdlr</b></a>
215  * </td>
216  * <td>
217  * A small example illustrating the use of an event handler.
218  * </td>
219  * </tr>
220  * <tr>
221  * <td>
222  * <a href="http://scip.zib.de/doc/examples/GMI"><b>GMI</b></a>
223  * </td>
224  * <td>
225  * An example about Gomory mixed-integer cuts.
226  * </td>
227  * </tr>
228  * </table>
229  *
230  */
231 
232 /** @page APPLICATIONS Application projects
233  *
234  * There are several extensions of SCIP for particular applications included in the release. They are contained in the &quot;applications&quot; directory
235  * in the source code distribution.
236  *
237  * <table>
238  * <tr>
239  * <td>
240  * <a href="http://scip.zib.de/doc/applications/Coloring"><b>Coloring</b></a>
241  * </td>
242  * <td>
243  * An implemenation of the column generation approach for graph coloring of Mehrotra and Trick.
244  * </td>
245  * </tr>
246  * <tr>
247  * <td>
248  * <a href="http://scip.zib.de/doc/applications/Scheduler"><b>Scheduler</b></a>
249  * </td>
250  * <td>
251  * A solver for scheduling problems.
252  * </td>
253  * </tr>
254  * <tr>
255  * <td>
256  * <a href="http://scip.zib.de/doc/applications/STP"><b>Steiner Tree Problem</b></a>
257  * </td>
258  * <td>
259  * A solver for Steiner Tree Problems in graphs, based on a branch-and-cut approach.
260  * </td>
261  * </tr>
262  * <tr>
263  * <td>
264  * <a href="http://scip.zib.de/doc/applications/MultiObjective"><b>Multi-objective Optimization</b></a>
265  * </td>
266  * <td>
267  * A solver for multi-objective optimization problems.
268  * </td>
269  * </tr>
270  * </table>
271  *
272  */
273 
274 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
275 /**@page CODE Coding style guidelines
276  *
277  * We follow the following coding style guidelines and recommend them for all developers.
278  *
279  * - Indentation is 3 spaces. No tabs anywhere in the code.
280  * - Always only one declaration in a line.
281  * - Braces are on a new line and not indented.
282  * - Spaces around all operators.
283  * - No spaces between control structure keywords like "if", "for", "while", "switch" and the corresponding brackets.
284  * - No spaces between a function name and the parenthesis in both the definition and function calls.
285  * - Use assert() to show preconditions for the parameters, invariants and postconditions.
286  * - All global functions start with "SCIP". In the usual naming scheme this is followed by the object and a method name
287  * like in SCIPlpAddRow(). Functions return TRUE or FALSE should be named like SCIPisFeasEQ().
288  * - Make all functions that are not used outside the module 'static'. Naming should start with a lower case letter.
289  * - Variable names should be all lower case.
290  * - For each structure there is a typedef with the name in all upper case.
291  * - Defines should be named all upper case.
292  * - Document functions, parameters, and variables in a doxygen conformed way.
293  *
294  * As an example, have a look at tree.c and see the examples below. We also provide settings for
295  * \ref XEMACS "(x)emacs" and \ref ECLIPSE "eclipse".
296  *
297  * @section CODEEXAMPLES Examples
298  *
299  * In this section we state a few examples illustrating the \SCIP code style.
300  *
301  * \code
302  * #ifdef __cplusplus
303  * extern "C" {
304  * #endif
305  *
306  * /** SCIP operation stage */
307  * enum SCIP_Stage
308  * {
309  * SCIP_STAGE_INIT = 0, /**< SCIP datastructures are initialized, no problem exists */
310  * SCIP_STAGE_PROBLEM = 1, /**< the problem is being created and modified */
311  * SCIP_STAGE_TRANSFORMING = 2, /**< the problem is being transformed into solving data space */
312  * SCIP_STAGE_TRANSFORMED = 3, /**< the problem was transformed into solving data space */
313  * SCIP_STAGE_PRESOLVING = 4, /**< the problem is being presolved */
314  * SCIP_STAGE_PRESOLVED = 5, /**< the problem was presolved */
315  * SCIP_STAGE_INITSOLVE = 6, /**< the solving process data is being initialized */
316  * SCIP_STAGE_SOLVING = 7, /**< the problem is being solved */
317  * SCIP_STAGE_SOLVED = 8, /**< the problem was solved */
318  * SCIP_STAGE_FREESOLVE = 9, /**< the solving process data is being freed */
319  * SCIP_STAGE_FREETRANS = 10 /**< the transformed problem is being freed */
320  * };
321  * typedef enum SCIP_Stage SCIP_STAGE;
322  *
323  * /** possible settings for enabling/disabling algorithms and other features */
324  * enum SCIP_Setting
325  * {
326  * SCIP_UNDEFINED = 0, /**< undefined setting */
327  * SCIP_DISABLED = 1, /**< feature is disabled */
328  * SCIP_AUTO = 2, /**< feature is set to automatic mode */
329  * SCIP_ENABLED = 3 /**< feature is enabled */
330  * };
331  * typedef enum SCIP_Setting SCIP_SETTING;
332  *
333  * #ifdef __cplusplus
334  * }
335  * #endif
336  * \endcode
337  *
338  * @section XEMACS Customize (x)emacs
339  *
340  * If you are using (x)emacs, you can use the following customization for the c++-mode. These settings satisfy the
341  * coding guidelines of \SCIP.
342  *
343  * \verbatim
344  (add-hook 'c++-mode-hook
345  (function
346  (lambda ()
347  ;; SCIP customizations for c-mode and c++-mode
348  (setq-default c-basic-offset 3)
349  (c-set-offset 'substatement-open 0)
350  (c-set-offset 'statement-case-open 0)
351  (c-set-offset 'brace-list-open '-)
352  (c-set-offset 'inextern-lang '0)
353  (c-set-offset 'arglist-intro '+)
354  (c-set-offset 'arglist-cont 0)
355  (c-set-offset 'arglist-cont-nonempty '+)
356  (c-set-offset 'arglist-close '+)
357  (set-variable 'fill-column 120)
358  ;; this will make sure spaces are used instead of tabs
359  (setq tab-width 8 indent-tabs-mode nil)
360  )))\endverbatim
361  *
362  * @section ECLIPSE Customize eclipse
363  *
364  *
365  * Eclipse user can use the profile below. This profile does not match the \SCIP coding guideline completely.
366  *
367  * \code
368  *
369  * <?xml version="1.0" encoding="UTF-8" standalone="no"?>
370  * <profiles version="1">
371  * <profile kind="CodeFormatterProfile" name="scip" version="1">
372  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_method_declaration" value="do not insert"/>
373  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_for" value="insert"/>
374  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_in_empty_block" value="insert"/>
375  * <setting id="org.eclipse.cdt.core.formatter.lineSplit" value="124"/>
376  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_base_types" value="do not insert"/>
377  * <setting id="org.eclipse.cdt.core.formatter.keep_else_statement_on_same_line" value="false"/>
378  * <setting id="org.eclipse.cdt.core.formatter.indent_switchstatements_compare_to_switch" value="false"/>
379  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_brace_in_array_initializer" value="insert"/>
380  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_method_declaration_parameters" value="do not insert"/>
381  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_if" value="insert"/>
382  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_exception_specification" value="do not insert"/>
383  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_parenthesized_expression" value="do not insert"/>
384  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_base_types" value="insert"/>
385  * <setting id="org.eclipse.cdt.core.formatter.indent_body_declarations_compare_to_access_specifier" value="true"/>
386  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_exception_specification" value="do not insert"/>
387  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_template_arguments" value="insert"/>
388  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_block" value="insert"/>
389  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_method_declaration" value="do not insert"/>
390  * <setting id="org.eclipse.cdt.core.formatter.use_tabs_only_for_leading_indentations" value="false"/>
391  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_colon_in_labeled_statement" value="do not insert"/>
392  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_colon_in_case" value="insert"/>
393  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_array_initializer" value="insert"/>
394  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_enum_declarations" value="insert"/>
395  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_expressions_in_array_initializer" value="16"/>
396  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_declarator_list" value="insert"/>
397  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_bracket" value="do not insert"/>
398  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_for" value="insert"/>
399  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_prefix_operator" value="do not insert"/>
400  * <setting id="org.eclipse.cdt.core.formatter.tabulation.size" value="3"/>
401  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_before_else_in_if_statement" value="insert"/>
402  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_enumerator_list" value="48"/>
403  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_parenthesized_expression" value="do not insert"/>
404  * <setting id="org.eclipse.cdt.core.formatter.insert_space_between_empty_parens_in_method_declaration" value="do not insert"/>
405  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_declarator_list" value="16"/>
406  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_switch" value="insert"/>
407  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_parenthesized_expression" value="do not insert"/>
408  * <setting id="org.eclipse.cdt.core.formatter.indent_empty_lines" value="false"/>
409  * <setting id="org.eclipse.cdt.core.formatter.indent_switchstatements_compare_to_cases" value="true"/>
410  * <setting id="org.eclipse.cdt.core.formatter.keep_empty_array_initializer_on_one_line" value="false"/>
411  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_method_declaration" value="insert"/>
412  * <setting id="org.eclipse.cdt.core.formatter.put_empty_statement_on_new_line" value="true"/>
413  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_switch" value="do not insert"/>
414  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_cast" value="do not insert"/>
415  * <setting id="org.eclipse.cdt.core.formatter.insert_space_between_empty_braces_in_array_initializer" value="do not insert"/>
416  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_method_declaration" value="next_line"/>
417  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_while" value="insert"/>
418  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_question_in_conditional" value="insert"/>
419  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_semicolon" value="do not insert"/>
420  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_closing_angle_bracket_in_template_arguments" value="insert"/>
421  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_colon_in_base_clause" value="do not insert"/>
422  * <setting id="org.eclipse.cdt.core.formatter.indent_breaks_compare_to_cases" value="true"/>
423  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_unary_operator" value="do not insert"/>
424  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_declarator_list" value="do not insert"/>
425  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_arguments_in_method_invocation" value="16"/>
426  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_while" value="do not insert"/>
427  * <setting id="org.eclipse.cdt.core.formatter.insert_space_between_empty_brackets" value="do not insert"/>
428  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_bracket" value="do not insert"/>
429  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_parameters_in_method_declaration" value="48"/>
430  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_before_closing_brace_in_array_initializer" value="do not insert"/>
431  * <setting id="org.eclipse.cdt.core.formatter.number_of_empty_lines_to_preserve" value="1"/>
432  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_method_invocation" value="do not insert"/>
433  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_brace_in_array_initializer" value="insert"/>
434  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_semicolon_in_for" value="do not insert"/>
435  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_block" value="next_line"/>
436  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_colon_in_conditional" value="insert"/>
437  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_type_declaration" value="next_line"/>
438  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_assignment_operator" value="insert"/>
439  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_angle_bracket_in_template_arguments" value="do not insert"/>
440  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_expression_list" value="do not insert"/>
441  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_angle_bracket_in_template_parameters" value="do not insert"/>
442  * <setting id="org.eclipse.cdt.core.formatter.continuation_indentation" value="1"/>
443  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_expression_list" value="0"/>
444  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_method_declaration" value="do not insert"/>
445  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_template_parameters" value="do not insert"/>
446  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_colon_in_default" value="do not insert"/>
447  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_binary_operator" value="insert"/>
448  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_conditional_expression" value="16"/>
449  * <setting id="org.eclipse.cdt.core.formatter.insert_space_between_empty_parens_in_method_invocation" value="do not insert"/>
450  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_array_initializer" value="do not insert"/>
451  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_if" value="insert"/>
452  * <setting id="org.eclipse.cdt.core.formatter.format_guardian_clause_on_one_line" value="false"/>
453  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_cast" value="do not insert"/>
454  * <setting id="org.eclipse.cdt.core.formatter.indent_access_specifier_compare_to_type_header" value="false"/>
455  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_type_declaration" value="insert"/>
456  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_colon_in_labeled_statement" value="insert"/>
457  * <setting id="org.eclipse.cdt.core.formatter.continuation_indentation_for_array_initializer" value="1"/>
458  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_method_declaration_parameters" value="insert"/>
459  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_semicolon_in_for" value="insert"/>
460  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_method_invocation" value="do not insert"/>
461  * <setting id="org.eclipse.cdt.core.formatter.indent_body_declarations_compare_to_namespace_header" value="false"/>
462  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_closing_brace_in_block" value="insert"/>
463  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_assignment_operator" value="insert"/>
464  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_compact_if" value="0"/>
465  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_array_initializer" value="insert"/>
466  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_at_end_of_file_if_missing" value="do not insert"/>
467  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_template_parameters" value="insert"/>
468  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_expression_list" value="insert"/>
469  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_question_in_conditional" value="insert"/>
470  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_exception_specification" value="insert"/>
471  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_binary_operator" value="insert"/>
472  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_before_identifier_in_function_declaration" value="do not insert"/>
473  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_base_clause_in_type_declaration" value="80"/>
474  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_method_declaration_throws" value="do not insert"/>
475  * <setting id="org.eclipse.cdt.core.formatter.insert_space_between_empty_parens_in_exception_specification" value="do not insert"/>
476  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_method_invocation_arguments" value="do not insert"/>
477  * <setting id="org.eclipse.cdt.core.formatter.indent_declaration_compare_to_template_header" value="false"/>
478  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_unary_operator" value="do not insert"/>
479  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_switch" value="do not insert"/>
480  * <setting id="org.eclipse.cdt.core.formatter.indent_statements_compare_to_body" value="true"/>
481  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_method_declaration_throws" value="insert"/>
482  * <setting id="org.eclipse.cdt.core.formatter.indent_statements_compare_to_block" value="true"/>
483  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_template_arguments" value="do not insert"/>
484  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_before_catch_in_try_statement" value="insert"/>
485  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_throws_clause_in_method_declaration" value="48"/>
486  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_method_invocation" value="do not insert"/>
487  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_closing_paren_in_cast" value="do not insert"/>
488  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_catch" value="insert"/>
489  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_angle_bracket_in_template_parameters" value="do not insert"/>
490  * <setting id="org.eclipse.cdt.core.formatter.tabulation.char" value="space"/>
491  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_angle_bracket_in_template_parameters" value="do not insert"/>
492  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_while" value="insert"/>
493  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_method_invocation_arguments" value="insert"/>
494  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_block_in_case" value="next_line"/>
495  * <setting id="org.eclipse.cdt.core.formatter.compact_else_if" value="true"/>
496  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_postfix_operator" value="do not insert"/>
497  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_colon_in_base_clause" value="insert"/>
498  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_after_template_declaration" value="do not insert"/>
499  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_catch" value="insert"/>
500  * <setting id="org.eclipse.cdt.core.formatter.keep_then_statement_on_same_line" value="false"/>
501  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_switch" value="next_line"/>
502  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_if" value="do not insert"/>
503  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_switch" value="insert"/>
504  * <setting id="org.eclipse.cdt.core.formatter.keep_imple_if_on_one_line" value="false"/>
505  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_after_opening_brace_in_array_initializer" value="do not insert"/>
506  * <setting id="org.eclipse.cdt.core.formatter.indentation.size" value="3"/>
507  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_namespace_declaration" value="end_of_line"/>
508  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_colon_in_conditional" value="insert"/>
509  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_enum_declarations" value="do not insert"/>
510  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_prefix_operator" value="do not insert"/>
511  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_angle_bracket_in_template_arguments" value="do not insert"/>
512  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_array_initializer" value="end_of_line"/>
513  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_colon_in_case" value="do not insert"/>
514  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_catch" value="do not insert"/>
515  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_namespace_declaration" value="insert"/>
516  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_postfix_operator" value="do not insert"/>
517  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_bracket" value="do not insert"/>
518  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_before_while_in_do_statement" value="insert"/>
519  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_for" value="do not insert"/>
520  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_closing_angle_bracket_in_template_parameters" value="insert"/>
521  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_angle_bracket_in_template_arguments" value="do not insert"/>
522  * </profile>
523  * </profiles>
524  * \endcode
525  */
526 
527 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
528 /**@page MAKE Makefiles / Installation information
529  *
530  *
531  * In most cases (LINUX and MAC) it is quite easy to compile and install SCIP. Therefore, reading the section
532  * \ref BRIEFINSTALL "Brief installation description" should usually be enough. If this is not the case you find
533  * \ref DETAILEDINSTALL "Detailed installation description" below as well as \ref EXAMPLE1 "Examples".
534 *
535  * @section BRIEFINSTALL Brief installation description
536  *
537  * The easiest way to install SCIP is to use the SCIP Optimization Suite which contains SCIP, SoPlex, and ZIMPL. For
538  * that we refer to the INSTALL file of the SCIP Optimization Suite (main advantage: there is no need
539  * to specify any directories, the compiling process is fully automated).
540  *
541  * Compiling SCIP directly can be done as follows:
542  *
543  * -# unpack the tarball <code>tar xvf scip-x.y.z.tgz</code>
544  * -# change to the directory <code>cd scip-x.y.z</code>
545  * -# start compiling SCIP by typing <code>make</code>
546  * -# (optional) install the header, libraries, and binary <code>make install INSTALLDIR="/usr/local/</code>
547  *
548  * During your first compilation you will be asked for some soft-link targets,
549  * depending on the LP solver you want to use. Usually, SCIP needs the
550  * following information
551  * -# the directory where the include files of the LP solver lie
552  * -# the library file(s) "lib*.a" or/and "lib*.so"
553  *
554  * Besides that, SCIP needs some soft-link targets, for ZIMPL
555  * -# the directory where the include files of ZIMPL lie
556  * -# the library file(s) "lib*.a" or/and "lib*.so"
557  *
558  * You will need either the .a or the .so files and can skip the others by
559  * just pressing return.
560  *
561  * The most common compiling issue is that some libraries are missing
562  * on your system or that they are outdated. SCIP per default requires
563  * zlib, gmp and readline. Try compiling with: <code> make ZLIB=false
564  * READLINE=false ZIMPL=false</code> or, better, install them. Note
565  * that under Linux-based systems, you need to install the
566  * developer-versions of gmp/zlib/readline, in order to also have the
567  * header-files available.
568  *
569  @section DETAILEDINSTALL Detailed installation description
570  *
571  * In this section we describe the use, and a few features, of the SCIP Makefile. We also give two examples for how to install
572  * SCIP. The \ref EXAMPLE1 "first example" illustrates the default installation. This means, with SoPleX and ZIMPL. The
573  * \ref EXAMPLE2 "second example" shows how to get CPLEX linked to SCIP without ZIMPL. This is followed by a section which
574  * gives some hints on what to do if the \ref COMPILERPROBLEMS "compilation throws an error". We give some comments on
575  * how to install SCIP under \ref WINDOWS "WINDOWS" and show \ref RUN "how to start SCIP".
576  *
577  * If you experience any problems during the installation, you will find help in the \ref INSTALL "INSTALL" file.
578  *
579  * SCIP contains a makefile system, which allows the individual setting of several parameters. For
580  * instance, the following settings are supported:
581  *
582  * - <code>OPT=<dbg|opt|opt-gccold></code> Here <code>dbg</code> turns on the debug mode of SCIP. This enables asserts
583  * and avoids macros for several function in order to ease debugging. The default is <code>opt</code>, which enables
584  * the optimized mode. The third option <code>opt-gccold</code> will work with older GCC compilers before version
585  * 4.2. We recommend using newer GCC versions.
586  *
587  * - <code>LPS=<clp|cpx|grb|msk|qso|spx|xprs|none></code> This determines the LP-solver, which should have been
588  * installed separately from SCIP. The options are the following:
589  * - <code>clp</code>: COIN-OR Clp LP-solver
590  * - <code>cpx</code>: CPLEX LP-solver
591  * - <code>grb</code>: Gurobi LP-solver (interface is in beta stage)
592  * - <code>msk</code>: Mosek LP-solver
593  * - <code>qso</code>: QSopt LP-solver
594  * - <code>spx</code>: SoPlex LP-solver (default)
595  * - <code>xprs</code>: XPress LP-solver
596  * - <code>none</code>: no LP-solver (you should set the parameter <lp/solvefreq> to <-1> to avoid solving LPs)
597  *
598  * - <code>LPSOPT=<dbg|opt|opt-gccold></code> Chooses the debug or optimized version (or old GCC optimized) version of
599  * the LP-solver. (currently only available for SoPlex and CLP)
600  *
601  * - <code>ZIMPL=<true|false></code> Turns direct support of ZIMPL in SCIP on (default) or off, respectively.
602  * - <code>ZIMPLOPT=<dbg|opt|opt-gccold></code> Chooses the debug or optimized (default) (or old GCC optimized)
603  * version of ZIMPL, if ZIMPL support is enabled. \n
604  * If the ZIMPL-support is disabled, the GMP-library is no longer needed for SCIP and therefore not linked to SCIP.
605  *
606  * - <code>READLINE=<true|false></code> Turns support via the readline library on (default) or off, respectively.
607  *
608  * - <code>IPOPT=<true|false></code> to enable or disable (default) IPOPT interface (needs IPOPT)
609  *
610  * - <code>EXPRINT=<cppad|none></code> to use CppAD as expressions interpreter (default) or no expressions interpreter
611  *
612  * - <code>GAMS=<true|false></code> to enable or disable (default) reading functionality in GAMS reader (needs GAMS)
613  *
614  * There are additional parameters for Linux/Gnu compilers:
615  *
616  * - <code>NOBLKBUFMEM=<true></code> turns off the internal SCIP block and buffer memory. This way the code can be checked by valgrind or
617  * similar tools. (The individual options <code>NOBLKMEM=<true></code> and <code>NOBUFMEM=<true></code> to turn off the SCIP block and
618  * buffer memory, respectively, exist as well).
619  *
620  * - <code>SHARED=<true></code> generates a shared object of the SCIP libraries. (The binary uses these shared
621  * libraries as well.)
622  * - <code>OPT=prf</code> generates a profiling version of SCIP providing a detailed statistic of the time usage of
623  * every method of SCIP.
624  *
625  * You can use other compilers - depending on the system:
626  *
627  * - <code>COMP=intel</code> Uses of the Intel compiler which is only available with the main optimization flags
628  * <code>OPT=<dbg|opt></code>. (Default is gcc/g++ represented through <code>COMP=gnu</code>.)
629  *
630  * There is the possibility to watch the compilation more precisely:
631  *
632  * - <code>VERBOSE=<true|false></code> Turns the extensive output on or off (default).
633  *
634  * The SCIP makefile supports several targets (used via <code>make ... "target"</code>):
635  *
636  * - <code>links</code> Reconfigures the links in the "lib" directory.
637  * - <code>doc</code> Creates documentation in the "doc" directory.
638  * - <code>clean</code> Removes all object files.
639  * - <code>depend</code> Creates dependencies files. This is only needed if you add files to SCIP.
640  * - <code>check</code> Runs the check script, see \ref TEST.
641  *
642  * The SCIP makefiles are structured as follows.
643  *
644  * - <code>Makefile</code> This is the basic makefile in the SCIP root directory. It loads
645  * additional makefile information depending on the parameters set.
646  * - <code>make/make.project</code> This file contains definitions that are useful for all codes
647  * that use SCIP, for instance, the examples.
648  * - <code>make.<sys>.<machine>.<compiler>.<dbg|opt|prf|opt-gccold></code> These file contain system/compiler specific
649  * definitions. If you have an unsupported compiler, you can copy one of these and modify it
650  * accordingly.
651  *
652  * If your platform or compiler is not supported by SCIP you might try and copy one of the existing
653  * makefiles in the <code>make</code> directory and modify it. If you succeed, we are always
654  * interested in including more Makefiles into the system.
655  *
656  *
657  * @section EXAMPLE1 Example 1 (defaults: SoPlex, with ZIMPL support):
658  *
659  * Typing <code>make</code> uses SoPlex as LP solver and includes support for the modeling language ZIMPL. You will be asked the
660  * following questions on the first call to "make" (example answers are already given):
661  *
662  * \verbatim
663  > make
664  make[1]: Entering directory `scip-1.2'
665 
666  - Current settings: LPS=spx OSTYPE=linux ARCH=x86_64 COMP=gnu SUFFIX= ZIMPL=true ZIMPLOPT=opt IPOPT=false IPOPTOPT=opt
667 
668  * SCIP needs some softlinks to external programs, in particular, LP-solvers.
669  * Please insert the paths to the corresponding directories/libraries below.
670  * The links will be installed in the 'lib' directory.
671  * For more information and if you experience problems see the INSTALL file.
672 
673  -> "spxinc" is the path to the SoPlex "src" directory, e.g., "../../soplex/src".
674  -> "libsoplex.*" is the path to the SoPlex library, e.g., "../../soplex/lib/libsoplex.linux.x86.gnu.opt.a"
675  -> "zimplinc" is a directory containing the path to the ZIMPL "src" directory, e.g., "../../zimpl/src".
676  -> "libzimpl.*" is the path to the ZIMPL library, e.g., "../../zimpl/lib/libzimpl.linux.x86.gnu.opt.a"
677 
678  - preparing missing soft-link "lib/spxinc":
679  > Enter soft-link target file or directory for "lib/spxinc" (return if not needed):
680  > ../../soplex/src/
681  -> creating softlink "lib/spxinc" -> "../../soplex/src"
682 
683 
684  - preparing missing soft-link "lib/libsoplex.linux.x86_64.gnu.opt.a":
685  > Enter soft-link target file or directory for "lib/libsoplex.linux.x86_64.gnu.opt.a" (return if not needed):
686  > ../../soplex/lib/libsoplex.linux.x86_64.gnu.opt.a
687  -> creating softlink "lib/libsoplex.linux.x86_64.gnu.opt.a" -> "../../soplex/lib/libsoplex.linux.x86_64.gnu.opt.a"
688 
689 
690  - preparing missing soft-link "lib/libsoplex.linux.x86_64.gnu.opt.so":
691  * this soft-link is not necessarily needed since "lib/libsoplex.linux.x86_64.gnu.opt.a" already exists - press return to skip
692  > Enter soft-link target file or directory for "lib/libsoplex.linux.x86_64.gnu.opt.so" (return if not needed):
693  >
694  * skipped creation of softlink "lib/libsoplex.linux.x86_64.gnu.opt.so". Call "make links" if needed later.
695 
696 
697  - preparing missing soft-link "lib/zimplinc/zimpl":
698  > Enter soft-link target file or directory for "lib/zimplinc/zimpl" (return if not needed):
699  ../../zimpl/src/
700  creating softlink "lib/zimplinc/zimpl" -> "../../zimpl/src"
701 
702 
703  - preparing missing soft-link "lib/libzimpl.linux.x86_64.gnu.opt.a":
704  > Enter soft-link target file or directory for "lib/libzimpl.linux.x86_64.gnu.opt.a" (return if not needed):
705  > ../../zimpl/lib/libzimpl.linux.x86_64.gnu.opt.a
706  -> creating softlink "lib/libzimpl.linux.x86_64.gnu.opt.a" -> "../../zimpl/lib/libzimpl.linux.x86_64.gnu.opt.a"
707 
708 
709  - preparing missing soft-link "lib/libzimpl.linux.x86_64.gnu.opt.so":
710  * this soft-link is not necessarily needed since "lib/libzimpl.linux.x86_64.gnu.opt.a" already exists - press return to skip
711  > Enter soft-link target file or directory for "lib/libzimpl.linux.x86_64.gnu.opt.so" (return if not needed):
712  >
713  * skipped creation of softlink "lib/libzimpl.linux.x86_64.gnu.opt.so". Call "make links" if needed later.
714 
715  ...
716 
717  -> generating library lib/libobjscip-1.2.0.linux.x86_64.gnu.opt.a
718  -> generating library lib/liblpispx-1.2.0.linux.x86_64.gnu.opt.a
719  -> generating library lib/libscip-1.2.0.linux.x86_64.gnu.opt.a
720  -> linking bin/scip-1.2.0.linux.x86_64.gnu.opt.spx
721 
722  \endverbatim
723  *
724  * @section EXAMPLE2 Example 2 (CPLEX, with no ZIMPL support):
725  *
726  * Typing <code>make LPS=cpx ZIMPL=false</code> uses CPLEX as LP solver. You will be asked the following questions on
727  * the first call to "make" (example answers are already given):
728  *
729  * \verbatim
730  > make LPS=cpx ZIMPL=false
731  make[1]: Entering directory `scip-1.2'
732 
733  - Current settings: LPS=cpx OSTYPE=linux ARCH=x86_64 COMP=gnu SUFFIX= ZIMPL=false ZIMPLOPT=opt IPOPT=false IPOPTOPT=opt
734 
735  * SCIP needs some softlinks to external programs, in particular, LP-solvers.
736  * Please insert the paths to the corresponding directories/libraries below.
737  * The links will be installed in the 'lib' directory.
738  * For more information and if you experience problems see the INSTALL file.
739 
740  -> "cpxinc" is the path to the CPLEX "include" directory, e.g., "<CPLEX-path>/include/ilcplex".
741  -> "libcplex.*" is the path to the CPLEX library, e.g., "<CPLEX-path>/lib/x86_rhel4.0_3.4/static_pic/libcplex.a"
742 
743  - preparing missing soft-link "lib/cpxinc":
744  > Enter soft-link target file or directory for "lib/cpxinc" (return if not needed):
745  > ../../cplex121/include
746  -> creating softlink "lib/cpxinc" -> "../../cplex121/include"
747 
748 
749  - preparing missing soft-link "lib/libcplex.linux.x86_64.gnu.a":
750  > Enter soft-link target file or directory for "lib/libcplex.linux.x86_64.gnu.a" (return if not needed):
751  > ../../cplex121/lib/x86-64_sles9.0_3.3/static_pic/libcplex.a
752  -> creating softlink "lib/libcplex.linux.x86_64.gnu.a" -> "../../../../adm_cple/cplex121/lib/x86-64_sles9.0_3.3/static_pic/libcplex.a"
753 
754 
755  - preparing missing soft-link "lib/libcplex.linux.x86_64.gnu.so":
756  > Enter soft-link target file or directory for "lib/libcplex.linux.x86_64.gnu.so" (return if not needed):
757  >
758  * skipped creation of softlink "lib/libcplex.linux.x86_64.gnu.so". Call "make links" if needed later.
759 
760  ...
761 
762  -> generating library lib/libobjscip-1.2.0.linux.x86_64.gnu.opt.a
763  -> generating library lib/liblpicpx-1.2.0.linux.x86_64.gnu.opt.a
764  -> generating library lib/libscip-1.2.0.linux.x86_64.gnu.opt.a
765  -> linking bin/scip-1.2.0.linux.x86_64.gnu.opt.cpx
766 
767  \endverbatim
768  *
769  * @section COMPILERPROBLEMS Compilation problems:
770  *
771  * - If the soft-link query script does not work on your machine, read step 2 in the \ref INSTALL "INSTALL" file for
772  * instructions on manually creating the soft-links.
773  *
774  * - If you get an error message of the type\n
775  * <code>make: *** No rule to make target `lib/???', needed by `obj/O.linux.x86.gnu.opt/lib/scip/???.o'. Stop.</code>\n
776  * the corresponding soft-link was not created or points to a wrong location. Check the soft-link targets in the "lib/"
777  * subdirectory. Try to delete all soft-links from the "lib/" directory\n and call "make links" to generate them
778  * again. If this still fails, read step 2 for instructions on manually\n creating the soft-links.
779  *
780  * - If you get an error message of the type\n
781  * <code>make: *** No rule to make target `make/make.?.?.?.?.?'. Stop.</code>,\n
782  * the corresponding machine dependent makefile for your architecture and compiler is missing.\n Create one of the given
783  * name in the "make/" subdirectory. You may take\n "make/make.linux.x86.gnu.opt" or any other file in the make
784  * subdirectory as example.\n
785  *
786  * - The readline library seems to differ slightly on different OS distributions. Some versions do
787  * not support the <code>remove_history()</code> call. In this case, you have to either add
788  * <code>-DNO_REMOVE_HISTORY</code> to the FLAGS in the appropriate "make/make.*" file, or to
789  * compile with <code>make USRFLAGS=-DNO_REMOVE_HISTORY</code>. Make sure, the file
790  * "src/scip/dialog.c" is recompiled. If this doesn't work either, disable the readline library
791  * with <code>make READLINE=false</code>.
792  *
793  * - On some systems, the <code>sigaction()</code> method is not available. In this case, you have
794  * to either add <code>-DNO_SIGACTION</code> to the FLAGS in the appropriate "make/make.*" file, or
795  * to compile with <code>make USRFLAGS=-DNO_SIGACTION</code>. Make sure, the file
796  * "src/scip/interrupt.c" is recompiled.
797  *
798  * - On some systems, the <code>rand_r()</code> method is not available. In this case, you have to either add
799  * <code>-DNO_RAND_R</code> to the FLAGS in the appropriate "make/make.*" file, or to compile with
800  * <code>make USRFLAGS=-DNO_RAND_R</code>. Make sure, the file "src/scip/misc.c" is recompiled.
801  *
802  * - On some systems, the <code>strtok_r()</code> method is not available. In this case, you have
803  * to either add <code>-DNO_STRTOK_R</code> to the FLAGS in the appropriate make/make.* file, or to
804  * compile with <code>make USRFLAGS=-DNO_STRTOK_R</code>. Make sure, the file "src/scip/misc.c" is
805  * recompiled.
806  *
807  * - On some systems, the <code>strerror_r()</code> method is not available. In this case, you have
808  * to either add <code>-DNO_STRERROR_R</code> to the FLAGS in the appropriate "make/make.*" file, or
809  * to compile with <code>make USRFLAGS=-DNO_STRERROR_R</code>. Make sure, the file
810  * "src/scip/misc.c" is recompiled.
811  *
812  * - On some systems, the option [-e] is not available for the read command. You have to compile with READ=read.
813  *
814  * - If you encounter other compiler or linker errors, you should recompile with <code>make
815  * VERBOSE=true ...</code> in order to get the full compiler invocation. This might help to fix the
816  * corresponding machine dependent makefile in the make subdirectory.
817  *
818  * @section WINDOWS Remarks on Installing under Windows using MinGW
819  *
820  * To build your own windows binaries under windows we recommend using the MinGW-Compiler with MSYS
821  * from <a href="http://www.mingw.org">www.mingw.org</a> .
822  *
823  * First install MSYS, then MinGW to the mingw folder inside the msys folder.
824  * Now you need to install the following packages to the mingw folder:
825  * - zlib (or use ZLIB=false)
826  * - pcre (here suffices the pcre7.0-lib.zip (or equivalent) to be extracted into the mingw-folder)
827  *
828  * After calling <code>make clean</code> in the ZIMPL folder you will also need flex and bison to
829  * remake ZIMPL. We recommend NOT to use <code>"make clean"</code> inside the ZIMPL-folder if you do
830  * not have these packages installed.
831  *
832  * You can download these additional packages from <a href="http://gnuwin32.sourceforge.net/packages.html">here</a>
833  * or compile the source on your own from their homepages.
834  *
835  * Second you need to copy the file <code>sh.exe</code> to <code>bash.exe</code> otherwise various
836  * scripts (including makefiles) will not work. Normally <code>unistd.h</code> covers also the
837  * getopt-options, but for mingw you need to add the entry <code>\#include <getopt.h></code> into
838  * "/mingw/include/unistd.h" after the other include-entries (if not present).
839  *
840  * Finally, there is one package you need to compile if you want to use ZIMPL and ZIMPL-support in
841  * SCIP (otherwise use <code>ZIMPL=false</code> as parameter with the make-call): the
842  * <code>gmplib</code> from <a href="http://www.gmplib.org">gmplib.org</a>. The command
843  * <code>./configure --prefix=/mingw ; make ; make install</code> should succeed without problems
844  * and installs the gmplib to the mingw folder.
845  *
846  * Now <code>make READLINE=false</code> should be compiling without errors. Please note that we
847  * do NOT support creating the doxygen documentation and readline-usage under windows.
848  *
849  *
850  * @section RUN How to run SCIP after successfully compiling SCIP
851  *
852  * To run the program, enter <code>bin/scip</code> for the last compiled version. If you have more than one compiled
853  * binary (i. e., one in debug and one in optimized mode) and wish to specify the binary, type
854  * <code>bin/scip.\$(OSTYPE).\$(ARCH).\$(COMP).\$(OPT).\$(LPS)</code>
855  * (e.g. <code>bin/scip.linux.x86_64.gnu.opt.spx</code>).
856  *
857  */
858 
859 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
860 /**@page START How to start a new project
861  *
862  * Once you succeeded installing SCIP together with an LP-solver on your system,
863  * you have a powerful tool for solving MIPs, MIQCPs,
864  * MINLPs, etc... at hand. SCIP can also be customized to the type of problems you
865  * are working on by additional plugins.
866  * Instructions on how to write a new plugin and include it in SCIP can be found in the corresponding
867  * \ref HOWTOADD "How to add ... pages".
868  *
869  * SCIP can also be used for writing your own branch-and-cut or branch-and-cut-and-price code. SCIP already
870  * provides a number of existing code examples which we suggest as both reference and starting point
871  * for these kinds of projects.
872  * Below, you find some hints of how to start such a project.
873  *
874  * - The example should be chosen
875  * depending on the programming language (<b>C</b> or <b>C++</b>) and the purpose
876  * (<b>branch-and-cut</b> or <b>branch-and-cut-and-price</b>) of your project.
877  * <br>
878  * We suggest the use one of the following examples:
879  * - 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
880  * in <b>C++</b>.
881  * - The <a href="http://scip.zib.de/doc/examples/Binpacking"><b>Binpacking</b></a>-example
882  * and the <a href="http://scip.zib.de/doc/applications/Coloring"><b>Coloring</b></a> application are
883  * <b>branch-and-cut-and-price</b> (column generation)-codes in <b>C</b>.
884  * - The <a href="http://scip.zib.de/doc/examples/TSP"><b>TSP</b></a>-example
885  * is a <b>branch-and-cut</b>-code in <b>C++</b>.
886  * - The <a href="http://scip.zib.de/doc/examples/LOP"><b>LOP</b></a>-example
887  * is a <b>branch-and-cut</b>-code in <b>C</b>.
888  * .
889  * - Copy one of the examples in the <code>examples</code> directory (in the SCIP root
890  * directory). For instance, type
891  * \verbatim
892  > cp -r examples/Binpacking/ ../SCIPProject/ ; cd ../SCIPProject
893  \endverbatim
894  * from the SCIP root directory for copying the content of the <code>Binpacking</code>-example into a fresh
895  * directory named SCIPProject in the parent directory of the SCIP root directory and jumping to
896  * the new SCIPProject directory rightafter.
897  * - Open the <code>Makefile</code> via
898  * \verbatim
899  > kate Makefile
900  \endverbatim
901  * and edit the following variables at the top to have a compilable code:
902  *
903  * - specify a correct path to the SCIP root (<code>SCIPDIR</code>)
904  * - rename the targets name (<code>MAINNAME</code>)
905  * - adjust the source file names (<code>MAINOBJ</code>).
906  * .
907  * - Once you have edited the makefile, you can use all the flags that can be used in SCIP to
908  * compile your code, see \ref MAKE.
909  * Note that you need to update the dependency files before compiling your project via <code>make depend</code>.
910  *
911  *
912  *
913  *
914  */
915 
916 
917 /**@page SHELL Tutorial: the interactive shell
918  *
919  * If are using SCIP as a black box solver, here you will find some tips and tricks what you can do.
920  *
921  * @section TUTORIAL_OPTIMIZE Read and optimize a problem instance
922  *
923  * First of all, we need a SCIP binary and an example problem file to work with. Therefore, you can either download the
924  * SCIP standard distribution (which includes problem files) and compile it on your own or you can download a
925  * 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).
926  *
927  * If you want to download the source code of the SCIP standard distribution, we recommend to go to the <a
928  * href="http://scip.zib.de/#download">SCIP download section</a>, download the latest release (version 3.0 as
929  * of this writing), inflate the tarball (e.g., with "tar xzf scipoptsuite-[version].tgz"), and follow the instructions
930  * in the INSTALL file. The instance stein27, which will serve as an example in this tutorial, can be found under
931  * scipoptsuite-[version]/scip-[version]/check/instances/MIP/stein27.mps.
932  *
933  * If you want to download a precompiled binary, go to the <a href="http://scip.zib.de/#download">SCIP download
934  * section</a> and download an appropriate binary for your operating system. The SCIP source code distribution already comes with
935  * the example problem instance used throughout this tutorial. To follow this tutorial with a precompiled binary, we recommend downloading the instance
936  * <a href="http://miplib.zib.de/miplib3/miplib3/stein27.mps.gz">stein27</a> from
937  * the <a href="http://miplib.zib.de/miplib3/miplib.html">MIPLIB 3.0</a> homepage.
938  *
939  * Now start your binary, without any arguments. This opens the interactive shell, which should look somehow like this:
940  *
941  * \code
942  * SCIP version 2.0.1 [precision: 8 byte] [memory: block] [mode: optimized] [LP solver: SoPlex 1.5.0]
943  * Copyright (c) 2002-2015 Konrad-Zuse-Zentrum fuer Informationstechnik Berlin (ZIB)
944  *
945  * External codes:
946  * SoPlex 1.5.0 Linear Programming Solver developed at Zuse Institute Berlin (soplex.zib.de)
947  * ZIMPL 3.1.0 Zuse Institute Mathematical Programming Language developed by T. Koch (zimpl.zib.de)
948  *
949  * user parameter file <scip.set> not found - using default parameters
950  *
951  * SCIP>
952  * \endcode
953  *
954  * First of all "help" shows you a list of all available shell commands. Brackets indicate a submenu with further options.
955  * \code
956  * SCIP> help
957 
958  * <display> display information
959  * <set> load/save/change parameters
960  * ...
961  * read read a problem
962  * \endcode
963  *
964  * Okay, let's solve some MIPs... use "read <path/to/file>" to parse a problem file, "optimize" to solve it and "display
965  * solution" to show the nonzero variables of the best found solution.
966 
967  * \code
968  * SCIP> read check/instances/MIP/stein27.fzn
969  * original problem has 27 variables (27 bin, 0 int, 0 impl, 0 cont) and 118 constraints
970  * SCIP> optimize
971  *
972  * feasible solution found by trivial heuristic, objective value 2.700000e+01
973  * presolving:
974  * (round 1) 0 del vars, 0 del conss, 0 chg bounds, 0 chg sides, 0 chg coeffs, 118 upgd conss, 0 impls, 0 clqs
975  * presolving (2 rounds):
976  * 0 deleted vars, 0 deleted constraints, 0 tightened bounds, 0 added holes, 0 changed sides, 0 changed coefficients
977  * 0 implications, 0 cliques
978  * presolved problem has 27 variables (27 bin, 0 int, 0 impl, 0 cont) and 118 constraints
979  * 1 constraints of type <knapsack>
980  * 117 constraints of type <logicor>
981  * transformed objective value is always integral (scale: 1)
982  * Presolving Time: 0.00
983  *
984  * time | node | left |LP iter|LP it/n| mem |mdpt |frac |vars |cons |cols |rows |cuts |confs|strbr| dualbound | primalbound | gap
985  * t 0.0s| 1 | 0 | 34 | - | 337k| 0 | 21 | 27 | 118 | 27 | 118 | 0 | 0 | 0 | 1.300000e+01 | 2.700000e+01 | 107.69%
986  * R 0.0s| 1 | 0 | 34 | - | 338k| 0 | 21 | 27 | 118 | 27 | 118 | 0 | 0 | 0 | 1.300000e+01 | 2.600000e+01 | 100.00%
987  * s 0.0s| 1 | 0 | 34 | - | 339k| 0 | 21 | 27 | 118 | 27 | 118 | 0 | 0 | 0 | 1.300000e+01 | 2.500000e+01 | 92.31%
988  * 0.0s| 1 | 0 | 44 | - | 392k| 0 | 21 | 27 | 118 | 27 | 120 | 2 | 0 | 0 | 1.300000e+01 | 2.500000e+01 | 92.31%
989  * b 0.0s| 1 | 0 | 44 | - | 393k| 0 | 21 | 27 | 118 | 27 | 120 | 2 | 0 | 0 | 1.300000e+01 | 1.900000e+01 | 46.15%
990  * ...
991  * 0.1s| 1 | 2 | 107 | - | 920k| 0 | 24 | 27 | 118 | 27 | 131 | 13 | 0 | 24 | 1.300000e+01 | 1.900000e+01 | 46.15%
992  * 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%
993  * 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%
994  * 0.1s| 200 | 86 | 1195 | 5.5 |1012k| 13 | - | 27 | 119 | 27 | 124 | 13 | 1 | 207 | 1.300000e+01 | 1.800000e+01 | 38.46%
995  * time | node | left |LP iter|LP it/n| mem |mdpt |frac |vars |cons |cols |rows |cuts |confs|strbr| dualbound | primalbound | gap
996  * 0.2s| 300 | 106 | 1686 | 5.3 |1024k| 13 | - | 27 | 119 | 27 | 124 | 13 | 1 | 207 | 1.350000e+01 | 1.800000e+01 | 33.33%
997  * ...
998  * 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%
999  *
1000  * SCIP Status : problem is solved [optimal solution found]
1001  * Solving Time (sec) : 0.73
1002  * Solving Nodes : 4192
1003  * Primal Bound : +1.80000000000000e+01 (283 solutions)
1004  * Dual Bound : +1.80000000000000e+01
1005  * Gap : 0.00 %
1006  *
1007  * SCIP> display solution
1008  *
1009  * objective value: 18
1010  * x0001 1 (obj:1)
1011  * x0003 1 (obj:1)
1012  * ...
1013  * x0027 1 (obj:1)
1014  *
1015  * SCIP>
1016  * \endcode
1017  *
1018  * What do we see here? After "optimize", SCIP first goes into presolving. Not much is happening for this instance, just
1019  * the linear constraints get upgraded to more specific types. Each round of presolving will be displayed in a single
1020  * line, with a short summary at the end. Here, there has only been one round with actual changes, the second round did
1021  * not bring any further reductions. Thus, it is not displayed and presolving is stopped. Then, we see the actual
1022  * solving process. The first three output lines indicate that new incumbent solutions were found by the primal
1023  * heuristics with display characters "t", "R", and "s"; see, how the "primalbound" column goes down from 27 to 25. In
1024  * 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
1025  * resolve after adding cuts). Little later, the root node processing is finished. We see that there are now two open
1026  * nodes in the "left" column. From now on, we will see an output line every hundredth node or whenever a new incumbent
1027  * is found (e.g. at node 14 in the above output). After some more nodes, the "dualbound" starts moving, too. At one
1028  * point, both will be the same, and the solving process terminates, showing us some wrap-up information.
1029  *
1030  * The exact performance varies amongst different architectures, operating systems, and so on. Do not be worried if
1031  * your installation needs more or less time or nodes to solve. Also, this instance has more than 2000 different optimal
1032  * solutions. The optimal objective value always has to be 18, but the solution vector may differ. If you are interested
1033  * in this behavior, which is called "performance variability", you may have a look at the MIPLIB2010 paper.
1034  *
1035  * @section TUTORIAL_FILEIO Writing problems and solutions to a file
1036 
1037  * SCIP can also write information to files. E.g., we could store the incumbent solution to a file, or output the
1038  * problem instance in another file format (the LP format is much more human readable than the MPS format, for example).
1039  *
1040  * \code
1041  * SCIP> write solution stein27.sol
1042  *
1043  * written solution information to file <stein27.sol>
1044  *
1045  * SCIP> write problem stein27.lp
1046  * written original problem to file <stein27.lp>
1047  *
1048  * SCIP> q
1049  * ...
1050  * \endcode
1051  *
1052  * Passing starting solutions can increase the solving performance so that SCIP does not need to construct an initial feasible solution
1053  * by itself. After reading the problem instance, use the "read" command again, this time with a file containing solution information.
1054  * Solutions can be specified in a raw or xml-format and must have the file extension ".sol", see the documentation of the
1055  * <a href="http://scip.zib.de/doc/html/reader__sol_8h.php">solution reader of SCIP</a> for further information.
1056  *
1057  * Customized settings are not written or read with the "write" and "read" commands, but with the three commands
1058  *
1059  * \code
1060  * SCIP> set save _settingsfilename_
1061  * SCIP> set diffsave _settingsfilename_
1062  * SCIP> set load _settingsfilename_
1063  * \endcode
1064  *
1065  * See the section on parameters \ref TUTORIAL_PARAMETERS for more information.
1066  *
1067  * @section TUTORIAL_STATISTICS Displaying detailed solving statistics
1068  *
1069  * We might want to have some more information now. Which were the heuristics that found the solutions? What plugins
1070  * were called during the solutions process and how much time did they spend? How did the instance that we were solving
1071  * look? Information on certain plugin types (e.g., heuristics, branching rules, separators) we get by
1072  * "display <plugin-type>", information on the solution process, we get by "display statistics", and "display problem"
1073  * shows us the current instance.
1074  *
1075  \code
1076  * SCIP> display heuristics
1077  * primal heuristic c priority freq ofs description
1078  * ---------------- - -------- ---- --- -----------
1079  * trivial t 10000 0 0 start heuristic which tries some trivial solutions
1080  * ...
1081  * rounding R -1000 1 0 LP rounding heuristic with infeasibility recovering
1082  * shifting s -5000 10 0 LP rounding heuristic with infeasibility recovering also using continuous variables
1083  * ...
1084  * SCIP> display statistics
1085  * ...
1086  * gomory : 0.02 6 0 0 461 0
1087  * cgmip : 0.00 0 0 0 0 0
1088  * strongcg : 0.01 6 0 0 598 0
1089  * ...
1090  * oneopt : 0.01 4 1
1091  * coefdiving : 0.02 57 0
1092  * ...
1093  * primal LP : 0.00 0 0 0.00 -
1094  * dual LP : 0.20 4187 14351 3.43 71755.00
1095  * ...
1096  * \endcode
1097  *
1098  * We see that rounding and shifting were the heuristics producing the solutions in the beginning. Rounding is called at
1099  * every node, shifting only at every tenth level of the tree. The statistics are quite comprehensive, thus, we just
1100  * explain a few lines here. We get information for all types of plugins and for the overall solving process. Besides
1101  * others, we see that in six calls, the gomory cut separator and the strong Chv&aacute;tal-Gomory separator each produced
1102  * several hundred cuts (of which only a few entered the LP). The oneopt heuristic found one solution in 4 calls,
1103  * whereas coefdiving failed all 57 times it was called. All the LPs have been solved with the dual simplex algorithm, which
1104  * took about 0.2 seconds of the 0.7 seconds overall solving time.
1105  *
1106  * @section TUTORIAL_PARAMETERS Changing parameters from the interactive shell
1107  *
1108  * Now, we can start playing around with parameters. Rounding and shifting seem to be quite successful on this instance,
1109  * wondering what happens if we disable them? Or what happens, if we are even more rigorous and disable all heuristics?
1110  * Or if we do the opposite and use aggressive heuristics?
1111  *
1112  * \code
1113  * SCIP> set
1114  *
1115  * <branching> change parameters for branching rules
1116  * ...
1117  * <heuristics> change parameters for primal heuristics
1118  *
1119  * SCIP/set> heuristics
1120  *
1121  * <actconsdiving> LP diving heuristic that chooses fixings w.r.t. the active constraints
1122  * ...
1123  * <shifting> LP rounding heuristic with infeasibility recovering also using continuous variables
1124  * ...
1125  *
1126  * SCIP/set/heuristics> shifting
1127  *
1128  * <advanced> advanced parameters
1129  * freq frequency for calling primal heuristic <shifting> (-1: never, 0: only at depth freqofs) [10]
1130  * freqofs frequency offset for calling primal heuristic <shifting> [0]
1131  *
1132  * SCIP/set/heuristics/shifting> freq
1133  * current value: 10, new value [-1,2147483647]: -1
1134  * heuristics/shifting/freq = -1
1135  *
1136  * SCIP> se he rou freq -1
1137  * heuristics/rounding/freq = -1
1138  *
1139  * SCIP> re check/instances/MIP/stein27.mps
1140  * original problem has 27 variables (27 bin, 0 int, 0 impl, 0 cont) and 118 constraints
1141  * SCIP> o
1142  *
1143  * feasible solution found by trivial heuristic, objective value 2.700000e+01
1144  * ...
1145  * 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%
1146  * 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%
1147  * * 0.1s| 39 | 28 | 386 | 7.0 |1092k| 14 | - | 27 | 118 | 27 | 123 | 14 | 0 | 199 | 1.300000e+01 | 1.800000e+01 | 38.46%
1148  * ...
1149  * SCIP Status : problem is solved [optimal solution found]
1150  * Solving Time (sec) : 0.75
1151  * Solving Nodes : 4253
1152  * Primal Bound : +1.80000000000000e+01 (287 solutions)
1153  * Dual Bound : +1.80000000000000e+01
1154  * Gap : 0.00 %
1155  *
1156  * SCIP>
1157  * \endcode
1158  *
1159  * We can navigate through the menus step-by-step and get a list of available options and submenus. Thus, we select
1160  * "set" to change settings, "heuristics" to change settings of primal heuristics, "shifting" for that particular
1161  * heuristic. Then we see a list of parameters (and yet another submenu for advanced parameters), and disable this
1162  * heuristic by setting its calling frequency to -1. If we already know the path to a certain setting, we can directly
1163  * type it (as for the rounding heuristic in the above example). Note that we do not have to use the full names, but we
1164  * may use short versions, as long as they are unique.
1165  *
1166  * To solve a problem a second time, we have to read it and start the optimization process again.
1167  *
1168  * \code
1169  * SCIP> set default
1170  * reset parameters to their default values
1171  * SCIP> set heuristics emphasis
1172  *
1173  * aggressive sets heuristics <aggressive>
1174  * fast sets heuristics <fast>
1175  * off turns <off> all heuristics
1176  *
1177  * SCIP/set/heuristics/emphasis> aggr
1178  * heuristics/veclendiving/freq = 5
1179  * ...
1180  * heuristics/crossover/minfixingrate = 0.5
1181  * SCIP> read check/instances/MIP/stein27.mps
1182  * original problem has 27 variables (27 bin, 0 int, 0 impl, 0 cont) and 118 constraints
1183 
1184  * SCIP> opt
1185  * ...
1186  * D 0.1s| 1 | 0 | 107 | - | 971k| 0 | 24 | 27 | 122 | 27 | 131 | 13 | 4 | 0 | 1.300000e+01 | 1.800000e+01 | 38.46%
1187  * 0.1s| 1 | 0 | 107 | - | 971k| 0 | 24 | 27 | 122 | 27 | 131 | 13 | 4 | 0 | 1.300000e+01 | 1.800000e+01 | 38.46%
1188  * 0.1s| 1 | 0 | 119 | - |1111k| 0 | 24 | 27 | 122 | 27 | 132 | 14 | 4 | 0 | 1.300000e+01 | 1.800000e+01 | 38.46%
1189  * 0.1s| 1 | 2 | 119 | - |1112k| 0 | 24 | 27 | 122 | 27 | 132 | 14 | 4 | 24 | 1.300000e+01 | 1.800000e+01 | 38.46%
1190  * time | node | left |LP iter|LP it/n| mem |mdpt |frac |vars |cons |cols |rows |cuts |confs|strbr| dualbound | primalbound | gap
1191  * 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%
1192  * 0.2s| 200 | 91 | 1226 | 5.6 |1155k| 14 | - | 27 | 122 | 27 | 123 | 14 | 4 | 207 | 1.300000e+01 | 1.800000e+01 | 38.46%
1193  * ^Cpressed CTRL-C 1 times (5 times for forcing termination)
1194  *
1195  * SCIP Status : solving was interrupted [user interrupt]
1196  * Solving Time (sec) : 0.32
1197  * Solving Nodes : 216
1198  * Primal Bound : +1.80000000000000e+01 (283 solutions)
1199  * Dual Bound : +1.30000000000000e+01
1200  * Gap : 38.46 %
1201  *
1202  * SCIP>
1203  * \endcode
1204  *
1205  * Okay, what happened here? First, we reset all parameters to their default values, using "set default". Next, we
1206  * loaded some meta-parameter settings (also see <a href="http://scip.zib.de/#faq">the FAQ</a>), to apply primal heuristics
1207  * more aggressively. SCIP shows us, which single parameters it changed therefor. Now, the optimal solution is already
1208  * found at the root node, by a heuristic which is deactivated by default. Then, after node 200, the user pressed
1209  * CTRL-C which interrupts the solving process, We see that now in the short status report, primal and dual bound are
1210  * different, thus, the problem is not solved yet. Nevertheless, we could access statistics, see the current incumbent
1211  * solution, change parameters and so on. Entering "optimize" we continue the solving process from the point on at which
1212  * it has been interrupted.
1213  *
1214  * Once you found a non-default parameter setting that you wish to save and use in the future, use either the command
1215  * \code
1216  * SCIP> set save settingsfile.set
1217  * \endcode
1218  * to save <b>all</b> parameter values to the specified file, or
1219  * \code
1220  * SCIP> set diffsave settingsfile.set
1221  * \endcode
1222  * in order to save only the nondefault parameters. The latter has several advantages, you can, e.g., combine parameter
1223  * settings from multiple settings files stored by the latter command, as long as they only affect mutually exclusive
1224  * parameter values.
1225  *
1226  * For loading a previously stored settings file, use the "load" command:
1227  *
1228  * \code
1229  * SCIP> set load settingsfile.set
1230  * \endcode
1231  *
1232  * Special attention should be drawn to the reserved settings file name "scip.set"; whenever the SCIP interactive shell
1233  * is started from a working directory that contains a settings file with the name "scip.set", it will be automatically
1234  * replace the default settings.
1235  *
1236  * For using special settings for automated tests as described in \ref TEST, save your custom settings in a subdirectory
1237  * "SCIP_HOME/settings".
1238  *
1239  *
1240  * We hope this tutorial gave you an overview of what is possible using the SCIP interactive shell. Please also read our
1241  * \ref FAQ, in particular the section <a href="http://scip.zib.de/#faq">Using SCIP as a standalone MIP/MINLP-Solver</a>.
1242  */
1243 
1244 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
1245 /**@page DOC How to search the documentation for interface methods
1246  *
1247  * If you are looking for a method in order to perform a specific task, there are usually two places to look at:
1248  * - The file "scip.h" in the file list.
1249  * In this main header file, you find all methods that perform "complex" operations that affect or need data from
1250  * different components of SCIP.
1251  * For these methods, you always have to provide the SCIP pointer that is created by SCIPcreate().
1252  * The documentation of "scip.h" is grouped into several blocks, each dealing with methods for a specific kind of
1253  * object.
1254  * For example, all methods operating on variables are grouped together.
1255 
1256  * - The files \ref PUBLICMETHODS "pub_<...>.h" contain methods that perform "easy" operations that only
1257  * affect the corresponding objects.
1258  * Usually, with these methods you can access the data of the object.
1259  * For example, in "pub_var.h" you find methods to get information about a variable.
1260  *
1261  * The file "pub_misc.h" contains methods for data structures like priority queues, hash tables, and hash maps,
1262  * as well as methods for sorting, numerics, random numbers, string operations, and file operations.
1263  *
1264  * If you are looking for a description of a callback method of a plugin that you want to implement, you have to
1265  * look at the corresponding \ref TYPEDEFINITIONS "type_<...>.h".
1266  */
1267 
1268 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
1269 /**@page CONS How to add constraint handlers
1270  *
1271  * A constraint handler defines the semantics and the algorithms to process constraints of a certain class. A single
1272  * constraint handler is responsible for all constraints belonging to its constraint class. For example, there is
1273  * one \ref cons_knapsack.h "knapsack constraint handler" that ensures solutions are only accepted if they satisfy all
1274  * knapsack constraints in the model. \n A complete list of all constraint handlers contained in this release can be
1275  * found \ref CONSHDLRS "here".
1276  *
1277  * We now explain how users can add their own constraint handlers.
1278  * For an example, look into the subtour constraint handler (examples/TSP/src/ConshdlrSubtour.cpp) of the
1279  * <a href="http://scip.zib.de/doc/examples/TSP">TSP </a> example project.
1280  * The example is written in C++ and uses the C++ wrapper classes.
1281  * However, we will explain the implementation of a constraint handler using the C interface.
1282  * It is very easy to transfer the C explanation to C++; whenever a method should be implemented using the
1283  * SCIP_DECL_CONS... notion, reimplement the corresponding virtual member function of the abstract scip::ObjConshdlr
1284  * base class.
1285  *
1286  * Additional documentation for the callback methods of a constraint handler can be found in the file
1287  * type_cons.h.
1288  *
1289  * Here is what you have to do (assuming your constraint handler should be named "subtour"):
1290  * -# Copy the template files src/scip/cons_xyz.c and src/scip/cons_xyz.h into files "cons_subtour.c"
1291  * and "cons_subtour.h".
1292  * \n
1293  * Make sure to <b>adjust your Makefile</b> such that these files are compiled and linked to your project.
1294  * -# Use SCIPincludeConsSubtour() in order to include the constraint handler into your SCIP instance,
1295  * e.g., in the main file of your project (see, e.g., src/cppmain.cpp in the TSP example).
1296  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "subtour".
1297  * -# Adjust the \ref CONS_PROPERTIES "properties of the constraint handler".
1298  * -# Define the \ref CONS_DATA "constraint data and the constraint handler data". This is optional.
1299  * -# Implement the \ref CONS_INTERFACE "interface methods".
1300  * -# Implement the \ref CONS_FUNDAMENTALCALLBACKS "fundamental callback methods".
1301  * -# Implement the \ref CONS_ADDITIONALCALLBACKS "additional callback methods". This is optional.
1302  *
1303  *
1304  * @section CONS_PROPERTIES Properties of a Constraint Handler
1305  *
1306  * At the top of the new file "cons_subtour.c" you can find the constraint handler properties.
1307  * These are given as compiler defines. Some of them are optional, as, e.g., separation-related properties,
1308  * which only have to be defined if the constraint handler supports the related callbacks.
1309  * In the C++ wrapper class, you have to provide the constraint handler properties by calling the constructor
1310  * of the abstract base class scip::ObjConshdlr from within your constructor (see the TSP example).
1311  * The properties you have to set have the following meaning:
1312  *
1313  * @subsection CONS_FUNDAMENTALPROPERTIES Fundamental Constraint Handler properties
1314  *
1315  * \par CONSHDLR_NAME: the name of the constraint handler.
1316  * This name is used in the interactive shell to address the constraint handler.
1317  * Additionally, if you are searching for a constraint handler with SCIPfindConshdlr(), this name is looked up.
1318  * Names have to be unique: no two constraint handlers may have the same name.
1319  *
1320  * \par CONSHDLR_DESC: the description of the constraint handler.
1321  * This string is printed as a description of the constraint handler in the interactive shell of SCIP.
1322  *
1323  * \par CONSHDLR_ENFOPRIORITY: the priority of the constraint handler for constraint enforcing.
1324  * Like the separation priority, the enforcement priorities define the order in which the different constraint handlers
1325  * are called in the constraint enforcement step of the subproblem processing.
1326  * The constraint enforcement is called after the price-and-cut loop is executed (in the case that the LP is solved
1327  * at the current subproblem).
1328  * \n
1329  * The integrality constraint handler has an enforcement priority of 0.
1330  * That means, if a constraint handler has negative enforcement priority, it only has to deal with integral solutions
1331  * in its enforcement methods, because for fractional solutions, the integrality constraint handler would have
1332  * created a branching, thereby aborting the enforcement step.
1333  * If you want to implement a constraint-depending branching rule (for example, SOS branching on special ordered
1334  * set constraints), you have to assign a positive enforcement priority to your constraint handler.
1335  * In this case, you have to be able to deal with fractional solutions.
1336  * \n
1337  * See \ref CONSENFOLP and \ref CONSENFOPS for further details of the separation callback.
1338  *
1339  * \par CONSHDLR_CHECKPRIORITY: the priority of the constraint handler for checking feasibility.
1340  * Like the separation priority, the checking priorities define the order in which the different constraint handlers
1341  * are called to check the feasibility of a given primal solution candidate.
1342  * The integrality constraint handler has a checking priority of 0.
1343  * That means, constraint handlers with negative checking priorities only have to deal with integral solutions.
1344  *
1345  * \par CONSHDLR_EAGERFREQ: the default frequency for using all instead of only the useful constraints in separation, propagation and enforcement.
1346  * If \em constraint \em aging is activated, some constraints that were not useful in the past for propagation or
1347  * separation are marked to be \em obsolete.
1348  * Usually, the obsolete constraints are not presented to the separation and propagation methods of the constraint
1349  * handlers, such that the constraint handlers only process the non-obsolete constraints.
1350  * However, every n'th call, with n being the EAGERFREQ of the constraint handler, all constraints are presented to the
1351  * separation and propagation methods of the constraint handler.
1352  * This gives obsolete constraints the chance of becoming non-obsolete again.
1353  * \n
1354  * If the eager evaluation frequency is set to -1, obsolete constraints are never presented to the separation and
1355  * propagation methods.
1356  * A frequency of 0 means, that obsolete constraints are only used in the first call of each method.
1357  *
1358  * \par CONSHDLR_NEEDSCONS: indicates whether the constraint handler should be skipped, if no constraints are available.
1359  * Usually, a constraint handler is only executed if there are constraints of its corresponding class in the model.
1360  * For those constraint handlers, the NEEDSCONS flag should be set to TRUE.
1361  * However, some constraint handlers must be called without having a constraint of the class in the model, because
1362  * the constraint is only implicitly available.
1363  * For example, the integrality constraint handler has the NEEDSCONS flag set to FALSE, because there is no explicit
1364  * integrality constraint in the model.
1365  * The integrality conditions are attached to the variables, and the integrality constraint handler has to check
1366  * all variables that are marked to be integer for integral values.
1367  *
1368  * @subsection CONS_ADDITIONALPROPERTIES Optional Constraint Handler properties
1369  *
1370  * The following properties are optional and only need to be defined if the constraint handlers support
1371  * separation, presolving, propagation, and/or upgrade functionality.
1372  *
1373  * \par LINCONSUPGD_PRIORITY: priority of the constraint handler for upgrading of linear constraints
1374  * This property is only needed if a certain linear constraint can be upgraded to a more specific one. In one of
1375  * the first presolving rounds SCIP tries to upgrade linear constraints to more specialized constraints, such as
1376  * knapsack constraints. The upgrading calls are processed in the order of decreasing priority.
1377  *
1378  * \par NONLINCONSUPGD_PRIORITY: priority of the constraint handler for upgrading of nonlinear constraints
1379  * This property has the same effect as the LINCONSUPGD_PRIORITY parameter, see above, and should be set whenever
1380  * an upgrade functionality from a general nonlinear constraint to the more specific one is defined.
1381  *
1382  * \par CONSHDLR_SEPAFREQ: the default frequency for separating cuts.
1383  * The separation frequency defines the depth levels at which the constraint handler's separation methods \ref CONSSEPALP
1384  * and \ref CONSSEPASOL are called.
1385  * For example, a separation frequency of 7 means, that the separation callback is executed for subproblems that are
1386  * in depth 0, 7, 14, ... of the branching tree.
1387  * A separation frequency of 0 means, that the separation method is only called at the root node.
1388  * A separation frequency of -1 disables the separation method of the constraint handler.
1389  * \n
1390  * The separation frequency can be adjusted by the user.
1391  * This property of the constraint handler only defines the default value of the frequency.
1392  * If you want to have a more flexible control of when to execute the separation algorithm, you have to assign
1393  * a separation frequency of 1 and implement a check at the beginning of your separation algorithm whether you really
1394  * want to execute the separator or not.
1395  * If you do not want to execute the method, set the result code to SCIP_DIDNOTRUN.
1396  *
1397  * \par CONSHDLR_SEPAPRIORITY: the priority of the constraint handler for separation. (optional: to be set only if the constraint handler supports separation)
1398  * In each separation round during the price-and-cut loop of the subproblem processing or during the separation loop
1399  * of the primal solution separation, the separators and separation methods of the constraint handlers are called in
1400  * a predefined order, which is given by the priorities of the separators and the separation priorities of the
1401  * constraint handlers.
1402  * First, the separators with non-negative priority are called in the order of decreasing priority.
1403  * Next, the separation methods of the different constraint handlers are called in the order of decreasing separation
1404  * priority.
1405  * Finally, the separators with negative priority are called in the order of decreasing priority.
1406  * \n
1407  * The separation priority of the constraint handler should be set according to the complexity of the cut separation
1408  * algorithm and the impact of the resulting cuts:
1409  * Constraint handlers that provide fast algorithms that usually have a high impact (i.e., cut off a large portion of
1410  * the LP relaxation) should have a high priority.
1411  * See \ref CONSSEPALP and \ref CONSSEPASOL for further details of the separation callbacks.
1412  *
1413  * \par CONSHDLR_DELAYSEPA: the default for whether the separation method should be delayed, if other separators found cuts.
1414  * If the constraint handler's separation method is marked to be delayed, it is only executed after no other separator
1415  * or constraint handler found a cut during the price-and-cut loop.
1416  * If the separation method of the constraint handler is very expensive, you may want to mark it to be delayed until all
1417  * cheap separation methods have been executed.
1418  *
1419  * \par CONSHDLR_PROPFREQ: the default frequency for propagating domains.
1420  * This default frequency has the same meaning as the CONSHDLR_SEPAFREQ with respect to the domain propagation
1421  * callback of the constraint handler.
1422  * A propagation frequency of 0 means that propagation is only applied in preprocessing and at the root node.
1423  * A propagation frequency of -1 disables the propagation method of the constraint handler.
1424  *
1425  * \par CONSHDLR_DELAYPROP: the default for whether the propagation method should be delayed, if other propagators found reductions.
1426  * This property is analogous to the DELAYSEPA flag, but deals with the propagation method of the constraint handler.
1427  *
1428  * \par CONSHDLR_PROP_TIMING: the propagation timing mask of the constraint handler.
1429  * SCIP calls the domain propagation routines at different places in the node processing loop.
1430  * This property indicates at which places the propagation routine of the constraint handler is called.
1431  * Possible values are defined in type_timing.h and can be concatenated, e.g., as in SCIP_PROPTIMING_ALWAYS.
1432  *
1433  * \par CONSHDLR_PRESOLTIMING: the timing of the constraint handler's presolving method (FAST, MEDIUM, or EXHAUSTIVE).
1434  * Every presolving round starts with the FAST presolving methods. MEDIUM presolvers are only called, if FAST presolvers did not find
1435  * enough reductions in this round so far, and EXHAUSTIVE presolving steps are only performed if all presolvers called before
1436  * in this round were unsuccessful.
1437  * Presolving methods should be assigned a timing based on how expensive they are, e.g., presolvers that provide fast algorithms that
1438  * usually have a high impact (i.e., remove lots of variables or tighten bounds of many variables) should have a timing FAST.
1439  * If a presolving method implements different algorithms of different complexity, it may also get multiple timings and check the timing
1440  * internally in the \ref CONSPRESOL callback to decide which algorithms to run.
1441  *
1442  * \par CONSHDLR_MAXPREROUNDS: the default maximal number of presolving rounds the constraint handler participates in.
1443  * The preprocessing is executed in rounds.
1444  * If enough changes have been applied to the model, an additional preprocessing round is performed.
1445  * The MAXPREROUNDS parameter of a constraint handler denotes the maximal number of preprocessing rounds the constraint
1446  * handler participates in.
1447  * A value of -1 means that there is no limit on the number of rounds.
1448  * A value of 0 means the preprocessing callback of the constraint handler is disabled.
1449  *
1450  *
1451  *
1452  * @section CONS_DATA Constraint Data and Constraint Handler Data
1453  *
1454  * Below the header "Data structures" you can find two structs called "struct SCIP_ConsData" and
1455  * "struct SCIP_ConshdlrData".
1456  * If you are using C++, you only need to define the "struct SCIP_ConsData".
1457  * The constraint handler data must be implemented as member variables of your constraint handler class.
1458  * \n
1459  * The constraint data are the information that is needed to define a single constraint of the constraint handler's
1460  * constraint class.
1461  * For example, the data of a knapsack constraint would consist of a list of variables, a list of weights, and
1462  * the capacity of the knapsack.
1463  * The data of a subtour constraint consists of the graph on which the problem is defined.
1464  * In the graph, each edge should be linked to the corresponding binary problem variable.
1465  * \n
1466  * The constraint handler data are additional variables, that belong to the constraint handler itself and which are
1467  * not specific to a single constraint.
1468  * For example, you can use these data to store parameters of the constraint handler or statistical information.
1469  * The constraint handler data are optional.
1470  * You can leave the struct empty.
1471  *
1472  *
1473  * @section CONS_INTERFACE Interface Methods
1474  *
1475  * At the bottom of "cons_subtour.c" you can find three interface methods, that also appear in "cons_subtour.h".
1476  * These are SCIPincludeConshdlrSubtour(), SCIPcreateConsSubtour(), and SCIPcreateConsSubtourBasic().
1477  * \n
1478  * The method SCIPincludeConshdlrSubtour() only has to be adjusted slightly.
1479  * It is responsible for notifying SCIP of the presence of the constraint handler by calling the method
1480  * SCIPincludeConshdlr().
1481  * It is called by the user, if (s)he wants to include the constraint handler, i.e., if (s)he wants to make
1482  * the constraint handler available to the model, and looks like this:
1483  * -# If you are using constraint handler data, you have to <b>allocate the memory for the data</b> at this point.
1484  * You also have to initialize the fields in struct SCIP_ConshdlrData afterwards.
1485  * \code
1486  * SCIP_RETCODE SCIPincludeConshdlrKnapsack(
1487  * ...
1488  * )
1489  * {
1490  * SCIP_EVENTHDLRDATA* eventhdlrdata;
1491  * SCIP_CONSHDLRDATA* conshdlrdata;
1492  * SCIP_CONSHDLR* conshdlr;
1493  *
1494  * SCIP_CALL( SCIPallocMemory(scip, &conshdlrdata) );
1495  * ...
1496  * \endcode
1497  * -# Now, <b>SCIP gets notified</b> of the presence of the constraint handler together with its \ref CONS_FUNDAMENTALCALLBACKS "basic callbacks".
1498  * \code
1499  * SCIP_CALL( SCIPincludeConshdlrBasic(scip, &conshdlr, CONSHDLR_NAME, CONSHDLR_DESC,
1500  * CONSHDLR_ENFOPRIORITY, CONSHDLR_CHECKPRIORITY, CONSHDLR_EAGERFREQ, CONSHDLR_NEEDSCONS,
1501  * consEnfolpKnapsack, consEnfopsKnapsack, consCheckKnapsack, consLockKnapsack,
1502  * conshdlrdata) );
1503  * assert(conshdlr != NULL);
1504  * \endcode
1505  * -# All \ref CONS_ADDITIONALCALLBACKS "additional callbacks" are added via their setter functions.
1506  * \code
1507  * SCIP_CALL( SCIPsetConshdlrCopy(scip, conshdlr, conshdlrCopyKnapsack, consCopyKnapsack) );
1508  * SCIP_CALL( SCIPsetConshdlrTrans(scip, conshdlr, consTransKnapsack) );
1509  * \endcode
1510  * -# If the constraint handler is a specialization of a general linear or nonlinear constraint, we want to include an <b>automatic
1511  * upgrading mechanism</b> by calling the interface method
1512  * \code
1513  * if( SCIPfindConshdlr(scip,"linear") != NULL )
1514  * {
1515  * SCIP_CALL( SCIPincludeLinconsUpgrade(scip, linconsUpgdKnapsack, LINCONSUPGD_PRIORITY, CONSHDLR_NAME) );
1516  * }
1517  * \endcode
1518  * or
1519  * \code
1520  * SCIP_CALL( SCIPincludeNonlinconsUpgrade(scip, nonlinconsUpgdSubtour, NULL, NONLINCONSUPGD_PRIORITY, TRUE, CONSHDLR_NAME) );
1521  * \endcode
1522  * in the nonlinear case.
1523  * See also cons_nonlinear.h for further information about the general upgrade procedure in the nonlinear case.
1524  * -# You may also add <b>user parameters</b> for your constraint handler.
1525  * Some parameters which are important to play with are added to every constraint automatically, as, e.g.,
1526  * propagation or separation frequency.
1527  * \code
1528  * SCIP_CALL( SCIPaddIntParam(scip,
1529  * "constraints/knapsack/sepacardfreq",
1530  * "multiplier on separation frequency, how often knapsack cuts are separated (-1: never, 0: only at root)",
1531  * &conshdlrdata->sepacardfreq, TRUE, DEFAULT_SEPACARDFREQ, -1, INT_MAX, NULL, NULL) );
1532  * ...
1533  * return SCIP_OKAY;
1534  * }
1535  * \endcode
1536  *
1537  *
1538  *
1539  *
1540  * The methods SCIPcreateConsSubtour() and SCIPcreateConsSubtourBasic() are called to create a single constraint of the constraint
1541  * handler's constraint class.
1542  * It should allocate and fill the constraint data, and call SCIPcreateCons().
1543  * Take a look at the following example from the \ref cons_knapsack.h "knapsack constraint handler":
1544  *
1545  * \code
1546  * SCIP_RETCODE SCIPcreateConsKnapsack(
1547  * SCIP* scip,
1548  * SCIP_CONS** cons,
1549  * const char* name,
1550  * int nvars,
1551  * SCIP_VAR** vars,
1552  * SCIP_Longint* weights,
1553  * SCIP_Longint capacity,
1554  * SCIP_Bool initial,
1555  * SCIP_Bool separate,
1556  * SCIP_Bool enforce,
1557  * SCIP_Bool check,
1558  * SCIP_Bool propagate,
1559  * SCIP_Bool local,
1560  * SCIP_Bool modifiable,
1561  * SCIP_Bool dynamic,
1562  * SCIP_Bool removable,
1563  * SCIP_Bool stickingatnode
1564  * )
1565  * {
1566  * SCIP_CONSHDLRDATA* conshdlrdata;
1567  * SCIP_CONSHDLR* conshdlr;
1568  * SCIP_CONSDATA* consdata;
1569  *
1570  * conshdlr = SCIPfindConshdlr(scip, CONSHDLR_NAME);
1571  * if( conshdlr == NULL )
1572  * {
1573  * SCIPerrorMessage("knapsack constraint handler not found\n");
1574  * return SCIP_PLUGINNOTFOUND;
1575  * }
1576  *
1577  * conshdlrdata = SCIPconshdlrGetData(conshdlr);
1578  * assert(conshdlrdata != NULL);
1579  * assert(conshdlrdata->eventhdlr != NULL);
1580  *
1581  * SCIP_CALL( consdataCreate(scip, &consdata, conshdlrdata->eventhdlr, nvars, vars, weights, capacity) );
1582  *
1583  * SCIP_CALL( SCIPcreateCons(scip, cons, name, conshdlr, consdata, initial, separate, enforce, check, propagate,
1584  * local, modifiable, dynamic, removable, stickingatnode) );
1585  *
1586  * return SCIP_OKAY;
1587  * }
1588  * \endcode
1589  *
1590  * In this example, consdataCreate() is a local method that allocates memory for the given consdata
1591  * and fills the data with the given <code>vars</code> array. For allocating memory for the constraint data, you
1592  * can use SCIP memory allocation:
1593  * \code
1594  * SCIP_CALL( SCIPallocBlockMemory(scip, consdata) );
1595  * \endcode
1596  *
1597  *
1598  * @section CONS_CALLBACKS Callback methods of Constraint handlers
1599  *
1600  * Besides the various functions which you will implement inside your constraint handler there exists a number
1601  * of <b> callback methods </b> associated with your constraint handler. Callback methods can be regarded as
1602  * tasks which your constraint handler is able to provide to the solver. They are grouped into two
1603  * categories:
1604  *
1605  * \ref CONS_FUNDAMENTALCALLBACKS "Fundamental Callback methods" are mandatory to implement
1606  * such that your code will work. For example, every constraint handler has to provide the
1607  * functionality to state whether all of its constraints are
1608  * fulfilled by a given variable assignment. Hence, the \ref CONSCHECK "CONSCHECK" callback is
1609  * one of the fundamental (or \a basic) callbacks of a constraint handler.
1610  *
1611  * Callbacks which are not necessarily implemented are grouped together as
1612  * \ref CONS_ADDITIONALCALLBACKS "additional callbacks". Such callbacks can be used to allocate and free memory
1613  * at different stages of the solving process. Although not mandatory, it might be useful to implement
1614  * some of these callbacks, e.g., to extend your constraint handler by a
1615  * \ref CONSSEPALP "separation" or \ref CONSPRESOL "presolving" functionality.
1616  *
1617  * All callbacks should be passed to SCIP during the SCIPinclude<PLUGINTYPE><PLUGINNAME> method
1618  * (e.g., SCIPincludeConshdlrKnapsack() for the \ref cons_knapsack.h "knapsack constraint handler").
1619  * Since SCIP version 3.0, two ways of setting callbacks can be used, either via SCIPincludeConshdlr()
1620  * (all at once, as it always was), or via SCIPincludeConshdlrBasic() and setter functions for additional callbacks.
1621  * Since the basic inclusion methods are very unlikely to change and will thus
1622  * make your code more stable towards future versions of SCIP with more callbacks,
1623  * we recommend the latter choice, as explained in the \ref CONS_INTERFACE "interface" section.
1624  *
1625  * @section CONS_FUNDAMENTALCALLBACKS Fundamental Callback Methods
1626  *
1627  * By implementing the fundamental callbacks, you define the semantics of the constraint class the constraint handler
1628  * deals with.
1629  * If these methods are implemented, the resulting code is already correct and finds the optimal solution to the
1630  * given problem instance.
1631  * However, it might be very slow because the additional features, like cut separation and domain propagation, are
1632  * missing.
1633  * In the C++ wrapper class scip::ObjConshdlr, the fundamental callback methods are virtual abstract member functions.
1634  * You have to implement them in order to be able to construct an object of your constraint handler class.
1635  *
1636  * There are three fundamental callback methods that are all dealing with the feasibility of a given solution.
1637  * They are called at different places in the algorithm and have slightly different meaning.
1638  * However, it is usually reasonable to implement a single local method that is called by all of the three callback
1639  * methods with slightly modified parameters.
1640  * The fourth method provides dual information that is used for example in preprocessing.
1641  *
1642  * Additional documentation for the callback methods can be found in type_cons.h.
1643  *
1644  * @subsection CONSCHECK
1645  *
1646  * The CONSCHECK callback gets a primal solution candidate in a SCIP_SOL* data structure
1647  * and has to check this solution for global feasibility.
1648  * It has to return a result SCIP_FEASIBLE, if the solution satisfies all the constraints of the constraint handler,
1649  * and a result SCIP_INFEASIBLE if there is at least one constraint that is violated.
1650  * The callback is used by primal heuristics to check a constructed solution for feasibility.
1651  * That means, the constraint handler has to deal with arbitrary solutions that do not necessarily satisfy the bounds
1652  * and constraints of the local subproblem.
1653  *
1654  * The value of a variable \em var in the given solution \em sol can be accessed by calling
1655  * \code
1656  * SCIPgetSolVal(scip, sol, var)
1657  * \endcode
1658  *
1659  * For example, the \ref cons_knapsack.h "knapsack constraint handler" loops over its constraints and
1660  * calculates the scalar product \f$w^T x\f$ of weights \f$w\f$ with the solution vector \f$x\f$.
1661  * This scalar product is compared with the capacity of the knapsack constraint.
1662  * If it exceeds the capacity, the CONSCHECK method is immediately aborted with the result SCIP_INFEASIBLE.
1663  * If all knapsack constraints are satisfied, a result SCIP_FEASIBLE is returned.
1664  *
1665  * @subsection CONSENFOLP
1666  *
1667  * The CONSENFOLP method is called after the price-and-cut loop was finished and an LP solution is available.
1668  * Like the CHECK call, the ENFOLP method should return a result SCIP_FEASIBLE, if the solution satisfies all the
1669  * constraints.
1670  * However, the behavior should be different, if the solution violates some of the associated constraints.
1671  * The constraint handler may return a result SCIP_INFEASIBLE in this situation, but this is not the best what
1672  * one can do.
1673  * The ENFOLP method has the possibility of \em resolving the infeasibility by
1674  * - stating that the current subproblem is infeasible (result SCIP_CUTOFF),
1675  * - adding an additional constraint that resolves the infeasibility (result SCIP_CONSADDED),
1676  * - reducing the domain of a variable (result SCIP_REDUCEDDOM),
1677  * - adding a cutting plane (result SCIP_SEPARATED),
1678  * - performing a branching (result SCIP_BRANCHED).
1679  *
1680  * However, the solution is not given as a SCIP_SOL* data structure.
1681  *
1682  * The value of a variable <code>var</code> in the LP solution can be accessed by calling
1683  * \code
1684  * SCIPgetVarSol(scip, var)
1685  * \endcode
1686  * or by
1687  * \code
1688  * SCIPgetSolVal(scip, NULL, var)
1689  * \endcode
1690  * By using the latter method, you can have a single local method to check a solution for feasibility by passing
1691  * the given <code>sol</code> to the CONSCHECK call and by passing a NULL pointer as <code>sol</code> to
1692  * the CONSENFOLP and CONSENFOPS calls.
1693  *
1694  *
1695  * @subsection CONSENFOPS
1696  *
1697  * The CONSENFOPS callback is similar to the CONSENFOLP callback, but deals with \em pseudo \em solutions instead
1698  * of LP solutions.
1699  *
1700  * If the LP was not solved at the current subproblem (either because the user did not want to solve it, or because
1701  * numerical difficulties in the LP solving process were detected) no LP solution is available.
1702  * In this situation, the pseudo solution is used instead.
1703  * In this solution, the variables are set to the local bound which is best with respect to the objective function.
1704  * You can think of the pseudo solution as solution to the LP relaxation with all constraints except the bounds
1705  * being removed.
1706  *
1707  * Like the ENFOLP callback, the ENFOPS callback has to check whether the pseudo solution satisfies all the constraints
1708  * of the constraint handler.
1709  * The pseudo solution can be accessed by the same methods as the LP solution (SCIP knows, if the LP was solved at the
1710  * current subproblem, and returns either the LP solution or the pseudo solution).
1711  *
1712  * Unlike the ENFOLP callback, the ENFOPS callback must not add cuts and cannot return the result SCIP_SEPARATED.
1713  * It is, however, possible to force the solving of the LP by returning the result SCIP_SOLVELP.
1714  * For example, the infeasibility of a linear constraint that contains continuous variables cannot be resolved,
1715  * if all integer variables in the constraint are already fixed.
1716  * In this case, the LP has to be solved in order to get a solution that satisfies the linear constraint.
1717  *
1718  * @subsection CONSLOCK
1719  *
1720  * The CONSLOCK callback provides dual information for a single constraint.
1721  * It has to tell SCIP, which variables are existing in the given constraint, and in which way modifications of these
1722  * variables may affect the feasibility of the constraint.
1723  *
1724  * For each variable that is affected by the constraint, the callback should call SCIPaddVarLocks():
1725  * - If the constraint may become violated by decreasing the value of a variable, it should call
1726  * SCIPaddVarLocks(scip, var, nlockspos, nlocksneg), saying that rounding down is potentially rendering the
1727  * (positive) constraint infeasible and rounding up is potentially rendering the negation of the constraint
1728  * infeasible.
1729  * - If the constraint may become violated by increasing the value of a variable, it should call
1730  * SCIPaddVarLocks(scip, var, nlocksneg, nlockspos), saying that rounding up is potentially rendering the
1731  * constraint's negation infeasible and rounding down is potentially rendering the constraint itself
1732  * infeasible.
1733  * - If the constraint may become violated by changing the variable in any direction, it should call
1734  * SCIPaddVarLocks(scip, var, nlockspos + nlocksneg, nlockspos + nlocksneg).
1735  *
1736  * <b>Note:</b> You do not have to worry about nlockspos and nlocksneg. These integer values are given as
1737  * parameter of the CONSLOCK callback (see type_cons.h). Just use these variables in the above described
1738  * fashion <b>without</b> adding or subtracting anything to them. In case of the knapsack constraints this
1739  * method looks like this.
1740  *
1741  * \code
1742  * static
1743  * SCIP_DECL_CONSLOCK(consLockKnapsack)
1744  * {
1745  * SCIP_CONSDATA* consdata;
1746  * int i;
1747  *
1748  * consdata = SCIPconsGetData(cons);
1749  * assert(consdata != NULL);
1750  *
1751  * for( i = 0; i < consdata->nvars; i++)
1752  * {
1753  * SCIP_CALL( SCIPaddVarLocks(scip, consdata->vars[i], nlocksneg, nlockspos) );
1754  * }
1755  *
1756  * return SCIP_OKAY;
1757  * }
1758  * \endcode
1759  *
1760  * To give same more intuition, consider the linear constraint \f$3x -5y +2z \leq 7\f$ as an example.
1761  * The CONSLOCK callback method of the linear constraint handler should call
1762  * SCIPaddVarLocks(scip, x, nlocksneg, nlockspos), SCIPaddVarLocks(scip, y, nlockspos, nlocksneg),
1763  * and SCIPaddVarLocks(scip, z, nlocksneg, nlockspos) to tell SCIP, that rounding up of \f$x\f$
1764  * and \f$z\f$ and rounding down of \f$y\f$ can destroy the feasibility of the constraint, while rounding
1765  * down of \f$x\f$ and \f$z\f$ and rounding up of \f$y\f$ can destroy the feasibility of the
1766  * constraint's negation \f$3x -5y +2z > 7\f$.
1767  * \n
1768  * A linear constraint \f$2 \leq 3x -5y +2z \leq 7\f$ should call
1769  * SCIPaddVarLocks(scip, ..., nlockspos + nlocksneg, nlockspos + nlocksneg) on all variables,
1770  * since rounding in both directions of each variable can destroy both the feasibility of the
1771  * constraint and it's negation \f$3x -5y +2z < 2\f$ or \f$3x -5y +2z > 7\f$.
1772  *
1773  *
1774  * @section CONS_ADDITIONALCALLBACKS Additional Callback Methods
1775  *
1776  * The additional callback methods do not need to be implemented in every case, but provide useful functionality
1777  * for many applications. They can be added to your constraint handler via setter functions, see
1778  * \ref CONS_INTERFACE "here".
1779  *
1780  * @subsection CONSFREE
1781  *
1782  * If you are using constraint handler data, you have to implement this method in order to free the
1783  * constraint handler data. This can be done by the following procedure (which is taken from the
1784  * \ref cons_knapsack.h "knapsack constraint handler"):
1785  *
1786  * \code
1787  * static
1788  * SCIP_DECL_CONSFREE(consFreeKnapsack)
1789  * {
1790  * SCIP_CONSHDLRDATA* conshdlrdata;
1791  *
1792  * conshdlrdata = SCIPconshdlrGetData(conshdlr);
1793  * assert(conshdlrdata != NULL);
1794  *
1795  * SCIPfreeMemory(scip, &conshdlrdata);
1796  *
1797  * SCIPconshdlrSetData(conshdlr, NULL);
1798  *
1799  * return SCIP_OKAY;
1800  * }
1801  * \endcode
1802  *
1803  * If you have allocated memory for fields in your constraint handler data, remember to free this memory
1804  * before freeing the constraint handler data itself.
1805  * If you are using the C++ wrapper class, this method is not available.
1806  * Instead, just use the destructor of your class to free the member variables of your class.
1807  *
1808  * @subsection CONSHDLRCOPY
1809  *
1810  * The CONSHDLRCOPY callback is executed when the SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this
1811  * callback as <code>NULL</code> the user disables the inclusion of the specified constraint handler into all copied SCIP
1812  * instances. This may deteriorate the performance of primal heuristics solving sub-SCIPs, since these constitute only
1813  * relaxations of the original problem if constraint handlers are missing.
1814  *
1815  * A usual implementation just
1816  * calls the interface method which includes the constraint handler to the model. For example, this callback is
1817  * implemented for the knapsack constraint handler as follows:
1818  *
1819  * \code
1820  * static
1821  * SCIP_DECL_CONSHDLRCOPY(conshdlrCopyKnapsack)
1822  * {
1823  * assert(scip != NULL);
1824  * assert(conshdlr != NULL);
1825  * assert(strcmp(SCIPconshdlrGetName(conshdlr), CONSHDLR_NAME) == 0);
1826  *
1827  * SCIP_CALL( SCIPincludeConshdlrKnapsack(scip) );
1828  *
1829  * *valid = TRUE;
1830  *
1831  * return SCIP_OKAY;
1832  * }
1833  * \endcode
1834  *
1835  * <b>Note:</b> If you implement this callback, take care when setting the valid pointer. The valid pointer should be
1836  * set to TRUE if (and only if!) you can make sure that all necessary data of the constraint handler are copied
1837  * correctly. If the complete problem is validly copied, i.e. if the copy methods of all problem defining plugins
1838  * (constraint handlers and pricers) return <code>*valid = TRUE</code>, then dual reductions found for the copied problem can be
1839  * transferred to the original SCIP instance. Thus, if the valid pointer is wrongly set to TRUE, it might happen that
1840  * optimal solutions are cut off.
1841  *
1842  * <b>Note:</b> If you implement this callback and the constraint handler needs constraints (see CONSHDLR_NEEDSCONS),
1843  * then you also need to implement the callback \ref CONSCOPY.
1844  *
1845  * @subsection CONSINIT
1846  *
1847  * The CONSINIT callback is executed after the problem is transformed.
1848  * The constraint handler may, e.g., use this call to replace the original variables in its constraints by transformed
1849  * variables, or to initialize its statistical constraint handler data.
1850  *
1851  * @subsection CONSEXIT
1852  *
1853  * The CONSEXIT callback is executed before the transformed problem is freed.
1854  * In this method, the constraint handler should free all resources that were allocated for the solving process.
1855  *
1856  * @subsection CONSINITPRE
1857  *
1858  * The CONSINITPRE callback is executed before the preprocessing is started, even if presolving is turned off.
1859  * The constraint handler may use this call to initialize its presolving data, or to modify its constraints
1860  * before the presolving process begins.
1861  * Necessary constraint modifications that have to be performed even if presolving is turned off should be done here
1862  * or in the presolving deinitialization call.
1863  *
1864  * @subsection CONSEXITPRE
1865  *
1866  * The CONSEXITPRE callback is executed after the preprocessing has been finished, even if presolving is turned off.
1867  * The constraint handler may use this call e.g. to clean up its presolving data, or to finally modify its constraints
1868  * before the branch-and-bound process begins.
1869  * Necessary constraint modifications that have to be performed even if presolving is turned off should be done here
1870  * or in the presolving initialization call.
1871  * Besides necessary modifications and clean up, no time consuming operations should be done.
1872  *
1873  * @subsection CONSINITSOL
1874  *
1875  * The CONSINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
1876  * begin.
1877  * The constraint handler may use this call to initialize its branch-and-bound specific data.
1878  *
1879  * @subsection CONSEXITSOL
1880  *
1881  * The CONSEXITSOL callback is executed before the branch-and-bound process is freed.
1882  * The constraint handler should use this call to clean up its branch-and-bound data, in particular to release
1883  * all LP rows that it has created or captured.
1884  *
1885  * @subsection CONSDELETE
1886  *
1887  * The CONSDELETE callback is executed if a constraint should be freed.
1888  * You can think of it as the destructor of a single constraint.
1889  * In the callback, you have to free the given constraint data.
1890  * The CONSDELETE callback is therefore the counterpart of the SCIPcreateCons...() interface method and the CONSTRANS
1891  * method.
1892  *
1893  * @subsection CONSTRANS
1894  *
1895  * The CONSTRANS method is called for each constraint of the constraint handler, when the user starts the solving
1896  * process.
1897  * It has to copy the original constraint data of the constraint to the memory for the transformed problem.
1898  * You can think of it as a copy constructor for a single constraint.
1899  *
1900  * The original model is copied in order to protect it from transformations that are applied during the solving process,
1901  * in particular during preprocessing.
1902  * Preprocessing and solving always operates on the transformed problem.
1903  * If the solving process data are freed, the original data still exist and the user can, e.g., modify the problem and
1904  * restart the solving process.
1905  *
1906  * If you do not implement the CONSTRANS method, a transformed constraint is created with the same flags and the
1907  * same constraint data pointer.
1908  * That means, the transformed constraint points to the original constraint data.
1909  * This is okay, as long as the constraint data is not changed during the solving process.
1910  * If you want to implement preprocessing methods or other methods that modify the constraint data, you have to
1911  * implement the CONSTRANS method and create a copy of the constraint data.
1912  *
1913  * Here is an example, which is taken from the \ref cons_knapsack.h "knapsack constraint handler":
1914  * \code
1915  * static
1916  * SCIP_DECL_CONSTRANS(consTransKnapsack)
1917  * {
1918  * SCIP_CONSHDLRDATA* conshdlrdata;
1919  * SCIP_CONSDATA* sourcedata;
1920  * SCIP_CONSDATA* targetdata;
1921  *
1922  * assert(conshdlr != NULL);
1923  * assert(strcmp(SCIPconshdlrGetName(conshdlr), CONSHDLR_NAME) == 0);
1924  * assert(SCIPgetStage(scip) == SCIP_STAGE_TRANSFORMING);
1925  * assert(sourcecons != NULL);
1926  * assert(targetcons != NULL);
1927  *
1928  * sourcedata = SCIPconsGetData(sourcecons);
1929  * assert(sourcedata != NULL);
1930  * assert(sourcedata->row == NULL);
1931  *
1932  * conshdlrdata = SCIPconshdlrGetData(conshdlr);
1933  * assert(conshdlrdata != NULL);
1934  * assert(conshdlrdata->eventhdlr != NULL);
1935  *
1936  * SCIP_CALL( consdataCreate(scip, &targetdata, conshdlrdata->eventhdlr,
1937  * sourcedata->nvars, sourcedata->vars, sourcedata->weights, sourcedata->capacity) );
1938  *
1939  * SCIP_CALL( SCIPcreateCons(scip, targetcons, SCIPconsGetName(sourcecons), conshdlr, targetdata,
1940  * SCIPconsIsInitial(sourcecons), SCIPconsIsSeparated(sourcecons), SCIPconsIsEnforced(sourcecons),
1941  * SCIPconsIsChecked(sourcecons), SCIPconsIsPropagated(sourcecons),
1942  * SCIPconsIsLocal(sourcecons), SCIPconsIsModifiable(sourcecons),
1943  * SCIPconsIsDynamic(sourcecons), SCIPconsIsRemovable(sourcecons), SCIPconsIsStickingAtNode(sourcecons)) );
1944  *
1945  * return SCIP_OKAY;
1946  * }
1947  * \endcode
1948  *
1949  * @subsection CONSINITLP
1950  *
1951  * The CONSINITLP callback is executed before the first LP relaxation is solved.
1952  * It should add the LP relaxations of all "initial" constraints to the LP. The method should scan the constraints
1953  * array for constraints that are marked initial via calls to SCIPconsIsInitial() and put the LP relaxation
1954  * of all initial constraints to the LP with calls to SCIPaddCut().
1955  *
1956  * @subsection CONSSEPALP
1957  *
1958  * The CONSSEPALP callback is executed during the price-and-cut loop of the subproblem processing.
1959  * It should try to generate cutting planes for the constraints of the constraint handler in order to separate
1960  * the current LP solution.
1961  * The method is called in the LP solution loop, which means that a valid LP solution exists.
1962  *
1963  * Usually, a separation callback searches and produces cuts, that are added with a call to SCIPaddCut().
1964  * If the cut should be remembered in the global cut pool, it may also call SCIPaddPoolCut().
1965  * However, the callback may also produce domain reductions or add other constraints.
1966  *
1967  * The CONSSEPALP callback has the following options:
1968  * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
1969  * - adding an additional constraint (result SCIP_CONSADDED)
1970  * - reducing a variable's domain (result SCIP_REDUCEDDOM)
1971  * - adding a cutting plane to the LP (result SCIP_SEPARATED)
1972  * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
1973  * (result SCIP_DIDNOTFIND)
1974  * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
1975  * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
1976  * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
1977  *
1978  * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1979  * CONSHDLR_SEPAFREQ, CONSHDLR_SEPAPRIORITY, and CONSHDLR_DELAYSEPA, which influence the behaviour of SCIP
1980  * calling CONSSEPALP.
1981  *
1982  * @subsection CONSSEPASOL
1983  *
1984  * The CONSSEPASOL callback is executed during separation loop on arbitrary primal solutions.
1985  * It should try to generate cutting planes for the constraints of the constraint handler in order to separate
1986  * the given primal solution.
1987  * The method is not called in the LP solution loop, which means that there is no valid LP solution.
1988  *
1989  * Usually, a separation callback searches and produces cuts, that are added with a call to SCIPaddCut().
1990  * If the cut should be remembered in the global cut pool, it may also call SCIPaddPoolCut().
1991  * However, the callback may also produce domain reductions or add other constraints.
1992  *
1993  * The CONSSEPASOL callback has the following options:
1994  * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
1995  * - adding an additional constraint (result SCIP_CONSADDED)
1996  * - reducing a variable's domain (result SCIP_REDUCEDDOM)
1997  * - adding a cutting plane to the LP (result SCIP_SEPARATED)
1998  * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
1999  * (result SCIP_DIDNOTFIND)
2000  * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
2001  * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
2002  * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
2003  *
2004  * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
2005  * CONSHDLR_SEPAFREQ, CONSHDLR_SEPAPRIORITY, and CONSHDLR_DELAYSEPA, which influence the behaviour of SCIP
2006  * calling CONSSEPASOL.
2007  *
2008  * @subsection CONSPROP
2009  *
2010  * The CONSPROP callback is called during the subproblem processing.
2011  * It should propagate the constraints, which means that it should infer reductions in the variables' local bounds
2012  * from the current local bounds.
2013  * This technique, which is the main workhorse of constraint programming, is called "node preprocessing" in the
2014  * Integer Programming community.
2015  *
2016  * The CONSPROP callback has the following options:
2017  * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
2018  * - reducing a variable's domain (result SCIP_REDUCEDDOM)
2019  * - stating that the propagator searched, but did not find domain reductions, cutting planes, or cut constraints
2020  * (result SCIP_DIDNOTFIND)
2021  * - stating that the propagator was skipped (result SCIP_DIDNOTRUN)
2022  * - stating that the propagator was skipped, but should be called again (result SCIP_DELAYED)
2023  *
2024  * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
2025  * CONSHDLR_PROPFREQ, CONSHDLR_DELAYPROP, and CONSHDLR_PROP_TIMING, which influence the behaviour of SCIP
2026  * calling CONSPROP.
2027  *
2028  * @subsection CONSRESPROP
2029  *
2030  * If the constraint handler should support \ref CONF "conflict analysis", it has to supply a CONSRESPROP method.
2031  * It also should call SCIPinferVarLbCons() or SCIPinferVarUbCons() in domain propagation instead of SCIPchgVarLb() or
2032  * SCIPchgVarUb() in order to deduce bound changes on variables.
2033  * In the SCIPinferVarLbCons() and SCIPinferVarUbCons() calls, the handler provides the constraint that deduced the
2034  * variable's bound change, and an integer value <code>inferinfo</code> that can be arbitrarily chosen.
2035  *
2036  * The propagation conflict resolving method CONSRESPROP must then be implemented to provide the "reasons" for the bound
2037  * changes, i.e., the bounds of variables at the time of the propagation, which forced the constraint to set the
2038  * conflict variable's bound to its current value. It can use the <code>inferinfo</code> tag to identify its own propagation rule
2039  * and thus identify the "reason" bounds. The bounds that form the reason of the assignment must then be provided by
2040  * calls to SCIPaddConflictLb() and SCIPaddConflictUb() in the propagation conflict resolving method.
2041  *
2042  * <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
2043  * need more information to efficiently infer the original propagation steps that lead to the conflict. This would,
2044  * however, require too much space. In the extreme, the original propagation steps have to be repeated.
2045  *
2046  * 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
2047  * 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
2048  * variables are 0.0). It uses <code>SCIPinferVarLbCons(scip, z, 1.0, c, 0)</code> to apply this assignment (an
2049  * inference information tag is not needed by the constraint handler and is set to 0). In the conflict analysis, the
2050  * constraint handler may be asked to resolve the lower bound change on \f$z\f$ with constraint \f$c\f$, that was
2051  * applied at a time given by a bound change index "bdchgidx". With a call to <code>SCIPvarGetLbAtIndex(z,
2052  * bdchgidx)</code>, the handler can find out, that the lower bound of variable \f$z\f$ was set to 1.0 at the given
2053  * point of time, and should call <code>SCIPaddConflictUb(scip, x, bdchgidx)</code> and <code>SCIPaddConflictUb(scip, y,
2054  * 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
2055  * the deduction of the lower bound of \f$z\f$.
2056  *
2057  * If conflict analysis should not be supported, the method has to set the result code to SCIP_DIDNOTFIND. Although
2058  * this is a viable approach to circumvent the implementation of the usually rather complex conflict resolving method, it
2059  * will make the conflict analysis less effective. We suggest to first omit the conflict resolving method and check how
2060  * effective the \ref CONSPROP "propagation method" is. If it produces a lot of propagations for your application, you definitely should
2061  * consider implementing the conflict resolving method.
2062  *
2063  * @subsection CONSPRESOL
2064  *
2065  * The CONSPRESOL callback is called during preprocessing.
2066  * It should try to tighten the domains of the variables, tighten the coefficients of the constraints of the constraint
2067  * handler, delete redundant constraints, aggregate and fix variables if possible, and upgrade constraints to more
2068  * specific types.
2069  *
2070  * If the CONSPRESOL callback applies changes to the constraint data, you also have to implement the \ref CONSTRANS callback
2071  * in order to copy the constraint data to the transformed problem space and protect the original problem from the
2072  * preprocessing changes.
2073  *
2074  * To inform SCIP that the presolving method found a reduction the result pointer has to be set in a proper way.
2075  * The following options are possible:
2076  *
2077  * - SCIP_UNBOUNDED : at least one variable is not bounded by any constraint in objective direction
2078  * - SCIP_CUTOFF : at least one constraint is infeasible in the variable's bounds
2079  * - SCIP_SUCCESS : the presolver found a reduction
2080  * - SCIP_DIDNOTFIND : the presolver searched, but did not find a presolving change
2081  * - SCIP_DIDNOTRUN : the presolver was skipped
2082  * - SCIP_DELAYED : the presolver was skipped, but should be called again
2083  *
2084  * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
2085  * CONSHDLR_PRESOLTIMING and CONSHDLR_MAXPREROUNDS, which influence the behaviour of SCIP
2086  * calling CONSPRESOL.
2087  *
2088  * @subsection CONSACTIVE
2089  *
2090  * The CONSACTIVE callback method is called each time a constraint of the constraint handler is activated.
2091  * For example, if a constraint is added locally to a subproblem, the CONSACTIVE callback is called whenever the
2092  * search enters the subtree where the constraint exists.
2093  *
2094  * @subsection CONSDEACTIVE
2095  *
2096  * The CONSDEACTIVE callback method is called each time a constraint of the constraint handler is deactivated.
2097  * For example, if a constraint is added locally to a subproblem, the CONSDEACTIVE callback is called whenever the
2098  * search leaves the subtree where the constraint exists.
2099  *
2100  * @subsection CONSENABLE
2101  *
2102  * The CONSENABLE callback method is called each time a constraint of the constraint handler is enabled.
2103  * Constraints might be active without being enabled. In this case, only the feasibility checks are executed,
2104  * but domain propagation and separation is skipped.
2105  *
2106  * @subsection CONSDISABLE
2107  *
2108  * The CONSDISABLE callback method is called each time a constraint of the constraint handler is disabled.
2109  *
2110  * @subsection CONSPRINT
2111  *
2112  * The CONSPRINT callback method is called, when the user asks SCIP to display the problem to the screen
2113  * or save the problem into a file. This is, however, only the case if the user requested the CIP format.
2114  * For more details about reading and writing with SCIP we refer to the \ref READER "file readers". In this
2115  * callback method the constraint handler should display the data of the constraint in an appropriate form.
2116  * The output format that is defined by the CONSPRINT callbacks is called CIP format.
2117  * In later versions of SCIP, the constraint handlers should also be able to parse (i.e., read) constraints
2118  * which are given in CIP format.
2119  *
2120  * @subsection CONSCOPY
2121  *
2122  * The CONSCOPY callback method is used whenever constraints should be copied from one SCIP instance into another SCIP
2123  * instance. This method comes with the necessary parameters to do so, most importantly with a mapping of the variables of the
2124  * source SCIP instance to the corresponding variables of the target SCIP instance, and a mapping for the constraints
2125  * in the same way. For a complete list of all arguments of this callback method see type_cons.h.
2126  *
2127  * To get the corresponding target variable of a given source variable, you can use the variable map directly:
2128  *
2129  * \code
2130  * targetvar = (SCIP_VAR*) (size_t) SCIPhashmapGetImage(varmap, sourcevar);
2131  * \endcode
2132  *
2133  * We recommend, however, to use the method SCIPgetVarCopy() which gets besides others the variable map and the constraint map as input
2134  * and returns the requested target variable. The advantage of using SCIPgetVarCopy() is that in the case
2135  * the required variable does not yet exist, it is created and added to the copy automatically:
2136  *
2137  * \code
2138  * SCIP_CALL( SCIPgetVarCopy(sourcescip, scip, sourcevar, &targetvar, varmap, consmap, global) );
2139  * \endcode
2140  *
2141  * Finally, the result pointer <code>valid</code> has to be set to TRUE if (and only if!) the copy process was successful.
2142  *
2143  * <b>Note:</b> Be careful when setting the valid pointer. If you set the valid pointer to TRUE, but the constraint was
2144  * not copied one-to-one, then optimal solutions might be cut off during the search (see section
2145  * CONSHDLRCOPY above).
2146  *
2147  * For an example implementation we refer to cons_linear.h. Additional documentation and the complete list of all
2148  * parameters can be found in the file in type_cons.h.
2149  *
2150  * @subsection CONSPARSE
2151  *
2152  * This method is the counter part to CONSPRINT. The ideal idea is that a constraint handler is able to parse the output
2153  * which it generated via the CONSPRINT method and creates the corresponding constraint. If the parsing was successfully
2154  * the result pointer success should be set to TRUE. An example implementation can be found in the \ref cons_linear.h
2155  * "linear constraint handler".
2156  *
2157  * @subsection CONSDELVARS
2158  *
2159  * This method should iterate over the given constraints and delete all variables that were marked for deletion by SCIPdelVar().
2160  * Variable deletion is especially interesting for branch-cut-and-price applications. If your constraint handler allows
2161  * the addition of variables during the solving process (see "modifiable" attribute of constraints), then you might also want to
2162  * implement this callback. This would allow you to not only create variables during solving, but also remove them dynamically
2163  * from the problem to reduce memory consumption in case they are no longer necessary.
2164  * During presolving, SCIP may also find that some variables are not needed anymore and then try
2165  * to delete them. Thus, if you do not implement this callback, the constraint handler should capture its variables via
2166  * SCIPcaptureVar() to prevent SCIP from erroneously deleting them.
2167  *
2168  * Additional documentation and the complete list of all parameters can be found in the file type_cons.h.
2169  *
2170  * @subsection CONSGETVARS
2171  *
2172  * The CONSGETVARS callback of a constraint handler can be implemented to give access to the constraint variables
2173  * as array, independently from the internal data structure of the constraint. The buffer array
2174  * is already passed, together with its length. Consider implementing @ref CONSGETNVARS, too, to have
2175  * information about the number of variables in this constraint.
2176  *
2177  * @subsection CONSGETNVARS
2178  *
2179  * This callback can be implemented to return the number of variables involved into a particular constraint.
2180  * In order to have access to the variable pointers, consider implementing @ref CONSGETVARS.
2181  *
2182  * @subsection CONSGETDIVEBDCHGS
2183  *
2184  * This callback is used inside the various diving heuristics of SCIP and does not affect the normal branching
2185  * of the actual search.
2186  * The constraint handler can provide this callback to render a current working solution (even more) infeasible by
2187  * suggesting one or several variable bound changes.
2188  *
2189  * @section CONS_FURTHERINFO Further documentation
2190  *
2191  * Further documentation can be found in @ref type_cons.h for callback descriptions and a complete
2192  * list of all callback parameters, or in @ref scip.h
2193  * for globally available functions.
2194  */
2195 
2196 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
2197 /**@page PRICER How to add variable pricers
2198  *
2199  * A pricer performs the dynamic generation of new variables in a column generation algorithm.
2200  * It is an algorithmic representation of a (usually exponential) number of variables.
2201  * The \ref PRICERREDCOST and \ref PRICERFARKAS methods are called after each LP solve to generate additional
2202  * variables which may improve the objective value or decrease the LP infeasibility, respectively.
2203  * \n
2204  * A complete list of all pricers contained in this release can be found \ref PRICERS "here".
2205  *
2206  * If the pricer finds one or more variables with negative reduced costs or negative Farkas value, it should
2207  * call SCIPcreateVar() and SCIPaddPricedVar() to create and add the variable to the problem. Additionally,
2208  * the pricer has to add the variable to all constraints in which it appears. Therefore, a pricer needs to
2209  * know the constraints of the model and their meaning. Note that all constraints for which additional variables
2210  * are generated by a pricer have to be flagged as "modifiable" in the SCIPcreateCons() call.
2211  *
2212  * We now explain how users can add their own pricers.
2213  * For example, look into the variable pricer for the binpacking problem (examples/Binpacking/src/pricer_binpacking.c) of the
2214  * Binpacking example project.
2215  * The example is written in C. C++ users can easily adapt the code by using the scip::scip::ObjPricer wrapper base class and
2216  * implement the scip_...() virtual methods instead of the SCIP_DECL_PRICER... callback methods.
2217  *
2218  * Additional documentation for the callback methods of a pricer can be found in the file
2219  * type_pricer.h.
2220  *
2221  * Notice that if your pricer cannot cope with variable bounds other than 0 and infinity, you have to mark
2222  * all constraints containing priced variables as modifiable, and you may have to disable reduced cost
2223  * strengthening by setting propagating/rootredcost/freq to -1.
2224  *
2225  * Here is what you have to do to implement a pricer:
2226  * -# Copy the template files src/scip/pricer_xyz.c and src/scip/pricer_xyz.h into files "pricer_mypricer.c"
2227  * and "pricer_mypricer.h".
2228  * \n
2229  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2230  * -# Use SCIPincludePricerMypricer() in order to include the pricer into your SCIP instance,
2231  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
2232  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mypricer".
2233  * -# Adjust the properties of the pricer (see \ref PRICER_PROPERTIES).
2234  * -# Define the pricer data (see \ref PRICER_DATA). This is optional.
2235  * -# Implement the interface methods (see \ref PRICER_INTERFACE).
2236  * -# Implement the fundamental callback methods (see \ref PRICER_FUNDAMENTALCALLBACKS).
2237  * -# Implement the additional callback methods (see \ref PRICER_ADDITIONALCALLBACKS). This is optional.
2238  *
2239  *
2240  * @section PRICER_PROPERTIES Properties of a Pricer
2241  *
2242  * At the top of the new file "pricer_mypricer.c" you can find the pricer properties.
2243  * These are given as compiler defines.
2244  * In the C++ wrapper class, you have to provide the pricer properties by calling the constructor
2245  * of the abstract base class scip::ObjPricer from within your constructor.
2246  * The properties you have to set have the following meaning:
2247  *
2248  * \par PRICER_NAME: the name of the pricer.
2249  * This name is used in the interactive shell to address the pricer.
2250  * Additionally, if you are searching for a pricer with SCIPfindPricer(), this name is looked up.
2251  * Names have to be unique: no two pricers may have the same name.
2252  *
2253  * \par PRICER_DESC: the description of the pricer.
2254  * This string is printed as a description of the pricer in the interactive shell.
2255  *
2256  * \par PRICER_PRIORITY: the priority of the pricer.
2257  * In each pricing round during the price-and-cut loop of the subproblem processing, the included pricers are
2258  * called in a predefined order, which is given by the priorities of the pricers.
2259  * The higher the priority, the earlier the pricer is called.
2260  * Usually, you will have only one pricer in your application and the priority is therefore irrelevant.
2261  *
2262  * \par PRICER_DELAY: the default for whether the pricer should be delayed, if other variables with negative reduced
2263  * costs have already been found in the current pricing round.
2264  * Variables may be declared to be "removable" in the SCIPcreateVar() call. This means that SCIP may remove the variable
2265  * from the LP if it was inactive (i.e., sitting at zero) for a number of LP solves. Nevertheless, after the removal of the
2266  * column from the LP, the variable still exists, and SCIP can calculate reduced costs and add it to the LP again if
2267  * necessary.
2268  * \n
2269  * If the PRICER_DELAY flag is set to TRUE (which is the common setting), all those existing variables with negative reduced costs
2270  * are added to the LP, and the LP is resolved before the pricer is called. Thus, the pricer can assume that all existing variables
2271  * have non-negative reduced costs if the \ref PRICERREDCOST method is called or non-positive Farkas value if the \ref PRICERFARKAS
2272  * method is called.
2273  * \n
2274  * In some applications, this inner pricing loop on the already existing variables can significantly slow down the solving process,
2275  * since it may lead to the addition of only very few variables in each pricing round. If this is an issue in your application,
2276  * you should consider setting the PRICER_DELAY flag to FALSE. You must, however, be aware of the fact that there may be already
2277  * existing variables with negative reduced costs. For example, this may lead to the issue that your pricer generates the same
2278  * variable twice. In some models, this is not critical because an optimal solution would choose only one of the two identical
2279  * variables anyway, but for other models this can lead to wrong results because the duplication of a variable essentially doubles
2280  * the upper bound of the variable.
2281  *
2282  *
2283  * @section PRICER_DATA Pricer Data
2284  *
2285  * Below the header "Data structures" you can find a struct which is called "struct SCIP_PricerData".
2286  * In this data structure, you can store the data of your pricer. For example, it may be convenient to store pointers to the
2287  * constraints of the problem instance here, because the pricer has to add variables to those constraints.
2288  * If you are using C++, you can add pricer data, as usual, as object variables to your class.
2289  * \n
2290  * Defining pricer data is optional. You can leave the struct empty.
2291  *
2292  *
2293  * @section PRICER_INTERFACE Interface Methods
2294  *
2295  * At the bottom of "pricer_mypricer.c" you can find the interface method SCIPincludePricerMypricer(), which also appears in "pricer_mypricer.h".
2296  * 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
2297  * be generated by this pricer.
2298  *
2299  * This method only has to be adjusted slightly.
2300  * It is responsible for notifying SCIP of the presence of the pricer. For this, you can either call SCIPincludePricer(),
2301  * or SCIPincludePricerBasic() since SCIP version 3.0. In the latter variant, \ref PRICER_ADDITIONALCALLBACKS "additional callbacks"
2302  * must be added via setter functions as, e.g., SCIPsetPricerCopy(). We recommend this latter variant because
2303  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
2304  * variant must be manually adjusted with every SCIP release containing new callbacks for pricers in order to compile.
2305  *
2306  *
2307  * In addition, the pricer has to be activated before the solution process starts, like it is done
2308  * in the pricer of the Coloring application (applications/Coloring/src/reader_col.c) by calling
2309  * \code
2310  * SCIP_CALL( SCIPactivatePricer(scip, SCIPfindPricer(scip, "coloring")) );
2311  * \endcode
2312  *
2313  * If you are using pricer data, you have to allocate the memory for the data at this point.
2314  * You can do this by calling:
2315  * \code
2316  * SCIP_CALL( SCIPallocMemory(scip, &pricerdata) );
2317  * \endcode
2318  * You also have to initialize the fields in struct SCIP_PricerData afterwards.
2319  *
2320  * You may also add user parameters for your pricer, see the method SCIPincludePricerColoring() in the pricer of the Coloring application
2321  * for an example of how to add user parameters.
2322  *
2323  *
2324  * @section PRICER_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Pricer
2325  *
2326  * The fundamental callback methods have to be implemented in order to obtain an operational algorithm.
2327  * They are passed together with the pricer itself to SCIP using SCIPincludePricer() or SCIPincludePricerBasic(),
2328  * see @ref PRICER_INTERFACE.
2329  *
2330  * In the case of a pricer, there are two fundamental callback methods, namely the @ref PRICERREDCOST and the
2331  * @ref PRICERFARKAS callbacks, which both search for new variables and add them to the problem.
2332  * These methods have to be implemented for every pricer; the other callback methods are optional.
2333  * In the C++ wrapper class scip::ObjPricer, the scip_redcost() method (which corresponds to the PRICERREDCOST callback)
2334  * is a virtual abstract member function. You have to implement it in order to be able to construct an object of your
2335  * pricer class.
2336  *
2337  * Additional documentation for the callback methods can be found in type_pricer.h.
2338  *
2339  * @subsection PRICERREDCOST
2340  *
2341  * The PRICERREDCOST callback is called inside the price-and-cut loop of the subproblem solving process if the current LP relaxation
2342  * is feasible.
2343  * It should search for additional variables that can contribute to improve the current LP's solution value.
2344  * In standard branch-and-price, these are variables with negative dual feasibility, that is negative
2345  * reduced costs for non-negative variables, positive reduced costs for non-positive variables,
2346  * and non-zero reduced costs for variables that can be negative and positive.
2347  *
2348  * Whenever the pricer finds a variable with negative dual feasibility, it should call SCIPcreateVar()
2349  * and SCIPaddPricedVar() to add the variable to the problem. Furthermore, it should call the appropriate
2350  * methods of the constraint handlers to add the necessary variable entries to the constraints, see pub_cons.h.
2351  *
2352  * In the usual case that the pricer either adds a new variable or ensures that there are no further variables with negative dual feasibility,
2353  * the result pointer should be set to SCIP_SUCCESS. Only if the pricer aborts pricing without creating a new variable, but
2354  * there might exist additional variables with negative dual feasibility, the result pointer should be set to SCIP_DIDNOTRUN.
2355  * In this case, which sometimes is referred to as "early branching", the LP solution will not be used as a lower bound.
2356  * The pricer can, however, store a valid lower bound in the <code>lowerbound</code> pointer.
2357  *
2358  * Pricers usually need the dual LP solution as input for the pricing algorithm.
2359  * Since SCIP does not know the semantics of the individual constraints in the problem, the dual solution
2360  * has to be provided by the constraint handlers.
2361  * For example, the \ref cons_setppc.h "setppc constraint handler", which deals with set partitioning, packing, and covering constraints, provides
2362  * the method SCIPgetDualsolSetppc() to access the dual solution value for a single constraint.
2363  * Similarly, the dual solution of a linear constraint can be queried with the method SCIPgetDualsolLinear() of cons_linear.h.
2364  * The reduced costs of the existing variables can be accessed with the method SCIPgetVarRedcost().
2365  *
2366  * @subsection PRICERFARKAS
2367  *
2368  * If the current LP relaxation is infeasible, it is the task of the pricer to generate additional variables that can
2369  * potentially render the LP feasible again. In standard branch-and-price, these are variables with positive Farkas values,
2370  * and the PRICERFARKAS method should identify those variables.
2371  *
2372  * If the LP was proven to be infeasible, we have an infeasibility proof by the dual Farkas multipliers \f$y\f$.
2373  * 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
2374  * by the sides of the LP rows and the sign of \f$y\f$:
2375  * - if \f$y_i\f$ is positive, \f$b_i\f$ is the left hand side of the row,
2376  * - if \f$y_i\f$ is negative, \f$b_i\f$ is the right hand side of the row.
2377  *
2378  * \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$,
2379  * especially by the (for this inequality least infeasible solution) \f$x'\f$ defined by
2380  * - \f$x'_i := ub_i\f$, if \f$y^T A_i \ge 0\f$
2381  * - \f$x'_i := lb_i\f$, if \f$y^T A_i < 0\f$.
2382  * 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$.
2383  *
2384  * To apply Farkas pricing, the pricer needs to know the Farkas values of the constraints. Like the dual solution values for
2385  * feasible LP solutions, the dual Farkas values for infeasible solutions can be obtained by constraint handler interface
2386  * methods such as the SCIPgetDualfarkasLinear() method of the linear constraint handler.
2387  * The Farkas values for the bounds of the variables are just the regular reduced costs and can be accessed with SCIPgetVarRedcost().
2388  *
2389  * It is useful to note that Farkas pricing is the same as the regular pricing with a zero objective function.
2390  * Therefore, a typical implementation of a pricer would consist of a generic pricing algorithm that gets a dual solution and an
2391  * objective function vector as input and generates variables by calling SCIPcreateVar() and SCIPaddPricedVar().
2392  * The PRICERREDCOST callback would call this function with the regular objective function and the regular dual solution vector,
2393  * while the PRICERFARKAS callback would call this function with a zero objective function and the Farkas vector.
2394  * From a practical point of view, it is usually the simplest approach to provide just one Boolean flag to the generic pricing
2395  * algorithm in order to identify whether it is reduced cost or Farkas pricing. Then, the algorithm would just call the appropriate
2396  * methods to access the dual solution or objective function, depending on the Boolean flag.
2397  *
2398  * @section PRICER_ADDITIONALCALLBACKS Additional Callback Methods of a Pricer
2399  *
2400  * The additional callback methods do not need to be implemented in every case.
2401  * However, some of them have to be implemented for most applications. They can either be passed directly with
2402  * SCIPincludePricer() to SCIP or via specific <b>setter functions</b> after a call of SCIPincludePricerBasic(),
2403  * see also @ref PRICER_INTERFACE.
2404  *
2405  * @subsection PRICERFREE
2406  *
2407  * If you are using pricer data, you have to implement this method in order to free the pricer data.
2408  * This can be done by the following procedure:
2409  * \code
2410  * static
2411  * SCIP_DECL_PRICERFREE(pricerFreeMypricer)
2412  * {
2413  * SCIP_PRICERDATA* pricerdata;
2414  *
2415  * pricerdata = SCIPpricerGetData(pricer);
2416  * assert(pricerdata != NULL);
2417  *
2418  * SCIPfreeMemory(scip, &pricerdata);
2419  *
2420  * SCIPpricerSetData(pricer, NULL);
2421  *
2422  * return SCIP_OKAY;
2423  * }
2424  * \endcode
2425  * If you have allocated memory for fields in your pricer data, remember to free this memory
2426  * before freeing the pricer data itself.
2427  * If you are using the C++ wrapper class, this method is not available.
2428  * Instead, just use the destructor of your class to free the member variables of your class.
2429  *
2430  * @subsection PRICERCOPY
2431  *
2432  * The PRICERCOPY callback is executed when the SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this
2433  * callback as <code>NULL</code> the user disables the inclusion of the pricer into all copied SCIP
2434  * instances. This means that primal heuristics will work on a sub-SCIP that contains only a part of the variables
2435  * and no variables are priced in during the solving process of the sub-SCIP. Therefore, primal solutions found in the
2436  * copied problem are typically still valid for the original problem and used for its solving process,
2437  * but dual reductions cannot be transferred to the original problem.
2438  *
2439  * <b>Note:</b> If you implement this callback, be careful when setting the valid pointer. The valid pointer should be
2440  * set to TRUE if (and only if!) you can make sure that all necessary data of the pricer are copied
2441  * correctly. If the complete problem is validly copied, i.e. if the copy methods of all problem defining plugins
2442  * (constraint handlers and pricers) return <code>*valid = TRUE</code>, then dual reductions found for the copied problem can be
2443  * transferred to the original SCIP instance. Thus, if the valid pointer is wrongly set to TRUE, it might happen that
2444  * optimal solutions are cut off.
2445  *
2446  * @subsection PRICERINIT
2447  *
2448  * The PRICERINIT callback is executed after the problem is transformed.
2449  * The pricer may, e.g., use this call to replace the original constraints stored in its pricer data by transformed
2450  * constraints, or to initialize other elements of its pricer data.
2451  *
2452  * @subsection PRICEREXIT
2453  *
2454  * The PRICEREXIT callback is executed before the transformed problem is freed.
2455  * In this method, the pricer should free all resources that have been allocated for the solving process in PRICERINIT.
2456  *
2457  * @subsection PRICERINITSOL
2458  *
2459  * The PRICERINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to begin.
2460  * The pricer may use this call to initialize its branch-and-bound specific data.
2461  *
2462  * @subsection PRICEREXITSOL
2463  *
2464  * The PRICEREXITSOL callback is executed before the branch-and-bound process is freed.
2465  * The pricer should use this call to clean up its branch-and-bound data, which was allocated in PRICERINITSOL.
2466  *
2467  * @section PRICER_REMARKS Further remarks
2468  *
2469  * 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".
2470  * Otherwise, SCIP will use its default branching rules, if necessary (which all branch on variables). This
2471  * could disturb the pricing problem or branching might not even be possible, e.g., if all variables created thus far have already been fixed.
2472  *
2473  * Note that if the original problem is a maximization problem, SCIP will transform the problem into a minimization
2474  * problem by multiplying the objective function by -1. The pricer has to take care of this by multiplying
2475  * the original objective function value of all variables created during the solving process by -1.
2476  *
2477  * In some cases, bounds on variables are implicitly enforced by constraints of the problem and the objective function.
2478  * 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
2479  * care about the corresponding dual values.
2480  * We call these bounds lazy bounds, they may be set by SCIPchgVarLbLazy() and SCIPchgVarUbLazy() for upper or lower bounds, respectively.
2481  * If the lazy bound is tighter than the local bound, the corresponding bound is not put into the LP.
2482  * In diving mode, lazy bounds are explicitly put into the LP, because changing the objective (which is only possible in diving)
2483  * might reverse the implicitly given bounds. When diving is finished, the bounds are again removed from the LP.
2484  */
2485 
2486 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
2487 /**@page PRESOL How to add presolvers
2488  *
2489  * Presolvers are used to reduce the size of the model by removing irrelevant information like redundant constraints,
2490  * to strengthen the LP relaxation by exploiting integrality information, and to extract useful information in the
2491  * presolving step.
2492  * Constraint based presolving is done in the CONSPRESOL callback methods of the constraint handlers, see \ref CONSPRESOL.
2493  * Some propagation steps can already be applied in presolving via the PROPRESOL callback methods of propagators, see \ref PROPPRESOL.
2494  * The presolver plugins complement these by additional, usually optimality based, presolving reductions.
2495  * \n
2496  * A complete list of all presolvers contained in this release can be found \ref PRESOLVERS "here".
2497  *
2498  * We now explain how users can add their own presolvers.
2499  * Take the trivial presolver (src/scip/presol_trivial.c) as an example.
2500  * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjPresol wrapper
2501  * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_PRESOL... callback methods.
2502  *
2503  * Additional documentation for the callback methods of a presolver, in particular for their input parameters,
2504  * can be found in the file type_presol.h.
2505  *
2506  * Here is what you have to do to implement a presolver:
2507  * -# Copy the template files src/scip/presol_xyz.c and src/scip/presol_xyz.h into files named "presol_mypresolver.c"
2508  * and "presol_mypresolver.h".
2509  * \n
2510  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2511  * -# Use SCIPincludePresolMypresolver() in order to include the presolver into your SCIP instance,
2512  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
2513  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mypresolver".
2514  * -# Adjust the properties of the presolver (see \ref PRESOL_PROPERTIES).
2515  * -# Define the presolver data (see \ref PRESOL_DATA). This is optional.
2516  * -# Implement the interface methods (see \ref PRESOL_INTERFACE).
2517  * -# Implement the fundamental callback methods (see \ref PRESOL_FUNDAMENTALCALLBACKS).
2518  * -# Implement the additional callback methods (see \ref PRESOL_ADDITIONALCALLBACKS). This is optional.
2519  *
2520  *
2521  * @section PRESOL_PROPERTIES Properties of a Presolver
2522  *
2523  * At the top of the new file "presol_mypresolver.c", you can find the presolver properties.
2524  * These are given as compiler defines.
2525  * In the C++ wrapper class, you have to provide the presolver properties by calling the constructor
2526  * of the abstract base class scip::ObjPresol from within your constructor.
2527  * The properties you have to set have the following meaning:
2528  *
2529  * \par PRESOL_NAME: the name of the presolver.
2530  * This name is used in the interactive shell to address the presolver.
2531  * Additionally, if you are searching for a presolver with SCIPfindPresol(), this name is looked up.
2532  * Names have to be <b>unique</b>: no two presolvers may have the same name.
2533  *
2534  * \par PRESOL_DESC: the description of the presolver.
2535  * This string is printed as a description of the presolver in the interactive shell.
2536  *
2537  * \par PRESOL_TIMING: the default timing of the presolver.
2538  * There are three presolving timings: FAST, MEDIUM, and EXHAUSTIVE.
2539  * Every presolving round starts with the FAST presolvers. MEDIUM presolvers are only called, if FAST presolvers did not find
2540  * enough reductions in this round so far, and EXHAUSTIVE presolving steps are only performed if all presolvers called before
2541  * in this round were unsuccessful.
2542  * Presolvers should be assigned a timing based on how expensive they are, e.g., presolvers that provide fast algorithms that
2543  * usually have a high impact (i.e., remove lots of variables or tighten bounds of many variables) should have a timing FAST.
2544  * If a presolver implements different algorithms of different complexity, it may also get multiple timings and check the timing
2545  * internally in the \ref PRESOLEXEC callback to decide which algorithms to run.
2546  *
2547  * \par PRESOL_PRIORITY: the priority of the presolver.
2548  * Within a presolving round, when calling all presolvers and presolving methods of propagators and constraint handlers
2549  * with a given timing, those are called in
2550  * a predefined order, which is given by the priorities of the presolvers and the check priorities of the
2551  * constraint handlers, see \ref CONS_PROPERTIES.
2552  * First, the presolvers with non-negative priority are called in the order of decreasing priority.
2553  * Next, the presolving methods of the different constraint handlers are called in the order of decreasing check
2554  * priority.
2555  * Finally, the presolvers with negative priority are called in the order of decreasing priority.
2556  * \n
2557  * Again, presolvers that provide fast algorithms that usually have a high impact (i.e., remove lots of variables or tighten
2558  * bounds of many variables) should have a high priority.
2559  * An easy way to list the timings and
2560  * priorities of all presolvers, propagators, and constraint handlers is to type "display presolvers", "display propagators",
2561  * and "display conshdlrs" in the interactive shell of SCIP.
2562  *
2563  * \par PRESOL_MAXROUNDS: the default maximal number of rounds the presolver participates in.
2564  * The presolving is conducted in rounds: the presolvers and presolving methods of the constraint handlers
2565  * are called iteratively until no more reductions have been found or some other abort criterion applies.
2566  * The "maxrounds" parameter of a presolver imposes a limit on the number of presolving rounds in which the
2567  * presolver is called. The PRESOL_MAXROUNDS property specifies the default value for this parameter.
2568  * A value of -1 represents an unlimited number of rounds.
2569  *
2570  *
2571  * @section PRESOL_DATA Presolver Data
2572  *
2573  * Below the header "Data structures" you can find a struct which is called "struct SCIP_PresolData".
2574  * In this data structure, you can store the data of your presolver. For example, you should store the adjustable parameters
2575  * of the presolver in this data structure.
2576  * If you are using C++, you can add presolver data as usual as object variables to your class.
2577  * \n
2578  * Defining presolver data is optional. You can leave this struct empty.
2579  *
2580  *
2581  * @section PRESOL_INTERFACE Interface Methods
2582  *
2583  * At the bottom of "presol_mypresolver.c", you can find the interface method SCIPincludePresolMypresolver(),
2584  * which also appears in "presol_mypresolver.h"
2585  * SCIPincludePresolMypresolver() is called by the user, if (s)he wants to include the presolver,
2586  * i.e., if (s)he wants to use the presolver in his/her application.
2587  *
2588  * This method only has to be adjusted slightly.
2589  * It is responsible for notifying SCIP of the presence of the presolver. For this, you can either call SCIPincludePresol(),
2590  * or SCIPincludePresolBasic() since SCIP version 3.0. In the latter variant, \ref PRESOL_ADDITIONALCALLBACKS "additional callbacks"
2591  * must be added via setter functions as, e.g., SCIPsetPresolCopy(). We recommend this latter variant because
2592  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
2593  * variant must be manually adjusted with every SCIP release containing new callbacks for presolvers in order to compile.
2594  *
2595  * If you are using presolver data, you have to allocate the memory for the data at this point.
2596  * You can do this by calling:
2597  * \code
2598  * SCIP_CALL( SCIPallocMemory(scip, &presoldata) );
2599  * \endcode
2600  * You also have to initialize the fields in struct SCIP_PresolData afterwards. For freeing the
2601  * presolver data, see \ref PRESOLFREE.
2602  *
2603  * You may also add user parameters for your presolver, see \ref PARAM for how to add user parameters and
2604  * the method SCIPincludePresolTrivial() in src/scip/presol_trivial.c for an example.
2605  *
2606  *
2607  * @section PRESOL_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Presolver
2608  *
2609  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
2610  * an operational algorithm.
2611  * They are passed together with the presolver itself to SCIP using SCIPincludePresol() or SCIPincludePresolBasic(),
2612  * see @ref PRESOL_INTERFACE.
2613  *
2614  * Presolver plugins have only one fundamental callback method, namely the @ref PRESOLEXEC method.
2615  * This method has to be implemented for every presolver; the other callback methods are optional.
2616  * In the C++ wrapper class scip::ObjPresol, the scip_exec() method (which corresponds to the PRESOLEXEC callback) is a virtual
2617  * abstract member function.
2618  * You have to implement it in order to be able to construct an object of your presolver class.
2619  *
2620  * Additional documentation for the callback methods, in particular to their input parameters,
2621  * can be found in type_presol.h.
2622  *
2623  * @subsection PRESOLEXEC
2624  *
2625  * The PRESOLEXEC callback is called inside the presolving loop and should perform the actual presolving reductions.
2626  * It should inspect the problem instance at hand and simplify it by tightening bounds of variables, aggregating or fixing
2627  * variables, changing the type of variables, modifying the graph that represents the instance of your application, and
2628  * the like.
2629  *
2630  * Typical methods called by a presolver are, for example, SCIPchgVarType(), SCIPfixVar(), SCIPaggregateVars(), SCIPtightenVarLb(),
2631  * and SCIPtightenVarUb().
2632  *
2633  *
2634  * @section PRESOL_ADDITIONALCALLBACKS Additional Callback Methods of a Presolver
2635  *
2636  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
2637  * implemented for most applications, they can be used, for example, to initialize and free private data.
2638  * Additional callbacks can either be passed directly with SCIPincludePresol() to SCIP or via specific
2639  * <b>setter functions</b> after a call of SCIPincludePresolBasic(), see also @ref PRESOL_INTERFACE.
2640  *
2641  * @subsection PRESOLFREE
2642  *
2643  * 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.
2644  * This can be done by the following procedure:
2645  * \code
2646  * static
2647  * SCIP_DECL_PRESOLFREE(presolFreeMypresolver)
2648  * {
2649  * SCIP_PRESOLDATA* presoldata;
2650  *
2651  * presoldata = SCIPpresolGetData(presol);
2652  * assert(presoldata != NULL);
2653  *
2654  * SCIPfreeMemory(scip, &presoldata);
2655  *
2656  * SCIPpresolSetData(presol, NULL);
2657  *
2658  * return SCIP_OKAY;
2659  * }
2660  * \endcode
2661  * If you have allocated memory for fields in your presolver data, remember to free this memory
2662  * before freeing the presolver data itself.
2663  * If you are using the C++ wrapper class, this method is not available.
2664  * Instead, just use the destructor of your class to free the member variables of your class.
2665  *
2666  * @subsection PRESOLINIT
2667  *
2668  * The PRESOLINIT callback is executed after the problem is transformed.
2669  * The presolver may, e.g., use this call to initialize its presolver data.
2670  * The difference between the original and the transformed problem is explained in
2671  * "What is this thing with the original and the transformed problem about?" on \ref FAQ.
2672  *
2673  * @subsection PRESOLCOPY
2674  *
2675  * The PRESOLCOPY callback is executed when a SCIP instance is copied, e.g. to
2676  * solve a sub-SCIP. By
2677  * defining this callback as
2678  * <code>NULL</code> the user disables the execution of the specified
2679  * presolver for all copied SCIP instances. This may deteriorate the performance
2680  * of primal heuristics using sub-SCIPs.
2681  *
2682  * @subsection PRESOLEXIT
2683  *
2684  * The PRESOLEXIT callback is executed before the transformed problem is freed.
2685  * In this method, the presolver should free all resources that have been allocated for the solving process in PRESOLINIT.
2686  *
2687  * @subsection PRESOLINITPRE
2688  *
2689  * The PRESOLINITPRE callback is executed when the presolving is about to begin.
2690  * The presolver may use this call to initialize its presolving data which only need to exist during the presolving stage.
2691  *
2692  * @subsection PRESOLEXITPRE
2693  *
2694  * The PRESOLEXITPRE callback is executed after presolving finishes and before the branch-and-bound process begins.
2695  * The presolver should use this call to clean up its presolving data, which was allocated in PRESOLINITPRE.
2696  */
2697 
2698 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
2699 /**@page SEPA How to add separators
2700  *
2701  * Separators are used to generate general purpose cutting planes.
2702  * Constraint based cutting planes, the second type of cutting planes in SCIP, are separated in the CONSSEPALP and
2703  * CONSSEPASOL callback methods of the constraint handlers, see \ref CONSSEPALP and \ref CONSSEPASOL. These cuts are
2704  * valid inequalities or even facets of the polyhedron described by a single constraint or a subset of the constraints of
2705  * a single constraint class. In contrast, general purpose cuts do not require or exploit any knowledge about the
2706  * underlying problem structure but use only the current LP relaxation and the integrality conditions. See also
2707  * "When should I implement a constraint handler, when should I implement a separator?" on \ref FAQ.
2708  * \n
2709  * A complete list of all separators contained in this release can be found \ref SEPARATORS "here".
2710  *
2711  * We now explain how users can add their own separators.
2712  * Take the separator for the class of Gomory mixed integer inequalities (src/scip/sepa_gomory.c) as an example.
2713  * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjSepa wrapper
2714  * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_SEPA... callback methods.
2715  *
2716  * Additional documentation for the callback methods of a separator, in particular for the input parameters,
2717  * can be found in the file type_sepa.h.
2718  *
2719  * Here is what you have to do to implement a separator:
2720  * -# Copy the template files src/scip/sepa_xyz.c and src/scip/sepa_xyz.h into files "sepa_myseparator.c"
2721  * and "sepa_myseparator.h".
2722  \n
2723  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2724  * -# Use SCIPincludeSepaMyseparator() in order to include the separator into your SCIP instance,
2725  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
2726  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "myseparator".
2727  * -# Adjust the properties of the separator (see \ref SEPA_PROPERTIES).
2728  * -# Define the separator data (see \ref SEPA_DATA). This is optional.
2729  * -# Implement the interface methods (see \ref SEPA_INTERFACE).
2730  * -# Implement the fundamental callback methods (see \ref SEPA_FUNDAMENTALCALLBACKS).
2731  * -# Implement the additional callback methods (see \ref SEPA_ADDITIONALCALLBACKS). This is optional.
2732  *
2733  *
2734  * @section SEPA_PROPERTIES Properties of a Separator
2735  *
2736  * At the top of the new file "sepa_myseparator.c", you can find the separator properties.
2737  * These are given as compiler defines.
2738  * In the C++ wrapper class, you have to provide the separator properties by calling the constructor
2739  * of the abstract base class scip::ObjSepa from within your constructor.
2740  * The properties you have to set have the following meaning:
2741  *
2742  * \par SEPA_NAME: the name of the separator.
2743  * This name is used in the interactive shell to address the separator.
2744  * Additionally, if you are searching for a separator with SCIPfindSepa(), this name is looked up.
2745  * Names have to be unique: no two separators may have the same name.
2746  *
2747  * \par SEPA_DESC: the description of the separator.
2748  * This string is printed as a description of the separator in the interactive shell.
2749  *
2750  * \par SEPA_PRIORITY: the priority of the separator.
2751  * In each separation round during the price-and-cut loop of the subproblem processing or the separation loop
2752  * of the primal solution separation, the separators and separation methods of the constraint handlers are called in
2753  * a predefined order, which is given by the priorities of the separators and the separation priorities
2754  * of the constraint handlers (see \ref CONS_PROPERTIES).
2755  * First, the separators with non-negative priority are called in the order of decreasing priority.
2756  * Next, the separation methods of the constraint handlers are called in the order of decreasing separation
2757  * priority.
2758  * Finally, the separators with negative priority are called in the order of decreasing priority. An easy way to list the
2759  * priorities of all separators and constraint handlers is to type "display separators" and "display conshdlrs" in
2760  * the interactive shell.
2761  * \n
2762  * The priority of the separator should be set according to the complexity of the cut separation algorithm and the
2763  * impact of the resulting cuts: separators that provide fast algorithms that usually have a high impact (i.e., cut off
2764  * a large portion of the LP relaxation) should have a high priority.
2765  * See \ref SEPAEXECLP and \ref SEPAEXECSOL for further details of the separation callbacks.
2766  *
2767  * \par SEPA_FREQ: the default frequency for separating cuts.
2768  * The frequency defines the depth levels at which the separation methods \ref SEPAEXECLP and \ref SEPAEXECSOL are called.
2769  * For example, a frequency of 7 means, that the separation callback is executed for subproblems that are in depth
2770  * 0, 7, 14, ... of the branching tree. A frequency of 0 means, that the separation method is only called at the root node.
2771  * A frequency of -1 disables the separator.
2772  * \n
2773  * The frequency can be adjusted by the user. This property of the separator only defines the default value of the frequency.
2774  * If you want to have a more flexible control of when to execute the separation algorithm, you have to assign
2775  * a frequency of 1 and implement a check at the beginning of your separation methods whether you really want to execute
2776  * the separation or not. If you do not want to execute it, set the result code of
2777  * \ref SEPAEXECLP and \ref SEPAEXECSOL to SCIP_DIDNOTRUN.
2778  *
2779  * \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.
2780  * At the current branch-and-bound node, the relative distance from its dual bound (local dual bound)
2781  * to the primal bound compared to the best node's dual bound (global dual bound) is considered. The separation method
2782  * of the separator will only be applied at the current node if this relative distance does not exceed SEPA_MAXBOUNDDIST.
2783  * \n
2784  * For example, if the global dual bound is 50 and the primal bound is 60, SEPA_MAXBOUNDDIST = 0.25 means that separation
2785  * 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
2786  * than or equal to 52.5.
2787  * \n
2788  * In particular, the values 0.0 and 1.0 mean that separation is applied at the current best node only or at all
2789  * nodes, respectively. Since separation seems to be most important to apply at nodes that define to the global
2790  * dual bound, 0.0 is probably a good choice for SEPA_MAXBOUNDDIST.
2791  * Note that separators with a frequency of SEPA_FREQ = 0 are only applied at the root node.
2792  * Obviously, at the root node the local dual bound is equal to the global dual bound and thus, the separator is called
2793  * for any value of SEPA_MAXBOUNDDIST.
2794  *
2795  * \par SEPA_USESSUBSCIP: Does the separator use a secondary SCIP instance?
2796  * Some heuristics and separators solve MIPs or SAT problems and use a secondary SCIP instance. Examples are
2797  * Large Neighborhood Search heuristics such as RINS and Local Branching or the CGMIP separator. To avoid recursion,
2798  * these plugins usually deactivate all other plugins that solve MIPs. If a separator uses a secondary SCIP instance,
2799  * this parameter has to be TRUE and it is recommended to call SCIPsetSubscipsOff() for the secondary SCIP instance.
2800  *
2801  * \par SEPA_DELAY: the default for whether the separation method should be delayed, if other separators or constraint handlers found cuts.
2802  * If the separator's separation method is marked to be delayed, it is only executed after no other separator
2803  * or constraint handler found a cut during the price-and-cut loop.
2804  * If the separation method of the separator is very expensive, you may want to mark it to be delayed until all cheap
2805  * separation methods have been executed.
2806  *
2807  * @section SEPA_DATA Separator Data
2808  *
2809  * Below the header "Data structures" you can find a struct which is called "struct SCIP_SepaData".
2810  * In this data structure, you can store the data of your separator. For example, you should store the adjustable
2811  * parameters of the separator in this data structure. In a separator, user parameters for the maximal number of
2812  * separation rounds per node and for the maximal number of cuts separated per separation round might be useful.
2813  * If you are using C++, you can add separator data as usual as object variables to your class.
2814  * \n
2815  * Defining separator data is optional. You can leave the struct empty.
2816  *
2817  * @section SEPA_INTERFACE Interface Methods
2818  *
2819  * At the bottom of "sepa_myseparator.c", you can find the interface method SCIPincludeSepaMyseparator(),
2820  * which also appears in "sepa_myseparator.h"
2821  * SCIPincludeSepaMyseparator() is called by the user, if (s)he wants to include the separator,
2822  * i.e., if (s)he wants to use the separator in his/her application.
2823  *
2824  * This method only has to be adjusted slightly.
2825  * It is responsible for notifying SCIP of the presence of the separator. For this, you can either call SCIPincludeSepa(),
2826  * or SCIPincludeSepaBasic() since SCIP version 3.0. In the latter variant, \ref SEPA_ADDITIONALCALLBACKS "additional callbacks"
2827  * must be added via setter functions as, e.g., SCIPsetSepaCopy(). We recommend this latter variant because
2828  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
2829  * variant must be manually adjusted with every SCIP release containing new callbacks for separators in order to compile.
2830  *
2831  * If you are using separator data, you have to allocate the memory
2832  * for the data at this point. You can do this by calling:
2833  * \code
2834  * SCIP_CALL( SCIPallocMemory(scip, &sepadata) );
2835  * \endcode
2836  * You also have to initialize the fields in "struct SCIP_SepaData" afterwards. For freeing the
2837  * separator data, see \ref SEPAFREE.
2838  *
2839  * You may also add user parameters for your separator, see \ref PARAM for how to add user parameters and
2840  * the method SCIPincludeSepaGomory() in src/scip/sepa_gomory.c for an example.
2841  *
2842  *
2843  * @section SEPA_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Separator
2844  *
2845  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
2846  * an operational algorithm.
2847  * They are passed together with the separator itself to SCIP using SCIPincludeSepa() or SCIPincludeSepaBasic(),
2848  * see @ref SEPA_INTERFACE.
2849  *
2850  * Separator plugins have two callbacks, @ref SEPAEXECLP and @ref SEPAEXECSOL, of which at least one must be implemented.
2851  *
2852  * Additional documentation for the callback methods, in particular to their input parameters,
2853  * can be found in type_sepa.h.
2854  *
2855  * @subsection SEPAEXECLP
2856  *
2857  * The SEPAEXECLP callback is executed during the price-and-cut loop of the subproblem processing.
2858  * It should try to generate general purpose cutting planes in order to separate the current LP solution.
2859  * The method is called in the LP solution loop, which means that a valid LP solution exists.
2860  *
2861  * Usually, the callback searches and produces cuts, that are added with a call to SCIPaddCut().
2862  * If the cut should be added to the global cut pool, it calls SCIPaddPoolCut().
2863  * In addition to LP rows, the callback may also produce domain reductions or add additional constraints.
2864  *
2865  * Overall, the SEPAEXECLP callback has the following options, which is indicated by the possible return values of
2866  * the 'result' variable (see type_sepa.h):
2867  * - detecting that the node is infeasible in the variable's bounds and can be cut off (result SCIP_CUTOFF)
2868  * - adding an additional constraint (result SCIP_CONSADDED)
2869  * - reducing a variable's domain (result SCIP_REDUCEDDOM)
2870  * - adding a cutting plane to the LP (result SCIP_SEPARATED)
2871  * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
2872  * (result SCIP_DIDNOTFIND)
2873  * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
2874  * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
2875  * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
2876  *
2877  * @subsection SEPAEXECSOL
2878  *
2879  * The SEPAEXECSOL callback is executed during the separation loop on arbitrary primal solutions.
2880  * It should try to generate general purpose cutting planes in order to separate the given primal solution.
2881  * The method is not called in the LP solution loop, which means that there is no valid LP solution.
2882  *
2883  * In the standard SCIP environment, the SEPAEXECSOL callback is not used because only LP solutions are
2884  * separated. The SEPAEXECSOL callback provides means to support external relaxation handlers like semidefinite
2885  * relaxations that want to separate an intermediate primal solution vector. Thus, if you do not want to support
2886  * such external plugins, you do not need to implement this callback method.
2887  *
2888  * Usually, the callback searches and produces cuts, that are added with a call to SCIPaddCut().
2889  * If the cut should be added to the global cut pool, it calls SCIPaddPoolCut().
2890  * In addition to LP rows, the callback may also produce domain reductions or add other constraints.
2891  *
2892  * Overall, the SEPAEXECSOL callback has the following options, which is indicated by the possible return values of
2893  * the 'result' variable (see type_sepa.h):
2894  * - detecting that the node is infeasible in the variable's bounds and can be cut off (result SCIP_CUTOFF)
2895  * - adding an additional constraint (result SCIP_CONSADDED)
2896  * - reducing a variable's domain (result SCIP_REDUCEDDOM)
2897  * - adding a cutting plane to the LP (result SCIP_SEPARATED)
2898  * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
2899  * (result SCIP_DIDNOTFIND)
2900  * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
2901  * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
2902  * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
2903  *
2904  *
2905  * @section SEPA_ADDITIONALCALLBACKS Additional Callback Methods of a Separator
2906  *
2907  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
2908  * implemented for most applications, they can be used, for example, to initialize and free private data.
2909  * Additional callbacks can either be passed directly with SCIPincludeSepa() to SCIP or via specific
2910  * <b>setter functions</b> after a call of SCIPincludeSepaBasic(), see also @ref SEPA_INTERFACE.
2911  *
2912  * @subsection SEPAFREE
2913  *
2914  * If you are using separator data (see \ref SEPA_DATA and \ref SEPA_INTERFACE), you have to implement this method
2915  * in order to free the separator data. This can be done by the following procedure:
2916  * \code
2917  * static
2918  * SCIP_DECL_SEPAFREE(sepaFreeMyseparator)
2919  * {
2920  * SCIP_SEPADATA* sepadata;
2921  *
2922  * sepadata = SCIPsepaGetData(sepa);
2923  * assert(sepadata != NULL);
2924  *
2925  * SCIPfreeMemory(scip, &sepadata);
2926  *
2927  * SCIPsepaSetData(sepa, NULL);
2928  *
2929  * return SCIP_OKAY;
2930  * }
2931  * \endcode
2932  * If you have allocated memory for fields in your separator data, remember to free this memory
2933  * before freeing the separator data itself.
2934  * If you are using the C++ wrapper class, this method is not available.
2935  * Instead, just use the destructor of your class to free the member variables of your class.
2936  *
2937  * @subsection SEPACOPY
2938  *
2939  * The SEPACOPY callback is executed when a SCIP instance is copied, e.g. to
2940  * solve a sub-SCIP. By
2941  * defining this callback as
2942  * <code>NULL</code> the user disables the execution of the specified
2943  * separator for all copied SCIP instances. This may deteriorate the performance
2944  * of primal heuristics using sub-SCIPs.
2945  *
2946  * @subsection SEPAINIT
2947  *
2948  * The SEPAINIT callback is executed after the problem is transformed.
2949  * The separator may, e.g., use this call to initialize its separator data.
2950  * The difference between the original and the transformed problem is explained in
2951  * "What is this thing with the original and the transformed problem about?" on \ref FAQ.
2952  *
2953  * @subsection SEPAEXIT
2954  *
2955  * The SEPAEXIT callback is executed before the transformed problem is freed.
2956  * In this method, the separator should free all resources that have been allocated for the solving process in SEPAINIT.
2957  *
2958  * @subsection SEPAINITSOL
2959  *
2960  * The SEPAINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
2961  * begin. The separator may use this call to initialize its branch-and-bound specific data.
2962  *
2963  * @subsection SEPAEXITSOL
2964  *
2965  * The SEPAEXITSOL callback is executed before the branch-and-bound process is freed. The separator should use this call
2966  * to clean up its branch-and-bound data, in particular to release all LP rows that it has created or captured.
2967  */
2968 
2969 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
2970 /**@page PROP How to add propagators
2971  *
2972  * Propagators are used to tighten the domains of the variables. Like for cutting planes, there are two different types
2973  * of domain propagations. Constraint based (primal) domain propagation algorithms are part of the corresponding
2974  * constraint handlers, see \ref CONSPROP. In contrast, domain propagators usually provide dual propagations, i.e.,
2975  * propagations that can be applied using the objective function and the current best known primal solution. This
2976  * section deals with such propagators.
2977  *
2978  * A complete list of all propagators contained in this release can be found \ref PROPAGATORS "here".
2979  *
2980  * We now explain how users can add their own propagators. Take the pseudo objective function propagator
2981  * (src/scip/prop_pseudoobj.c) as an example. As all other default plugins, it is written in C. C++ users can easily
2982  * adapt the code by using the scip::ObjProp wrapper base class and implement the @c scip_...() virtual methods instead
2983  * of the @c SCIP_DECL_PROP... callback methods.
2984  *
2985  * Additional documentation for the callback methods of a propagator can be found in the file type_prop.h.
2986  *
2987  * Here is what you have to do to implement a propagator:
2988  * -# Copy the template files src/scip/prop_xyz.c and src/scip/prop_xyz.h into files named "prop_mypropagator.c"
2989  * and "prop_mypropagator.h".
2990  * \n
2991  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2992  * -# Use SCIPincludePropMypropagator() in order to include the propagator into your SCIP instance,
2993  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
2994  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mypropagator".
2995  * -# Adjust the properties of the propagator (see \ref PROP_PROPERTIES).
2996  * -# Define the propagator data (see \ref PROP_DATA). This is optional.
2997  * -# Implement the interface methods (see \ref PROP_INTERFACE).
2998  * -# Implement the fundamental callback methods (see \ref PROP_FUNDAMENTALCALLBACKS).
2999  * -# Implement the additional callback methods (see \ref PROP_ADDITIONALCALLBACKS). This is optional.
3000  *
3001  * @section PROP_PROPERTIES Properties of a Propagator
3002  *
3003  * At the top of the new file "prop_mypropagator.c" you can find the propagator properties. These are given as compiler
3004  * defines. The presolving-related properties are optional,
3005  * they only have to be defined if the propagator supports presolving routines.
3006  * In the C++ wrapper class, you have to provide the propagator properties by calling the constructor of the
3007  * abstract base class scip::ObjProp from within your constructor. The properties you have the following meaning:
3008  *
3009  * @subsection PROP_FUNDAMENTALPROPERTIES Fundamental properties of a propagator
3010  *
3011  * \par PROP_NAME: the name of the propagator.
3012  * This name is used in the interactive shell to address the propagator. Additionally, if you are searching for a
3013  * propagator with SCIPfindProp(), this name is searched for. Names have to be unique: no two propagators may have the
3014  * same name.
3015  *
3016  * \par PROP_DESC: the description of the propagator.
3017  * This string is printed as a description of the propagator in the interactive shell.
3018  *
3019  * \par PROP_PRIORITY: the priority of the propagator.
3020  * In each propagation round, the propagators and propagation methods of the constraint handlers are called in a
3021  * predefined order, which is given by the priorities of the propagators and the check priorities of the constraint
3022  * handlers. First, the propagators with non-negative priority are called in order of decreasing priority. Next, the
3023  * propagation methods of the different constraint handlers are called in order of decreasing check priority. Finally,
3024  * the propagators with negative priority are called in order of decreasing priority. \n The priority of the
3025  * propagators should be set according to the complexity of the propagation algorithm and the impact of the domain
3026  * propagations: propagators providing fast algorithms that usually have a high impact (i.e., tighten many bounds)
3027  * should have a high priority.
3028  *
3029  * \par PROP_FREQ: the default frequency for propagating domains.
3030  * The frequency defines the depth levels at which the propagation method \ref PROPEXEC is called. For example, a
3031  * frequency of 7 means, that the propagation callback is executed for subproblems that are in depth 0, 7, 14, ... of
3032  * the branching tree. A frequency of 0 means that propagation is only applied in preprocessing and at the root node. A
3033  * frequency of -1 disables the propagator.
3034  * \n
3035  * The frequency can be adjusted by the user. This property of the propagator only defines the default value of the
3036  * frequency.\n
3037  * <b>Note:</b> If you want to have a more flexible control of when to execute the propagation algorithm, you have to
3038  * assign a frequency of 1 and implement a check at the beginning of your propagation algorithm whether you really want
3039  * to execute the domain propagation or not. If you do not want to execute it, set the result code to SCIP_DIDNOTRUN.
3040  *
3041  * \par PROP_DELAY: the default for whether the propagation method should be delayed, if other propagators or constraint handlers found domain reductions.
3042  * If the propagator's propagation method is marked to be delayed, it is only executed after no other propagator or
3043  * constraint handler found a domain reduction in the current iteration of the domain propagation loop. If the
3044  * propagation method of the propagator is very expensive, you may want to mark it to be delayed until all cheap
3045  * propagation methods have been executed.
3046  *
3047  * \par PROP_TIMING: the timing mask of the propagator.
3048  * SCIP calls the domain propagation routines at different places in the node processing loop.
3049  * This property indicates at which places the propagator is called.
3050  * Possible values are defined in type_timing.h and can be concatenated, e.g., as in SCIP_PROPTIMING_ALWAYS.
3051  *
3052  * @subsection PROP_ADDITIONALPROPERTIES Optional propagator properties
3053  *
3054  * The following properties are optional and only need to be defined if the propagator supports
3055  * presolving, that is, if the \ref PROPPRESOL "presolving callback" is implemented.
3056 
3057  * \par PROP_PRESOLTIMING: the timing of the presolving method (FAST, MEDIUM, or EXHAUSTIVE).
3058  * Every presolving round starts with the FAST presolving methods. MEDIUM presolvers are only called, if FAST presolvers did not find
3059  * enough reductions in this round so far, and EXHAUSTIVE presolving steps are only performed if all presolvers called before
3060  * in this round were unsuccessful.
3061  * Presolving methods should be assigned a timing based on how expensive they are, e.g., presolvers that provide fast algorithms that
3062  * usually have a high impact (i.e., remove lots of variables or tighten bounds of many variables) should have a timing FAST.
3063  * If a presolving method implements different algorithms of different complexity, it may also get multiple timings and check the timing
3064  * internally in the \ref PROPPRESOL callback to decide which algorithms to run.
3065  *
3066  * \par PROP_PRESOL_PRIORITY: the priority of the presolving method.
3067  * This attribute is analogous to the PROP_PRIORITY flag, but deals with the preprocessing method of the presolver.
3068  *
3069  * \par PROP_PRESOL_MAXROUNDS: the default maximal number of presolving rounds the propagator participates in.
3070  * The preprocessing is executed in rounds.
3071  * If enough changes have been applied to the model, an additional preprocessing round is performed.
3072  * The MAXROUNDS parameter of a propagator denotes the maximal number of preprocessing rounds, the propagator
3073  * participates in.
3074  * A value of -1 means, that there is no limit on the number of rounds.
3075  * A value of 0 means, the preprocessing callback of the propagator is disabled.
3076  *
3077  * @section PROP_DATA Propagator Data
3078  *
3079  * Below the title "Data structures" you can find a struct called <code>struct SCIP_PropData</code>. In this data
3080  * structure, you can store the data of your propagator. For example, you should store the adjustable parameters of the
3081  * propagator in this data structure. If you are using C++, you can add propagator data as object variables to your
3082  * class as usual .
3083  * \n
3084  * Defining propagator data is optional. You can leave the struct empty.
3085  *
3086  *
3087  * @section PROP_INTERFACE Interface Methods
3088  *
3089  * At the bottom of "prop_mypropagator.c", you can find the interface method SCIPincludeSepaMypropagator(),
3090  * which also appears in "prop_mypropagator.h"
3091  * SCIPincludePropMypropagator() is called by the user, if (s)he wants to include the propagator,
3092  * i.e., if (s)he wants to use the propagator in his/her application.
3093  *
3094  * This method only has to be adjusted slightly.
3095  * It is responsible for notifying SCIP of the presence of the propagator. For this, you can either call SCIPincludeProp(),
3096  * or SCIPincludePropBasic() since SCIP version 3.0. In the latter variant, \ref PROP_ADDITIONALCALLBACKS "additional callbacks"
3097  * must be added via setter functions as, e.g., SCIPsetPropCopy(). We recommend this latter variant because
3098  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
3099  * variant must be manually adjusted with every SCIP release containing new callbacks for separators in order to compile.
3100  *
3101  *
3102  * If you are using propagator data, you have to allocate the memory for the data at this point. You can do this by
3103  * calling
3104  * \code
3105  * SCIP_CALL( SCIPallocMemory(scip, &propdata) );
3106  * \endcode
3107  * You also have to initialize the fields in <code>struct SCIP_PropData</code> afterwards.
3108  *
3109  * You may also add user parameters for your propagator, see the method SCIPincludePropPseudoobj() in
3110  * src/scip/prop_pseudoobj.c for an example.
3111  *
3112  *
3113  * @section PROP_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Propagator
3114  *
3115  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
3116  * an operational algorithm.
3117  * They are passed together with the propagator itself to SCIP using SCIPincludeProp() or SCIPincludePropBasic(),
3118  * see @ref PROP_INTERFACE.
3119  *
3120  * Propagator plugins have one fundamental callback method, namely the \ref PROPEXEC method
3121  * method. This method has to be implemented for every propagator; the other callback methods are optional. In the
3122  * C++ wrapper class scip::ObjProp, the scip_exec() method (which corresponds to the \ref PROPEXEC
3123  * callback) is a virtual abstract member function. You have to
3124  * implement it in order to be able to construct an object of your propagator class.
3125  *
3126  * Additional documentation for the callback methods can be found in type_prop.h.
3127  *
3128  * @subsection PROPEXEC
3129  *
3130  * The PROPEXEC callback is called during presolving and during the subproblem processing. It should perform the actual
3131  * domain propagation, which means that it should tighten the variables' bounds. The technique of domain propagation,
3132  * which is the main workhorse of constraint programming, is called "node preprocessing" in the Integer Programming
3133  * community.
3134  *
3135  * The PROPEXEC callback has the following options:
3136  * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
3137  * - reducing (i.e, tightening) the domains of some variables (result SCIP_REDUCEDDOM)
3138  * - stating that the propagator searched, but did not find domain reductions, cutting planes, or cut constraints
3139  * (result SCIP_DIDNOTFIND)
3140  * - stating that the propagator was skipped (result SCIP_DIDNOTRUN)
3141  * - stating that the propagator was skipped, but should be called again (result SCIP_DELAYED)
3142  *
3143  *
3144  *
3145  * @section PROP_ADDITIONALCALLBACKS Additional Callback Methods of a Propagator
3146  *
3147  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
3148  * implemented for most applications, they can be used, for example, to initialize and free private data.
3149  * Additional callbacks can either be passed directly with SCIPincludeProp() to SCIP or via specific
3150  * <b>setter functions</b> after a call of SCIPincludePropBasic(), see also @ref PROP_INTERFACE.
3151  *
3152  * @subsection PROPRESPROP
3153  *
3154  * If the propagator wants to support \ref CONF "conflict analysis", it has to supply the PROPRESPROP method. It also should call
3155  * SCIPinferVarLbProp() or SCIPinferVarUbProp() in the domain propagation instead of SCIPchgVarLb() or SCIPchgVarUb() in
3156  * order to deduce bound changes on variables. In the SCIPinferVarLbProp() and SCIPinferVarUbProp() calls, the
3157  * propagator provides a pointer to itself and an integer value "inferinfo" that can be arbitrarily chosen.
3158  *
3159  * The propagation conflict resolving method PROPRESPROP must then be implemented to provide the "reasons" for the bound
3160  * changes, i.e., the bounds of variables at the time of the propagation, which forced the propagator to set the
3161  * conflict variable's bound to its current value. It can use the "inferinfo" tag to identify its own propagation rule
3162  * and thus identify the "reason" bounds. The bounds that form the reason of the assignment must then be provided by
3163  * calls to SCIPaddConflictLb() and SCIPaddConflictUb() in the propagation conflict resolving method.
3164  *
3165  * See the description of the propagation conflict resolving method \ref CONSRESPROP of constraint handlers for
3166  * further details.
3167  *
3168  * Omitting the PROPRESPROP callback circumvents the implementation of the usually rather complex conflict resolving method.
3169  * Yet, it
3170  * will make the conflict analysis less effective. We suggest to first omit the conflict resolving method and check how
3171  * effective the propagation method is. If it produces a lot of propagations for your application, you definitely should
3172  * consider implementing the conflict resolving method.
3173  *
3174  *
3175  * @subsection PROPFREE
3176  *
3177  * If you are using propagator data, you have to implement this method in order to free the propagator data.
3178  * This can be done by the following procedure:
3179  * \code
3180  * static
3181  * SCIP_DECL_PROPFREE(propFreeMypropagator)
3182  * {
3183  * SCIP_PROPDATA* propdata;
3184  *
3185  * propdata = SCIPpropGetData(prop);
3186  * assert(propdata != NULL);
3187  *
3188  * SCIPfreeMemory(scip, &propdata);
3189  *
3190  * SCIPpropSetData(prop, NULL);
3191  *
3192  * return SCIP_OKAY;
3193  * }
3194  * \endcode
3195  * If you have allocated memory for fields in your propagator data, remember to free this memory
3196  * before freeing the propagator data itself.
3197  * If you are using the C++ wrapper class, this method is not available.
3198  * Instead, just use the destructor of your class to free the member variables of your class.
3199  *
3200  * @subsection PROPINIT
3201  *
3202  * The PROPINIT callback is executed after the problem is transformed. The propagator may, e.g., use this call to
3203  * initialize its propagator data.
3204  *
3205  * @subsection PROPCOPY
3206  *
3207  * The PROPCOPY callback is executed when a SCIP instance is copied, e.g. to
3208  * solve a sub-SCIP. By
3209  * defining this callback as
3210  * <code>NULL</code> the user disables the execution of the specified
3211  * propagator for all copied SCIP instances. This may deteriorate the performance
3212  * of primal heuristics using sub-SCIPs.
3213  *
3214  * @subsection PROPEXIT
3215  *
3216  * The PROPEXIT callback is executed before the transformed problem is freed.
3217  * In this method, the propagator should free all resources that have been allocated for the solving process in PROPINIT.
3218  *
3219  * @subsection PROPINITPRE
3220  *
3221  * The PROPINITPRE callback is executed before the preprocessing is started, even if presolving is turned off.
3222  * The propagator may use this call to initialize its presolving data before the presolving process begins.
3223  *
3224  * @subsection PROPEXITPRE
3225  *
3226  * The PROPEXITPRE callback is executed after the preprocessing has been finished, even if presolving is turned off.
3227  * The propagator may use this call, e.g., to clean up its presolving data.
3228  * Besides clean up, no time consuming operations should be done.
3229  *
3230  * @subsection PROPINITSOL
3231  *
3232  * The PROPINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
3233  * begin.
3234  * The propagator may use this call to initialize its branch-and-bound specific data.
3235  *
3236  * @subsection PROPEXITSOL
3237  *
3238  * The PROPEXITSOL callback is executed before the branch-and-bound process is freed.
3239  * The propagator should use this call to clean up its branch-and-bound data.
3240  *
3241  * @subsection PROPPRESOL
3242  *
3243  * Seaches for domain propagations, analogous to the \ref PROPEXEC callback.
3244  * However, this callback is called during preprocessing.
3245  *
3246  * To inform SCIP that the presolving method found a reduction the result pointer has to be set in a proper way.
3247  * The following options are possible:
3248  *
3249  * - SCIP_UNBOUNDED : at least one variable is not bounded by any constraint in objective direction
3250  * - SCIP_CUTOFF : at least one domain reduction that renders the problem infeasible has been found
3251  * - SCIP_SUCCESS : the presolver found a domain reduction
3252  * - SCIP_DIDNOTFIND : the presolver searched, but did not find a presolving change
3253  * - SCIP_DIDNOTRUN : the presolver was skipped
3254  * - SCIP_DELAYED : the presolver was skipped, but should be called again
3255  *
3256  *
3257  * Please see also the @ref PROP_ADDITIONALPROPERTIES section to learn about the properties
3258  * PROP_PRESOLTIMING and PROP_PRESOL_MAXROUNDS, which influence the behaviour of SCIP
3259  * calling PROPPRESOL.
3260  *
3261  */
3262 
3263 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
3264 /**@page BRANCH How to add branching rules
3265  *
3266  * Branching rules are used to split the problem at the current node into smaller subproblems. Branching rules can be called at three
3267  * different occasions, which is why they have three different execution methods (see \ref
3268  * BRANCHRULE_ADDITIONALCALLBACKS). Branching is performed if:
3269  * - the LP solution of the current problem is fractional. In this case, the integrality constraint handler calls the
3270  * \ref BRANCHEXECLP methods of the branching rules.
3271  * - the list of external branching candidates is not empty. This will only be the case if branching candidates were added
3272  * by a user's \ref RELAX "relaxation handler" or \ref CONS "constraint handler" plugin, calling SCIPaddExternBranchCand().
3273  * These branching candidates should be processed by the \ref BRANCHEXECEXT method.
3274  * - if an integral solution violates one or more constraints and this infeasibility could not be resolved in the callback methods
3275  * \ref CONSENFOLP and \ref CONSENFOPS of the corresponding constraint handlers. In this case, the \ref BRANCHEXECPS method will be called. This is the
3276  * 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
3277  * branching on pseudo solutions works as a last resort.
3278  *
3279  * The idea of branching rules is to take a global view on the problem. In contrast, branching paradigms which are
3280  * specific to one type of constraint are best implemented within the enforcement callbacks of your constraint handler.
3281  * See, e.g., the constraint specific branching rules provided by the constraint handlers for special ordered sets
3282  * (src/scip/cons_sos{1,2}.c)).
3283  * \n
3284  * All branching rules that come with the default distribution of SCIP create two subproblems by splitting a single
3285  * variable's domain. It is, however, fully supported to implement much more general branching schemes, for example by
3286  * creating more than two subproblems, or by adding additional constraints to the subproblems instead of tightening the
3287  * domains of the variables.
3288  * \n
3289  * A complete list of all branching rules contained in this release can be found \ref BRANCHINGRULES "here".
3290  *
3291  * We now explain how users can add their own branching rules. Take the most infeasible LP branching rule
3292  * (src/scip/branch_mostinf.c) as an example. As all other default plugins, it is written in C. C++ users can easily
3293  * adapt the code by using the scip::ObjBranchrule wrapper base class and implement the scip_...() virtual methods instead of
3294  * the SCIP_DECL_BRANCH... callback methods.
3295  *
3296  * Additional documentation for the callback methods of a branching rule can be found in the file type_branch.h.
3297  *
3298  * Here is what you have to do to implement a branching rule:
3299  * -# Copy the template files src/scip/branch_xyz.c and src/scip/branch_xyz.h into files named
3300  * "branch_mybranchingrule.c" and "branch_mybranchingrule.h".
3301  * \n
3302  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
3303  * -# Use SCIPincludeBranchruleMybranchingrule() in order to include the branching rule into your SCIP instance,
3304  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
3305  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mybranchingrule".
3306  * -# Adjust the properties of the branching rule (see \ref BRANCHRULE_PROPERTIES).
3307  * -# Define the branching rule data (see \ref BRANCHRULE_DATA). This is optional.
3308  * -# Implement the interface methods (see \ref BRANCHRULE_INTERFACE).
3309  * -# Implement the fundamental callback methods (see \ref BRANCHRULE_FUNDAMENTALCALLBACKS).
3310  * -# Implement the additional callback methods (see \ref BRANCHRULE_ADDITIONALCALLBACKS). This is optional.
3311  *
3312  *
3313  * @section BRANCHRULE_PROPERTIES Properties of a Branching Rule
3314  *
3315  * At the top of the new file "branch_mybranchingrule.c" you can find the branching rule properties.
3316  * These are given as compiler defines.
3317  * In the C++ wrapper class, you have to provide the branching rule properties by calling the constructor
3318  * of the abstract base class scip::ObjBranchrule from within your constructor.
3319  * The properties you have to set have the following meaning:
3320  *
3321  * \par BRANCHRULE_NAME: the name of the branching rule.
3322  * This name is used in the interactive shell to address the branching rule.
3323  * Additionally, if you are searching for a branching rule with SCIPfindBranchrule(), this name is looked up.
3324  * Names have to be unique: no two branching rules may have the same name.
3325  *
3326  * \par BRANCHRULE_DESC: the description of the branching rule.
3327  * This string is printed as a description of the branching rule in the interactive shell.
3328  *
3329  * \par BRANCHRULE_PRIORITY: the default value for the priority of the branching rule.
3330  * In the subproblem processing, the branching rules are called in decreasing order of their priority until
3331  * one succeeded to branch. Since most branching rules are able to generate a branching in all situations,
3332  * only the rule of highest priority is used. In combination with the BRANCHRULE_MAXDEPTH and
3333  * BRANCHRULE_MAXBOUNDDIST settings, however, interesting strategies can be easily employed. For example,
3334  * the user can set the priority of the "full strong branching" strategy to the highest value and assign the
3335  * second highest value to the "reliable pseudo cost" rule. If (s)he also sets the maximal depth for the
3336  * "full strong branching" to 5, in the top 5 depth levels of the search tree the "full strong branching" is
3337  * applied, while in the deeper levels "reliable pseudo cost branching" is used.
3338  * \n
3339  * Note that the BRANCHRULE_PRIORITY property only specifies the default value of the priority. The user can
3340  * change this value arbitrarily.
3341  *
3342  * \par BRANCHRULE_MAXDEPTH: the default value for the maximal depth level of the branching rule.
3343  * This parameter denotes the maximal depth level in the branch-and-bound tree up to which the branching method of the
3344  * branching rule will be applied. Use -1 for no limit.
3345  * \n
3346  * Note that this property only specifies the default value. The user can change this value arbitrarily.
3347  *
3348  * \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.
3349  * At the current branch-and-bound node, the relative distance from its dual bound (local dual bound)
3350  * to the primal bound compared to the best node's dual bound (global dual bound) is considered. The branching method of
3351  * the branching rule will only be applied at the node if this relative distance does not exceed BRANCHRULE_MAXBOUNDDIST.
3352  * \n
3353  * For example, if the global dual bound is 50 and the primal bound is 60, BRANCHRULE_MAXBOUNDDIST = 0.25 means that
3354  * 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
3355  * 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
3356  * current best node only or at all nodes, respectively.
3357  * \n
3358  * Note that the BRANCHRULE_MAXBOUNDDIST property only specifies the default value of the maximal bound distance.
3359  * The user can change this value arbitrarily.
3360  *
3361  *
3362  * @section BRANCHRULE_DATA Branching Rule Data
3363  *
3364  * Below the header "Data structures" you can find a struct which is called "struct SCIP_BranchruleData".
3365  * In this data structure, you can store the data of your branching rule. For example, you should store the adjustable
3366  * parameters of the branching rule in this data structure.
3367  * If you are using C++, you can add branching rule data as usual as object variables to your class.
3368  * \n
3369  * Defining branching rule data is optional. You can leave the struct empty.
3370  *
3371  *
3372  * @section BRANCHRULE_INTERFACE Interface Methods
3373  *
3374  * At the bottom of "branch_mybranchingrule.c", you can find the interface method SCIPincludeBranchruleMybranchingrule(),
3375  * which also appears in "branch_mybranchingrule.h"
3376  * SCIPincludeBranchruleMybranchingrule() is called by the user, if (s)he wants to include the branching rule,
3377  * i.e., if (s)he wants to use the branching rule in his/her application.
3378  *
3379  * This method only has to be adjusted slightly.
3380  * It is responsible for notifying SCIP of the presence of the branching rule. For this, you can either call
3381  * SCIPincludeBranchrule(),
3382  * or SCIPincludeBranchruleBasic() since SCIP version 3.0. In the latter variant, \ref BRANCHRULE_ADDITIONALCALLBACKS "additional callbacks"
3383  * must be added via setter functions as, e.g., SCIPsetBranchruleCopy(). We recommend this latter variant because
3384  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
3385  * variant must be manually adjusted with every SCIP release containing new callbacks for branchrule in order to compile.
3386  *
3387  *
3388  * If you are using branching rule data, you have to allocate the memory for the data at this point.
3389  * You can do this by calling:
3390  * \code
3391  * SCIP_CALL( SCIPallocMemory(scip, &branchruledata) );
3392  * \endcode
3393  * You also have to initialize the fields in struct SCIP_BranchruleData afterwards.
3394  *
3395  * You may also add user parameters for your branching rule, see the method SCIPincludeBranchruleRelpscost() in
3396  * src/scip/branch_relpscost.c for an example.
3397  *
3398  *
3399  * @section BRANCHRULE_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Branching Rule
3400  *
3401  * Branching rules do not have any fundamental callback methods, i.e., all callback methods are optional.
3402  * In most cases, however, you want to implement the \ref BRANCHEXECLP method and sometimes the \ref BRANCHEXECPS method.
3403  *
3404  *
3405  * @section BRANCHRULE_ADDITIONALCALLBACKS Additional Callback Methods of a Branching Rule
3406  *
3407  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
3408  * implemented for most applications, they can be used, for example, to initialize and free private data.
3409  * Additional callbacks can either be passed directly with SCIPincludeBranchrule() to SCIP or via specific
3410  * <b>setter functions</b> after a call of SCIPincludeBranchruleBasic(), see also @ref BRANCHRULE_INTERFACE.
3411  *
3412  * The most important callback methods are the \ref BRANCHEXECLP, \ref BRANCHEXECEXT,
3413  * and \ref BRANCHEXECPS methods, which perform the actual task of generating a branching.
3414  *
3415  * Additional documentation for the callback methods can be found in type_branch.h.
3416  *
3417  * @subsection BRANCHEXECLP
3418  *
3419  * The BRANCHEXECLP callback is executed during node processing if a fractional LP solution is available. It should
3420  * split the current problem into smaller subproblems. Usually, the branching is done in a way such that the current
3421  * fractional LP solution is no longer feasible in the relaxation of the subproblems. It is, however, possible to
3422  * create a child node for which the fractional LP solution is still feasible in the relaxation, for example, by
3423  * branching on a variable with integral LP value. In every case, you have to make sure that each subproblem is a
3424  * proper restriction of the current problem. Otherwise, you risk to produce an infinite path in the search tree.
3425  *
3426  * The user gains access to the branching candidates, i.e., to the fractional variables, and their LP solution values by
3427  * calling the method SCIPgetLPBranchCands(). Furthermore, SCIP provides two methods for performing the actual
3428  * branching, namely SCIPbranchVar() and SCIPcreateChild().
3429  *
3430  * Given an integral variable \f$x\f$ with fractional LP solution value \f$x^*\f$, the method SCIPbranchVar() creates
3431  * two child nodes; one contains the bound \f$x \le \lfloor x^* \rfloor\f$ and the other one contains the bound \f$x \ge
3432  * \lceil x^* \rceil\f$, see the BRANCHEXECLP callback in src/scip/branch_mostinf.c for an example. In addition, if a
3433  * proven lower objective bound of a created child node is known, like after strong branching has been applied, the user
3434  * may call the method SCIPupdateNodeLowerbound() in order to update the child node's lower bound.
3435  *
3436  * Please also see the \ref BRANCHEXEC "further information for the three execution methods".
3437  *
3438  * @subsection BRANCHEXECEXT
3439  *
3440  * The BRANCHEXECEXT callback is executed during node processing if no LP solution is available and the list of
3441  * external branching candidates is not empty. It should split the current problem into smaller subproblems. If you
3442  * do not use relaxation handlers or constraints handlers that provide external branching candidates, you do not need to
3443  * implement this callback.
3444  *
3445  * In contrast to the LP branching candidates and the pseudo branching candidates, the list of external branching
3446  * candidates will not be generated automatically. The user has to add all variables to the list by calling
3447  * SCIPaddExternBranchCand() for each of them. Usually, this will happen in the execution method of a relaxation handler or in the
3448  * enforcement methods of a constraint handler.
3449  *
3450  * The user gains access to these branching candidates by calling the method SCIPgetExternBranchCands(). Furthermore,
3451  * SCIP provides two methods for performing the actual branching with a given solution value, namely SCIPbranchVarVal()
3452  * and SCIPcreateChild(). SCIPbranchVarVal() allows users to specify the branching point for a variable in contrast to
3453  * SCIPbranchVar(), which will always use the current LP or pseudo solution.
3454  *
3455  * This paragraph contains additional information regarding how the method SCIPbranchVarVal() works. For external branching candidates,
3456  * there are three principle possibilities:
3457  * - Given a continuous variable \f$x\f$ with solution value \f$x^*\f$, the method SCIPbranchVarVal() creates
3458  * two child nodes; one contains the bound \f$x \le x^* \f$ and the other one contains the bound \f$x \ge x^* \f$.
3459  * - Given an integer variable \f$x\f$ with fractional solution value \f$x^*\f$, the method
3460  * SCIPbranchVarVal() creates two child nodes; one contains the bound \f$x \le \lfloor x^* \rfloor\f$ and the other
3461  * one contains the bound \f$x \ge \lceil x^* \rceil\f$.
3462  * - Given an integer variable \f$x\f$ with integral solution value \f$x^*\f$, the method SCIPbranchVarVal()
3463  * creates three child nodes; one contains the bound \f$x \le x^* -1\f$, one contains the bound \f$x \ge x^* +1\f$,
3464  * one contains the fixing \f$x = x^*\f$.
3465  *
3466  * See the BRANCHEXECEXT callback in src/scip/branch_random.c for an example. In addition, if a proven lower bound of a
3467  * created child node is known the user may call the method SCIPupdateNodeLowerbound() in order to update the child
3468  * node's lower bound.
3469  *
3470  * Please also see the \ref BRANCHEXEC "further information for the three execution methods".
3471  *
3472  * @subsection BRANCHEXECPS
3473  *
3474  * The BRANCHEXECPS callback is executed during node processing if no LP solution is available and at least one of the
3475  * integer variables is not yet fixed. It should split the current problem into smaller subproblems. PS stands for
3476  * pseudo solution which is the vector of all variables set to their locally best (w.r.t. the objective function)
3477  * bounds.
3478  *
3479  * The user gains access to the branching candidates, i.e., to the non-fixed integer variables, by calling the method
3480  * SCIPgetPseudoBranchCands(). Furthermore, SCIP provides two methods for performing the actual branching, namely
3481  * SCIPbranchVar() and SCIPcreateChild().
3482  *
3483  * Given an integer variable \f$x\f$ with bounds \f$[l,u]\f$ and not having solved the LP, the method SCIPbranchVar()
3484  * creates two child nodes:
3485  * - If both bounds are finite, then the two children will contain the domain reductions \f$x \le x^*\f$, and \f$x \ge
3486  * x^*+1\f$ with \f$x^* = \lfloor \frac{l + u}{2}\rfloor\f$. The current pseudo solution will remain feasible in one
3487  * of the branches, but the hope is that halving the domain's size leads to good propagations.
3488  * - If only one of the bounds is finite, the variable will be fixed to that bound in one of the child nodes. In the
3489  * other child node, the bound will be shifted by one.
3490  * - 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$.
3491 
3492  *
3493  * See the BRANCHEXECPS callback in src/scip/branch_random.c for an example. In addition, if a proven lower bound of a
3494  * created child node is known, the user may call the method SCIPupdateNodeLowerbound() in order to update the child
3495  * node's lower bound.
3496  *
3497  * Please also see the \ref BRANCHEXEC "further information for the three execution methods".
3498  *
3499  * @subsection BRANCHEXEC Further information for the three execution methods
3500  *
3501  * In order to apply more general branching schemes, one should use the method SCIPcreateChild().
3502  * After having created a child node, the additional restrictions of the child node have to be added with calls to
3503  * SCIPaddConsNode(), SCIPchgVarLbNode(), or SCIPchgVarUbNode().
3504  * \n
3505  * In the method SCIPcreateChild(), the branching rule has to assign two values to the new nodes: a node selection
3506  * priority for each node and an estimate for the objective value of the best feasible solution contained in the subtree
3507  * after applying the branching. If the method SCIPbranchVar() is used, these values are automatically assigned. For
3508  * variable based branching schemes, one might use the methods SCIPcalcNodeselPriority() and the method
3509  * SCIPcalcChildEstimate().
3510  *
3511  * In some cases, the branching rule can tighten the current subproblem instead of producing a branching. For example,
3512  * strong branching might have proven that rounding up a variable would lead to an infeasible LP relaxation and thus,
3513  * the variable must be rounded down. Therefore, the BRANCHEXECLP, BRANCHEXECPS and BRANCHEXECREL callbacks may also
3514  * produce domain reductions or add additional constraints to the current subproblem.
3515  *
3516  * The execution callbacks have the following options:
3517  * - detecting that the node is infeasible and can be cut off (result SCIP_CUTOFF)
3518  * - adding an additional constraint (e.g. a conflict constraint) (result SCIP_CONSADDED; note that this action
3519  * must not be performed if the input "allowaddcons" is FALSE)
3520  * - reducing the domain of a variable such that the current LP solution becomes infeasible (result SCIP_REDUCEDDOM)
3521  * - applying a branching (result SCIP_BRANCHED)
3522  * - stating that the branching rule was skipped (result SCIP_DIDNOTRUN).
3523  *
3524  * Only the BRANCHEXECLP callback has the possibility to add a cutting plane to the LP (result SCIP_SEPARATED).
3525  *
3526  * @subsection BRANCHFREE
3527  *
3528  * If you are using branching rule data, you have to implement this method in order to free the branching rule data.
3529  * This can be done by the following procedure:
3530  * \code
3531  * static
3532  * SCIP_DECL_BRANCHFREE(branchFreeMybranchingrule)
3533  * {
3534  * SCIP_BRANCHRULEDATA* branchruledata;
3535  *
3536  * branchruledata = SCIPbranchruleGetData(branchrule);
3537  * assert(branchruledata != NULL);
3538  *
3539  * SCIPfreeMemory(scip, &branchruledata);
3540  *
3541  * SCIPbranchruleSetData(branchrule, NULL);
3542  *
3543  * return SCIP_OKAY;
3544  * }
3545  * \endcode
3546  * If you have allocated memory for fields in your branching rule data, remember to free this memory
3547  * before freeing the branching rule data itself.
3548  * If you are using the C++ wrapper class, this method is not available.
3549  * Instead, just use the destructor of your class to free the member variables of your class.
3550  *
3551  * @subsection BRANCHINIT
3552  *
3553  * The BRANCHINIT callback is executed after the problem is transformed.
3554  * The branching rule may, e.g., use this call to initialize its branching rule data.
3555  *
3556  * @subsection BRANCHCOPY
3557  *
3558  * The BRANCHCOPY callback is executed when a SCIP instance is copied, e.g. to
3559  * solve a sub-SCIP. By
3560  * defining this callback as
3561  * <code>NULL</code> the user disables the execution of the specified
3562  * branching rule for all copied SCIP instances. This may deteriorate the performance
3563  * of primal heuristics using sub-SCIPs.
3564  *
3565  * @subsection BRANCHEXIT
3566  *
3567  * The BRANCHEXIT callback is executed before the transformed problem is freed.
3568  * In this method, the branching rule should free all resources that have been allocated for the solving process in
3569  * BRANCHINIT.
3570  *
3571  * @subsection BRANCHINITSOL
3572  *
3573  * The BRANCHINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
3574  * begin.
3575  * The branching rule may use this call to initialize its branch-and-bound specific data.
3576  *
3577  * @subsection BRANCHEXITSOL
3578  *
3579  * The BRANCHEXITSOL callback is executed before the branch-and-bound process is freed.
3580  * The branching rule should use this call to clean up its branch-and-bound data.
3581  */
3582 
3583 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
3584 /**@page NODESEL How to add node selectors
3585  *
3586  * Node selectors are used to decide which of the leaves in the current branching tree is selected as next subproblem
3587  * to be processed. The ordering relation of the tree's leaves for storing them in the leaf priority queue is also
3588  * defined by the node selectors.
3589  * \n
3590  * A complete list of all node selectors contained in this release can be found \ref NODESELECTORS "here".
3591  *
3592  * We now explain how users can add their own node selectors.
3593  * Take the node selector for depth first search (src/scip/nodesel_dfs.c) as an example.
3594  * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjNodesel wrapper
3595  * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_NODESEL... callback methods.
3596  *
3597  * Additional documentation for the callback methods of a node selector can be found in the file type_nodesel.h.
3598  *
3599  * Here is what you have to do to implement a node selector:
3600  * -# Copy the template files src/scip/nodesel_xyz.c and src/scip/nodesel_xyz.h into files named "nodesel_mynodeselector.c"
3601  * and "nodesel_mynodeselector.h".
3602  * \n
3603  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
3604  * -# Use SCIPincludeNodeselMynodeselector() in oder to include the node selector into your SCIP instance,
3605  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
3606  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mynodeselector".
3607  * -# Adjust the properties of the node selector (see \ref NODESEL_PROPERTIES).
3608  * -# Define the node selector data (see \ref NODESEL_DATA). This is optional.
3609  * -# Implement the interface methods (see \ref NODESEL_INTERFACE).
3610  * -# Implement the fundamental callback methods (see \ref NODESEL_FUNDAMENTALCALLBACKS).
3611  * -# Implement the additional callback methods (see \ref NODESEL_ADDITIONALCALLBACKS). This is optional.
3612  *
3613  *
3614  * @section NODESEL_PROPERTIES Properties of a Node Selector
3615  *
3616  * At the top of the new file "nodesel_mynodeselector.c" you can find the node selector properties.
3617  * These are given as compiler defines.
3618  * In the C++ wrapper class, you have to provide the node selector properties by calling the constructor
3619  * of the abstract base class scip::ObjNodesel from within your constructor.
3620  * The properties you have to set have the following meaning:
3621  *
3622  * \par NODESEL_NAME: the name of the node selector.
3623  * This name is used in the interactive shell to address the node selector.
3624  * Additionally, if you are searching for a node selector with SCIPfindNodesel(), this name is looked up.
3625  * Names have to be unique: no two node selectors may have the same name.
3626  *
3627  * \par NODESEL_DESC: the description of the node selector.
3628  * This string is printed as a description of the node selector in the interactive shell.
3629  *
3630  * \par NODESEL_STDPRIORITY: the default priority of the node selector in the standard mode.
3631  * The first step of each iteration of the main solving loop is the selection of the next subproblem to be processed.
3632  * The node selector of highest priority (the active node selector) is called to do this selection.
3633  * In particular, if you implemented your own node selector plugin which you want to be applied, you should choose a priority
3634  * which is greater then all priorities of the SCIP default node selectors.
3635  * Note that SCIP has two different operation modes: the standard mode and the memory saving mode. If the memory
3636  * limit - given as a parameter by the user - is almost reached, SCIP switches from the standard mode to the memory saving
3637  * mode in which different priorities for the node selectors are applied. NODESEL_STDPRIORITY is the priority of the
3638  * node selector used in the standard mode.
3639  * \n
3640  * Note that this property only defines the default value of the priority. The user may change this value arbitrarily by
3641  * adjusting the corresponding parameter setting.
3642  *
3643  * \par NODESEL_MEMSAVEPRIORITY: the default priority of the node selector in the memory saving mode.
3644  * The priority NODESEL_MEMSAVEPRIORITY of the node selector has the same meaning as the priority NODESEL_STDPRIORITY, but
3645  * is used in the memory saving mode.
3646  * Usually, you want the best performing node selector, for example best estimate search, to have maximal
3647  * standard priority, while you want a node selector which tends to keep the growth of the search tree limited, for example
3648  * depth first search, to have maximal memory saving priority.
3649  * \n
3650  * Note that this property only defines the default value of the priority. The user may change this value arbitrarily by
3651  * adjusting the corresponding parameter setting.
3652  *
3653  *
3654  * @section NODESEL_DATA Node Selector Data
3655  *
3656  * Below the header "Data structures" you can find a struct which is called "struct SCIP_NodeselData".
3657  * In this data structure, you can store the data of your node selector. For example, you should store the adjustable
3658  * parameters of the node selector in this data structure.
3659  * If you are using C++, you can add node selector data as usual as object variables to your class.
3660  * \n
3661  * Defining node selector data is optional. You can leave the struct empty.
3662  *
3663  *
3664  * @section NODESEL_INTERFACE Interface Methods
3665  *
3666  * At the bottom of "nodesel_mynodeselector.c", you can find the interface method SCIPincludeNodeselMynodeselector(),
3667  * which also appears in "nodesel_mynodeselector.h"
3668  * SCIPincludeNodeselMynodeselector() is called by the user, if (s)he wants to include the node selector,
3669  * i.e., if (s)he wants to use the node selector in his/her application.
3670  *
3671  * This method only has to be adjusted slightly.
3672  * It is responsible for notifying SCIP of the presence of the node selector. For this, you can either call
3673  * SCIPincludeNodesel(),
3674  * or SCIPincludeNodeselBasic() since SCIP version 3.0. In the latter variant, \ref NODESEL_ADDITIONALCALLBACKS "additional callbacks"
3675  * must be added via setter functions as, e.g., SCIPsetNodeselCopy(). We recommend this latter variant because
3676  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
3677  * variant must be manually adjusted with every SCIP release containing new callbacks for node selectors in order to compile.
3678  *
3679  *
3680  * If you are using node selector data, you have to allocate the memory for the data at this point.
3681  * You can do this by calling:
3682  * \code
3683  * SCIP_CALL( SCIPallocMemory(scip, &nodeseldata) );
3684  * \endcode
3685  * You also have to initialize the fields in struct SCIP_NodeselData afterwards.
3686  *
3687  * You may also add user parameters for your node selector, see the method SCIPincludeNodeselRestartdfs() in
3688  * src/scip/nodesel_restartdfs.c for an example.
3689  *
3690  *
3691  * @section NODESEL_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Node Selector
3692  *
3693  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
3694  * an operational algorithm.
3695  * They are passed together with the node selector itself to SCIP using SCIPincludeNodesel() or SCIPincludeNodeselBasic(),
3696  * see @ref NODESEL_INTERFACE.
3697  *
3698  * Node selector plugins have two fundamental callback methods, namely the NODESELSELECT method and the NODESELCOMP method.
3699  * These methods have to be implemented for every node selector; the other callback methods are optional.
3700  * They implement the two requirements every node selector has to fulfill: Selecting a node from the queue to be processed
3701  * next and, given two nodes, deciding which of both is favored by the node selector's selection rule. The first
3702  * task is implemented in the NODESELSELECT callback, the second one in the NODESELCOMP callback.
3703  * In the C++ wrapper class scip::ObjNodesel, the scip_select() method and the scip_comp() method (which correspond to the
3704  * NODESELSELECT callback and the NODESELCOMP callback, respectively) are virtual abstract member functions.
3705  * You have to implement them in order to be able to construct an object of your node selector class.
3706  *
3707  * Additional documentation for the callback methods can be found in type_nodesel.h.
3708  *
3709  * @subsection NODESELSELECT
3710  *
3711  * The NODESELSELECT callback is the first method called in each iteration in the main solving loop. It should decide
3712  * which of the leaves in the current branching tree is selected as the next subproblem to be processed.
3713  * It can arbitrarily decide between all leaves stored in the tree, but for performance reasons,
3714  * the current node's children and siblings are often treated different from the remaining leaves.
3715  * This is mainly due to the warm start capabilities of the simplex algorithm and the expectation that the bases of
3716  * neighboring vertices in the branching tree very similar.
3717  * The node selector's choice of the next node to process can
3718  * have a large impact on the solver's performance, because it influences the finding of feasible solutions and the
3719  * development of the global dual bound.
3720  *
3721  * Besides the ranking of the node selector, every node gets assigned a node selection priority by the branching rule
3722  * that created the node. See the \ref BRANCHEXECLP and \ref BRANCHEXECPS callbacks of the branching rules for details.
3723  * For example, the node where the branching went in the same way as the deviation from the branching variable's
3724  * root solution could be assigned a higher priority than the node where the branching went in the opposite direction.
3725  *
3726  * The following methods provide access to the various types of leaf nodes:
3727  * - SCIPgetPrioChild() returns the child of the current node with the largest node selection priority, as assigned by the
3728  * branching rule.
3729  * If no child is available (for example, because the current node was pruned), a NULL pointer is returned.
3730  * - SCIPgetBestChild() returns the best child of the current node with respect to the node selector's ordering relation as
3731  * defined by the \ref NODESELCOMP callback. If no child is available, a NULL pointer is returned.
3732  * - SCIPgetPrioSibling() returns the sibling of the current node with the largest node selection priority.
3733  * If no sibling is available (for example, because all siblings of the current node have already been processed), a NULL
3734  * pointer is returned.
3735  * Note that in binary branching every node has at most one sibling, but since SCIP supports arbitrary branching rules,
3736  * this might not always be the case.
3737  * - SCIPgetBestSibling() returns the best sibling of the current node with respect to the node selector's ordering relation
3738  * as defined by the \ref NODESELCOMP callback. If no sibling is available, a NULL pointer is returned.
3739  * - SCIPgetBestNode() returns the best leaf from the tree (children, siblings, or other leaves) with respect to the node
3740  * selector's ordering relation as defined by the \ref NODESELCOMP callback. If no open leaf exists, a NULL pointer is
3741  * returned. In this case, the optimization is finished, and the node selector should return a NULL pointer as 'selnode'.
3742  * - SCIPgetBestboundNode() returns a leaf from the tree (children, siblings, or other leaves) with the smallest lower (dual)
3743  * objective bound. If the queue is empty, a NULL pointer is returned. In this case, the optimization is finished, and the
3744  * node selector should return a NULL pointer as 'selnode'.
3745  *
3746  *
3747  * @subsection NODESELCOMP
3748  *
3749  * The NODESELCOMP callback is called to compare two leaves of the current branching tree (say node 1 and node 2)
3750  * regarding their ordering relation.
3751  *
3752  * The NODESELCOMP should return the following values:
3753  * - value < 0, if node 1 comes before (is better than) node 2
3754  * - value = 0, if both nodes are equally good
3755  * - value > 0, if node 1 comes after (is worse than) node 2.
3756  *
3757  * @section NODESEL_ADDITIONALCALLBACKS Additional Callback Methods of a Node Selector
3758  *
3759  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
3760  * implemented for most applications, they can be used, for example, to initialize and free private data.
3761  * Additional callbacks can either be passed directly with SCIPincludeNodesel() to SCIP or via specific
3762  * <b>setter functions</b> after a call of SCIPincludeNodeselBasic(), see also @ref NODESEL_INTERFACE.
3763  *
3764  * @subsection NODESELFREE
3765  *
3766  * If you are using node selector data, you have to implement this method in order to free the node selector data.
3767  * This can be done by the following procedure:
3768  * \code
3769  * static
3770  * SCIP_DECL_NODESELFREE(nodeselFreeMynodeselector)
3771  * {
3772  * SCIP_NODESELDATA* nodeseldata;
3773  *
3774  * nodeseldata = SCIPnodeselGetData(nodesel);
3775  * assert(nodeseldata != NULL);
3776  *
3777  * SCIPfreeMemory(scip, &nodeseldata);
3778  *
3779  * SCIPnodeselSetData(nodesel, NULL);
3780  *
3781  * return SCIP_OKAY;
3782  * }
3783  * \endcode
3784  * If you have allocated memory for fields in your node selector data, remember to free this memory
3785  * before freeing the node selector data itself.
3786  * If you are using the C++ wrapper class, this method is not available.
3787  * Instead, just use the destructor of your class to free the member variables of your class.
3788  *
3789  * @subsection NODESELINIT
3790  *
3791  * The NODESELINIT callback is executed after the problem is transformed.
3792  * The node selector may, e.g., use this call to initialize its node selector data.
3793  *
3794  * @subsection NODESELCOPY
3795  *
3796  * The NODESELCOPY callback is executed when a SCIP instance is copied, e.g. to
3797  * solve a sub-SCIP. By
3798  * defining this callback as
3799  * <code>NULL</code> the user disables the execution of the specified
3800  * node selector for all copied SCIP instances. This may deteriorate the performance
3801  * of primal heuristics using sub-SCIPs.
3802  *
3803  * @subsection NODESELEXIT
3804  *
3805  * The NODESELEXIT callback is executed before the transformed problem is freed.
3806  * In this method, the node selector should free all resources that have been allocated for the solving process
3807  * in NODESELINIT.
3808  *
3809  * @subsection NODESELINITSOL
3810  *
3811  * The NODESELINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
3812  * begin.
3813  * The node selector may use this call to initialize its branch-and-bound specific data.
3814  *
3815  * @subsection NODESELEXITSOL
3816  *
3817  * The NODESELEXITSOL callback is executed before the branch-and-bound process is freed.
3818  * The node selector should use this call to clean up its branch-and-bound data.
3819  */
3820 
3821 
3822 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
3823 /**@page HEUR How to add primal heuristics
3824  *
3825  * Feasible solutions can be found in two different ways during the traversal of the branch-and-bound tree. On one
3826  * hand, the solution of a node's relaxation may be feasible with respect to the constraints (including the integrality).
3827  * On the other hand, feasible solutions can be discovered by primal heuristics.
3828  * \n
3829  * A complete list of all primal heuristics contained in this release can be found \ref PRIMALHEURISTICS "here".
3830  * \n
3831  * Diving heuristics are primal heuristics that explore an auxiliary search tree in a depth-first manner. Since SCIP
3832  * version 3.2, it is easy to integrate further diving heuristics by using a special controller for the scoring,
3833  * see \ref DIVINGHEUR "here" for information on how to implement a diving heuristic.
3834  * \n
3835  * We now explain how users can add their own primal heuristics.
3836  * Take the simple and fast LP rounding heuristic (src/scip/heur_simplerounding.c) as an example.
3837  * The idea of simple rounding is to iterate over all fractional variables of an LP solution and round them down,
3838  * if the variables appears only with nonnegative coefficients in the system Ax <= b and round them up if
3839  * the variables appears only with nonpositive coefficients.
3840  * If one of both conditions applies for each of the fractional variables, this will give a feasible solution.
3841  * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjHeur wrapper
3842  * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_HEUR... callback methods.
3843  *
3844  * Additional documentation for the callback methods of a primal heuristic can be found in the file type_heur.h.
3845  *
3846  * Here is what you have to do to implement a primal heuristic:
3847  * -# Copy the template files src/scip/heur_xyz.c and src/scip/heur_xyz.h into files named "heur_myheuristic.c"
3848  * and "heur_myheuristic.h".
3849  * \n
3850  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
3851  * -# Use SCIPincludeHeurMyheuristic() in order to include the heuristic into your SCIP instance,
3852  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
3853  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "myheuristic".
3854  * -# Adjust the properties of the primal heuristic (see \ref HEUR_PROPERTIES).
3855  * -# Define the primal heuristic data (see \ref HEUR_DATA). This is optional.
3856  * -# Implement the interface methods (see \ref HEUR_INTERFACE).
3857  * -# Implement the fundamental callback methods (see \ref HEUR_FUNDAMENTALCALLBACKS).
3858  * -# Implement the additional callback methods (see \ref HEUR_ADDITIONALCALLBACKS). This is optional.
3859  *
3860  *
3861  * @section HEUR_PROPERTIES Properties of a Primal Heuristic
3862  *
3863  * At the top of the new file "heur_myheuristic.c" you can find the primal heuristic properties.
3864  * These are given as compiler defines.
3865  * In the C++ wrapper class, you have to provide the primal heuristic properties by calling the constructor
3866  * of the abstract base class scip::ObjHeur from within your constructor.
3867  * Of course, all of them are of relevant, but the most important ones for controlling the performance
3868  * are usually HEUR_FREQ and HEUR_TIMING.
3869  * The properties you have to set have the following meaning:
3870  *
3871  * \par HEUR_NAME: the name of the primal heuristic.
3872  * This name is used in the interactive shell to address the primal heuristic.
3873  * Additionally, if you are searching for a primal heuristic with SCIPfindHeur(), this name is looked up.
3874  * Names have to be unique: no two primal heuristics may have the same name.
3875  *
3876  * \par HEUR_DESC: the description of the primal heuristic.
3877  * This string is printed as a description of the primal heuristic in the interactive shell when you call "display heuristics".
3878  *
3879  * \par HEUR_DISPCHAR: the display character of the primal heuristic.
3880  * In the interactive shell, this character is printed in the first column of a status information row, if the primal
3881  * heuristic found the feasible solution belonging to the primal bound. Note that a star '*' stands for an integral
3882  * LP-relaxation.
3883  * In order to avoid confusion, display characters should be unique: no two primal heuristics should have the same display character.
3884  * You can get a list of all primal heuristics along with their display characters by entering "display heuristics" in the
3885  * SCIP interactive shell.
3886  *
3887  * \par HEUR_PRIORITY: the priority of the primal heuristic.
3888  * At each of the different entry points of the primal heuristics during the solving process (see HEUR_TIMING), they are
3889  * called in decreasing order of their priority.
3890  * \n
3891  * The priority of a primal heuristic should be set according to the complexity of the heuristic and the likelihood to find
3892  * feasible solutions: primal heuristics that provide fast algorithms that often succeed in finding a feasible solution should have
3893  * a high priority (like simple rounding). In addition, the interaction between different types of primal heuristics should be taken into account.
3894  * For example, improvement heuristics, which try to generate improved solutions by inspecting one or more of the feasible
3895  * solutions that have already been found, should have a low priority (like Crossover which by default needs at least 3 feasible solutions).
3896  *
3897  * \par HEUR_FREQ: the default frequency for executing the primal heuristic.
3898  * The frequency together with the frequency offset (see HEUR_FREQOFS) defines the depth levels at which the execution
3899  * method of the primal heuristic \ref HEUREXEC is called. For example, a frequency of 7 together with a frequency offset
3900  * of 5 means, that the \ref HEUREXEC callback is executed for subproblems that are in depth 5, 12, 19, ... of the branching tree. A
3901  * frequency of 0 together with a frequency offset of 3 means, that the execution method is only called at those nodes that are in
3902  * depth level 3 (i.e., at most for \f$2^3 = 8\f$ nodes if binary branching is applied).
3903  * Typical cases are: A frequency of 0 and an offset of 0 which means that
3904  * the heuristic is only called at the root node and a frequency of -1 which disables the heuristic.
3905  * \n
3906  * The frequency can be adjusted by the user. This property of the primal heuristic only defines the default value of the
3907  * frequency. If you want to have a more flexible control of when to execute the primal heuristic, you have to assign
3908  * a frequency of 1 and implement a check at the beginning of your execution method whether you really want to search for feasible
3909  * solutions or not. If you do not want to execute the method, set the result code to SCIP_DIDNOTRUN.
3910  *
3911  * \par HEUR_FREQOFS: the frequency offset for executing the primal heuristic.
3912  * The frequency offset defines the depth of the branching tree at which the primal heuristic is executed for the first
3913  * time. For example, a frequency of 7 (see HEUR_FREQ) together with a frequency offset of 10 means, that the
3914  * callback is executed for subproblems that are in depth 10, 17, 24, ... of the branching tree. In particular, assigning
3915  * different offset values to heuristics of the same type, like diving heuristics, can be useful for evenly spreading the
3916  * application of these heuristics across the branch-and-bound tree.
3917  * Note that if the frequency is equal to 1, the heuristic is applied for all nodes with depth level larger or equal to
3918  * the frequency offset.
3919  *
3920  * \par HEUR_MAXDEPTH: the maximal depth level for executing the primal heuristic.
3921  * This parameter denotes the maximal depth level in the branching tree up to which the execution method of the primal
3922  * heuristic is called. Use -1 for no limit (a usual case).
3923  *
3924  * \par HEUR_TIMING: the execution timing of the primal heuristic.
3925  * Primal heuristics have different entry points during the solving process and the execution timing parameter defines the
3926  * entry point at which the primal heuristic is executed first.
3927  * \n
3928  * The primal heuristic can be called first:
3929  * - before the processing of the node starts (SCIP_HEURTIMING_BEFORENODE)
3930  * - after each LP solve during the cut-and-price loop (SCIP_HEURTIMING_DURINGLPLOOP)
3931  * - after the cut-and-price loop was finished (SCIP_HEURTIMING_AFTERLPLOOP)
3932  * - after the processing of a node <em>with solved LP</em> was finished (SCIP_HEURTIMING_AFTERLPNODE)
3933  * - after the processing of a node <em>without solved LP</em> was finished (SCIP_HEURTIMING_AFTERPSEUDONODE)
3934  * - after the processing of the last node in the current plunge was finished, <em>and only if the LP was solved for
3935  * this node</em> (SCIP_HEURTIMING_AFTERLPPLUNGE)
3936  * - after the processing of the last node in the current plunge was finished, <em>and only if the LP was not solved
3937  * for this node</em> (SCIP_HEURTIMING_AFTERPSEUDOPLUNGE).
3938  * \par
3939  * A plunge is the successive solving of child and sibling nodes in the search tree.
3940  * The flags listed above can be combined to call the heuristic at multiple times by concatenating them with a bitwise OR.
3941  * Two useful combinations are already predefined:
3942  * - after the processing of a node was finished (SCIP_HEURTIMING_AFTERNODE; combines SCIP_HEURTIMING_AFTERLPNODE and
3943  * SCIP_HEURTIMING_AFTERPSEUDONODE)
3944  * - after the processing of the last node in the current plunge was finished (SCIP_HEURTIMING_AFTERPLUNGE; combines
3945  * SCIP_HEURTIMING_AFTERLPPLUNGE and SCIP_HEURTIMING_AFTERPSEUDOPLUNGE)
3946  * \par
3947  * Calling a primal heuristic "before the processing of the node starts" is particularly useful for heuristics
3948  * that do not need to access the LP solution of the current node. If such a heuristic finds a feasible solution, the
3949  * leaves of the branching tree exceeding the new primal bound are pruned. It may happen that even the current node can
3950  * be cut off without solving the LP relaxation. Combinatorial heuristics, like the farthest insert heuristic for the TSP
3951  * (see examples/TSP/src/HeurFarthestInsert.cpp), are often applicable at this point.
3952  * \n
3953  * Very fast primal heuristics that require an LP solution can also be called "after each LP solve during the
3954  * cut-and-price loop". Rounding heuristics, like the simple and fast LP rounding heuristic
3955  * (src/scip/heur_simplerounding.c), belong to this group of primal heuristics.
3956  * \n
3957  * Most heuristics, however, are called either after a node was completely processed
3958  * (e.g. expensive rounding heuristics like RENS), or even only after a full plunge was finished (e.g., diving heuristics).
3959  *
3960  * \par HEUR_USESSUBSCIP: Does the heuristic use a secondary SCIP instance?
3961  * Some heuristics and separators solve MIPs or SAT problems using a secondary SCIP instance. Examples are
3962  * Large Neighborhood Search heuristics such as RINS and Local Branching or the CGMIP separator. To avoid recursion,
3963  * these plugins usually deactivate all other plugins that solve MIPs. If a heuristic uses a secondary SCIP instance,
3964  * this parameter has to be TRUE and it is recommended to call SCIPsetSubscipsOff() for the secondary SCIP instance.
3965  *
3966  * Computational experiments indicate that for the overall performance of a MIP solver, it is important to evenly
3967  * spread the application of the heuristics across the branch-and-bound tree. Thus, the assignment of the parameters
3968  * HEUR_FREQ, HEUR_FREQOFS, and HEUR_TIMING should contribute to this aim.
3969  *
3970  * Note that all diving heuristics in the SCIP distribution (see, e.g., src/scip/heur_guideddiving.c) check whether other diving
3971  * heuristics have already been called at the current node. This can be done by comparing SCIPgetLastDivenode(scip) and
3972  * SCIPgetNNodes(scip). If the two are equal, and if the current node is not the root node (SCIPgetDepth(scip) > 0), diving
3973  * heuristics should be delayed by returning the result code 'SCIP_DELAYED'. This is an additional contribution to the goal of
3974  * not calling multiple similar heuristics at the same node.
3975  *
3976  *
3977  * @section HEUR_DATA Primal Heuristic Data
3978  *
3979  * Below the header "Data structures" you can find a struct which is called "struct SCIP_HeurData".
3980  * In this data structure, you can store the data of your primal heuristic. For example, you should store the adjustable
3981  * parameters of the primal heuristic or a working solution in this data structure.
3982  * If you are using C++, you can add primal heuristic data as usual as object variables to your class.
3983  * \n
3984  * Defining primal heuristic data is optional. You can leave the struct empty.
3985  *
3986  *
3987  * @section HEUR_INTERFACE Interface Methods
3988  *
3989  * At the bottom of "heur_myheuristic.c", you can find the interface method SCIPincludeHeurMyheuristic(),
3990  * which also appears in "heur_myheuristic.h"
3991  * SCIPincludeHeurMyheuristic() is called by the user, if (s)he wants to include the heuristic,
3992  * i.e., if (s)he wants to use the heuristic in his/her application.
3993  *
3994  * This method only has to be adjusted slightly.
3995  * It is responsible for notifying SCIP of the presence of the heuristic. For this, you can either call
3996  * SCIPincludeHeur(),
3997  * or SCIPincludeHeurBasic() since SCIP version 3.0. In the latter variant, \ref HEUR_ADDITIONALCALLBACKS "additional callbacks"
3998  * must be added via setter functions as, e.g., SCIPsetHeurCopy(). We recommend this latter variant because
3999  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
4000  * variant must be manually adjusted with every SCIP release containing new callbacks for heuristics in order to compile.
4001  *
4002  * If you are using primal heuristic data, you have to allocate the memory for the data at this point.
4003  * You can do this by calling:
4004  * \code
4005  * SCIP_CALL( SCIPallocMemory(scip, &heurdata) );
4006  * \endcode
4007  * You also have to initialize the fields in struct SCIP_HeurData afterwards.
4008  *
4009  * You may also add user parameters for your primal heuristic, see the method SCIPincludeHeurFeaspump() in
4010  * src/scip/heur_oneopt.c for an example where a single Boolean parameter is added.
4011  *
4012  *
4013  * @section HEUR_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Primal Heuristic
4014  *
4015  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
4016  * an operational algorithm.
4017  * They are passed together with the primal heuristic itself to SCIP using SCIPincludeHeur() or SCIPincludeHeurBasic(),
4018  * see @ref HEUR_INTERFACE.
4019  *
4020  *
4021  * Primal heuristic plugins have only one fundamental callback method, namely the HEUREXEC method.
4022  * This method has to be implemented for every primal heuristic; the other callback methods are optional.
4023  * In the C++ wrapper class scip::ObjHeur, the scip_exec() method (which corresponds to the HEUREXEC callback) is a virtual
4024  * abstract member function. You have to implement it in order to be able to construct an object of your primal heuristic
4025  * class.
4026  *
4027  * Additional documentation for the callback methods can be found in type_heur.h.
4028  *
4029  * @subsection HEUREXEC
4030  *
4031  * The HEUREXEC callback is called at different positions during the node processing loop, see HEUR_TIMING. It should
4032  * search for feasible solutions and add them to the solution pool. For creating a new feasible solution, the
4033  * methods SCIPcreateSol() and SCIPsetSolVal() can be used. Afterwards, the solution can be added to the storage by
4034  * calling the method SCIPtrySolFree() (or SCIPtrySol() and SCIPfreeSol()).
4035  *
4036  * The HEUREXEC callback gets a SCIP pointer, a pointer to the heuristic itself, the current point in the
4037  * solve loop and a result pointer as input (see type_heur.h).
4038  *
4039  * The heuristic has to set the result pointer appropriately!
4040  * Therefore it has the following options:
4041  * - finding at least one feasible solution (result SCIP_FOUNDSOL)
4042  * - stating that the primal heuristic searched, but did not find a feasible solution (result SCIP_DIDNOTFIND)
4043  * - stating that the primal heuristic was skipped (result SCIP_DIDNOTRUN)
4044  * - stating that the primal heuristic was skipped, but should be called again (result SCIP_DELAYED).
4045  *
4046  *
4047  * @section HEUR_ADDITIONALCALLBACKS Additional Callback Methods of a Primal Heuristic
4048  *
4049  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
4050  * implemented for most applications, they can be used, for example, to initialize and free private data.
4051  * Additional callbacks can either be passed directly with SCIPincludeHeur() to SCIP or via specific
4052  * <b>setter functions</b> after a call of SCIPincludeHeurBasic(), see also @ref HEUR_INTERFACE.
4053  *
4054  * @subsection HEURFREE
4055  *
4056  * If you are using primal heuristic data, you have to implement this method in order to free the primal heuristic data.
4057  * This can be done by the following procedure:
4058  * \code
4059  * static
4060  * SCIP_DECL_HEURFREE(heurFreeMyheuristic)
4061  * {
4062  * SCIP_HEURDATA* heurdata;
4063  *
4064  * heurdata = SCIPheurGetData(heur);
4065  * assert(heurdata != NULL);
4066  *
4067  * SCIPfreeMemory(scip, &heurdata);
4068  *
4069  * SCIPheurSetData(heur, NULL);
4070  *
4071  * return SCIP_OKAY;
4072  * }
4073  * \endcode
4074  * If you have allocated memory for fields in your primal heuristic data, remember to free this memory
4075  * before freeing the primal heuristic data itself.
4076  * If you are using the C++ wrapper class, this method is not available.
4077  * Instead, just use the destructor of your class to free the member variables of your class.
4078  *
4079  * @subsection HEURINIT
4080  *
4081  * The HEURINIT callback is executed after the problem is transformed.
4082  * The primal heuristic may, e.g., use this call to initialize its primal heuristic data.
4083  *
4084  * @subsection HEURCOPY
4085  *
4086  * The HEURCOPY callback is executed when a SCIP instance is copied, e.g. to
4087  * solve a sub-SCIP. By
4088  * defining this callback as
4089  * <code>NULL</code> the user disables the execution of the specified
4090  * heuristic for all copied SCIP instances. This may deteriorate the performance
4091  * of primal heuristics using sub-SCIPs.
4092  *
4093  * @subsection HEUREXIT
4094  *
4095  * The HEUREXIT callback is executed before the tDIVINGHEURransformed problem is freed.
4096  * In this method, the primal heuristic should free all resources that have been allocated for the solving process in
4097  * HEURINIT.
4098  *
4099  * @subsection HEURINITSOL
4100  *
4101  * The HEURINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
4102  * begin. The primal heuristic may use this call to initialize its branch-and-bound specific data.
4103  *
4104  * @subsection HEUREXITSOL
4105  *
4106  * The HEUREXITSOL callback is executed before the branch-and-bound process is freed. The primal heuristic should use this
4107  * call to clean up its branch-and-bound data, which was allocated in HEURINITSOL.
4108  */
4109 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
4110 
4111 /**@page DIVINGHEUR How to implement a diving heuristic
4112  *
4113  * Diving heuristics are an important addon to the branch-and-cut search. A diving heuristic explores a single probing
4114  * path down the search tree. In contrast to the regular search guided by branching rule(s) and the selected
4115  * node selector, the diving is performed in an auxiliary tree originating from the focus node of the main
4116  * search tree where the heuristic was called. The advantage of this approach is that many different scoring mechanisms
4117  * can be safely tried as diving heuristic and may probably lead to better solutions. SCIP has a lot of diving heuristics
4118  * included in its default plugin set.
4119  * \n
4120  *
4121  * Since SCIP version 3.2, the diving heuristics have been redesigned to contain mainly the scoring function used by the
4122  * heuristic. In order to implement a user-defined diving heuristic, it is possible to create one (or several)
4123  * divesets that control the scoring mechanism and add them to the primal heuristic. This has the advantage that
4124  * less code is necessary to create a working diving heuristic. The SCIP statistics now also display some interesting statistics
4125  * about every diveset together in the section 'Diving Statistics'.
4126  * \n
4127  *
4128  * This page contains the necessary steps to understand and include a diveset into ones primal diving heuristic plugin. As
4129  * a prerequisite, you should understand the basic implementation steps for a primal heuristic, see \ref HEUR.
4130  * In order to make use of divesets, they must be included _after_ the primal heuristic to which they should belong
4131  * has been included, by using SCIPincludeDiveset(). This will create the data structure for the diveset and
4132  * append it to the list of divesets belonging to the heuristic, which can be retrieved later together with their number
4133  * by using SCIPheurGetDivesets() and SCIPheurGetNDivesets(), respectively. No further memory allocation or deletion is needed;
4134  * As a member of the heuristic, SCIP automatically takes care of freeing the diveset when it is exiting.
4135  * \n
4136  *
4137  * Before the inclusion, one may think of adjusting the various properties that a diveset offers to control
4138  * the behavior of the algorithm. These are subject to the following section.
4139  * \n
4140  *
4141  * It is mandatory to implement the fundamental scoring callback of the diveset, which is explained in more detail
4142  * in Section \ref DIVING_FUNDAMENTALCALLBACKS.
4143  * \n
4144  *
4145  * Once the properties have been carefully adjusted and the scoring
4146  * has been defined, use the method SCIPperformGenericDivingAlgorithm() inside the execution callback (\ref HEUREXEC) of the primal
4147  * heuristic to which the diveset belongs, after checking possible preliminaries that may not be met at all times of the search.
4148  * \n
4149  *
4150  * For a code example, we refer to \ref heur_guideddiving.h, which guides the diving into the direction of the current incumbent solution.
4151  * Before it calls SCIPperformGenericDivingAlgorithm(), it checks whether an incumbent is available, and returns if there is none.
4152  *
4153  *
4154  * @section DIVING_PARAMETERS User parameters and properties for every diveset
4155  *
4156  * Every diveset controls the diving behavior through a set of user-defined parameters, which are explained in the following:
4157  *
4158  * \par MINRELDEPTH
4159  * the minimal relative depth (to the maximum depth explored during regular search) of the current focus node to start diving
4160  *
4161  * \par MAXRELDEPTH
4162  * the maximal relative depth (to the maximum depth explored during regular search) of the current focus node to start diving
4163  *
4164  * \par MAXLPITERQUOT
4165  * maximal fraction of diving LP iterations compared to node LP iterations that this dive controller may consume
4166  *
4167  * \par MAXLPITEROFS
4168  * an additional number of allowed LP iterations
4169  *
4170  * \par MAXDIVEUBQUOT
4171  * maximal quotient (curlowerbound - lowerbound)/(cutoffbound - lowerbound)
4172  * where diving is performed (0.0: no limit)
4173  *
4174  * \par MAXDIVEAVGQUOT
4175  * maximal quotient (curlowerbound - lowerbound)/(avglowerbound - lowerbound)
4176  * where diving is performed (0.0: no limit)
4177  *
4178  * \par MAXDIVEUBQUOTNOSOL
4179  * maximal UBQUOT when no solution was found yet (0.0: no limit)
4180  *
4181  * \par MAXDIVEAVGQUOTNOSOL
4182  * maximal AVGQUOT when no solution was found yet (0.0: no limit)
4183  *
4184  * \par BACKTRACK
4185  * use one level of backtracking if infeasibility is encountered?
4186  *
4187  * \par LPRESOLVEDOMCHGQUOT
4188  * parameter to control LP resolve dynamically based on this percentage of observed bound changes relative to all variables or
4189  * the LP branching candidates (integer variables with fractional solution values) from the last node where an LP has been solved.
4190  * This property has no effect when the LPSOLVEFREQ is set to 1.
4191  *
4192  * \par LPSOLVEFREQ
4193  * LP solve frequency for diveset, use a positive integer k to solve an LP at every k'th depth of the diving search (ie. 1 causes the
4194  * diveset to solve _all_ intermediate LPs) or 0 to only resolve the LP relaxation after propagation found at least a certain percentage
4195  * domain changes, see also the previous LPRESOLVEDOMCHGQUOT parameter.
4196  *
4197  * \par ONLYLPBRANCHCANDS
4198  * Set this property to TRUE if only LP branching candidates be considered for the execution of the diving algorithm instead of the slower but
4199  * more general constraint handler diving variable selection.
4200  *
4201  * \par DIVETYPES
4202  * bit mask that represents all supported dive types. Irrelevant if only LP branching candidates should be scored, otherwise, different
4203  * constraint handlers may ask the diveset if it supports their preferred divetype. See \ref type_heur.h for a list of
4204  * available dive types.
4205  *
4206  * @section DIVING_FUNDAMENTALCALLBACKS Fundamental callbacks of a diveset
4207  *
4208  * Only one callback is necessary to complete a diveset to guide the diving search performed:
4209  *
4210  * @subsection DIVESETGETSCORE
4211  *
4212  * The scoring callback expects a candidate variable and calculates a score value and a preferred direction. The selected
4213  * variable for diving will be one that _maximizes_ the score function provided by the diveset.
4214  * If the diveset should support more than one possible type of diving, it may use the divetype argument as a hint how
4215  * the caller of the score function (could be the diving algorithm itself or one of the constraint handlers that
4216  * implement diving variable selection) intends to perform the search.
4217  *
4218  * @section DIVING_FURTHERINFO Further information
4219  *
4220  * This is all there is to extend the SCIP set of diving heuristics by a new one. For further information, please see
4221  * diveset related methods in \ref type_heur.h, \ref pub_heur.h, \ref pub_dive.h, and \ref heur_guideddiving.h or
4222  * other diving heuristics that implement diving through a diveset.
4223  */
4224 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
4225 
4226 /**@page RELAX How to add relaxation handlers
4227  *
4228  * SCIP provides specific support for LP relaxations of constraint integer programs. In addition, relaxation handlers,
4229  * also called relaxators, can be used to include other relaxations, e.g. Lagrange relaxations or semidefinite
4230  * relaxations. The relaxation handler manages the necessary data structures and calls the relaxation solver to generate dual
4231  * bounds and primal solution candidates.
4232  * \n
4233  * However, the data to define a single relaxation must either be extracted by the relaxation handler itself (e.g., from
4234  * the user defined problem data, the LP information, or the integrality conditions), or be provided by the constraint
4235  * handlers. In the latter case, the constraint handlers have to be extended to support this specific relaxation.
4236  * \n
4237  *
4238  * We now explain how users can add their own relaxation handlers using the C interface. It is very easy to
4239  * transfer the C explanation to C++: whenever a method should be implemented using the SCIP_DECL_RELAX... notion,
4240  * reimplement the corresponding virtual member function of the abstract scip::ObjRelax wrapper base class.
4241  * Unfortunately, SCIP does not contain a default relaxation handler plugin, which could be used as an example.
4242  *
4243  * Additional documentation for the callback methods of a relaxation handler can be found in the file type_relax.h.
4244  *
4245  * Here is what you have to do to implement a relaxation handler:
4246  * -# Copy the template files src/scip/relax_xyz.c and src/scip/relax_xyz.h into files named "relax_myrelaxator.c"
4247  * and "relax_myrelaxator.h".
4248  * \n
4249  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
4250  * -# Use SCIPincludeRelaxMyrelaxator() in order to include the relaxation handler into your SCIP instance,
4251  * e.g, in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
4252  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "myrelaxator".
4253  * -# Adjust the properties of the relaxation handler (see \ref RELAX_PROPERTIES).
4254  * -# Define the relaxation handler data (see \ref RELAX_DATA). This is optional.
4255  * -# Implement the interface methods (see \ref RELAX_INTERFACE).
4256  * -# Implement the fundamental callback methods (see \ref RELAX_FUNDAMENTALCALLBACKS).
4257  * -# Implement the additional callback methods (see \ref RELAX_ADDITIONALCALLBACKS). This is optional.
4258  *
4259  *
4260  * @section RELAX_PROPERTIES Properties of a Relaxation Handler
4261  *
4262  * At the top of the new file "relax_myrelaxator.c" you can find the relaxation handler properties.
4263  * These are given as compiler defines.
4264  * In the C++ wrapper class, you have to provide the relaxation handler properties by calling the constructor
4265  * of the abstract base class scip::ObjRelax from within your constructor.
4266  * The properties you have to set have the following meaning:
4267  *
4268  * \par RELAX_NAME: the name of the relaxation handler.
4269  * This name is used in the interactive shell to address the relaxation handler.
4270  * Additionally, if you are searching for a relaxation handler with SCIPfindRelax(), this name is looked up.
4271  * Names have to be unique: no two relaxation handlers may have the same name.
4272  *
4273  * \par RELAX_DESC: the description of the relaxation handler.
4274  * This string is printed as a description of the relaxation handler in the interactive shell.
4275  *
4276  * \par RELAX_PRIORITY: the priority of the relaxation handler.
4277  * During each relaxation solving round, the included relaxation handlers and the
4278  * price-and-cut loop for solving the LP relaxation are called in a predefined order, which is given by the priorities
4279  * of the relaxation handlers.
4280  * First, the relaxation handlers with non-negative priority are called in the order of decreasing priority.
4281  * Next, the price-and-cut loop for solving the LP relaxation is executed.
4282  * Finally, the relaxation handlers with negative priority are called in the order of decreasing priority.
4283  * \n
4284  * Usually, you will have only one relaxation handler in your application and thus only have to decide whether it should
4285  * be called before or after solving the LP relaxation. For this decision you should consider the complexity of
4286  * the relaxation solving algorithm and the impact of the resulting solution: if your relaxation handler provides a fast
4287  * algorithm that usually has a high impact (i.e. the relaxation is a good approximation of the
4288  * feasible region of the subproblem and the solution severely improves the dual bound), it should have a non-negative
4289  * priority.
4290  * \n
4291  * Note that for certain applications, it is useful to disable the LP relaxation and only use your custom relaxation.
4292  * This can easily be achieved by setting the "lp/solvefreq" parameter to -1.
4293  *
4294  * \par RELAX_FREQ: the default frequency for solving the relaxation.
4295  * The frequency defines the depth levels at which the relaxation solving method \ref RELAXEXEC is called.
4296  * For example, a frequency of 7 means, that the relaxation solving callback is executed for subproblems that are in depth
4297  * 0, 7, 14, ... of the branching tree. A frequency of 0 means that the callback is only executed at the root node, i.e.,
4298  * only the relaxation of the root problem is solved. A frequency of -1 disables the relaxation handler.
4299  *
4300  *
4301  * @section RELAX_DATA Relaxation Handler Data
4302  *
4303  * Below the header "Data structures" you can find a struct which is called "struct SCIP_RelaxData".
4304  * In this data structure, you can store the data of your relaxation handler. For example, you should store the adjustable
4305  * parameters of the relaxation handler in this data structure.
4306  * If you are using C++, you can add relaxation handler data as usual as object variables to your class.
4307  * \n
4308  * Defining relaxation handler data is optional. You can leave the struct empty.
4309  *
4310  *
4311  * @section RELAX_INTERFACE Interface Methods
4312  *
4313  * At the bottom of "relax_myrelaxator.c", you can find the interface method SCIPincludeRelaxMyrelaxator(),
4314  * which also appears in "relax_myrelaxator.h".
4315  * SCIPincludeRelaxMyrelaxator() is called by the user, if (s)he wants to include the relaxation handler,
4316  * i.e., if (s)he wants to use the relaxation handler in his/her application.
4317  *
4318  * This method only has to be adjusted slightly.
4319  * It is responsible for notifying SCIP of the presence of the relaxation handler. For this, you can either call
4320  * SCIPincludeRelax(),
4321  * or SCIPincludeRelaxBasic() since SCIP version 3.0. In the latter variant, \ref RELAX_ADDITIONALCALLBACKS "additional callbacks"
4322  * must be added via setter functions as, e.g., SCIPsetRelaxCopy(). We recommend this latter variant because
4323  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
4324  * variant must be manually adjusted with every SCIP release containing new callbacks for relaxation handlers in order to compile.
4325  *
4326  * If you are using relaxation handler data, you have to allocate the memory for the data at this point.
4327  * You can do this by calling:
4328  * \code
4329  * SCIP_CALL( SCIPallocMemory(scip, &relaxdata) );
4330  * \endcode
4331  * You also have to initialize the fields in struct SCIP_RelaxData afterwards.
4332  *
4333  * You may also add user parameters for your relaxation handler, see the method SCIPincludeConshdlrKnapsack() in
4334  * the \ref cons_knapsack.h "knapsack constraint handler" for an example of how to add user parameters.
4335  *
4336  *
4337  * @section RELAX_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Relaxation Handler
4338  *
4339  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
4340  * an operational algorithm.
4341  * They are passed together with the relaxation handler itself to SCIP using SCIPincludeRelax() or SCIPincludeRelaxBasic(),
4342  * see @ref RELAX_INTERFACE.
4343  *
4344  *
4345  * Relaxation handler plugins have only one fundamental callback method, namely the \ref RELAXEXEC method.
4346  * This method has to be implemented for every relaxation handler; the other callback methods are optional.
4347  * In the C++ wrapper class scip::ObjRelax, the scip_exec() method (which corresponds to the \ref RELAXEXEC callback) is a virtual
4348  * abstract member function.
4349  * You have to implement it in order to be able to construct an object of your relaxation handler class.
4350  *
4351  * Additional documentation for the callback methods can be found in type_relax.h.
4352  *
4353  * @subsection RELAXEXEC
4354  * The RELAXEXEC is called in each relaxation solving round. It should solve the current
4355  * subproblem's relaxation.
4356  *
4357  * Note that, like the LP relaxation, the relaxation handler should only operate on variables for which the corresponding
4358  * column exists in the transformed problem. Typical methods called by a relaxation handler are SCIPconstructLP() and SCIPflushLP() to
4359  * make sure that the LP of the current node is constructed and its data can be accessed via calls to SCIPgetLPRowsData()
4360  * and SCIPgetLPColsData(), SCIPseparateSol() to call the cutting plane separators for a given primal solution, and
4361  * SCIPupdateLocalLowerbound() to update the current node's dual bound after having solved the relaxation.
4362  * In addition, you may want to call SCIPtrySolFree() if you think that you have found a feasible primal solution.
4363  *
4364  * The primal solution of the relaxation can be stored inside the data structures of SCIP with
4365  * <code>SCIPsetRelaxSolVal()</code> and <code>SCIPsetRelaxSolVals()</code> and later accessed by
4366  * <code>SCIPgetRelaxSolVal()</code>.
4367  * Furthermore, there is a list of external branching candidates, that can be filled by relaxation handlers and constraint handlers,
4368  * allowing branching rules to take these candidates as a guide on how to split the problem into subproblems.
4369  * Relaxation handlers should store appropriate candidates in this list using the method <code>SCIPaddExternBranchCand()</code>.
4370  *
4371  * Usually, the RELAXEXEC callback only solves the relaxation and provides a lower (dual) bound with a call to
4372  * SCIPupdateLocalLowerbound().
4373  * However, it may also produce domain reductions, add additional constraints or generate cutting planes. It has the
4374  * following options:
4375  * - detecting that the node is infeasible in the variable's bounds and can be cut off (result SCIP_CUTOFF)
4376  * - adding an additional constraint and stating that the relaxation handler should not be called again on the same
4377  * relaxation (result SCIP_CONSADDED)
4378  * - reducing a variable's domain and stating that the relaxation handler should not be called again on the same
4379  * relaxation (result SCIP_REDUCEDDOM)
4380  * - adding a cutting plane to the LP and stating that the relaxation handler should not be called again on the same
4381  * relaxation (result SCIP_SEPARATED)
4382  * - stating that the relaxation handler solved the relaxation and should not be called again on the same relaxation
4383  * (result SCIP_SUCCESS)
4384  * - interrupting the solving process to wait for additional input, e.g., cutting planes (result SCIP_SUSPENDED)
4385  * - stating that the separator was skipped (result SCIP_DIDNOTRUN).
4386  *
4387  * In the above criteria, "the same relaxation" means that the LP relaxation stayed unmodified. This means in particular
4388  * that no row has been added and no bounds have been modified. For example, changing the bounds of a variable will, as
4389  * long as it was a COLUMN variable, lead to a modification in the LP such that the relaxation handler is called again
4390  * after it returned with the result code SCIP_REDUCEDDOM.
4391  *
4392  *
4393  * @section RELAX_ADDITIONALCALLBACKS Additional Callback Methods of a Relaxation Handler
4394  *
4395  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
4396  * implemented for most applications, they can be used, for example, to initialize and free private data.
4397  * Additional callbacks can either be passed directly with SCIPincludeRelax() to SCIP or via specific
4398  * <b>setter functions</b> after a call of SCIPincludeRelaxBasic(), see also @ref RELAX_INTERFACE.
4399  *
4400  * @subsection RELAXFREE
4401  *
4402  * If you are using relaxation handler data, you have to implement this method in order to free the relaxation handler
4403  * data. This can be done by the following procedure:
4404  * \code
4405  * static
4406  * SCIP_DECL_RELAXFREE(relaxFreeMyrelaxator)
4407  * {
4408  * SCIP_RELAXDATA* relaxdata;
4409  *
4410  * relaxdata = SCIPrelaxGetData(relax);
4411  * assert(relaxdata != NULL);
4412  *
4413  * SCIPfreeMemory(scip, &relaxdata);
4414  *
4415  * SCIPrelaxSetData(relax, NULL);
4416  *
4417  * return SCIP_OKAY;
4418  * }
4419  * \endcode
4420  * If you have allocated memory for fields in your relaxation handler data, remember to free this memory
4421  * before freeing the relaxation handler data itself.
4422  * If you are using the C++ wrapper class, this method is not available.
4423  * Instead, just use the destructor of your class to free the member variables of your class.
4424  *
4425  * @subsection RELAXINIT
4426  *
4427  * The RELAXINIT callback is executed after the problem is transformed.
4428  * The relaxation handler may, e.g., use this call to initialize its relaxation handler data.
4429  *
4430  * @subsection RELAXCOPY
4431  *
4432  * The RELAXCOPY callback is executed when a SCIP instance is copied, e.g. to
4433  * solve a sub-SCIP. By
4434  * defining this callback as
4435  * <code>NULL</code> the user disables the execution of the specified
4436  * relaxation handler for all copied SCIP instances. This may deteriorate the performance
4437  * of primal heuristics using sub-SCIPs.
4438  *
4439  * @subsection RELAXEXIT
4440  *
4441  * The RELAXEXIT callback is executed before the transformed problem is freed.
4442  * In this method, the relaxation handler should free all resources that have been allocated for the solving process in
4443  * RELAXINIT.
4444  *
4445  * @subsection RELAXINITSOL
4446  *
4447  * The RELAXINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
4448  * begin. The relaxation handler may use this call to initialize its branch-and-bound specific data.
4449  *
4450  * @subsection REALXEXITSOL
4451  *
4452  * The RELAXEXITSOL callback is executed before the branch-and-bound process is freed.
4453  * The relaxation handler should use this call to clean up its branch-and-bound data.
4454  */
4455 
4456 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
4457 /**@page READER How to add file readers
4458  *
4459  * Mainly, file readers are called to parse an input file and generate a constraint integer programming model. They
4460  * create constraints and variables and activate variable pricers if necessary. However, they can also be called, for
4461  * example, to parse an input file containing information about a primal solution or fixing of variables. Besides that
4462  * it is possible to use some of them for writing (exporting) the problem in a specific format. \n A complete list of
4463  * all file readers contained in this release can be found \ref FILEREADERS "here".
4464  *
4465  * Since a file reader is also responsible for writing a file, the user may
4466  * ask why the readers have not the name "filehandler". This name would
4467  * represent this plugin much better than the used one.
4468  * \n
4469  * The used name "readers" is historically grown. In the beginning of SCIP
4470  * there was no need to write/export problems. Therefore, the the plugin
4471  * name "readers" was best fitting for this plugin since only reading was essential.
4472  * It turned out, however, that it is quite nice to write/export certain subproblem during
4473  * the solving process mainly for debugging. Therefore, a writing callback
4474  * was added to the "readers" plugin.
4475  *
4476  * We now explain how users can add their own file readers.
4477  * Take the file reader for MIPs in IBM's Mathematical Programming System format (src/scip/reader_mps.c) as an example.
4478  * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjReader wrapper
4479  * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_READER... callback methods.
4480  *
4481  * Additional documentation for the callback methods of a file reader can be found in the file type_reader.h.
4482  *
4483  * Here is what you have to do to implement a file reader named "myreader" in C:
4484  * -# Copy the template files src/scip/reader_xyz.c and src/scip/reader_xyz.h into files named
4485  * "reader_myreader.c" and "reader_myreader.h".
4486  * \n
4487  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
4488  * -# Use SCIPincludeReaderMyreader() in order to include the file reader into your SCIP instance,
4489  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
4490  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "myreader".
4491  * -# Adjust the \ref READER_PROPERTIES "properties of the file reader".
4492  * -# Define the \ref READER_DATA "file reader data". This is optional.
4493  * -# Implement the \ref READER_INTERFACE "interface methods".
4494  * -# Implement the \ref READER_FUNDAMENTALCALLBACKS "fundamental callback methods".
4495  * -# Implement the \ref READER_ADDITIONALCALLBACKS "additional callback methods". This is optional.
4496  *
4497  *
4498  * @section READER_PROPERTIES Properties of a File Reader
4499  *
4500  * At the top of the new file "reader_myreader.c" you can find the file reader properties.
4501  * These are given as compiler defines.
4502  * In the C++ wrapper class, you have to provide the file reader properties by calling the constructor
4503  * of the abstract base class scip::ObjReader from within your constructor.
4504  * The properties you have to set have the following meaning:
4505  *
4506  * \par READER_NAME: the name of the file reader.
4507  * This name is used in the interactive shell to address the file reader.
4508  * Additionally, if you are searching for a file reader with SCIPfindReader(), this name is looked up.
4509  * Names have to be unique: no two file readers may have the same name.
4510  *
4511  * \par READER_DESC: the description of the file reader.
4512  * This string is printed as a description of the file reader in the interactive shell.
4513  *
4514  * \par READER_EXTENSION: the file name extension of the file reader.
4515  * Each file reader is hooked to a single file name extension. It is automatically called if the user wants to read in a
4516  * file of corresponding name. The extensions of the different file readers have to be unique.
4517  * Note that the additional extension '.gz', '.z', or '.Z' (indicating a gzip compressed file) are ignored for assigning
4518  * an input file to a reader.
4519  * \n
4520  * It is not possible to hook up a (single) file reader with more than one file extension.
4521  * It is, however, not necessary to implement the same (parsing/writing) methods more than once, if you want to
4522  * support several file extension with the same parser. To do so look at the files reader_lp.c
4523  * and reader_rlp.c. Both support the LP format.
4524  *
4525  *
4526  * @section READER_DATA File Reader Data
4527  *
4528  * Below the header "Data structures" you can find a struct which is called "struct SCIP_ReaderData".
4529  * In this data structure, you can store the data of your file reader. For example, you should store the adjustable
4530  * parameters of the file reader in this data structure.
4531  * If you are using C++, you can add file reader data as usual as object variables to your class.
4532  * \n
4533  * Defining file reader data is optional. You can leave the struct empty.
4534  *
4535  *
4536  * @section READER_INTERFACE Interface Methods
4537  *
4538  * At the bottom of "reader_myreader.c", you can find the interface method SCIPincludeReaderMyreader(),
4539  * which also appears in "reader_myreader.h".
4540  * SCIPincludeReaderMyreader() is called by the user, if (s)he wants to include the reader,
4541  * i.e., if (s)he wants to use the reader in his/her application.
4542  *
4543  * This method only has to be adjusted slightly.
4544  * It is responsible for notifying SCIP of the presence of the reader. For this, you can either call
4545  * SCIPincludeReader(),
4546  * or SCIPincludeReaderBasic() since SCIP version 3.0. In the latter variant, \ref READER_ADDITIONALCALLBACKS "additional callbacks"
4547  * must be added via setter functions as, e.g., SCIPsetReaderCopy(). We recommend this latter variant because
4548  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
4549  * variant must be manually adjusted with every SCIP release containing new callbacks for readers in order to compile.
4550  *
4551  * If you are using file reader data, you have to allocate the memory for the data at this point.
4552  * You can do this by calling:
4553  * \code
4554  * SCIP_CALL( SCIPallocMemory(scip, &readerdata) );
4555  * \endcode
4556  * You also have to initialize the fields in struct SCIP_ReaderData afterwards.
4557  *
4558  * You may also add user parameters for your file reader, see the method SCIPincludeReaderLp() in
4559  * src/scip/reader_lp.c for an example.
4560  *
4561  *
4562  * @section READER_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a File Reader
4563  *
4564  * File reader plugins have no fundamental callback methods. This is due to
4565  * the fact that a file reader can be used for reading and/or writing a
4566  * file. A file reader is only useful if the reader method \ref READERREAD
4567  * and/or the writing method \ref READERWRITE is implemented. One of these
4568  * methods should be implemented for every file reader; the other callback
4569  * methods \ref READERCOPY and \ref READERFREE are optional. In the C++ wrapper class scip::ObjReader, the
4570  * scip_read() and scip_write() methods (which corresponds to the \ref
4571  * READERREAD and \ref READERWRITE callback) are virtual member
4572  * functions. At least one of them should be implemented.
4573  *
4574  * Additional documentation for the callback methods can be found in type_reader.h.
4575  *
4576  *
4577  * @section READER_ADDITIONALCALLBACKS Additional Callback Methods of a File Reader
4578  *
4579  * Additional callbacks can either be passed directly with SCIPincludeReader() to SCIP or via specific
4580  * <b>setter functions</b> after a call of SCIPincludeReaderBasic(), see also @ref READER_INTERFACE.
4581  *
4582  *
4583  * File reader plugins contain only additional callback methods, namely the methods \ref READERREAD,
4584  * \ref READERWRITE, \ref READERFREE, and \ref READERCOPY. Therefore, these are not needed to be implemented. However,
4585  * at least \ref READERREAD and/or \ref READERWRITE should be implemented (see notes
4586  * \ref READER_FUNDAMENTALCALLBACKS "above").
4587  *
4588  *
4589  * @subsection READERREAD
4590  *
4591  * The READERREAD callback is called when the user invokes SCIP to read in a file with file name extension
4592  * corresponding to the READER_EXTENSION property of the file reader. This is usually triggered by a call to the method
4593  * SCIPreadProb() or by an interactive shell command.
4594  * The READERREAD callback should parse the input file and perform the desired action, which usually means
4595  * generating a constraint integer programming model, adding a primal solution, fixing variables
4596  * in an existing model.
4597  * \n
4598  * Typical methods called by a file reader that is used to read/generate constraint
4599  * integer programming models are, for example,
4600  *
4601  * - creating an empty problem: SCIPcreateProb()
4602  * - creating the variables: SCIPcreateVar(), SCIPchgVarType(), SCIPchgVarLb(), SCIPchgVarUb(), SCIPaddVar(), and
4603  * SCIPreleaseVar()
4604  * - modifying the objective function: SCIPchgVarObj() and SCIPsetObjsense().
4605  * - creating the constraints: SCIPcreateConsLinear(), SCIPaddCoefLinear(), SCIPchgLhsLinear(), SCIPchgRhsLinear(),
4606  * SCIPaddCons(), and SCIPreleaseCons()
4607  *
4608  * Primal solutions can only be created for the transformed problem. Therefore, the user has to call SCIPtransformProb()
4609  * before (s)he reads in the file containing the solution and adds it to the solution pool via the method SCIPreadSol().
4610  *
4611  *
4612  * @subsection READERWRITE
4613  *
4614  * The READERWRITE callback is called when the user invokes SCIP to write a problem (original or transformed)
4615  * in the format the reader supports. This is only possible if this callback is implemented. To write the problem
4616  * all necessary information is given through the parameters of this callback method (see type_reader.h). This
4617  * information should be used to output the problem in the requested format. This callback method is usually
4618  * triggered by the call of the methods SCIPwriteOrigProblem(), SCIPwriteTransProblem(), SCIPprintOrigProblem(),
4619  * or SCIPprintTransProblem().
4620  * \n
4621  * A typical method called by a file reader which is used to write/export a constraint
4622  * integer programming model is SCIPinfoMessage(). This method outputs a given string into a file
4623  * or into stdout.
4624  * \n
4625  * For an example we refer to the writing method of the MPS reader (see reader_mps.c).
4626  *
4627  *
4628  * @subsection READERCOPY
4629  *
4630  * The READERCOPY callback is executed when a SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this
4631  * callback as <code>NULL</code> the user disables the execution of the specified reader for all copied SCIP
4632  * instances. The question might arise why to copy that plugin. In case of debugging it is nice to be able to
4633  * write/display the copied instances. Since the reader is in charge of that, you might want to copy the plugin. Below
4634  * you see a standard implementation.
4635  *
4636  * \code
4637  * static
4638  * SCIP_DECL_READERCOPY(readerCopyMyreader)
4639  * {
4640  * assert(scip != NULL);
4641  * assert(reader != NULL);
4642  * assert(strcmp(SCIPreaderGetName(reader), READER_NAME) == 0);
4643  *
4644  * SCIP_CALL( SCIPincludeReaderMyreader(scip) );
4645  *
4646  * return SCIP_OKAY;
4647  * }
4648  * \endcode
4649  *
4650  * @subsection READERFREE
4651  *
4652  * If you are using file reader data, you have to implement this method in order to free the file reader data.
4653  * This can be done by the following procedure:
4654  * \code
4655  * static
4656  * SCIP_DECL_READERFREE(readerFreeMyreader)
4657  * {
4658  * SCIP_READERDATA* readerdata;
4659  *
4660  * readerdata = SCIPreaderGetData(reader);
4661  * assert(readerdata != NULL);
4662  *
4663  * SCIPfreeMemory(scip, &readerdata);
4664  *
4665  * SCIPreaderSetData(reader, NULL);
4666  *
4667  * return SCIP_OKAY;
4668  * }
4669  * \endcode
4670  * If you have allocated memory for fields in your file reader data, remember to free this memory
4671  * before freeing the file reader data itself.
4672  * If you are using the C++ wrapper class, this method is not available.
4673  * Instead, just use the destructor of your class to free the member variables of your class.
4674  *
4675  */
4676 
4677 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
4678 /**@page DIALOG How to add dialogs
4679  *
4680  * SCIP comes with a command line shell which allows the user to read in problem instances, modify the solver's
4681  * parameters, initiate the optimization and display certain statistics and solution information. This shell consists
4682  * of dialogs, which are organized as a tree in SCIP. A node of this tree which is not a leaf represents a menu in
4683  * the shell and the children of this node correspond to the entries of this menu (which can again be menus). All
4684  * different dialogs are managed by a dialog handler, which, in particular, is responsible for executing the dialog
4685  * corresponding to the user's command in the shell. The concept of a dialog handler is different to that
4686  * of a constraint handler, which is used to manage objects of the same structure, see \ref CONS. In particular, SCIP
4687  * features only one dialog handler (dialog_default.h), whereas there may exist different constraint handlers.
4688  * \n
4689  * A complete list of all dialogs contained in this release can be found \ref DIALOGS "here".
4690  *
4691  * We now explain how users can extend the interactive shell by adding their own dialog.
4692  * We give the explanation for creating your own source file for each additional dialog. Of course, you can collect
4693  * different dialogs in one source file. Take src/scip/dialog_default.c, where all default dialog plugins are collected, as an
4694  * example.
4695  * As all other default plugins, the default dialog plugin and the template dialog are written in C. C++ users can easily
4696  * adapt the code by using the scip::ObjDialog wrapper base class and implement the scip_...() virtual methods instead of the
4697  * SCIP_DECL_DIALOG... callback methods.
4698  *
4699  * Additional documentation for the callback methods of a dialog can be found in the file type_dialog.h.
4700  *
4701  * Here is what you have to do to add a dialog (assuming your dialog is named "mydialog"):
4702  * -# Copy the template files src/scip/dialog_xyz.c and src/scip/dialog_xyz.h into files named "dialog_mydialog.c"
4703  * and "dialog_mydialog.h".
4704  * \n
4705  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
4706  * -# Use SCIPincludeDialogMydialog() in order to include the dialog handler into your SCIP instance,
4707  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
4708  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mydialog".
4709  * -# Adjust the \ref DIALOG_PROPERTIES "properties of the dialog".
4710  * -# Define the \ref DIALOG_DATA "dialog data". This is optional.
4711  * -# Implement the \ref DIALOG_INTERFACE "interface methods".
4712  * -# Implement the \ref DIALOG_FUNDAMENTALCALLBACKS "fundamental callback methods".
4713  * -# Implement the \ref DIALOG_ADDITIONALCALLBACKS "additional callback methods". This is optional.
4714  *
4715  *
4716  * @section DIALOG_PROPERTIES Properties of a Dialog
4717  *
4718  * At the top of the new file "dialog_mydialog.c" you can find the dialog properties.
4719  * These are given as compiler defines.
4720  * In the C++ wrapper class, you have to provide the dialog properties by calling the constructor
4721  * of the abstract base class scip::ObjDialog from within your constructor.
4722  * The properties you have to set have the following meaning:
4723  *
4724  * \par DIALOG_NAME: the name of the dialog.
4725  * In the interactive shell, this name appears as the command name of the dialog in the parent dialog.
4726  * Additionally, if you are searching an entry in a menu with SCIPdialogFindEntry(), this name is looked up.
4727  * Names within one menu have to be unique: no two dialogs in the same menu may have the same name.
4728  *
4729  * \par DIALOG_DESC: the description of the dialog.
4730  * This string is printed as a description of the dialog in the interactive shell if the additional
4731  * callback method \ref DIALOGDESC is not implemented.
4732  *
4733  * \par DIALOG_ISSUBMENU: whether the dialog is a (sub)menu.
4734  * This parameter states whether the dialog is a menu in the interactive shell, i.e., is the parent of further
4735  * dialogs.
4736  *
4737  *
4738  * @section DIALOG_DATA Dialog Data
4739  *
4740  * Below the header "Data structures" you can find a struct which is called "struct SCIP_DialogData".
4741  * In this data structure, you can store the data of your dialog.
4742  * If you are using C++, you can add dialog data as usual as object variables to your class.
4743  * \n
4744  * Defining dialog data is optional. You can leave the struct empty.
4745  *
4746  *
4747  * @section DIALOG_INTERFACE Interface Methods
4748  *
4749  * At the bottom of "dialog_mydialog.c" you can find the interface method SCIPincludeDialogMydialog(), which also appears
4750  * in "dialog_mydialog.h".
4751  * \n
4752  * This method only has to be adjusted slightly.
4753  * It is responsible for notifying SCIP of the presence of the dialog, which can be done by the following lines of code:
4754  * \code
4755  * if( !SCIPdialogHasEntry(parentdialog, DIALOG_NAME) )
4756  * {
4757  * SCIP_CALL( SCIPcreateDialog(scip, &dialog, dialogExecMydialog, dialogDescMydialog, dialogFreeMydialog,
4758  * DIALOG_NAME, DIALOG_DESC, DIALOG_ISSUBMENU, dialogdata) );
4759  *
4760  * SCIP_CALL( SCIPaddDialogEntry(scip, parentdialog, dialog) );
4761  *
4762  * SCIP_CALL( SCIPreleaseDialog(scip, &dialog) );
4763  * }
4764  * \endcode
4765  * Here "parentdialog" has to be an existing dialog which is defined to be a menu (see DIALOG_ISSUBMENU), e.g.,
4766  * the default root dialog. The method SCIPgetRootDialog() returns the root dialog.
4767  *
4768  * 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
4769  * his/her application.
4770  * Note that in order to be able to link the new dialog to an existing default dialog
4771  * (except the root dialog) it has to be included <b>after the
4772  * default dialogs plugin</b>, i.e., the SCIPincludeDialogMydialog() call has to occur after the
4773  * SCIPincludeDialogDefault() call. The SCIPincludeDialogDefault() method is called from within the SCIPincludeDefaultPlugins()
4774  * method. Therefore, it suffices to include your dialog plugins after you have called SCIPincludeDefaultPlugins().
4775  * In case you want to add a dialog to the <b>root dialog</b>, you just use the following
4776  * lines of code to get/create the root dialog.
4777  *
4778  * \code
4779  * SCIP_DIALOG* root;
4780  *
4781  * root = SCIPgetRootDialog(scip);
4782  * if( root == NULL )
4783  * {
4784  * SCIP_CALL( SCIPcreateRootDialog(scip, &root) );
4785  * }
4786  * assert( root != NULL );
4787  * \endcode
4788  *
4789  * Therefore, in this case you do not have to worry about the calls of
4790  * SCIPincludeDialogDefault() and SCIPincludeDefaultPlugins() .
4791  *
4792  * If you are using dialog data, you have to allocate the memory for the data at this point.
4793  * You can do this by calling:
4794  * \code
4795  * SCIP_CALL( SCIPallocMemory(scip, &dialogdata) );
4796  * \endcode
4797  * You also have to initialize the fields in struct SCIP_DialogData afterwards.
4798  *
4799  * Consider the following example. The user wants to add a "drawgraph" command to the root menu of SCIP.
4800  * (S)he copies the "dialog_xyz.c" and "dialog_xyz.h" files into files "dialog_drawgraph.c" and "dialog_drawgraph.h", respectively.
4801  * Then, (s)he puts the following code into the SCIPincludeDialogDrawgraph() method, compare SCIPincludeDialogDefault() in
4802  * src/scip/dialog_default.c:
4803  * \code
4804  * SCIP_RETCODE SCIPincludeDialogDrawgraph(
4805  * SCIP* scip
4806  * )
4807  * {
4808  * SCIP_DIALOG* root;
4809  * SCIP_DIALOG* dialog;
4810  *
4811  * root = SCIPgetRootDialog(scip);
4812  * if( root == NULL )
4813  * {
4814  * SCIP_CALL( SCIPcreateRootDialog(scip, &root) );
4815  * }
4816  * assert( root != NULL );
4817  *
4818  * if( !SCIPdialogHasEntry(root, "drawgraph") )
4819  * {
4820  * SCIP_CALL( SCIPcreateDialog(scip, &dialog, SCIPdialogExecDrawgraph, NULL, NULL,
4821  * "drawgraph", "draws the graph for the current problem instance", FALSE, NULL) );
4822  * SCIP_CALL( SCIPaddDialogEntry(scip, root, dialog) );
4823  * SCIP_CALL( SCIPreleaseDialog(scip, &dialog) );
4824  * }
4825  *
4826  * return SCIP_OKAY;
4827  * }
4828  * \endcode
4829  *
4830  * Using this code, it is even possible to call SCIPincludeDialogDrawgraph() before including the default dialog plugins,
4831  * and you can also call it multiple times without causing inconsistencies in the dialog structure.
4832  *
4833  *
4834  * @section DIALOG_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Dialog
4835  *
4836  * Dialogs have only one fundamental callback method, namely the \ref DIALOGEXEC method.
4837  * This method has to be implemented for every dialog; the other callback methods are optional.
4838  * In the C++ wrapper class scip::ObjDialog, the scip_exec() method (which corresponds to the \ref DIALOGEXEC callback) is a virtual
4839  * abstract member function.
4840  * You have to implement it in order to be able to construct an object of your dialog class.
4841  *
4842  * Additional documentation for the callback methods can be found in type_dialog.h.
4843  *
4844  * @subsection DIALOGEXEC
4845  *
4846  * The DIALOGEXEC method is invoked, if the user selected the dialog's command name in the parent's menu. It should
4847  * execute what is stated in DIALOG_DESC, e.g., the display constraint handlers dialog should display information about
4848  * the constraint handlers included in SCIP, see src/scip/dialog_default.c.
4849  *
4850  * For typical methods called by the execution method, have a look at src/scip/dialog_default.c.
4851  *
4852  * The callback has to return which dialog should be processed next. This can be, for example, the root dialog
4853  * (SCIPdialoghdlrGetRoot()), the parent dialog (SCIPdialogGetParent()) or NULL, which stands for closing the interactive
4854  * shell.
4855  *
4856  *
4857  * @section DIALOG_ADDITIONALCALLBACKS Additional Callback Methods of a Dialog
4858  *
4859  * The additional callback methods do not need to be implemented in every case.
4860  * They can be used, for example, to free private data.
4861  *
4862  * @subsection DIALOGPFREE
4863  *
4864  * If you are using dialog data, you have to implement this method in order to free the dialog data.
4865  * This can be done by the following procedure:
4866  * \code
4867  * static
4868  * SCIP_DECL_DIALOGFREE(dialogFreeMydialog)
4869  * {
4870  * SCIP_DIALOGDATA* dialogdata;
4871  *
4872  * dialogdata = SCIPdialogGetData(dialog);
4873  * assert(dialogdata != NULL);
4874  *
4875  * SCIPfreeMemory(scip, &dialogdata);
4876  *
4877  * SCIPdialogSetData(dialog, NULL);
4878  *
4879  * return SCIP_OKAY;
4880  * }
4881  * \endcode
4882  * If you have allocated memory for fields in your dialog data, remember to free this memory
4883  * before freeing the dialog data itself.
4884  * If you are using the C++ wrapper class, this method is not available.
4885  * Instead, just use the destructor of your class to free the member variables of your class.
4886  *
4887  * @subsection DIALOGDESC
4888  *
4889  * This method is called when the help menu of the parent is displayed. It should output (usually a single line of)
4890  * information describing the meaning of the dialog.
4891  * \n
4892  * If this callback is not implemented, the description string of the dialog (DIALOG_DESC) is displayed instead.
4893  *
4894  * @subsection DIALOGCOPY
4895  *
4896  * The DIALOGCOPY callback is executed when a SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this
4897  * callback as <code>NULL</code> the user disables the execution of this dialog for all copied SCIP instances. In
4898  * general there is no need to copy any dialog since it is most unlikely to start the interactive shell of the copied
4899  * instances.
4900  *
4901  */
4902 
4903 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
4904 /**@page DISP How to add display columns
4905  *
4906  * While solving a constraint integer program, SCIP displays status information in a column-like fashion. The current
4907  * number of processed branching tree nodes, the solving time, and the relative gap between primal and dual bound are
4908  * examples of such display columns. There already exists a wide variety of display columns which can be activated or
4909  * deactivated on demand, see src/scip/disp_default.c. Additionally, the user can implement his/her own display columns
4910  * in order to track problem or algorithm specific values.
4911  * \n
4912  * A complete list of all displays contained in this release can be found \ref DISPLAYS "here".
4913  *
4914  * We now explain users can add their own display columns.
4915  * We give the explanation for creating your own source file for each additional display column. Of course, you can collect
4916  * different additional display columns in one source file.
4917  * Take src/scip/disp_default.c, where all default display columns are collected, as an example.
4918  * As all other default plugins, the default display column plugins and the display column template are written in C.
4919  * C++ users can easily adapt the code by using the scip::ObjDisp wrapper base class and implement the scip_...() virtual methods
4920  * instead of the SCIP_DECL_DISP... callback methods.
4921  *
4922  *
4923  * Additional documentation for the callback methods of a display column can be found in the file type_disp.h.
4924  *
4925  * Here is what you have to do to implement a display column (assuming your display column is named "mydisplaycolumn"):
4926  * -# Copy the template files src/scip/disp_xyz.c and src/scip/disp_xyz.h into files named "disp_mydisplaycolumn.c"
4927  * and "disp_mydisplaycolumn.h".
4928  \n
4929  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
4930  * -# Use SCIPincludeDispMydisplaycolumn() in order to include the display column into your SCIP instance,
4931  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
4932  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mydisplaycolumn".
4933  * -# Adjust the \ref DISP_PROPERTIES "properties of the display column".
4934  * -# Define the \ref DISP_DATA "display column data". This is optional.
4935  * -# Implement the \ref DISP_INTERFACE "interface methods".
4936  * -# Implement the \ref DISP_FUNDAMENTALCALLBACKS "fundamental callback methods".
4937  * -# Implement the \ref DISP_ADDITIONALCALLBACKS "additional callback methods". This is optional.
4938  *
4939  *
4940  * @section DISP_PROPERTIES Properties of a Display Column
4941  *
4942  * At the top of the new file "disp_mydisplaycolumn.c" you can find the display column properties.
4943  * These are given as compiler defines.
4944  * In the C++ wrapper class, you have to provide the display column properties by calling the constructor
4945  * of the abstract base class scip::ObjDisp from within your constructor.
4946  * The properties you have to set have the following meaning:
4947  *
4948  * \par DISP_NAME: the name of the display column.
4949  * This name is used in the interactive shell to address the display column.
4950  * Additionally, if you are searching for a display column with SCIPfindDisp(), this name is looked up.
4951  * Names have to be unique: no two display columns may have the same name.
4952  *
4953  * \par DISP_DESC: the description of the display column.
4954  * This string is printed as a description of the display column in the interactive shell.
4955  *
4956  * \par DISP_HEADER: the header of the display column.
4957  * This string is printed as the header of the display column in the status information display.
4958  *
4959  * \par DISP_WIDTH: the width of the display column.
4960  * This parameter defines the width (number of characters) of the display column. The value of the parameter has to be
4961  * greater than or equal to the number of characters in the header string.
4962  *
4963  * \par DISP_PRIORITY: the priority of the display column.
4964  * The total width of status information lines is bounded by the parameter "display width". The display columns actually contained
4965  * in the status information display are selected in decreasing order of their priority. Furthermore, the user can force
4966  * columns to be displayed or not to be displayed in the status information display. For that, (s)he has to switch the value
4967  * of the display column's parameter "active" from "auto" (its default value) to "on" or "off", respectively.
4968  *
4969  * \par DISP_POSITION: the relative position of the display column.
4970  * In the status information display, the display columns are arranged from left to right in increasing order of their
4971  * relative position.
4972  *
4973  * \par DISP_STRIPLINE: the default for whether the display column should be separated with a line from its right neighbor.
4974  * This parameter states whether the display column should be separated with the string "|" from its right neighbor. In so
4975  * doing, the clearness of the status information display may improve.
4976  *
4977  * @section DISP_DATA Display Column Data
4978  *
4979  * Below the header "Data structures" you can find a struct which is called "struct SCIP_DispData".
4980  * In this data structure, you can store the data of your display column. For example, you should store the adjustable
4981  * parameters of the display column in this data structure.
4982  * If you are using C++, you can add display column data as usual as object variables to your class.
4983  * \n
4984  * Defining display column data is optional. You can leave the struct empty.
4985  *
4986  *
4987  * @section DISP_INTERFACE Interface Methods
4988  *
4989  * At the bottom of "disp_mydisplaycolumn.c" you can find the interface method SCIPincludeDispMydisplaycolumn(), which also
4990  * appears in "disp_mydisplaycolumn.h".
4991  * \n
4992  * This method only has to be adjusted slightly.
4993  * It is responsible for notifying SCIP of the presence of the display column by calling the method
4994  * SCIPincludeDisp().
4995  *
4996  * 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
4997  * application.
4998  *
4999  * If you are using display column data, you have to allocate the memory for the data at this point.
5000  * You can do this by calling:
5001  * \code
5002  * SCIP_CALL( SCIPallocMemory(scip, &dispdata) );
5003  * \endcode
5004  * You also have to initialize the fields in struct SCIP_DispData afterwards.
5005  *
5006  * Although this is very uncommon, you may also add user parameters for your display column, see the method
5007  * SCIPincludeConshdlrKnapsack() in the \ref cons_knapsack.h "knapsack constraint handler" for an example.
5008  *
5009  *
5010  * @section DISP_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Display Column
5011  *
5012  * Display column plugins have only one fundamental callback method, namely the \ref DISPOUTPUT method.
5013  * This method has to be implemented for every display column; the other callback methods are optional.
5014  * In the C++ wrapper class scip::ObjDisp, the scip_output() method (which corresponds to the \ref DISPOUTPUT callback) is a virtual
5015  * abstract member function.
5016  * You have to implement it in order to be able to construct an object of your display column class.
5017  *
5018  * Additional documentation for the callback methods can be found in type_disp.h.
5019  *
5020  * @subsection DISPOUTPUT
5021  *
5022  * The DISPOUTPUT callback is called after each pricing loop during node processing and after a node has been processed.
5023  * In addition, at the root node, the callback is executed after each iteration of the price-and-cut loop.
5024  * It should write the display column information for the current node to a given output file stream.
5025  *
5026  * Typical methods called by a display column are, for example, SCIPdispLongint(), SCIPdispInt(), SCIPdispTime(), and
5027  * SCIPinfoMessage().
5028  *
5029  *
5030  * @section DISP_ADDITIONALCALLBACKS Additional Callback Methods of a Display Column
5031  *
5032  * The additional callback methods do not need to be implemented in every case.
5033  * They can be used, for example, to initialize and free private data.
5034  *
5035  * @subsection DISPCOPY
5036  *
5037  * The DISPCOPY callback is executed when a SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this callback
5038  * as <code>NULL</code> the user disables the execution of the specified column. In general it is probably not needed to
5039  * implement that callback since the output of the copied instance is usually suppressed. In the other case or for
5040  * debugging the callback should be implement.
5041  *
5042  *
5043  * @subsection DISPFREE
5044  *
5045  * If you are using display column data, you have to implement this method in order to free the display column data.
5046  * This can be done by the following procedure:
5047  * \code
5048  * static
5049  * SCIP_DECL_DISPFREE(dispFreeMydisplaycolumn)
5050  * {
5051  * SCIP_DISPDATA* dispdata;
5052  *
5053  * dispdata = SCIPdispGetData(disp);
5054  * assert(dispdata != NULL);
5055  *
5056  * SCIPfreeMemory(scip, &dispdata);
5057  *
5058  * SCIPdispSetData(disp, NULL);
5059  *
5060  * return SCIP_OKAY;
5061  * }
5062  * \endcode
5063  * If you have allocated memory for fields in your display column data, remember to free this memory
5064  * before freeing the display column data itself.
5065  * If you are using the C++ wrapper class, this method is not available.
5066  * Instead, just use the destructor of your class to free the member variables of your class.
5067  *
5068  * @subsection DISPINIT
5069  *
5070  * The DISPINIT callback is executed after the problem is transformed.
5071  * The display column may, e.g., use this call to initialize its display column data.
5072  *
5073  * @subsection DISPEXIT
5074  *
5075  * The DISPEXIT callback is executed before the transformed problem is freed.
5076  * In this method, the display column should free all resources that have been allocated for the solving process in
5077  * \ref DISPINIT.
5078  *
5079  * @subsection DISPINITSOL
5080  *
5081  * The DISPINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
5082  * begin. The display column may use this call to initialize its branch-and-bound specific data.
5083  *
5084  * @subsection DISPEXITSOL
5085  *
5086  * The DISPEXITSOL callback is executed before the branch-and-bound process is freed. The display column should use this
5087  * call to clean up its branch-and-bound data specific data.
5088  */
5089 
5090 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5091 /**@page EVENT How to add event handler
5092  *
5093  * While solving a constraint integer program, SCIP drops thousands of events such as SCIP_EVENTTYPE_VARFIXED (a
5094  * complete list of all events is given in type_event.h). These events can be caught and used to do something after a
5095  * certain event happens. Events can be used to speed up the solution process. For example, the set partitioning
5096  * constraint is only worth propagating if one of the involved variables is fixed. This can be detected by
5097  * catching the event SCIP_EVENTTYPE_VARFIXED. To be able to catch an event it is necessary to write an event handler
5098  * which defines what to do after a certain event was caught.
5099  *
5100  * We now explain how users can add their own event handlers. We give the explanation for creating your own
5101  * source file for each additional event handler. Of course, you can collect different event handlers in one source file
5102  * or you can put the event handler directly into the constraint handler. In a \ref EVENTUSAGE "second step" we discuss
5103  * the usage of an event handler. This means how to catch and drop events. \ref EVENTTYPES "Finally", we give some notes on the existing
5104  * types of events.
5105  *
5106  * Take src/scip/cons_logior.c, where the event handler is directly included into the constraint handler. As all other
5107  * default plugins, the event handlers are written in C. C++ users can easily adapt the code by using the scip::ObjEventhdlr
5108  * wrapper base class and implement the scip_...() virtual methods instead of the SCIP_DECL_EVENT... callback methods.
5109  *
5110  * Additional documentation for the callback methods of an event handler can be found in the file type_event.h. There is
5111  * also an example written in C which deals with an event handler. You find this example in the directory
5112  * "examples/Eventhdlr/". An C++ example can be found within the TSP project (examples/TSP/src/EventhdlrNewSol.cpp).
5113  *
5114  * Here is what you have to do to implement an event handler (assuming your event handler is named "bestsol"):
5115  * -# Copy the template files src/scip/event_xyz.c and src/scip/event_xyz.h into files named "event_bestsol.c"
5116  * and "event_bestsol.h".
5117  \n
5118  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
5119  * -# Use SCIPincludeEventBestsol() in order to include the event handler into your SCIP instance,
5120  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Eventhdlr example).
5121  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "bestsol".
5122  * -# Adjust the \ref EVENTHDLR_PROPERTIES "properties of the event handler".
5123  * -# Implement the \ref EVENT_INTERFACE "interface methods".
5124  * -# Implement the \ref EVENT_FUNDAMENTALCALLBACKS "fundamental callback methods".
5125  * -# Implement the \ref EVENT_ADDITIONALCALLBACKS "additional callback methods". This is optional.
5126  *
5127  *
5128  * @section EVENTHDLR_PROPERTIES Properties of a Event Handler
5129  *
5130  * At the top of the new file "event_bestsol.c" you can find the event handler properties.
5131  * These are given as compiler defines.
5132  * In the C++ wrapper class, you have to provide the event handler properties by calling the constructor
5133  * of the abstract base class scip::ObjEventhdlr from within your constructor.
5134  * The properties you have to set have the following meaning:
5135  *
5136  * \par EVENT_NAME: the name of the event handler.
5137  * This name has to be unique with respect to all other event handlers. If you are searching for an event handler with
5138  * SCIPfindEventhdlr(), this name is looked up.
5139  *
5140  * \par EVENT_DESC: the description of the event handler.
5141  * This string is printed as a description of the event handler.
5142  *
5143  * @section EVENTHDLR_DATA Event Handler Data
5144  *
5145  * Below the header "Data structures" you can find a struct which is called "struct SCIP_EventhdlrData".
5146  * In this data structure, you can store the data of your event handler. For example, you should store the adjustable
5147  * parameters of the event handler in this data structure.
5148  * If you are using C++, you can add event handler data as usual as object variables to your class.
5149  * \n
5150  * Defining event handler data is optional. You can leave the struct empty.
5151  *
5152  *
5153  * @section EVENT_INTERFACE Interface Methods
5154  *
5155  * At the bottom of "event_bestsol.c", you can find the interface method SCIPincludeEventBestsol(),
5156  * which also appears in "event_bestsol.h".
5157  * SCIPincludeEventBestsol() is called by the user, if (s)he wants to include the event handler,
5158  * i.e., if (s)he wants to use the event handler in his/her application.
5159  *
5160  * This method only has to be adjusted slightly.
5161  * It is responsible for notifying SCIP of the presence of the event handler. For this, you can either call
5162  * SCIPincludeEventhdlr(),
5163  * or SCIPincludeEventhdlrBasic() since SCIP version 3.0. In the latter variant, \ref EVENT_ADDITIONALCALLBACKS "additional callbacks"
5164  * must be added via setter functions as, e.g., SCIPsetReaderCopy(). We recommend this latter variant because
5165  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
5166  * variant must be manually adjusted with every SCIP release containing new callbacks for event handlers in order to compile.
5167  *
5168  * If you are using event handler data, you have to allocate the memory for the data at this point.
5169  * You can do this by calling:
5170  * \code
5171  * SCIP_CALL( SCIPallocMemory(scip, &eventhdlrdata) );
5172  * \endcode
5173  * You also have to initialize the fields in struct SCIP_EventhdlrData afterwards.
5174  *
5175  * Although this is very uncommon, you may also add user parameters for your event handler, see the method
5176  * SCIPincludeConshdlrKnapsack() in the \ref cons_knapsack.h "knapsack constraint handler" for an example.
5177  *
5178  *
5179  * @section EVENT_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Event Handler
5180  *
5181  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
5182  * an operational algorithm.
5183  * They are passed together with the event handler itself to SCIP using SCIPincludeEventhdlr() or SCIPincludeEventhdlrBasic(),
5184  * see @ref EVENT_INTERFACE.
5185  *
5186  *
5187  * Event handler plugins have only one fundamental callback method, namely the \ref EVENTEXEC method. This method has
5188  * to be implemented for every event handler; the other callback methods are optional. In the C++ wrapper class
5189  * scip::ObjEventhdlr, the scip_exec() method (which corresponds to the \ref EVENTEXEC callback) is a virtual abstract member
5190  * function. You have to implement it in order to be able to construct an object of your event handler class.
5191  *
5192  * Additional documentation for the callback methods can be found in type_event.h.
5193  *
5194  * @subsection EVENTEXEC
5195  *
5196  * The EVENTEXEC callback is called after the requested event happened. Then the event handler can do some action in
5197  * reaction to the event.
5198  *
5199  * Typical the execution method sets a parameter to TRUE to indicate later in solving process that something happened
5200  * which should be analyzed further. In the \ref cons_knapsack.h "knapsack constraint handler" you find such a typical
5201  * example.
5202  *
5203  * @section EVENT_ADDITIONALCALLBACKS Additional Callback Methods of a Event Handler
5204  *
5205  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
5206  * implemented for most applications, they can be used, for example, to initialize and free private data.
5207  * Additional callbacks can either be passed directly with SCIPincludeEventhdlr() to SCIP or via specific
5208  * <b>setter functions</b> after a call of SCIPincludeEventhdlrBasic(), see also @ref EVENT_INTERFACE.
5209  *
5210  * @subsection EVENTCOPY
5211  *
5212  * The EVENTCOPY callback is executed when a SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this
5213  * callback as <code>NULL</code> the user disables the execution of the specified event handler for all copied SCIP
5214  * instances. Note that in most cases the event handler in the copied instance will be initialize by those objects (such
5215  * as constraint handlers or propagators) which need this event handler (see \ref cons_knapsack.h). In these cases the copy
5216  * callback can be ignored. In case of general events, such as a new best solution being found
5217  * (SCIP_EVENTTYPE_BESTSOLFOUND), you might want to implement that callback. The event handler example which you find
5218  * in the directory "examples/Eventhdlr/" uses that callback.
5219  *
5220  * \code
5221  * static
5222  * SCIP_DECL_EVENTCOPY(eventCopyBestsol)
5223  * {
5224  * assert(scip != NULL);
5225  * assert(eventhdlr != NULL);
5226  * assert(strcmp(SCIPeventhdlrGetName(eventhdlr), EVENTHDLR_NAME) == 0);
5227  *
5228  * SCIP_CALL( SCIPincludeEventHdlrBestsol(scip) );
5229  *
5230  * return SCIP_OKAY;
5231  * }
5232  * \endcode
5233  *
5234  *
5235  * @subsection EVENTFREE
5236  *
5237  * If you are using event handler data, you have to implement this method in order to free the event handler data.
5238  * This can be done by the following procedure:
5239  * \code
5240  * static
5241  * SCIP_DECL_EVENTFREE(eventFreeBestsol)
5242  * {
5243  * SCIP_EVENTHDLRDATA* eventhdlrdata;
5244  *
5245  * eventhdlrdata = SCIPeventhdlrGetData(eventhdlr);
5246  * assert(eventhdlrdata != NULL);
5247  *
5248  * SCIPfreeMemory(scip, &eventhdlrdata);
5249  *
5250  * SCIPeventhdlrSetData(eventhdlr, NULL);
5251  *
5252  * return SCIP_OKAY;
5253  * }
5254  * \endcode
5255  * If you have allocated memory for fields in your event handler data, remember to free this memory
5256  * before freeing the event handler data itself.
5257  * If you are using the C++ wrapper class, this method is not available.
5258  * Instead, just use the destructor of your class to free the member variables of your class.
5259  *
5260  *
5261  * @subsection EVENTINIT
5262  *
5263  * The EVENTINIT callback is executed after the problem is transformed.
5264  * The event handler may, e.g., use this call to initialize its event handler data.
5265  *
5266  * @subsection EVENTEXIT
5267  *
5268  * The EVENTEXIT callback is executed before the transformed problem is freed.
5269  * In this method, the event handler should free all resources that have been allocated for the solving process in
5270  * \ref EVENTINIT.
5271  *
5272  * @subsection EVENTINITSOL
5273  *
5274  * The EVENTINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
5275  * begin. The event handler may use this call to initialize its branch-and-bound specific data.
5276  *
5277  * @subsection EVENTEXITSOL
5278  *
5279  * The EVENTEXITSOL callback is executed before the branch-and-bound process is freed. The event handler should use this
5280  * call to clean up its branch-and-bound data specific data.
5281  *
5282  * @section EVENTUSAGE Catching and Dropping Events
5283  *
5284  * After you have implemented the event handler, you have to tell SCIP for which events this event handler should be
5285  * used. This can be a general events, such as <code>SCIP_EVENTTYPE_BESTSOLFOUND</code>, or a variable event which is the most common
5286  * way.
5287  *
5288  * In case of a general (not variable) event you use the function SCIPcatchEvent() to attach to an event and
5289  * SCIPdropEvent() to release this event later.
5290  *
5291  * \code
5292  * SCIP_CALL( SCIPcatchEvent( scip, SCIP_EVENTTYPE_BESTSOLFOUND, eventhdlr, NULL, NULL) );
5293  * \endcode
5294  *
5295  * \code
5296  * SCIP_CALL( SCIPdropEvent( scip, SCIP_EVENTTYPE_BESTSOLFOUND, eventhdlr, NULL, NULL) );
5297  * \endcode
5298  *
5299  * If you want trigger some variable event, you use the method SCIPcatchVarEvent() to attach the variable event and
5300  * SCIPdropVarEvent() to drop it later.
5301  *
5302  * \code
5303  * SCIP_CALL( SCIPcatchVarEvent( scip, var, SCIP_EVENTTYPE_VARFIXED, eventhdlr, NULL, NULL) );
5304  * \endcode
5305  *
5306  * \code
5307  * SCIP_CALL( SCIPdropVarEvent( scip, var, SCIP_EVENTTYPE_VARFIXED, eventhdlr, NULL, NULL) );
5308  * \endcode
5309  *
5310  * @section EVENTTYPES Event types
5311  *
5312  * All available events are listed in type_event.h. There are atomic events such as <code>SCIP_EVENTTYPE_VARFIXED</code>
5313  * and combined events such as <code>SCIP_EVENTTYPE_VARCHANGED</code>. The events are encoded via bit masks. Each atomic
5314  * event has a unique power of two. This enables combination of the atomic events.
5315  *
5316  * SCIP only throws atomic events. However, an event handler might be interested in bunch of events. Through the
5317  * underlying bit masks it is possible to combine the atomic events. For example, <code>SCIP_EVENTTYPE_VARCHANGED</code>
5318  * is an event which combines the events <code>SCIP_EVENTTYPE_VARFIXED</code>, <code>SCIP_EVENTTYPE_VARUNLOCKED</code>,
5319  * <code>SCIP_EVENTTYPE_OBJCHANGED</code>, <code>SCIP_EVENTTYPE_GBDCHANGED</code>,
5320  * <code>SCIP_EVENTTYPE_DOMCHANGED</code>, and <code>SCIP_EVENTTYPE_IMPLADDED</code>.
5321  *
5322  * \code
5323  * #define SCIP_EVENTTYPE_VARCHANGED (SCIP_EVENTTYPE_VARFIXED | SCIP_EVENTTYPE_VARUNLOCKED | SCIP_EVENTTYPE_OBJCHANGED
5324  * | SCIP_EVENTTYPE_GBDCHANGED | SCIP_EVENTTYPE_DOMCHANGED | SCIP_EVENTTYPE_IMPLADDED)
5325  * \endcode
5326  *
5327  * Depending on the event type, the event offers different information. The methods which can be used to gain
5328  * access to this information are given in pub_event.h.
5329  *
5330  */
5331 
5332 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5333 /**@page NLPI How to add interfaces to nonlinear programming solvers
5334  *
5335  * NLPIs are used to interface a solver for nonlinear programs (NLP).
5336  * It is used, e.g., to solve convex relaxations of the problem or to find locally optimal solutions of
5337  * nonlinear relaxations or subproblems.
5338  * The NLPI has been designed such that it can be used independently from SCIP.
5339  *
5340  * While the NLPI itself corresponds to the solver interface, the NLPIPROBLEM corresponds to the
5341  * (solver specific) representation of a concrete nonlinear program.
5342  * An NLP is specified as a set of indexed variables with variable bounds, an objective function,
5343  * and a set of constraints, where each constraint is specified as a function which is restricted to lie
5344  * between given left and right hand sides (possibly infinite).
5345  * A function consists of a linear, quadratic, and general nonlinear part.
5346  * The linear and quadratic parts are specified via variable indices and coefficients, while the
5347  * general nonlinear part is specified via an expression tree.
5348  * That is, the user of the NLPI does not provide function evaluation callbacks but an algebraic representation of the NLP.
5349  * Interfaces for solvers that require function evaluations can make use of the NLPIORACLE, which
5350  * provides a set of methods to compute functions values, gradients, Jacobians, and Hessians for a given NLP.
5351  * See the interface to Ipopt for an example on how to use the NLPIORACLE.
5352  *
5353  * A complete list of all NLPIs contained in this release can be found \ref NLPIS "here".
5354  *
5355  * We now explain how users can add their own NLP solver interface.
5356  * Take the interface to Ipopt (src/nlpi/nlpi_ipopt.cpp) as an example.
5357  * Unlike most other plugins, it is written in C++.
5358  * Additional documentation for the callback methods of an NLPI, in particular for their input parameters,
5359  * can be found in the file type_nlpi.h.
5360  *
5361  * Here is what you have to do to implement an NLPI:
5362  * -# Copy the template files src/nlpi/nlpi_xyz.c and src/nlpi/nlpi_xyz.h into files named "nlpi_mynlpi.c"
5363  * and "nlpi_mynlpi.h".
5364  * \n
5365  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
5366  * -# Use SCIPcreateNlpSolverMynlpi() in order to include the NLPI into your SCIP instance,
5367  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
5368  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mynlpi".
5369  * -# Adjust the properties of the nlpi (see \ref NLPI_PROPERTIES).
5370  * -# Define the NLPI and NLPIPROBLEM data (see \ref NLPI_DATA).
5371  * -# Implement the interface methods (see \ref NLPI_INTERFACE).
5372  * -# Implement the fundamental callback methods (see \ref NLPI_FUNDAMENTALCALLBACKS).
5373  *
5374  *
5375  * @section NLPI_PROPERTIES Properties of an NLPI
5376  *
5377  * At the top of the new file "nlpi_mynlpi.c", you can find the NLPI properties.
5378  * These are given as compiler defines.
5379  * The properties you have to set have the following meaning:
5380  *
5381  * \par NLPI_NAME: the name of the NLP solver interface.
5382  * This name is used in the interactive shell to address the NLPI.
5383  * Additionally, if you are searching for an NLPI with SCIPfindNLPI(), this name is looked up.
5384  * Names have to be unique: no two NLPIs may have the same name.
5385  *
5386  * \par NLPI_DESC: the description of the NLPI.
5387  * This string is printed as a description of the NLPI in the interactive shell.
5388  *
5389  * \par NLPI_PRIORITY: the priority of the NLPI.
5390  * If an NLP has to be solved, an NLP solver has to be selected.
5391  * By default, the solver with the NLPI with highest priority is selected.
5392  * The priority of an NLPI should be set according to performance of the solver:
5393  * solvers that provide fast algorithms that are usually successful on a wide range of problems should have a high priority.
5394  * An easy way to list the priorities of all NLPIs is to type "display nlpis" in the interactive shell of SCIP.
5395  *
5396  * @section NLPI_DATA NLPI Data
5397  *
5398  * Below the header "Data structures" you can find structs which are called "struct SCIP_NlpiData" and "struct SCIP_NlpiProblem".
5399  * In this data structure, you can store the data of your solver interface and of a specific NLP problem.
5400  * For example, you could store a pointer to the block memory data structure in the SCIP_NlpiData data structure
5401  * and store a pointer to an NLPIoracle in the SCIP_NlpiProblem data structure.
5402  *
5403  * @section NLPI_INTERFACE Interface Methods
5404  *
5405  * At the bottom of "nlpi_mynlpi.c", you can find the interface method SCIPcreateNlpSolverXyz(),
5406  * which also appears in "nlpi_mynlpi.h".
5407  * \n
5408  * This method only has to be adjusted slightly.
5409  * It is responsible for creating an NLPI that contains all properties and callback methods of your
5410  * solver interface by calling the method SCIPnlpiCreate().
5411  * SCIPcreateNlpSolverXyz() is called by the user (e.g., SCIP), if (s)he wants to use this solver interface in his/her application.
5412  *
5413  * If you are using NLPI data, you have to allocate the memory for the data at this point.
5414  * You can do this by calling:
5415  * \code
5416  * SCIP_CALL( SCIPallocMemory(scip, &nlpidata) );
5417  * \endcode
5418  * You also have to initialize the fields in struct SCIP_NlpiData afterwards. For freeing the
5419  * NLPI data, see \ref NLPIFREE.
5420  *
5421  *
5422  * @section NLPI_FUNDAMENTALCALLBACKS Fundamental Callback Methods of an NLPI
5423  *
5424  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
5425  * an operational algorithm. Currently, all NLPI callbacks are fundamental.
5426  *
5427  * Additional documentation of the callback methods, in particular to their input parameters,
5428  * can be found in type_nlpi.h.
5429  *
5430  * @subsection NLPICOPY
5431  *
5432  * The NLPICOPY callback is executed if the plugin should be copied, e.g., when a SCIP instance is copied.
5433  *
5434  * @subsection NLPIFREE
5435  *
5436  * The NLPIFREE callback is executed if the NLP solver interface data structure should be freed, e.g., when a SCIP instance is freed.
5437  *
5438  * @subsection NLPIGETSOLVERPOINTER
5439  *
5440  * The NLPIGETSOLVERPOINTER callback can be used to pass a pointer to a solver specific data structure to the user.
5441  *
5442  * @subsection NLPICREATEPROBLEM
5443  *
5444  * The NLPICREATEPROBLEM callback is executed if a particular NLP problem is to be created.
5445  * The callback method should initialize a SCIP_NlpiProblem struct here that corresponds to an empty NLP.
5446  *
5447  * @subsection NLPIFREEPROBLEM
5448  *
5449  * The NLPIFREEPROBLEMPOINTER callback is executed if a particular NLP problem is to be freed.
5450  * The callback method should free a SCIP_NlpiProblem struct here.
5451  *
5452  * @subsection NLPIGETPROBLEMPOINTER
5453  *
5454  * The NLPIGETPROBLEMPOINTER callback can be used to pass a pointer to a solver specific data structure of the NLP to the user.
5455  *
5456  * @subsection NLPIADDVARS
5457  *
5458  * The NLPIADDVARS callback is executed if a set of variables with lower and upper bounds and names should be added to a particular NLP.
5459  * The callback method must add the new variables behind the previously added variables, if any.
5460  * If NULL is given for the lower bounds arguments, -infinity is assumed as lower bound for each new variable.
5461  * If NULL is given for the upper bounds arguments, +infinity is assumed as upper bound for each new variable.
5462  * It is also permitted to use NULL for the names argument.
5463  *
5464  * @subsection NLPIADDCONSTRAINTS
5465  *
5466  * The NLPIADDCONSTRAINTS callback is executed if a set of constraints should be added to a particular NLP.
5467  * Constraints are specified by providing left and right hand sides, linear and quadratic coefficients, expression trees, and constraint names.
5468  * All of these arguments are optional, giving NULL for left hand sides corresponds to -infinity, giving NULL for right hand sides corresponds to +infinity.
5469  *
5470  * @subsection NLPISETOBJECTIVE
5471  *
5472  * The NLPISETOBJECTIVE callback is executed to set the objective function of a particular NLP.
5473  *
5474  * @subsection NLPICHGVARBOUNDS
5475  *
5476  * The NLPICHGVARBOUNDS callback is executed to change the bounds on a set of variables of an NLP.
5477  *
5478  * @subsection NLPICHGCONSSIDES
5479  *
5480  * The NLPICHGCONSSIDES callback is executed to change the sides on a set of constraints of an NLP.
5481  *
5482  * @subsection NLPIDELVARSET
5483  *
5484  * The NLPIDELVARSET callback is executed to delete a set of variables from an NLP.
5485  * The caller provides an array in which for each variable it is marked whether it should be deleted.
5486  * In the same array, the method should return the new position of each variable in the NLP, or -1 if it was deleted.
5487  *
5488  * @subsection NLPIDELCONSSET
5489  *
5490  * The NLPIDELCONSSET callback is executed to delete a set of constraints from an NLP.
5491  * The caller provides an array in which for each constraint it is marked whether it should be deleted.
5492  * In the same array, the method should return the new position of each constraint in the NLP, or -1 if it was deleted.
5493  *
5494  * @subsection NLPICHGLINEARCOEFS
5495  *
5496  * The NLPICHGLINEARCOEFS callback is executed to change the coefficients in the linear part of the objective function or a constraint of an NLP.
5497  *
5498  * @subsection NLPICHGQUADCOEFS
5499  *
5500  * The NLPICHGQUADCOEFS callback is executed to change the coefficients in the quadratic part of the objective function or a constraint of an NLP.
5501  *
5502  * @subsection NLPICHGEXPRTREE
5503  *
5504  * The NLPICHGEXPRTREE callback is executed to replace the expression tree of the objective function or a constraint of an NLP.
5505  *
5506  * @subsection NLPICHGNONLINCOEF
5507  *
5508  * 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.
5509  *
5510  * @subsection NLPICHGOBJCONSTANT
5511  *
5512  * The NLPICHGOBJCONSTANT callback is executed to change the constant offset of the objective function of an NLP.
5513  *
5514  * @subsection NLPISETINITIALGUESS
5515  *
5516  * The NLPISETINITIALGUESS callback is executed to provide primal and dual initial values for the variables and constraints of an NLP.
5517  * For a local solver, these values can be used as a starting point for the search.
5518  * 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).
5519  * In this case, the solver should clear previously set starting values and setup its own starting point.
5520  *
5521  * @subsection NLPISOLVE
5522  *
5523  * The NLPISOLVE callback is executed when an NLP should be solved.
5524  * The solver may use the initial guess provided by \ref NLPISETINITIALGUESS as starting point.
5525  * The status of the solving process and solution can be requested by
5526  * \ref NLPIGETSOLSTAT, \ref NLPIGETTERMSTAT, \ref NLPIGETSOLUTION, and \ref NLPIGETSTATISTICS.
5527  *
5528  * @subsection NLPIGETSOLSTAT
5529  *
5530  * The NLPIGETSOLSTAT callback can be used to request the solution status (solved, infeasible, ...) after an NLP has been solved.
5531  *
5532  * @subsection NLPIGETTERMSTAT
5533  *
5534  * The NLPIGETTERMSTAT callback can be used to request the termination reason (normal, iteration limit, ...) after an NLP has been solved.
5535  *
5536  * @subsection NLPIGETSOLUTION
5537  *
5538  * The NLPIGETSOLUTION callback can be used to request the primal and dual solution values after an NLP solve.
5539  * The method should pass pointers to arrays of variable values to the caller.
5540  * 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.
5541  *
5542  * @subsection NLPIGETSTATISTICS
5543  *
5544  * The NLPIGETSTATISTICS callback can be used to request the statistical values (number of iterations, time, ...) after an NLP solve.
5545  * The method should fill the provided NLPSTATISTICS data structure.
5546  *
5547  * <!-- NLPIGETWARMSTARTSIZE, NLPIGETWARMSTARTMEMO, NLPISETWARMSTARTMEMO are not documented,
5548  since they are currently not used, not implemented, and likely to change with a next version. -->
5549  *
5550  * @subsection NLPIGETINTPAR
5551  *
5552  * The NLPIGETINTPAR callback can be used to request the value of an integer valued NLP parameter.
5553  *
5554  * @subsection NLPISETINTPAR
5555  *
5556  * The NLPISETINTPAR callback is executed to set the value of an integer valued NLP parameter.
5557  *
5558  * @subsection NLPIGETREALPAR
5559  *
5560  * The NLPIGETREALPAR callback can be used to request the value of a real valued NLP parameter.
5561  *
5562  * @subsection NLPISETREALPAR
5563  *
5564  * The NLPISETREALPAR callback is executed to set the value of a real valued NLP parameter.
5565  *
5566  * @subsection NLPIGETSTRINGPAR
5567  *
5568  * The NLPIGETSTRINGPAR callback can be used to request the value of a string valued NLP parameter.
5569  *
5570  * @subsection NLPISETSTRINGPAR
5571  *
5572  * The NLPISETSTRINGPAR callback is executed to set the value of a string valued NLP parameter.
5573  */
5574 
5575 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5576 /**@page EXPRINT How to add interfaces to expression interpreters
5577  *
5578  * An expression interpreter is a tool to compute point-wise and interval-wise the function values, gradients, and
5579  * derivatives of algebraic expressions which are given in the form of an expression tree.
5580  * It is used, e.g., by an NLP solver interface to compute Jacobians and Hessians for the solver.
5581  *
5582  * The expression interpreter interface in SCIP has been implemented similar to those of the LP solver interface (LPI).
5583  * For one binary, exactly one expression interpreter has to be linked.
5584  * The expression interpreter API has been designed such that it can be used independently from SCIP.
5585  *
5586  * A complete list of all expression interpreters contained in this release can be found \ref EXPRINTS "here".
5587  *
5588  * We now explain how users can add their own expression interpreters.
5589  * Take the interface to CppAD (\ref exprinterpret_cppad.cpp) as an example.
5590  * Unlike most other plugins, it is written in C++.
5591  *
5592  * Additional documentation for the callback methods of an expression interpreter, in particular for their input parameters,
5593  * can be found in the file \ref exprinterpret.h
5594  *
5595  * Note that the expression interpreter API has <b>BETA status</b> and thus may change in the next version.
5596  *
5597  * Here is what you have to do to implement an expression interpreter:
5598  * -# Copy the file \ref exprinterpret_none.c into a file named "exprinterpreti_myexprinterpret.c".
5599  * \n
5600  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
5601  * -# Open the new files with a text editor.
5602  * -# Define the expression interpreter data (see \ref EXPRINT_DATA).
5603  * -# Implement the interface methods (see \ref EXPRINT_INTERFACE).
5604  *
5605  *
5606  * @section EXPRINT_DATA Expression Interpreter Data
5607  *
5608  * In "struct SCIP_ExprInt", you can store the general data of your expression interpreter.
5609  * For example, you could store a pointer to the block memory data structure.
5610  *
5611  * @section EXPRINT_INTERFACE Interface Methods
5612  *
5613  * The expression interpreter has to implement a set of interface method.
5614  * In your "exprinterpret_myexprinterpret.c", these methods are mostly dummy methods that return error codes.
5615  *
5616  * @subsection SCIPexprintGetName
5617  *
5618  * The SCIPexprintGetName method should return the name of the expression interpreter.
5619  *
5620  * @subsection SCIPexprintGetDesc
5621  *
5622  * The SCIPexprintGetDesc method should return a short description of the expression interpreter, e.g., the name of the developer of the code.
5623  *
5624  * @subsection SCIPexprintGetCapability
5625  *
5626  * The SCIPexprintGetCapability method should return a bitmask that indicates the capabilities of the expression interpreter,
5627  * i.e., whether it can evaluate gradients, Hessians, or do interval arithmetic.
5628  *
5629  * @subsection SCIPexprintCreate
5630  *
5631  * The SCIPexprintCreate method is called to create an expression interpreter data structure.
5632  * The method should initialize a "struct SCIP_ExprInt" here.
5633  *
5634  * @subsection SCIPexprintFree
5635  *
5636  * The SCIPexprintFree method is called to free an expression interpreter data structure.
5637  * The method should free a "struct SCIP_ExprInt" here.
5638  *
5639  * @subsection SCIPexprintCompile
5640  *
5641  * The SCIPexprintCompile method is called to initialize the data structures that are required to evaluate
5642  * a particular expression tree.
5643  * The expression interpreter can store data that is particular to a given expression tree in the tree by using
5644  * SCIPexprtreeSetInterpreterData().
5645  *
5646  * @subsection SCIPexprintFreeData
5647  *
5648  * The SCIPexprintFreeData method is called when an expression tree is freed.
5649  * The expression interpreter should free the given data structure.
5650  *
5651  * @subsection SCIPexprintNewParametrization
5652  *
5653  * The SCIPexprintNewParametrization method is called when the values of the parameters in a parametrized expression tree have changed.
5654  *
5655  * @subsection SCIPexprintEval
5656  *
5657  * The SCIPexprintEval method is called when the value of an expression represented by an expression tree should be computed for a point.
5658  *
5659  * @subsection SCIPexprintEvalInt
5660  *
5661  * 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.
5662  *
5663  * @subsection SCIPexprintGrad
5664  *
5665  * The SCIPexprintGrad method is called when the gradient of an expression represented by an expression tree should be computed for a point.
5666  *
5667  * @subsection SCIPexprintGradInt
5668  *
5669  * 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.
5670  *
5671  * @subsection SCIPexprintHessianSparsityDense
5672  *
5673  * The SCIPexprintHessianSparsityDense method is called when the sparsity structure of the Hessian matrix should be computed and returned in dense form.
5674  *
5675  * @subsection SCIPexprintHessianDense
5676  *
5677  * The SCIPexprintHessianDense method is called when the Hessian of an expression represented by an expression tree should be computed for a point.
5678  */
5679 
5680 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5681 /**@page CONF How to use conflict analysis
5682  *
5683  * Conflict analysis is a way to automatically use the information obtained from infeasible nodes
5684  * in the branch-and-bound tree.
5685  *
5686  * Once a node is declared infeasible, SCIP automatically tries to infer a constraint that explains the reason for the
5687  * infeasibility, in order to avoid similar situations later in the search. This explanation essentially consists of a
5688  * constraint stating that at least one of its variables should have a bound different from the current infeasible node,
5689  * because the current setting led to infeasibility. Clearly, all variables that are fixed in the current infeasible
5690  * node would yield such a constraint (since this leads to infeasibility). The key point rather is to infer a "small"
5691  * constraint that does the same job. SCIP handles this by several heuristics. For this, SCIP sets up a
5692  * so-called (directed) conflict graph. The nodes in this graph correspond to bound changes of variables and an arc (@a
5693  * 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
5694  * will have several ingoing arcs which represent all bound changes that have been used to infer (propagate) the bound
5695  * change in question. The graph also contains source nodes for each bound that has been changed during branching and an
5696  * artificial target node representing the conflict, i.e., the infeasibility. Essentially, SCIP heuristically constructs
5697  * a cut in this graph that involves few "branching nodes". For details on the techniques that SCIP uses,
5698  * we refer to the paper @par
5699  * Tobias Achterberg, Conflict Analysis in Mixed Integer Programming@n
5700  * Discrete Optimization, 4, 4-20 (2007)
5701  *
5702  * For conflict analysis to work well, the author of a \ref CONS "Constraint Handler" or a
5703  * \ref PROP "Propagator" has to implement three kinds of functionality:
5704  *
5705  * -# If one detects infeasibility, one should initiate conflict analysis, see \ref INITCONFS "below".
5706  * -# During propagation, one should call the right functions to fix variables.
5707  * -# One should implement the <em>so-called reverse propagation</em>.
5708  *
5709  * If this functionality is not implemented, SCIP will still work correctly, but cannot use the information of the constraint
5710  * handler or the propagator for conflict analysis. In this case, each bound reduction performed by the constraint
5711  * handler/propagator will be treated as if it had been a branching decision.
5712  *
5713  * @section INITCONFS Initiating Conflict Analysis
5714  *
5715  * If one detects infeasibility within propagation, one should do the following:
5716  * -# Call SCIPinitConflictAnalysis().
5717  * -# Inform SCIP about the variable bounds that are the reason for the detection of infeasibility
5718  * via the functions SCIPaddConflictLb(), SCIPaddConflictUb(), SCIPaddConflictBd(), or
5719  * SCIPaddConflictBinvar(). If there is more than one valid explanation of infeasibility, either one can be used.
5720  * Typically, smaller explanations tend to be better.
5721  * -# Call SCIPanalyzeConflict() from a propagator or SCIPanalyzeConflictCons() from a constraint
5722  * handler.
5723  *
5724  * This functionality allows SCIP to set up the conflict graph and perform a conflict analysis.
5725  *
5726  * @section Propagation
5727  *
5728  * When propagating variable domains, SCIP needs to be informed that the deduced variable bounds should be
5729  * used in conflict analysis. This can be done by the functions SCIPinferVarLbCons(),
5730  * SCIPinferVarUbCons(), and SCIPinferBinvarCons() for constraint handlers and SCIPinferVarLbProp(),
5731  * SCIPinferVarUbProp(), and SCIPinferBinvarProp() for propagators. You can pass one integer of
5732  * information that should indicate the reason of the propagation and can be used in reverse
5733  * propagation, see the next section.
5734  *
5735  * @section RESPROP Reverse Propagation
5736  *
5737  * Reverse Propagation is used to build up the conflict graph. Essentially, it provides an algorithm to detect the arcs
5738  * leading to a node in the conflict graph, i.e., the bound changes responsible for the new bound change deduced during
5739  * propagation. Reverse Propagation needs to be implemented in the RESPROP callback functions of
5740  * \ref CONSRESPROP "constraint handlers" or \ref PROPRESPROP "propagators".
5741  * These callbacks receive the following information: the variable which is under investigation (@p
5742  * infervar), the corresponding bound change (@p bdchgidx, @p boundtype), and the integer (@p inferinfo) that has been
5743  * supplied during propagation.
5744  *
5745  * One can use SCIPvarGetUbAtIndex() or SCIPvarGetLbAtIndex() to detect the bounds before or after the propagation that
5746  * should be investigated. Then the bounds that were involved should be passed to SCIP via SCIPaddConflictLb() and
5747  * SCIPaddConflictUb(). If there is more than one valid explanation of infeasibility, either one can be used.
5748  * Typically, smaller explanations tend to be better.
5749  *
5750  * Details and (more) examples are given in Sections @ref CONSRESPROP and @ref PROPRESPROP.
5751  *
5752  *
5753  * @section Example
5754  *
5755  * Consider the constraint handler @p cons_linearordering.c in the
5756  * <a href="http://scip.zib.de/doc/examples/LOP"><b>linear ordering example</b></a>
5757  * (see @p example/LOP directory). This constraint handler propagates the equations \f$x_{ij} + x_{ji} =
5758  * 1\f$ and triangle inequalities \f$x_{ij} + x_{jk} + x_{ki} \leq 2\f$.
5759  *
5760  * When propagating the equation and <code>vars[i][j]</code> is fixed to 1, the constraint handler uses
5761  * \code
5762  * SCIP_CALL( SCIPinferBinvarCons(scip, vars[j][i], FALSE, cons, i*n + j, &infeasible, &tightened) );
5763  * \endcode
5764  * Thus, variable <code>vars[j][i]</code> is fixed to 0 (@p FALSE), and it passes <code>i*n + j </code> as @p inferinfo.
5765  *
5766  * When it propagates the triangle inequality and both <code>vars[i][j]</code> and <code>vars[j][k]</code>
5767  * are fixed to 1, the constraint handler uses
5768  * \code
5769  * SCIP_CALL( SCIPinferBinvarCons(scip, vars[k][i], FALSE, cons, n*n + i*n*n + j*n + k, &infeasible, &tightened) );
5770  * \endcode
5771  * 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
5772  * passed as <code>inferinfo</code>.
5773  *
5774  * In reverse propagation, the two cases can be distinguished by @p inferinfo: if it is less than @p n*n,
5775  * we deal with an equation, otherwise with a triangle inequality. The constraint handler can then extract the
5776  * indices @p i, @p j (and @p k in the second case) from inferinfo.
5777  *
5778  * In the first case, it has to distinguish whether <code>vars[i][j]</code> is fixed to 0 or 1 &ndash;
5779  * by calling SCIPaddConflictLb()
5780  * or SCIPaddConflictUb(), respectively, with variable <code>vars[j][i]</code>. In the second case, it is clear that the only
5781  * 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>
5782  * are fixed to 1. It then calls
5783  * SCIPaddConflictLb() for both <code>vars[k][i]</code> and <code>vars[j][k]</code>.
5784  */
5785 
5786 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5787 /**@page REOPT How to use reoptimization
5788  *
5789  * The reoptimization feature of SCIP can be used to solve a sequence of optimization problems \f$(P_{i})_{i \in I}\f$ with
5790  * \f[
5791  * (P_i) \quad \min \{ c_i^T x \;|\; A^ix \geq b^i,\; x_{j} \in \{0,1\}^{n}\;\forall j \in \mathcal{I} \}
5792  * \f]
5793  * such that between two problems \f$P_i\f$ and \f$P_{i+1}\f$ the space of solutions gets restricted and/or the objective
5794  * fuction changes. To use reoptimization the user has to change the parameter <code>reoptimization/enable</code> to
5795  * <code>TRUE</code> before the solving process of the first problem of the sequence starts, i.e., in stage
5796  * <code>SCIP_STAGE_INIT</code> or <code>SCIP_STAGE_PROBLEM</code>. This can be done via the interactive shell or by
5797  * calling SCIPenableReoptimization(). In both cases SCIP changes some parameters and fixes them:
5798  * -# disable conflict analysis based on dual information
5799  * -# set the limit <code>maxorigsol</code> of stored solutions to zero because this is handled by a special solution tree provided
5800  * by the reoptimization feature itself
5801  * -# disable restarts (<code>presolving/maxrestarts = 0</code>)
5802  * -# disable multi-aggegations (<code>presolving/donotmultaggr = TRUE</code>)
5803  * -# disable dual reductions within presolvers and propagators (<code>misc/allowdualreds = FALSE</code>)
5804  * -# disable propagation with current cutoff bound (<code>misc/allowobjprop = FALSE</code>)
5805  *
5806  * In contrast to the presolving and propagating methods that are using dual information, performing strong branching is
5807  * allowed. The bound tightenings resulting from strong branching are handeled in a special way. After changing the objective
5808  * function and solving the modified problem the feasible region that was pruned by strong branching will be reconstructed
5809  * within the tree.
5810  *
5811  * If the reoptimization feature is enabled SCIP tries to reuse the search tree, especially the search frontier at the end
5812  * of the solving process, to speed up the solving process of the following problems. Therefore, the current release
5813  * provides the branching rule <code>branch_nodereopt</code> to reconstruct the tree. SCIP triggers a restart of the
5814  * reoptimization, i.e., solving the problem from scratch, if
5815  *
5816  * -# the stored search tree is too large,
5817  * -# the objective functions changed too much, or
5818  * -# the last \f$n\f$ optimal solution are updated solution of previous runs.
5819  *
5820  * The thresholds to trigger a restart can be set by the user:
5821  *
5822  * -# <code>reoptimization/maxsavednodes</code>
5823  * -# <code>reoptimization/delay</code>
5824  * -# <code>reoptimization/forceheurrestart</code>
5825  *
5826  * Before SCIP discards all the stored information and solves the problem from scratch it tries to compress the search
5827  * tree. Therefore, the current release provides compression heuristics that try to find a good and much smaller
5828  * representation of the current search tree.
5829  *
5830  * After a problem in the sequence of optimization problems was solved, the objective function can be changed in two ways:
5831  * -# Using the provided reader <code>reader_diff</code> the objective function can be changed via using the interactive
5832  * shell
5833  * \code
5834  * SCIP> read new_obj.diff
5835  * \endcode
5836  * or by calling SCIPreadDiff().
5837  * -# The objective function can be changed within the code. Therefore, the transformed problem needs to be freed by
5838  * calling SCIPfreeTransform(). Afterwards, the objective coefficient of each variable can be changed by calling
5839  * SCIPchgVarObj().
5840  *
5841  * After changing the objective function the modified problem can be solved as usal.
5842  *
5843  * \note Currently, the reoptimization feature only supports pure binary and mixed binary programs. In case the original
5844  * problem containts integer and implicit integer variables, reoptimization will be automatically disabled if there are
5845  * still (implicit) integer variables after presolving the problem.
5846  *
5847  * For more information on reoptimization we refer to@par
5848  * Jakob Witzig@n
5849  * Reoptimization Techniques in MIP Solvers@n
5850  * Master's Thesis, Technical University of Berlin, 2014.
5851  */
5852 
5853 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5854 /**@page OBJ Creating, capturing, releasing, and adding data objects
5855  *
5856  * Data objects (variables, constraints, rows, ... ) are subject to reference counting
5857  * to avoid expensive copying operations. This concept is similar to smart pointers.
5858  * Creating such an object (e.g., by calling SCIPcreateVar()) will set the
5859  * reference counter to one. Capturing an object (e.g., by calling SCIPcaptureVar()) increases the reference counter,
5860  * releasing it (e.g., by calling SCIPreleaseVar()) decreases the counter. If the reference counter gets zero, the
5861  * object will be destroyed automatically.
5862  *
5863  * Remember that a created data object is automatically captured. If the user
5864  * doesn't need the object anymore, (s)he has to call the object's release method.
5865  *
5866  * When a data object is added to SCIP (e.g., by calling SCIPaddVar()) , it is captured again, such that a
5867  * release call does not destroy the object. If SCIP doesn't need the object
5868  * anymore, it is automatically released.
5869  *
5870  * E.g., if the user calls
5871  * \code
5872  * SCIPcreateVar(); // reference counter 1
5873  * SCIPaddVar(); // reference counter 2
5874  * SCIPreleaseVar(); // reference counter 1
5875  * \endcode
5876  * the reference counter will be 1 afterwards, and the variable will be destroyed, if SCIP frees the problem.
5877  * If the user wants to use this variable, e.g. for extracting statistics after SCIP was finished, the user must not call
5878  * SCIPreleaseVar() right after adding the variable, but before terminating the program.
5879  */
5880 
5881 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5882 /**@page PARAM How to add additional user parameters
5883  *
5884  * Users may add their own parameters to SCIP by calling SCIPaddXyzParam(). Using
5885  * this method, there are two possibilities for where to store the actual parameter value:
5886  * - If the given valueptr is NULL, SCIP stores the parameter value internally, and
5887  * the user can only access the value with the SCIPgetXyzParam() and
5888  * SCIPsetXyzParam() calls.
5889  * - If the given valueptr is not NULL, SCIP stores the parameter value at the given
5890  * address, and the user can directly manipulate the value at this address.
5891  * (S)he has to be careful with memory management in string parameters: when the
5892  * SCIPaddStringParam() method is called, the given address must hold a char*
5893  * pointer with value NULL. The default value is then copied into this pointer,
5894  * allocating memory with BMSallocMemoryArray(). If the parameter is changed, the
5895  * old string is freed with BMSfreeMemoryArray() and the new one is copied to a new
5896  * memory area allocated with BMSallocMemoryArray(). When the parameter is freed,
5897  * the memory is freed with BMSfreeMemoryArray().
5898  * The user should not interfere with this internal memory management. Accessing
5899  * the string parameter through the given valueptr is okay as long as it does not
5900  * involve reallocating memory for the string.
5901  *
5902  * In some cases, it is necessary to keep track of changes in a parameter.
5903  * If this is the case, the user can define a method by the PARAMCHGD callback and use this method as
5904  * the @c paramchgd parameter of the @c SCIPaddXyzParam() method, also giving a pointer to the data, which is
5905  * needed in this method, as @c paramdata. If this method is not NULL, it is called every time
5906  * the value of the parameter is changed.
5907  */
5908 
5909 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5910 /**@page MEMORY Using the memory functions of SCIP
5911  *
5912  * SCIP provides three ways for allocating memory.
5913  *
5914  * @section STDMEM Standard memory
5915  *
5916  * SCIP provides an access to the standard C functions @c malloc and @c free with the additional feature of tracking
5917  * memory in debug mode. In this way, memory leaks can be easily detected. This feature is automatically activated in
5918  * debug mode.
5919  *
5920  * The most important functions are
5921  * - SCIPallocMemory(), SCIPallocMemoryArray() to allocate memory
5922  * - SCIPfreeMemory(), SCIPfreeMemoryArray() to free memory
5923  *
5924  * @section BLKMEM Block memory
5925  *
5926  * SCIP offers its own block memory handling, which allows efficient handling of smaller blocks of memory in cases in
5927  * which many blocks of the same (small) size appear. This is adaquate for branch-and-cut codes in which small blocks
5928  * of the same size are allocated and freed very often (for data structures used to store rows or branch-and-bound
5929  * nodes). Actually, most blocks allocated within SCIP have small sizes like 8, 16, 30, 32, 64. The idea is simple:
5930  * There is a separate list of memory blocks for each interesting small size. When allocating memory, the list is
5931  * checked for a free spot in the list; if no such spot exists the list is enlarged. Freeing just sets the block to be
5932  * available. Very large blocks are handled separatedly. See the dissertation of Tobias Achterberg for more details.
5933  *
5934  * One important comment is that freeing block memory requires the size of the block in order to find the right list.
5935  *
5936  * The most important functions are
5937  * - SCIPallocBlockMemory(), SCIPallocBlockMemoryArray() to allocate memory
5938  * - SCIPfreeBlockMemory(), SCIPfreeBlockMemoryArray() to free memory
5939  *
5940  * An example code is:
5941  * \code
5942  * SCIP_RETCODE dosomething(
5943  * SCIP* scip
5944  * )
5945  * {
5946  * int nvars;
5947  * int* array;
5948  *
5949  * nvars = SCIPgetNVars(scip);
5950  * SCIP_CALL( SCIPallocBlockMemoryArray(scip, &array, nvars) );
5951  *
5952  * do something ...
5953  *
5954  * SCIPfreeBlockMemoryArray(scip, &array, nvars);
5955  * }
5956  * \endcode
5957  *
5958  * @section BUFMEM Buffer memory
5959  *
5960  * In addition to block memory, SCIP offers buffer memory. This should be used if memory is locally
5961  * used within a function and freed within the same function. For this purpose, SCIP has a list of memory buffers
5962  * that are reused for this purpose. In this way, a very efficient allocation/freeing is possible.
5963  *
5964  * The most important functions are
5965  * - SCIPallocBufferMemory(), SCIPallocBufferArray() to allocate memory
5966  * - SCIPfreeBufferMemory(), SCIPfreeBufferArray() to free memory
5967  *
5968  * SCIP 3.2 introduced a new type of buffer memory, the clean buffer. It provides memory which is initialized to zero
5969  * and requires the user to reset the memory to zero before freeing it. This can be used at performance-critical
5970  * places where only few nonzeros are added to a dense array and removing these nonzeros individually is much faster
5971  * than clearing the whole array. Same as the normal buffer array, the clean buffer should be used for temporary memory
5972  * allocated and freed within the same function.
5973  *
5974  * The most important functions are
5975  * - SCIPallocCleanBufferArray() to allocate memory
5976  * - SCIPfreeCleanBufferArray() to free memory
5977  *
5978  * @section GENMEM General notes
5979  *
5980  * The following holds for all three types of memory functions:
5981  * - In debug mode the arguments are checked for overly large allocations (negative sizes are converted into very large values of type @c size_t).
5982  * - The functions always allocate at least one byte, so that freeing is always possible.
5983  * - The freeing methods set the pointer to the memory to NULL.
5984  * - For maximum speed you should free memory in the reverse order in which it was allocated.
5985  * For block and buffer memory this @b significantly speeds up the code.
5986  */
5987 
5988 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5989 /**@page DEBUG Debugging
5990  *
5991  * If you need to debug your own code that uses SCIP, here are some tips and tricks:
5992  *
5993  * - Use <b>asserts</b> in your code to show preconditions for the parameters, invariants and postconditions.
5994  * Assertions are boolean expressions which inevitably have to evaluate to <code>TRUE</code>. Consider the
5995  * following example, taken from the file src/scip/cons_linear.c:
5996  * \code
5997  * SCIP_RETCODE consdataCatchEvent(
5998  * SCIP* scip, /**< SCIP data structure */
5999  * SCIP_CONSDATA* consdata, /**< linear constraint data */
6000  * SCIP_EVENTHDLR* eventhdlr, /**< event handler to call for the event processing */
6001  * int pos /**< array position of variable to catch bound change events for */
6002  * )
6003  * {
6004  * assert(scip != NULL);
6005  * assert(consdata != NULL);
6006  * assert(eventhdlr != NULL);
6007  * assert(0 <= pos && pos < consdata->nvars);
6008  * ...
6009  * }
6010  * \endcode
6011  * As you can see, both pointers and integers are checked for valid values at the beginning of the
6012  * function <code>consdataCatchEvent()</code>. This is particularly important for, e.g., array indices like
6013  * the variable <code>pos</code> in this example, where using the <code>consdata->nvars[pos]</code>
6014  * pointer could result in unexspected behaviour
6015  * if the asserted precondition on <code>pos</code> were not matched and <pos> were an arbitrary index
6016  * outside the array range.
6017  *
6018  * - In order to activate assertions, use the <b>Debug mode</b> by compiling SCIP via
6019  * \code
6020  * make OPT=dbg
6021  * \endcode and run the code. See \ref MAKE for further information about compiler options for SCIP.
6022  *
6023  * - Spending only little extra time on
6024  * asserting preconditions saves most of the time spent on debugging!
6025  *
6026  * - Turn on <b>additional debug output</b> by adding the line
6027  * \code
6028  * #define SCIP_DEBUG
6029  * \endcode
6030  * at the top of SCIP files you want to analyze. This will output messages included in the code using
6031  * <code>SCIPdebugMessage()</code> (see \ref EXAMPLE_1).
6032  * We recommend to also use <code>SCIPdebugMessage()</code> in your own code for being able to activate
6033  * debug output in the same way.
6034  * - If available on your system, we recommend to use a debugger like <code>gdb</code>
6035  * to trace all function calls on the stack,
6036  * display values of certain expressions, manually break the running code, and so forth.
6037  * - If available on your system, you can use software like <a href="http://valgrind.org">valgrind</a> to check for uninitialized
6038  * values or segmentation faults.
6039  * - For checking the usage of SCIP memory, you can use
6040  * <code>SCIPprintMemoryDiagnostic()</code>. This outputs memory that is currently in use,
6041  * which can be useful after a <code>SCIPfree()</code> call.
6042  * - If there are memory leaks for which you cannot detect the origin, you can remake your code with the option NOBLKBUFMEM=true
6043  * (do not forget to clean your code before with <code>make OPT=... LPS=... clean</code>). After that valgrind (or similar) helps
6044  * to detect leaked memory.
6045  * - If your code cuts off a feasible solution, but you do not know which component is responsible,
6046  * you can define <code>SCIP_DEBUG_SOLUTION</code> in the file <code>debug.h</code> to be a filename
6047  * containing a solution in SCIP format (see \ref EXAMPLE_2).
6048  * This solution is then read and it is checked for every cut, whether the solution violates the cut.
6049  *
6050  * @section EXAMPLE_1 How to activate debug messages
6051  * For example, if we include a <code>\#define SCIP_DEBUG</code> at the top of \ref heur_oneopt.h, recompile SCIP
6052  * in DBG mode, and run the SCIP interactive shell to solve p0033.mps from the
6053  * <a href="http://miplib.zib.de/miplib3/miplib.html">MIPLIB 3.0</a> , we get some output like:
6054  * \code
6055  * SCIP version 1.1.0 [precision: 8 byte] [memory: block] [mode: debug] [LP solver: SoPlex 1.4.0]
6056  * Copyright (c) 2002-2015 Konrad-Zuse-Zentrum fuer Informationstechnik Berlin (ZIB)
6057  *
6058  * user parameter file <scip.set> not found - using default parameters
6059  *
6060  * SCIP> read check/IP/miplib/p0033.mps
6061  * original problem has 33 variables (33 bin, 0 int, 0 impl, 0 cont) and 16 constraints
6062  * SCIP> optimize
6063  * ...
6064  * 0.1s| 1 | 0 | 132 | 257k| 0 | 14 | 30 | 13 | 13 | 30 | 51 | 39 | 0 | 0 | 3.026472e+03 | 3.347000e+03 | 10.59%
6065  * [src/scip/heur_oneopt.c:332] debug: Row <R122> has activity 110
6066  * [src/scip/heur_oneopt.c:332] debug: Row <R123> has activity 216
6067  * ...
6068  * [src/scip/heur_oneopt.c:101] debug: Try to shift down variable <t_C157> with
6069  * [src/scip/heur_oneopt.c:102] debug: lb:<-0> <= val:<1> <= ub:<1> and obj:<171> by at most: <1>
6070  * [src/scip/heur_oneopt.c:135] debug: -> The shift value had to be reduced to <0>, because of row <R122>.
6071  * [src/scip/heur_oneopt.c:137] debug: lhs:<-1e+20> <= act:<110> <= rhs:<148>, colval:<-60>
6072  * ...
6073  * [src/scip/heur_oneopt.c:383] debug: Only one shiftcand found, var <t_C167>, which is now shifted by<-1.0>
6074  * 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%
6075  * [src/scip/heur_oneopt.c:436] debug: found feasible shifted solution:
6076  * objective value: 3164.00000000012
6077  * C157 1 (obj:171)
6078  * C163 1 (obj:163)
6079  * C164 1 (obj:69)
6080  * C170 1 (obj:49)
6081  * C172 1 (obj:258)
6082  * C174 1 (obj:250)
6083  * C175 1 (obj:500)
6084  * C179 1 (obj:318)
6085  * C181 1 (obj:318)
6086  * C182 1 (obj:159)
6087  * C183 1.00000000000038 (obj:318)
6088  * C184 1 (obj:159)
6089  * C185 1 (obj:318)
6090  * C186 1 (obj:114)
6091  * [src/scip/heur_oneopt.c:498] debug: Finished 1-opt heuristic
6092  * ...
6093  * \endcode
6094  *
6095  * @section EXAMPLE_2 How to add a debug solution
6096  *
6097  * Continuing the example above, we finish the solving process.
6098  * The optimal solution can now be written to a file:
6099  * \code
6100  * SCIP> display solution
6101  *
6102  * objective value: 3089
6103  * C157 1 (obj:171)
6104  * C163 1 (obj:163)
6105  * C164 1 (obj:69)
6106  * C166 1 (obj:183)
6107  * C170 1 (obj:49)
6108  * C174 1 (obj:250)
6109  * C177 1 (obj:500)
6110  * C179 1 (obj:318)
6111  * C181 1 (obj:318)
6112  * C182 1 (obj:159)
6113  * C183 1 (obj:318)
6114  * C184 1 (obj:159)
6115  * C185 1 (obj:318)
6116  * C186 1 (obj:114)
6117  *
6118  * SCIP> write solution check/p0033.sol
6119  *
6120  * written solution information to file <check/p0033.sol>
6121  * \endcode
6122  *
6123  * If we afterwards use
6124  * <code>\#define SCIP_DEBUG_SOLUTION "check/p0033.sol"</code> in debug.h, recompile and run SCIP,
6125  * it will output:
6126  * \code
6127  * SCIP> read check/IP/miplib/p0033.mps
6128  * original problem has 33 variables (33 bin, 0 int, 0 impl, 0 cont) and 16 constraints
6129  * SCIP> optimize
6130  *
6131  * presolving:
6132  * ***** debug: reading solution file <check/p0033.sol>
6133  * ***** debug: read 15 non-zero entries
6134  * \endcode
6135  * Further debug output would only appear, if the solution was cut off in the solving process.
6136  * Of course, this is not the case! Hopefully...otherwise, please send a bug report ;-)
6137  */
6138 
6139 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6140 /**@page TEST How to run automated tests with SCIP
6141  *
6142  * SCIP comes along with a set of useful tools that allow to perform automated tests. The
6143  * following is a step-by-step guide from setting up the test environment for evaluation and
6144  * customization of test runs.
6145  *
6146  *
6147  * @section SETUP Setting up the test environment
6148  *
6149  * At first you should create a file listing all problem instances that should be part of the test.
6150  * This file has to be located in the the directory <code>scip/check/testset/</code>
6151  * and has to have the file extension <code>.test</code>, e.g., <code>testrun.test</code>,
6152  * in order to be found by the <code>scip/check/check.sh</code> script.
6153  * \n
6154  * All test problems can be listed in the <code>test</code>-file by a relative path,
6155  * e.g., <code>../../problems/instance1.lp</code> or absolute path, e.g., <code>/home/problems/instance2.mps</code>
6156  * in this file. Only one problem should be listed on every line (since the command <code>cat</code> is used to parse this file).
6157  * Note that these problems have to be readable for SCIP in order to solve them.
6158  * However, you can use different file formats.
6159  *
6160  * Optionally, you can provide a solution file in the <code>scip/check/testset/</code> directory containing
6161  * known information about the feasibility and the best known objective values for the test instances.
6162  * SCIP can use these values to verify the results. The file has to have the same basename as the
6163  * <code>.test</code>-file, i.e., in our case <code>testrun.solu</code>. One line can only contain
6164  * information about one test instance. A line has to start with the type of information given:
6165  *
6166  * - <code>=opt=</code> stating that a problem name with an optimal objective value follows
6167  * - <code>=best=</code> stating that a problem name with a best know objective value follows
6168  * - <code>=inf=</code> stating that a problem name follows which is infeasible
6169  *
6170  * With these information types you can encode for an instance named <code>instance1.lp</code> the following
6171  * information:
6172  * - The instance has a known optimal (objective) value of 10.
6173  * \code
6174  * =opt= instance1 10
6175  * \endcode
6176  * - The instance has a best known solution with objective value 15.
6177  * \code
6178  * =best= instance1 15
6179  * \endcode
6180  * - The instance is feasible (but has no objective function or we don't know a solution value)
6181  * \code
6182  * =feas= instance1
6183  * \endcode
6184  * - The instance is infeasible.
6185  * \code
6186  * =inf= instance1
6187  * \endcode
6188  *
6189  * If you don't know whether the instance is feasible or not (so the status is unknown),
6190  * you can omit the instance in the <code>solu</code>-file or write
6191  * \code
6192  * =unkn= instance1
6193  * \endcode
6194  *
6195  * <b>Note that in all lines the file extension of the file name is omitted.</b>
6196  * \n
6197  * See the files <code>scip/check/testset/short.test</code> and <code>scip/check/testset/short.solu</code>
6198  * for an example of a <code>test</code>-file and its corresponding <code>solu</code>-file.
6199  *
6200  *
6201  *
6202  * @section STARTING Starting a test run
6203  *
6204  *
6205  * \code
6206  * make TEST=testrun test
6207  * \endcode
6208  *
6209  * in the SCIP root directory. Note that <code>testrun</code> is exactly the basename of our
6210  * <code>test</code>-file (<code>testrun.test</code>). This will cause SCIP to solve our test instances
6211  * one after another and to create various output files (see \ref EVAL).
6212  *
6213  *
6214  * @section EVAL Evaluating a test run
6215  *
6216  * During computation, SCIP automatically creates the directory <code>scip/check/results/</code>
6217  * (if it does not already exist) and stores the following output files there.
6218  *
6219  * \arg <code>*.out</code> - output of <code>stdout</code>
6220  * \arg <code>*.err</code> - output of <code>stderr</code>
6221  * \arg <code>*.set</code> - copy of the used settings file
6222  *
6223  * \arg <code>*.res</code> - ASCII table containing a summary of the computational results
6224  * \arg <code>*.tex</code> - TeX table containing a summary of the computational results
6225  * \arg <code>*.pav</code> - <a href="http://www.gamsworld.org/performance/paver/">PAVER</a> output
6226  *
6227  * The last three files in the above list, i.e., the files containing a summary of the computational results,
6228  * can also be generated manually. Therefore the user has to call the <code>evalcheck.sh</code> script in the
6229  * @c check directory with the corresponding @c out file as argument. For example, this may be useful if the user stopped the
6230  * test before it was finished, in which case the last three files will not be automatically generated by SCIP.
6231  *
6232  * The last column of the ASCII summary table contains the solver status. We distinguish the following statuses: (in order of priority)
6233  *
6234  * \arg abort: solver broke before returning solution
6235  * \arg fail: solver cut off a known feasible solution (value of the <code>solu</code>-file is beyond the dual bound;
6236  * especially if problem is claimed to be solved but solution is not the optimal solution)
6237  * <b>or</b> if a final solution check revealed a violation of one of the original constraints.
6238  * \arg ok: solver solved problem with the value in solu-file
6239  * \arg solved: solver solved problem which has no (optimal) value in solu-file (since we here cannot detect the direction
6240  * of optimization, it is possible that a solver claims an optimal solution which contradicts a known feasible solution)
6241  * \arg better: solver found solution better than known best solution (or no solution was noted in the <code>solu</code>-file so far)
6242  * \arg gaplimit, sollimit: solver reached gaplimit or limit of number of solutions (at present: only in SCIP)
6243  * \arg timeout: solver reached any other limit (like time or nodes)
6244  * \arg unknown: otherwise
6245  *
6246  * Additionally the <code>evalcheck.sh</code> script can generate a <code>solu</code>-file by calling
6247  * \code
6248  * ./evalcheck.sh writesolufile=1 NEWSOLUFILE=<solu-file> <out-file>
6249  * \endcode
6250  * where <code><solu-file></code> denotes the filename of the new file where the solutions shall be
6251  * (and <code><out-file></code> denotes the output (<code>.out</code>) files to evaluate).
6252  *
6253  * Another feature can be enabled by calling:
6254  * \code
6255  * ./evalcheck.sh printsoltimes=1 ...
6256  * \endcode
6257  * The output has two additional columns containing the solving time until the first and the best solution was found.
6258  *
6259  *
6260  * @b Note: The @em basename of all these files is the same and has the following structure
6261  * which allows us to reconstruct the test run:
6262  *
6263  * \code
6264  * check.<test name>.<binary>.<machine name>.<setting name>
6265  * \endcode
6266  *
6267  * \arg <<code>test name</code>> indicates the name of the the test file, e.g., <code>testrun</code>
6268  * \arg <<code>binary</code>> defines the used binary, e.g., <code>scip-3.2.0.linux.x86_64.gnu.opt.spx</code>
6269  * \arg <<code>machine name</code>> tells the name of the machine, e.g., <code>mycomputer</code>
6270  * \arg <<code>setting name</code>> denotes the name of the used settings, e.g., <code>default</code>
6271  * means the (SCIP) default settings were used
6272  *
6273  * Using the examples out of the previous listing the six file names would have the name:
6274  *
6275  * \code
6276  * check.testrun.scip-1.1.0.linux.x86.gnu.opt.spx.mycomputer.default.<out,err,set,res,tex,pav>
6277  * \endcode
6278  *
6279  *
6280  * @section USING Using customized setting files
6281  *
6282  * It is possible to use customized settings files for the test run instead of testing SCIP with default settings.
6283  * These have to be placed in the directory <code>scip/settings/</code>.
6284  *
6285  * @b Note: Several common user parameters such as, e.g., the time limit and node limit parameters,
6286  * <b>cannot</b> be controlled by the settings file, whose specifications would be overwritten
6287  * by optional command line arguments to the <code>make test</code> command, see @ref ADVANCED
6288  * for a list of available advanced testing options that have to be specified from the command line.
6289  *
6290  * @b Note: Accessing settings files in subfolders of the @c settings directory is currently not supported.
6291  *
6292  * To run SCIP with a custom settings file, say for example <code>fast.set</code>, we call
6293  *
6294  * \code
6295  * make TEST=testrun SETTINGS=fast test
6296  * \endcode
6297  *
6298  * in the SCIP root directory. It is possible to enter a list of settings files as a double-quoted,
6299  * comma-separated list of settings names as <code>fast</code> above, i.e. <code>SETTINGS="fast,medium,slow"</code>
6300  * will invoke the solution process for every instance with the three settings <code>fast.set, medium.set, slow.set</code>
6301  * before continuing with the next instance from the <code>.test</code>-file. This may come in handy if the
6302  * whole test runs for a longer time and partial results are already available.
6303  *
6304  *
6305  * @section ADVANCED Advanced options
6306  *
6307  * We can further customize the test run by specifying the following options in the <code>make</code> call:
6308  *
6309  * \arg <code>CONTINUE</code> - continue the test run if it was previously aborted [default: "false"]
6310  * \arg <code>DISPFREQ</code> - display frequency of the output [default: 10000]
6311  * \arg <code>FEASTOL</code> - LP feasibility tolerance for constraints [default: "default"]
6312  * \arg <code>LOCK</code> - should the test run be locked to prevent other machines from performing the same test run [default: "false"]
6313  * \arg <code>MAXJOBS=n</code> - run tests on 'n' cores in parallel. Note that several instances are solved in parallel, but
6314  * only one thread is used per job (parallelization is not that easy) [default: 1]
6315  * \arg <code>MEM</code> - memory limit in MB [default: 6144]
6316  * \arg <code>NODES</code> - node limit [default: 2100000000]
6317  * \arg <code>TIME</code> - time limit for each test instance in seconds [default: 3600]
6318  * \arg <code>SETCUTOFF</code> - if set to '1', an optimal solution value (from the <code>.solu</code>-file) is used as objective limit [default: 0]
6319  * \arg <code>THREADS</code> - the number of threads used for solving LPs, if the linked LP solver supports multithreading [default: 1]
6320  * \arg <code>VALGRIND</code> - run valgrind on the SCIP binary; errors and memory leaks found by valgrind are reported as fails [default: "false"]
6321  *
6322  *
6323  * @section COMPARE Comparing test runs for different settings
6324  *
6325  * Often test runs are performed on the basis of different settings. In this case, it is useful to
6326  * have a performance comparison. For this purpose, we can use the <code>allcmpres.sh</code> script in
6327  * the @c check directory.
6328  *
6329  * Suppose, we performed our test run with two different settings, say <code>fast.set</code> and
6330  * <code>slow.set</code>. Assuming that all other parameters (including the SCIP binary), were the same,
6331  * we may have the following <code>res</code>-files in the directory <code>scip/check/results/</code>
6332  *
6333  * \code
6334  * check.testrun.scip-3.2.0.linux.x86_64.gnu.opt.spx.mycomputer.fast.res
6335  * check.testrun.scip-3.2.0.linux.x86_64.gnu.opt.spx.mycomputer.slow.res
6336  * \endcode
6337  *
6338  * For a comparison of both computations, we simply call
6339  *
6340  * \code
6341  * allcmpres.sh results/check.testrun.scip-3.2.0.linux.x86_64.gnu.opt.spx.mycomputer.fast.res \
6342  * results/check.testrun.scip-3.2.0.linux.x86_64.gnu.opt.spx.mycomputer.slow.res
6343  * \endcode
6344  *
6345  * in the @c check directory. This produces an ASCII table on the console that provide a detailed
6346  * performance comparison of both test runs. Note that the first <code>res</code>-file serves as reference
6347  * computation. The following list explains the output.
6348  * (The term "solver" can be considered as the combination of SCIP with a specific setting file.)
6349  *
6350  * \arg <code>Nodes</code> - Number of processed branch-and-bound nodes.
6351  * \arg <code>Time</code> - Computation time in seconds.
6352  * \arg <code>F</code> - If no feasible solution was found, then '#', empty otherwise.
6353  * \arg <code>NodQ</code> - Equals Nodes(i) / Nodes(0), where 'i' denotes the current solver and '0' stands for the reference solver.
6354  * \arg <code>TimQ</code> - Equals Time(i) / Time(0).
6355  * \arg <code>bounds check</code> - Status of the primal and dual bound check.
6356  *
6357  * \arg <code>proc</code> - Number of instances processed.
6358  * \arg <code>eval</code> - Number of instances evaluated (bounds check = "ok", i.e., solved to optimality
6359  * within the time and memory limit and result is correct). Only these instances are used in the calculation
6360  * of the mean values.
6361  * \arg <code>fail</code> - Number of instances with bounds check = "fail".
6362  * \arg <code>time</code> - Number of instances with timeout.
6363  * \arg <code>solv</code> - Number of instances correctly solved within the time limit.
6364  * \arg <code>wins</code> - Number of instances on which the solver won (i.e., the
6365  * solver was at most 10% slower than the fastest solver OR had the best
6366  * primal bound in case the instance was not solved by any solver within
6367  * the time limit).
6368  * \arg <code>bett</code> - Number of instances on which the solver was better than the
6369  * reference solver (i.e., more than 10% faster).
6370  * \arg <code>wors</code> - Number of instances on which the solver was worse than the
6371  * reference solver (i.e., more than 10% slower).
6372  * \arg <code>bobj</code> - Number of instances on which the solver had a better primal
6373  * bound than the reference solver (i.e., a difference larger than 10%).
6374  * \arg <code>wobj</code> - Number of instances on which the solver had a worse primal
6375  * bound than the reference solver (i.e., a difference larger than 10%).
6376  * \arg <code>feas</code> - Number of instances for which a feasible solution was found.
6377  * \arg <code>gnodes</code> - Geometric mean of the processed nodes over all evaluated instances.
6378  * \arg <code>shnodes</code> - Shifted geometric mean of the processed nodes over all evaluated instances.
6379  * \arg <code>gnodesQ</code> - Equals nodes(i) / nodes(0), where 'i' denotes the current
6380  * solver and '0' stands for the reference solver.
6381  * \arg <code>shnodesQ</code> - Equals shnodes(i) / shnodes(0).
6382  * \arg <code>gtime</code> - Geometric mean of the computation time over all evaluated instances.
6383  * \arg <code>shtime</code> - Shifted geometric mean of the computation time over all evaluated instances.
6384  * \arg <code>gtimeQ</code> - Equals time(i) / time(0).
6385  * \arg <code>shtimeQ</code> - Equals shtime(i) / shtime(0).
6386  * \arg <code>score</code> - N/A
6387  *
6388  * \arg <code>all</code> - All solvers.
6389  * \arg <code>optimal auto settings</code> - Theoretical result for a solver that performed 'best of all' for every instance.
6390  * \arg <code>diff</code> - Solvers with instances that differ from the reference solver in the number of
6391  * processed nodes or in the total number of simplex iterations.
6392  * \arg <code>equal</code> - Solvers with instances whose number of processed nodes and total number of
6393  * simplex iterations is equal to the reference solver (including a 10% tolerance) and where no timeout
6394  * occured.
6395  * \arg <code>all optimal</code> - Solvers with instances that could be solved to optimality by
6396  * <em>all</em> solvers; in particular, no timeout occurred.
6397  *
6398  * Since this large amount of information is not always needed, one can generate a narrower table by calling:
6399  * \code
6400  * allcmpres.sh short=1 ...
6401  * \endcode
6402  * where <code>NodQ</code>, <code>TimQ</code> and the additional comparison tables are omitted.
6403  *
6404  * If the <code>res</code>-files were generated with the parameter <code>printsoltimes=1</code>
6405  * we can enable the same feature here as well by calling:
6406  * \code
6407  * allcmpres.sh printsoltimes=1 ...
6408  * \endcode
6409  * As in the evaluation, the output contains the two additional columns of the solving time until the first and the best solution was found.
6410  *
6411  * @section STATISTICS Statistical tests
6412  *
6413  * The \c allcmpres script also performs two statistical tests for comparing different settings: For deciding whether
6414  * more feasible solutions have been found or more instances have been solved to optimality or not, we use a McNemar
6415  * test. For comparing the running time and number of nodes, we use a variant of the Wilcoxon signed rank test. A
6416  * detailed explanation can be found in the PhD thesis of Timo Berthold (Heuristic algorithms in global MINLP solvers).
6417  *
6418  * @subsection McNemar McNemar test
6419  *
6420  * Assume that we compare two settings \c S1 and \c S2 with respect to the number of instances solved to optimality
6421  * within the timelimit. The null hypothesis would be "Both settings lead to an equal number of instances being solved
6422  * to optimality", which we would like to disprove. Let \f$n_1\f$ be the number of instances solved by setting \c S1
6423  * but not by \c S2, and let \f$n_2\f$ be the number of instances solved by setting \c S2 but not by \c S1. The
6424  * McNemar test statistic is
6425  * \f[
6426  * \chi^2 = \frac{(n_1 - n_2)^2}{n_1 + n_2}.
6427  * \f]
6428  * Under the null hypothesis, \f$\chi^2\f$ is chi-squared distributed with one degree of freedom. This allows to compute
6429  * a \f$p\f$-value as the probability for obtaining a similar or even more extreme result under the null hypothesis.
6430  * More explicitly, \c allcmpres uses the following evaluation:
6431  * - \f$0.05 < p\f$: The null hypothesis is accepted (marked by "X").
6432  * - \f$0.005 < p \leq 0.05\f$: The null hypothesis might be false (marked by "!").
6433  * - \f$0.0005 < p \leq 0.005\f$: The null hypothesis can be false (marked by "!!").
6434  * - \f$p \leq 0.0005\f$: The null hypothesis is very likely false (marked by "!!!").
6435  *
6436  * As an example consider the following output:
6437  * \code
6438  * McNemar (feas) x2 0.0000, 0.05 < p X
6439  * McNemar (opt) x2 6.0000, p ~ (0.005, 0.05] !
6440  * \endcode
6441  * Here, \c x2 represents \f$\chi^2\f$.
6442  *
6443  * In this case, the test with respect to the number of found feasible solutions is irrelevant, since their number is
6444  * equal. In particular, the null hypothesis gets accepted (i.e., there is no difference in the settings - this is
6445  * marked by "X").
6446  *
6447  * With respect to the number of instances solved to optimality within the timelimit, we have that \f$0.005 < p <=
6448  * 0.05\f$ (marked by <tt>p ~ (0.005, 0.05)</tt>). Thus, there is some evidence that the null hypothesis is false, i.e., the
6449  * settings perform differently; this is marked by "!". In the concrete case, we have 230 instances, all of which are
6450  * solved by setting \c S2, but only 224 by setting \c S1.
6451  *
6452  * @subsection Wilcoxon Wilcoxon signed rank test
6453  *
6454  * Assume that we compare two settings \c S1 and \c S2 with respect to their solution times (within the time limit). We
6455  * generate a sorted list of the ratios of the run times, where ratios that are (absolutely or relatively) within 1\%
6456  * of 1.0 are discarded, and ratios between 0.0 and 0.99 are replaced with their negative inverse in order to
6457  * obtain a symmetric distribution for the ratios around the origin.
6458  * We then assign ranks 1 to \c N to the remaining \c N data points in nondecreasing
6459  * order of their absolute ratio. This yields two groups \c G1
6460  * and \c G2 depending on whether the ratios are smaller than -1.0 or larger than 1.0 (\c G1 contains the instances for which
6461  * setting \c S1 is faster). Then the sums of the ranks in groups \c G1 and \c G2 are computed, yielding values \c R1
6462  * and \c R2, respectively.
6463  *
6464  * The Wilcoxon test statistic is then
6465  * \f[
6466  * z = \frac{\min(R1, R2) - \frac{N(N+1)}{4}}{\sqrt{\frac{N(N+1)(2N+1)}{24}}},
6467  * \f]
6468  * which we assume to be (approximately) normally distributed (with zero mean) and allows to compute the probability
6469  * \f$p\f$ that one setting is faster than the other. (Note that for \f$N \leq 60\f$, we apply a correction by
6470  * subtracting 0.5 from the numerator).
6471  *
6472  * As an example consider the following output:
6473  * \code
6474  * Wilcoxon (time) z -0.1285, 0.05 <= p X
6475  * Wilcoxon (nodes) z -11.9154, p < 0.0005 !!!
6476  * \endcode
6477  * While the \f$z\f$-value is close to zero for the run time, it is extremely negative regarding the solving nodes. This latter
6478  * tendency for the number of nodes is significant on a 0.05 % level, i.e., the probability \f$p\f$ that setting \c S1 uses more
6479  * nodes than setting \c S2 is negligible (this null hypothesis is rejected - marked by "!!!").
6480  *
6481  * However, the null hypothesis is not rejected with respect to the run time. In the concrete case, setting \c S1 has a
6482  * shifted geometric mean of its run times (over 230 instances) of 248.5, for \c S2 it is 217.6. This makes a ratio of
6483  * 0.88. Still - the null hypothesis is not rejected.
6484  *
6485  * @section SOLVER Testing and Evaluating for other solvers
6486  *
6487  * Analogously to the target <code>test</code> there are further targets to run automated tests with other MIP solvers.
6488  * These are:
6489  * \arg for <a href="http://www-01.ibm.com/software/integration/optimization/cplex-optimizer/">cplex</a>
6490  * \code
6491  * make testcplex
6492  * \endcode
6493  * \arg for <a href="http://www.gurobi.com/">gurobi</a>
6494  * \code
6495  * make testgurobi
6496  * \endcode
6497  * \arg for <a href="https://projects.coin-or.org/Cbc">cbc</a>
6498  * \code
6499  * make testcbc
6500  * \endcode
6501  * \arg for <a href="http://www.mosek.com/">mosek</a>
6502  * \code
6503  * make testmosek
6504  * \endcode
6505  * \arg for <a href="http://www.gnu.org/software/glpk/">glpk</a>
6506  * \code
6507  * make testglpk
6508  * \endcode
6509  * \arg for <a href="https://projects.coin-or.org/SYMPHONY">symphony</a>
6510  * \code
6511  * make testsymphony
6512  * \endcode
6513  * \arg for <a href="https://projects.coin-or.org/CHiPPS">blis</a>
6514  * \code
6515  * make testblis
6516  * \endcode
6517  * \arg for <a href="http://www.gams.com/">gams</a>
6518  * \code
6519  * make testgams GAMSSOLVER=xyz
6520  * \endcode
6521  * For this target, the option GAMSSOLVER has to be given to specify the name of a GAMS solver to run, e.g. GAMSSOLVER=SCIP.
6522  * Additional advanced options specific to this target are:
6523  * GAMS to specify the GAMS executable (default: gams),
6524  * GAP to specify a gap limit (default: 0.0),
6525  * CLIENTTMPDIR to specify a directory where GAMS should put its scratch files (default: /tmp),
6526  * 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).
6527  * The following options are NOT supported (and ignored): DISPFREQ, FEASTOL, LOCK.
6528  * 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).
6529  *
6530  * Note: This works only if the referred programs are installed globally on your machine.
6531  *
6532  * The above options like <code>TIME</code> are also available for the other solvers.
6533  *
6534  * For cbc, cplex, gams, and gurobi another advanced option is available:
6535  * \arg <code>THREADS</code> - number of threads used in the solution process
6536  *
6537  * After the testrun there should be an <code>.out</code>, an <code>.err</code> and a <code>.res</code> file
6538  * with the same basename as described above.
6539  *
6540  * Furthermore you can also use the script <code>allcmpres.sh</code> for comparing results of different solvers.
6541  *
6542  */
6543 
6544 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6545 /**@page CHG1 Interface changes between SCIP 0.9 and SCIP 1.0
6546  *
6547  * @section CHGPARAM New parameters
6548  *
6549  * - All functions SCIP<datatype>Param() got a new parameter "isadvanced".
6550  * \n
6551  * This does not influence the performance of SCIP, but the position of the parameter in the settings menu.
6552  * Hence, if you do not care about this, you can assign any value to it.
6553  * You should add the corresponding flag to the SCIP<datatype>Param() calls in your own source code.
6554  *
6555  */
6556 
6557 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6558 /**@page CHG2 Interface changes between SCIP 1.0 and SCIP 1.1
6559  *
6560  * - SCIPcreateChild() has a new last parameter giving an estimate for value of best feasible solution in the subtree to
6561  * be created. One possibility is to use SCIPgetLocalOrigEstimate() for this value.
6562  *
6563  * - The callback \ref CONSCHECK in the constraint handlers now has a new parameter <code>printreason</code> that tells
6564  * a constraint handler to output the reason for a possible infeasibility of the solution to be checked using
6565  * SCIPinfoMessage(). Have a look at one of the constraint handlers implemented in SCIP to see how it works. This
6566  * methodology makes it possible to output the reason of a violation in human readable form, for instance, for the check
6567  * at the end of a SCIP run, where the obtained best solution is checked against the original formulation.\n This change
6568  * often has little effect on C-implementations, since this parameter can be safely ignored with respect to the
6569  * correctness of the code. The corresponding C++ method scip::ObjConshdlr::scip_check(), however, has to be extended
6570  * and will not compile otherwise.
6571  *
6572  * - SCIPcheckSolOrig() is restructured. The last two parameters have changed. They are now bools indicating
6573  * whether the reason for the violation should be printed to the standard output and whether all violations should be
6574  * printed. This reflects the changes in the constraint handlers above, which allow the automation of the feasibility
6575  * test. The pointers to store the constraint handler or constraint are not needed anymore.
6576  *
6577  * - New parameters "extension" and "genericnames" in SCIPprintTransProblem(), SCIPprintOrigProblem(),
6578  * SCIPwriteOrigProblem(), and SCIPwriteTransProblem() defining the requested format or NULL for default CIP format
6579  * and using generic names for the variables and constraints. Examples are
6580  * - <code>SCIPprintTransProblem(scip, NULL, NULL, TRUE)</code> displays the transformed problem in CIP format with
6581  * generic variables and constraint names
6582  * - <code>SCIPprintOrigProblem(scip, NULL, "lp", FALSE)</code> displays the original problem in LP format with
6583  * original variables and constraint names.
6584  *
6585  * - New callback method SCIP_DECL_READERWRITE(x) in type_reader.h; this method is called to write a problem to file
6586  * stream in the format the reader stands for; useful for writing the transformed problem in LP or MPS format. Hence,
6587  * also SCIPincludeReader() has changed.
6588  *
6589  * - New parameter "conshdlrname" in SCIPincludeLinconsUpgrade().
6590  *
6591  * - Added user pointer to callback methods of hash table, see pub_misc.h.
6592  *
6593  * - New parameter "extension" in SCIPreadProb(), defining a desired file format or NULL if file extension should be used.
6594  */
6595 
6596 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6597 /**@page CHG3 Interface changes between SCIP 1.1 and SCIP 1.2
6598  *
6599  *
6600  * @section CHGCALLBACKS New and changed callbacks
6601  *
6602  * - The callback SCIP_DECL_PRICERREDCOST(x) in the \ref PRICER "pricers" has two new parameters:
6603  * - A <code>result</code> pointer determines whether the pricer guarantees that there exist no more variables. This allows for early branching.
6604  * - A pointer for providing a lower bound.
6605  *
6606  * - The \ref CONS "constraint handlers" have two new callback methods (see type_cons.h for more details).
6607  * - SCIP_DECL_CONSCOPY(x) - this method can be used to copy a constraint.
6608  * - SCIP_DECL_CONSPARSE(x) - this method can be used to parse a constraint in CIP format.
6609  *
6610  * @section CHGINTERFUNC New parameters in interface methods
6611  *
6612  * - SCIPcalcMIR() in scip.h has two new parameter "mksetcoefsvalid" and "sol". The parameter "mksetcoefsvalid" stores
6613  * whether the coefficients of the mixed knapsack set ("mksetcoefs") computed in SCIPlpCalcMIR() are valid. If the mixed knapsack constraint obtained after aggregating LP rows
6614  * 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.
6615  * The input parameter "sol" can be used to separate a solution different from the LP solution.
6616  *
6617  * - 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.
6618  *
6619  * @section MISCELLANEOUS Miscellaneous
6620  *
6621  * - A significant change for <b>C++ users</b> is that all include files of SCIP
6622  * automatically detect C++ mode, i.e., no <code>extern "C"</code> is needed anymore.
6623  *
6624  * For further release notes we refer to the \ref RELEASENOTES "Release notes".
6625  */
6626 
6627 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6628 /**@page CHG4 Interface changes between SCIP 1.2 and SCIP 2.0
6629  *
6630  *
6631  * @section CHGCALLBACKS4 New and changed callbacks
6632  *
6633  *
6634  * - <b>Copying a SCIP instance</b>:
6635  * <br>
6636  * <br>
6637  * - All plugins, like \ref BRANCH "branching rules" and \ref HEUR "primal heuristics", have a new callback method (see, e.g.,
6638  * type_branch.h and type_heur.h for more details):
6639  * - SCIP_DECL_BRANCHCOPY(x), SCIP_DECL_HEURCOPY(x) etc.
6640  * - When copying a SCIP instance, these methods are called to copy the plugins.
6641  * <br>
6642  * <br>
6643  * - Constraint handlers have two new callback methods. One for copying the constraint handler plugins
6644  * SCIP_DECL_CONSHDLRCOPY() and the other for copying a constraint itself, SCIP_DECL_CONSCOPY().
6645  * <br>
6646  * <br>
6647  * - Variables have a new callback method (see type_var.h for more details):
6648  * - SCIP_DECL_VARCOPY(x) - When copying a SCIP instance, this method is called to copy the variables' data.
6649  * <br>
6650  * <br>
6651  * - The main problem has a new callback method (see type_prob.h for more details):
6652  * - SCIP_DECL_PROBCOPY(x) - When copying a SCIP instance, this method is called to copy the problem's data.
6653  * <br>
6654  * <br>
6655  * - The argument success in SCIP_DECL_CONSCOPY has been renamed to valid.
6656  *
6657  * - <b>Branching on externally given candidates</b>:
6658  * <br>
6659  * <br>
6660  * - The \ref BRANCH "branching rules" have a second new callback method (see type_branch.h for more details):
6661  * - SCIP_DECL_BRANCHEXECEXT(x) - This method can be used to branch on external branching candidates,
6662  * which can be added by a user's "relaxation handler" or "constraint handler" plugin, calling <code>SCIPaddExternBranchCand()</code>.
6663  *
6664  * - <b>Restarts</b>:
6665  * <br>
6666  * <br>
6667  * - The callback SCIP_DECL_PROBEXITSOL(x) in the main problem has one new parameter (see type_prob.h for more details):
6668  * - The parameter <code>restart</code> is <code>TRUE</code> if the callback method was triggered by a restart.
6669  *
6670  *
6671  * <br>
6672  * @section CHGINTERFUNC4 Changed interface methods
6673  *
6674  * - <b>Copying a SCIP instance</b>:
6675  * <br>
6676  * <br>
6677  * - Every new callback method resulted in a new parameter of the include function for the corresponding plugin,
6678  * e.g., SCIPincludeBranchrule() has two new parameters <code>SCIP_DECL_BRANCHCOPY((*branchcopy))</code> and
6679  * <code>SCIP_DECL_BRANCHEXECREL((*branchexecrel))</code>. In the same fashion, the new callbacks
6680  * SCIP_DECL_VARCOPY and SCIP_DECL_PROBCOPY led to new parameters in SCIPcreateVar() and SCIPcreateProb() in
6681  * scip.c, respectively.
6682  * <br><br>
6683  * - SCIPincludeHeur() and SCIPincludeSepa() in \ref scip.h, as well as scip::ObjSepa() and scip::ObjHeur(), have a new parameter:
6684  * - <code>usessubscip</code> - It can be used to inform SCIP that the heuristic/separator to be included uses a secondary SCIP instance.
6685  * <br><br>
6686  * - SCIPapplyRens() in \ref heur_rens.h has a new parameter <code>uselprows</code>. It can be used to switch from LP rows
6687  * to constraints as basis of the sub-SCIP constructed in the RENS heuristic.
6688  * <br>
6689  * <br>
6690  * - W.r.t. to copy and the C++ wrapper classes there are two new classes. These are <code>ObjCloneable</code> and
6691  * <code>ObjProbCloneable</code>. The constraint handlers and variables pricers are derived from
6692  * <code>ObjProbCloneable</code> and all other plugin are derived from <code>ObjCloneable</code>. Both
6693  * classes implement the function <code>iscloneable()</code> which return whether a plugin is clone
6694  * able or not. Besides that
6695  * each class has a function named <code>clone()</code> which differ in their signature.
6696  * See objcloneable.h, objprobcloneable.h, and the TSP example for more details.
6697  *
6698  * - <b>Branching</b>:
6699  * <br><br>
6700  * - The method SCIPgetVarStrongbranch() has been replaced by two methods SCIPgetVarStrongbranchFrac() and
6701  * SCIPgetVarStrongbranchInt().
6702  * <br><br>
6703  * - The methods SCIPgetVarPseudocost() and SCIPgetVarPseudocostCurrentRun() in \ref scip.h now return the pseudocost value of
6704  * one branching direction, scaled to a unit interval. The former versions of SCIPgetVarPseudocost() and
6705  * SCIPgetVarPseudocostCurrentRun() are now called SCIPgetVarPseudocostVal() and SCIPgetVarPseudocostValCurrentRun(), respectively.
6706  * <br>
6707  * <br>
6708  * - The methods SCIPgetVarConflictScore() and SCIPgetVarConflictScoreCurrentRun() in \ref scip.h are now called
6709  * SCIPgetVarVSIDS() and SCIPgetVarVSIDSCurrentRun(), respectively.
6710  * <br><br>
6711  * - The methods SCIPvarGetNInferences(), SCIPvarGetNInferencesCurrentRun(), SCIPvarGetNCutoffs(), and
6712  * SCIPvarGetNCutoffsCurrentRun() are now called SCIPvarGetInferenceSum(), SCIPvarGetInferenceSumCurrentRun(),
6713  * SCIPvarGetCutoffSum(), and SCIPvarGetCutoffSumCurrentRun(), respectively. Furthermore, they now return
6714  * <code>SCIP_Real</code> instead of <code>SCIP_Longint</code> values.
6715  *
6716  * - <b>Others</b>:
6717  * <br><br>
6718  * - SCIPcutGenerationHeuristicCmir() in \ref sepa_cmir.h has three new parameters:
6719  * - <code>maxmksetcoefs</code> - If the mixed knapsack constraint obtained after aggregating LP rows contains more
6720  * than <code>maxmksetcoefs</code> nonzero coefficients the generation of the <b>c-MIR cut</b> is aborted.
6721  * - <code>delta</code> - It can be used to obtain the scaling factor which leads to the best c-MIR cut found within
6722  * the cut generation heuristic. If a <code>NULL</code> pointer is passed, the corresponding c-MIR cut will already be
6723  * added to SCIP by SCIPcutGenerationHeuristicCmir(). Otherwise, the user can generate the cut and add it to SCIP
6724  * on demand afterwards.
6725  * - <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>,
6726  * <code>deltavalid</code> will be <code>TRUE</code> if the stored scaling factor <code>delta</code> will lead to a violated c-MIR cut.
6727  * <br>
6728  * <br>
6729  * - All functions for setting <b>user parameters</b> of different types like SCIPparamSetBool(), SCIPparamSetChar(),
6730  * SCIPparamSetInt(), SCIPparamSetLongint(), and SCIPparamSetString() in pub_paramset.h have a new parameter:
6731  * - <code>quiet</code> - It prevents any output during the assign to a new value.
6732  *
6733  * <br>
6734  * @section MISCELLANEOUS4 Miscellaneous
6735  *
6736  * - The NLPI library is now a separate library that is required when linking against the SCIP library.
6737  * This requires changes to Makefiles that use SCIP, see the \ref RELEASENOTES "Release notes" for more details.
6738  *
6739  * - We do not distinguish between <b>block memory</b> for the original and the transformed problem anymore. The same
6740  * block memory is now used in both problem stages.
6741  *
6742  * - The usage of <b>strong branching</b> changed. Now, SCIPstartStrongbranch() and SCIPendStrongbranch() must be
6743  * called before and after strong branching, respectively.
6744  *
6745  * - All <b>C++</b> objects and constructors have a SCIP pointer, now.
6746  *
6747  * - The <b>predefined setting files</b> like "settings/cuts/off.set,aggressive.set,fast.set" have been replaced by
6748  * interface methods like SCIPsetHeuristics(), SCIPsetPresolving(), SCIPsetSeparating(), and SCIPsetEmphasis() in
6749  * \ref scip.h and by user dialogs in the interactive shell like
6750  * <br>
6751  * <br>
6752  * <code>SCIP&gt; set {heuristics|presolving|separating} emphasis {aggressive|fast|off}</code>
6753  * <br>
6754  * <br>
6755  * or
6756  * <br>
6757  * <br>
6758  * <code>SCIP&gt; set emphasis {counter|cpsolver|easycip|feasibility|hardlp|optimality}</code>
6759  *
6760  *
6761  * <br>
6762  * For further release notes we refer to the \ref RELEASENOTES "Release notes".
6763  */
6764 
6765 /* - SCIP now has "lazy bounds", which are useful for column generation - see @ref PRICER_REMARKS "pricer remarks" for an explanation.
6766  *
6767  * - SCIP has rudimentary support to solve quadratic nonlinear integer programs - see \ref cons_quadratic.h.
6768  *
6769  * - There are LP-interfaces to QSopt and Gurobi (rudimentary).
6770  *
6771  * - SCIP can now handle indicator constraints (reading (from LP, ZIMPL), writing, solving, ...) - see \ref cons_indicator.h.
6772  *
6773  * - One can now do "early branching" useful for column generation.
6774  *
6775  * - Can now run a black-box lexicographic dual simplex algorithm.
6776  */
6777 
6778  /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6779  /**@page CHG5 Interface changes between SCIP 2.0 and SCIP 2.1
6780  *
6781  *
6782  * @section CHGCALLBACKS5 New and changed callbacks
6783  *
6784  * - <b>Presolving</b>:
6785  * <br>
6786  * <br>
6787  * - The new parameters "nnewaddconss" and "naddconss" were added to the constraint handler callback method SCIP_DECL_CONSPRESOL()
6788  * and the presolver callback method SCIP_DECL_PRESOLEXEC(). These parameters were also added to corresponding C++ wrapper class methods.
6789  * - Propagators are now also called in during presolving, this is supported by the new callback methods SCIP_DECL_PROPINITPRE(),
6790  * SCIP_DECL_PROPEXITPRE(), and SCIP_DECL_PROPPRESOL().
6791  * - New parameters "isunbounded" and "isinfeasible" for presolving initialization (SCIP_DECL_CONSINITPRE(),
6792  * SCIP_DECL_PRESOLINITPRE(), SCIP_DECL_PROPINITPRE()) and presolving deinitialization (SCIP_DECL_CONSEXITPRE(),
6793  * SCIP_DECL_PRESOLEXITPRE(), SCIP_DECL_PROPEXITPRE()) callbacks of presolvers,
6794  * constraint handlers and propagators, telling the callback whether the problem was already declared to be
6795  * unbounded or infeasible. This allows to avoid expensive steps in these methods in case the problem is already
6796  * solved, anyway.
6797  * <br>
6798  * <br>
6799  * <DIV class="note">
6800  * Note, that the C++ methods
6801  * - scip::ObjConshdlr::scip_presol() corresponding to SCIP_DECL_CONSPRESOL()
6802  * - scip::ObjConshdlr::scip_initpre() corresponding to SCIP_DECL_CONSINITPRE()
6803  * - scip::ObjPresol::scip_initpre() corresponding to SCIP_DECL_PRESOLINITPRE()
6804  * - scip::ObjProp::scip_initpre() corresponding to SCIP_DECL_PROPINITPRE()
6805  * - scip::ObjConshdlr::scip_exitpre() corresponding to SCIP_DECL_CONSEXITPRE()
6806  * - scip::ObjPresol::scip_exitpre() corresponding to SCIP_DECL_PRESOLEXITPRE()
6807  * - scip::ObjProp::scip_exitpre() corresponding to and SCIP_DECL_PROPEXITPRE()
6808  * .
6809  * are virtual functions. That means, if you are not adding the new parameters, your code will still compile, but these methods are not executed.
6810  * </DIV>
6811  *
6812  * - <b>Constraint Handler</b>:
6813  * <br>
6814  * <br>
6815  * - The new constraint handler callback SCIP_DECL_CONSDELVARS() is called after variables were marked for deletion.
6816  * This method is optional and only of interest if you are using SCIP as a branch-and-price framework. That means,
6817  * you are generating new variables during the search. If you are not doing that just define the function pointer
6818  * to be NULL.
6819  * <br>
6820  * If this method gets implemented you should iterate over all constraints of the constraint handler and delete all
6821  * variables that were marked for deletion by SCIPdelVar().
6822  *
6823  * - <b>Problem Data</b>:
6824  * <br>
6825  * <br>
6826  * - 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.
6827  *
6828  * - <b>Conflict Analysis</b>:
6829  * <br>
6830  * <br>
6831  * - Added parameter "separate" to conflict handler callback method SCIP_DECL_CONFLICTEXEC() that defines whether the conflict constraint should be separated or not.
6832  *
6833  * - <b>NLP Solver Interface</b>:
6834  * <br>
6835  * <br>
6836  * - The callbacks SCIP_DECL_NLPIGETSOLUTION() and SCIP_DECL_NLPISETINITIALGUESS() got new parameters to get/set values of dual variables.
6837  * - The callback SCIP_DECL_NLPICOPY() now passes the block memory of the target SCIP as an additional parameter.
6838  *
6839  * <br>
6840  * @section CHGINTERFUNC5 Changed interface methods
6841  *
6842  * - <b>Writing and Parsing constraints</b>:
6843  * <br>
6844  * <br>
6845  * - The methods SCIPwriteVarName(), SCIPwriteVarsList(), and SCIPwriteVarsLinearsum() got a new boolean parameter "type"
6846  * that indicates whether the variable type should be written or not.
6847  * - The method SCIPwriteVarsList() got additionally a new parameter "delimiter" that defines the character which is used for delimitation.
6848  * - The methods SCIPparseVarName() and SCIPparseVarsList() got a new output parameter "endptr" that is filled with the position where the parsing stopped.
6849  *
6850  * - <b>Plugin management</b>:
6851  * <br>
6852  * <br>
6853  * - 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.
6854  * - SCIPincludeConshdlr() got additional parameters to set the variable deletion callback function and the timing mask for propagation.
6855  *
6856  * - <b>Constraint Handlers</b>:
6857  * <br>
6858  * <br>
6859  * - Method SCIPseparateRelaxedKnapsack() in knapsack constraint handler got new parameter "cutoff", which is a pointer to store whether a cutoff was found.
6860  * - Method SCIPincludeQuadconsUpgrade() of quadratic constraint handler got new parameter "active" to indicate whether the upgrading method is active by default.
6861  *
6862  * - <b>Nonlinear expressions, relaxation, and solver interface</b>:
6863  * <br>
6864  * <br>
6865  * - The methods SCIPexprtreeEvalSol(), SCIPexprtreeEvalIntLocalBounds(), and SCIPexprtreeEvalIntGlobalBounds() have been renamed to SCIPevalExprtreeSol(),
6866  * SCIPevalExprtreeLocalBounds(), and SCIPevalExprtreeGlobalBounds() and are now located in scip.h.
6867  * - Various types and functions dealing with polynomial expressions have been renamed to use the proper terms "monomial" and "polynomial".
6868  * - The methods SCIPnlpGetObjective(), SCIPnlpGetSolVals(), and SCIPnlpGetVarSolVal() have been removed, use SCIPgetNLPObjval(), SCIPvarGetNLPSol()
6869  * and SCIPcreateNLPSol() to retrieve NLP solution values instead.
6870  * - Removed methods SCIPmarkRequireNLP() and SCIPisNLPRequired(), because the NLP is now always constructed if nonlinearities are present.
6871  * - SCIPgetNLP() has been removed and NLP-methods from pub_nlp.h have been moved to scip.h, which resulted in some renamings, too.
6872  * - The functions SCIPnlpiGetSolution() and SCIPnlpiSetInitialGuess() got additional arguments to get/set dual values.
6873  * - The method SCIPgetNLPI() got a new parameter "nlpiproblem", which is a pointer to store the NLP solver interface problem.
6874  *
6875  * - <b>Others</b>:
6876  * <br>
6877  * <br>
6878  * - 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
6879  * the given variable is contained in the given hash map.
6880  * - Removed method SCIPreadSol(); call solution reading via SCIPreadProb() which calls the solution reader for .sol files.
6881  * - SCIPchgVarType() got an extra boolean parameter to store if infeasibility is recognized while upgrading a variable from continuous type to an integer type.
6882  * - SCIPdelVar() got a new parameter "deleted", which stores whether the variable was successfully marked to be deleted.
6883  * - SCIPcalcNodeselPriority() got a new parameter "branchdir", which defines the type of branching that was performed: upwards, downwards, or fixed.
6884  * - The parameters "timelimit" and "memorylimit" were removed from SCIPapplyRens().
6885  *
6886  * <br>
6887  * @section MISCELLANEOUS5 Miscellaneous
6888  *
6889  * - The result value SCIP_NEWROUND has been added, it allows a separator/constraint handler to start a new separation round
6890  * (without previous calls to other separators/conshdlrs).
6891  * - All timing flags are now defined type_timing.h.
6892  * - The variable deletion event is now a variable specific event and not global, anymore.
6893  * - The emphasis setting types now distinguish between plugin-type specific parameter settings (default, aggressive, fast, off), which are changed by
6894  * SCIPsetHeuristics/Presolving/Separating(), and global emphasis settings (default, cpsolver, easycip, feasibility, hardlp, optimality, counter),
6895  * which can be set using SCIPsetEmphasis().
6896  *
6897  * <br>
6898  * For further release notes we refer to the \ref RELEASENOTES "Release notes".
6899  */
6900 
6901  /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6902  /**@page CHG6 Interface changes between SCIP 2.1 and SCIP 3.0
6903  *
6904  *
6905  * @section CHGCALLBACKS6 New and changed callbacks
6906  *
6907  * - <b>Conflict Analysis</b>:
6908  * <br>
6909  * <br>
6910  * - Added parameter "relaxedbds" to conflict handler callback method SCIP_DECL_CONFLICTEXEC(). This array contains
6911  * bounds which are sufficient to create a valid conflict
6912  *
6913  * - <b>Constraint Handler</b>:
6914  * <br>
6915  * <br>
6916  * - New optional callback methods in constraint handlers: SCIP_DECL_CONSGETVARS and SCIP_DECL_CONSGETNVARS.
6917  * These callbacks, if implemented, should return an array of all variables and the number of all variables used
6918  * by the given constraint, respectively. (This method might, e.g., be called by a presolver)
6919  * - Added a propagation timing parameter "proptiming" to SCIP_DECL_CONSPROP(), giving the current timing at which
6920  * this method is called
6921  * - Added a parameter 'restart' to the SCIP_DECL_CONSEXITSOL() callback method, indicating whether this call was
6922  * triggered by a restart.
6923  * - Added a parameter 'relaxedbd' to SCIP_DECL_CONSRESPROP() callback method. If explaining a given bound change
6924  * (index), it is sufficient to explain the reason for reaching the 'relaxedbd' value, see above
6925  * - Removed parameters "isunbounded", "isinfeasible" and "result" from SCIP_DECL_CONSINITPRE() and
6926  * SCIP_DECL_CONSEXITPRE() callback methods. It is not allowed to determine unboundedness or infeasibility in
6927  * these callbacks, anymore.
6928  *
6929  * - <b>Message Handler</b>:
6930  * <br>
6931  * <br>
6932  * - New callback method SCIP_DECL_MESSAGEHDLRFREE() which is called when the message handler is freed.
6933  * - The old callback method SCIP_DECL_MESSAGEERROR() was replaced by the callback method SCIP_DECL_ERRORPRINTING().
6934  *
6935  * - <b>Presolving</b>:
6936  * <br>
6937  * <br>
6938  * - Removed parameters "isunbounded", "isinfeasible" and "result" from SCIP_DECL_PRESOLINITPRE() and
6939  * SCIP_DECL_PRESOLSEXITPRE(). It is not allowed to determine unboundedness or infeasibility in these
6940  * callbacks, anymore.
6941  *
6942  * - <b>Propagator</b>:
6943  * <br>
6944  * <br>
6945  * - Added a propagation timing parameter "proptiming" to SCIP_DECL_PROPEXEC(), giving the
6946  * current timing at which this method is called.
6947  * - Added a parameter 'restart' to SCIP_DECL_PROPEXITSOL() callback method, indicating whether this call was
6948  * triggered by a restart.
6949  * - Added a parameter 'relaxedbd' to SCIP_DECL_PROPRESPROP() callback method. If explaining a given bound change
6950  * (index), it is sufficient to explain the reason for reaching the 'relaxedbd' value.
6951  * - Removed parameters "isunbounded", "isinfeasible" and "result" from SCIP_DECL_PROPINITPRE() and
6952  * SCIP_DECL_PROPEXITPRE() callback methods. It is not allowed to determined unboundedness or infeasibility in
6953  * these callbacks, anymore.
6954  *
6955  * - <b>NLP Solver Interface</b>:
6956  * <br>
6957  * <br>
6958  * - New NLPI callback SCIP_DECL_NLPISETMESSAGEHDLR() to set message handler in NLP solver interfaces.
6959  *
6960  * <br>
6961  * @section CHGINTERFUNC6 Changed interface methods
6962  *
6963  * - <b>Plugin management</b>:
6964  * <br>
6965  * <br>
6966  * - Added basic include methods for almost all plugin types, e.g., SCIPincludeConshdlrBasic();
6967  * these methods should make the usage easier, sparing out optional callbacks and parameters.
6968  * - To extend the basic functionalities, there are setter method to add
6969  * optional callbacks. For example SCIPsetConshdlrParse(), SCIPsetPropCopy() or SCIPsetHeurInitsol().
6970  *
6971  * - <b>Constraint Handlers</b>:
6972  * <br>
6973  * <br>
6974  * - Added basic creation methods for all constraints types, e.g., SCIPcreateConsBasicLinear(); these methods should make the usage easier,
6975  * sparing out optional callbacks and parameters.
6976  * - New methods SCIPgetConsVars() and SCIPgetConsNVars() (corresponding callbacks need to be implemented, see above)
6977  *
6978  * - <b>Problem</b>:
6979  * <br>
6980  * <br>
6981  * - Added basic creation methods SCIPcreateVarBasic() and SCIPcreateProbBasic() and setter functions
6982  * - Added method SCIPisPresolveFinished() which returns whether the presolving process would be stopped after the
6983  * current presolving round, given no further reductions will be found.
6984  * - Forbid problem modifications in SCIP_STAGE_{INIT,EXIT}PRESOLVE (see pre-conditions for corresponding methods in scip.h).
6985  *
6986  * - <b>Variable usage</b>:
6987  * <br>
6988  * <br>
6989  * - Renamed SCIPvarGetBestBound() to SCIPvarGetBestBoundLocal(), SCIPvarGetWorstBound() to
6990  * SCIPvarGetWorstBoundLocal() and added new methods SCIPvarGetBestBoundGlobal() and SCIPvarGetWorstBoundGlobal().
6991  * - Method SCIPvarGetProbvarSum() is not public anymore, use SCIPgetProbvarSum() instead.
6992  * - Replaced method SCIPvarGetRootRedcost() by SCIPvarGetBestRootRedcost().
6993  *
6994  * - <b>Message Handler</b>:
6995  * <br>
6996  * <br>
6997  * - Changed the message handler system within SCIP heavily such that it is thread-safe. SCIPcreateMessagehdlr() in
6998  * scip.{c,h} was replaced by SCIPmessagehdlrCreate() in pub_message.h/message.c with a changed parameter list.
6999  * - Error messages (SCIPerrorMessage()) are not handled via the message handler anymore; per default the error
7000  * message is written to stderr.
7001  *
7002  * - <b>Separation</b>:
7003  * <br>
7004  * <br>
7005  * - New functions SCIPcreateEmptyRowCons(), SCIPcreateEmptyRowSepa(), SCIPcreateRowCons(), and SCIPcreateRowSepa()
7006  * that allow to set the originating constraint handler or separator of a row respectively; this is, for instance,
7007  * needed for statistics on the number of applied cuts. If rows are created outside a constraint handler or separator
7008  * use SCIPcreateRowUnspec() and SCIPcreateEmptyRowUnspec(). The use of SCIPcreateEmptyRow() and SCIPcreateRow() is
7009  * deprecated.
7010  * - New functions SCIProwGetOrigintype(), SCIProwGetOriginCons(), and SCIProwGetOriginSepa() to obtain the originator
7011  * that created a row.
7012  *
7013  * - <b>LP interface</b>:
7014  * <br>
7015  * <br>
7016  * - SCIPlpiCreate() got a new parameter 'messagehdlr'.
7017  * - SoPlex LPI supports setting of SCIP_LPPAR_DUALFEASTOL when using SoPlex version 1.6.0.5 and higher.
7018  *
7019  * - <b>Nonlinear expressions, relaxation, and solver interface</b>:
7020  * <br>
7021  * <br>
7022  * - Renamed SCIPmarkNonlinearitiesPresent() to SCIPenableNLP() and SCIPhasNonlinearitiesPresent() to
7023  * SCIPisNLPEnabled().
7024  * - Method SCIPexprtreeRemoveFixedVars() is not public anymore.
7025  *
7026  * - <b>Counting</b>:
7027  * <br>
7028  * <br>
7029  * - Changed the counting system within SCIP heavily. SPARSESOLUTION was renamed to SCIP_SPARSESOL. New method for
7030  * SCIP_SPARSESOL usage, SCIPsparseSolCreate(), SCIPsparseSolFree(), SCIPsparseSolGetVars(),
7031  * SCIPsparseSolGetNVars(), SCIPsparseSolGetLbs(), SCIPsparseSolGetUbs() in (pub_)misc.{c,h}.
7032  * - Renamed SCIPgetCountedSparseSolutions() to SCIPgetCountedSparseSols() in cons_countsols.{c,h}.
7033  *
7034  * <br>
7035  * @section MISCELLANEOUS6 Miscellaneous
7036  *
7037  * - Replaced SCIPparamSet*() by SCIPchg*Param() (where * is either Bool, Int, Longint, Real, Char, or String).
7038  * - New parameter in SCIPcopy() and SCIPcopyPlugins() to indicate whether the message handler from the source SCIP
7039  * should be passed to the target SCIP (only the pointer is copied and the usage counter of the message handler is
7040  * increased).
7041  * - SCIPprintCons() does not print termination symbol ";\n" anymore; if wanted, use SCIPinfoMessage() to print
7042  * ";\n" manually
7043  * - All objscip *.h file now use the default SCIP interface macros.
7044  * - The methods SCIPsortedvecInsert*() have an additional parameter which can be used to receive the position where
7045  * the new element was inserted.
7046  * - New macro SCIPdebugPrintCons() to print constraint only if SCIP_DEBUG flag is set.
7047  *
7048  * <br>
7049  * For further information we refer to the \ref RELEASENOTES "Release notes" and the \ref CHANGELOG "Changelog".
7050  */
7051 
7052  /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
7053  /**@page CHG7 Interface changes between SCIP 3.0 and SCIP 3.1
7054  *
7055  *
7056  * @section CHGCALLBACKS7 New and changed callbacks
7057  *
7058  * - <b>Branching Rules</b>:
7059  * <br>
7060  * <br>
7061  * - new possible return value "SCIP_DIDNOTFIND" for SCIP_DECL_BRANCHEXECLP(), SCIP_DECL_BRANCHEXECPS(), and
7062  * SCIP_DECL_BRANCHEXECEXT() callbacks to state that the branching rule searched, but did not find a branching.
7063  *
7064  * - <b>Domain Propagation</b>:
7065  * <br>
7066  * <br>
7067  * - added parameter "nmarkedconss" to SCIP_DECL_CONSPROP() callback which gives the number of constraints marked
7068  * for propagation (these constraints are listed first in the conss array given as parameter).
7069  *
7070  * - <b>Message Handler</b>:
7071  * <br>
7072  * <br>
7073  * - New generic messagehandler output callback method SCIP_DECL_MESSAGEOUTPUTFUNC().
7074  * - Removed parameter "msglength" from callback method SCIP_DECL_ERRORPRINTING().
7075  *
7076  * - <b>Variable Pricers</b>:
7077  * <br>
7078  * <br>
7079  * - Added parameter "stopearly" to callback method SCIP_DECL_PRICERREDCOST(). This boolean pointer should be used
7080  * by the pricer to state whether early branching should be performed, even if new variables were added in the
7081  * current pricing round.
7082  *
7083  * - <b>Primal Heuristics</b>:
7084  * <br>
7085  * <br>
7086  * - Added parameter "nodeinfeasible" to SCIP_DECL_HEUREXEC() callback which states whether the current subproblem
7087  * was already detected to be infeasible. In this case, the current LP solution might not respect local bounds,
7088  * and the heuristic must not assume that it does.
7089  *
7090  *
7091  * <br>
7092  * @section CHGINTERFUNC7 Changed interface methods
7093  *
7094  * - <b>Branching Rules</b>:
7095  * <br>
7096  * <br>
7097  * - Added parameter "nfracimplvars" to SCIPgetLPBranchCands()
7098  *
7099  * - <b>Constraint Handlers</b>:
7100  * <br>
7101  * <br>
7102  * - New method SCIPconshdlrGetStrongBranchPropTime() which returns the time used for domain propagation methods
7103  * of the constraint handler during strong branching.
7104  * - New method SCIPconsIsMarkedPropagate() which returns whether a constraint is marked for propagation.
7105  * - New methods SCIPconsAddUpgradeLocks() and SCIPconsGetNUpgradeLocks() to increase or get the number of upgrade
7106  * locks of a constraint.
7107  *
7108  * - <b>Domain Propagation</b>:
7109  * <br>
7110  * <br>
7111  * - New method SCIPpropGetStrongBranchPropTime() which returns the time spent by a domain propagator during strong
7112  * branching.
7113  * - New methods SCIPmarkConsPropagate() and SCIPunmarkConsPropagate to (un)mark a constraint for propagation.
7114  *
7115  * - <b>LP and Cutting Planes</b>:
7116  * <br>
7117  * <br>
7118  * - New methods SCIProwChgRank() and SCIProwGetRank() to change and get the rank of a cutting plane, respectively.
7119  * - Added parameter "sidetypes" to SCIPcalcMIR() to specify the specify row side type to be used.
7120  * - Added parameter "cutrank" to SCIPcalcMIR() and SCIPcalcStrongCG() which stores the rank of the returned cut.
7121  * - New method SCIPisCutApplicable() which returns whether a cut is good enough to be applied.
7122  * - Added parameter "infeasible" to SCIPaddCut() which is a pointer to store whether the cut is infeasible for the
7123  * local bounds.
7124  * - delayed cutpool
7125  * - New methods SCIPchgRowLhsDive() and SCIPchgRowRhsDive() to change left and right hand side of a row during diving.
7126  * - Added parameter "cutoff" to SCIPsolveDiveLP(), SCIPsolveProbingLP(), and SCIPsolveProbingLPWithPricing()
7127  * which is a pointer to store whether the diving/probing LP was infeasible or the objective limit was reached.
7128  *
7129  * - <b>Message Handler</b>:
7130  * <br>
7131  * <br>
7132  * - New method SCIPmessageVPrintError() to print an error message.
7133  * - Removed method SCIPmessagePrintWarningHeader().
7134  *
7135  * - <b>Parameters</b>:
7136  * <br>
7137  * <br>
7138  * - New method SCIPparamGetCharAllowedValues() to get the allowed values for a char parameter.
7139  *
7140  * - <b>Variables</b>:
7141  * <br>
7142  * <br>
7143  * - New structure to store value-based branching and inference history (see pub_history.h).
7144  * - New method SCIPvarGetValuehistory() to get the value-based history of a variable.
7145  *
7146  * - <b>Data structures</b>:
7147  * <br>
7148  * <br>
7149  * - New method SCIPgmlWriteNodeWeight() to write a node section including weight to a .gml graph file.
7150  * - New methods SCIPsparseSolGetFirstSol() and SCIPsparseSolGetNextSol() to get the first sparse solution
7151  * or iterate over the sparse solutions, respectively.
7152  * - New methods in pub_misc.h to handle a (circular) queue, e.g., SCIPqueueCreate(), SCIPqueueFree(),
7153  * SCIPqueueInsert(), ...
7154  * - New methods for hash tables: SCIPhashtableRemoveAll(), SCIPhashtableGetNElements(), SCIPhashtableGetLoad()
7155  * - New methods in pub_misc.h to handle a resource activity, e.g., SCIPactivityCreate(), SCIPactivityFree(),
7156  * SCIPactivityGetVar(), SCIPactivityGetDemand() ...
7157  * - New methods for digraphs: SCIPdigraphResize() to resize the graph and SCIPdigraphSetNodeDatas() and
7158  * SCIPdigraphGetNodeDatas() to set and get the data attached to the nodes.
7159  *
7160  * - <b>Misc</b>:
7161  * <br>
7162  * <br>
7163  * - New method SCIPcopyOrig() to copy the original problem. Analoguosly, use SCIPcopyOrigProb(), SCIPcopyOrigVars(),
7164  * and SCIPcopyOrigConss() to copy original problem data, variables, or constraints, respectively.
7165  * - New method SCIPcopyImplicationsCliques() to copy implications and cliques to a copied SCIP instance.
7166  * - New method SCIPgetParam() to get the parameter with a given name.
7167  * - New method SCIPaddOrigObjoffset() to add an offset to the objective function.
7168  * - New method SCIPgetNCheckConss() which returns the number of checked constraints.
7169  * - Added parameter "endptr" to SCIPparseVar() which stores the final string position after parsing.
7170  * - Added parameter "enablepropagation" to SCIPstartStrongbranch(), which can be used to enable strong branching
7171  * with domain propagation.
7172  * - New method SCIPgetVarStrongbranchWithPropagation() which performs strong branching with propagation on a variable.
7173  * - New method SCIPwriteCliqueGraph() to write the clique graph.
7174  * - New method SCIPdoNotMultaggr() which returns whether multi-aggregation was disabled.
7175  * - Added parameter "lazyconss" to SCIPwriteMIP() to swith writing removable rows as lazy constraints.
7176  * - New method SCIPcreateFiniteSolCopy() to create a copy of a solution with infinite fixings removed.
7177  * - New method SCIPadjustImplicitSolVals() which sets implicit integer variables to an integer value in the given
7178  * solution without deteriorating its objective value.
7179  * - New method SCIPprintDualSol() which prints the dual solution for a pure LP (works only with preprocessing disabled).
7180  * - New method SCIPgetOpenNodesData() which returns all unprocessed nodes.
7181  * - New method SCIPgetFirstLPTime() and SCIPgetNRootFirstLPIterations() to return time and iterations for the first
7182  * LP solve and SCIPgetFirstLPDualboundRoot() and SCIPgetFirstLPLowerboundRoot() to return the first root LP dual and
7183  * lower bound.
7184  * - New method SCIPgetNLimSolsFound() returning the number of feasible primal solution respecting the objective limit.
7185  * - Added parameter "endline" to SCIPprintDisplayLine() to switch printing a newline symbol at the end of the line.
7186  *
7187  * <br>
7188  * @section MISCELLANEOUS7 Miscellaneous
7189  *
7190  * - Moved LP solver interfaces to subdirectory src/lpi.
7191  *
7192  * <br>
7193  * For further information we refer to the \ref RELEASENOTES "Release notes" and the \ref CHANGELOG "Changelog".
7194  */
7195 
7196  /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
7197  /**@page CHG8 Interface changes between SCIP 3.1 and SCIP 3.2
7198  *
7199  *
7200  * @section CHGCALLBACKS8 New and changed callbacks
7201  *
7202  * - <b>Branching Rules</b>:
7203  * - Added paramter "forcestrongbranch" to SCIPselectVarStrongBranching()
7204  * - Added paramter "executebranching" SCIPexecRelpscostBranching()
7205  * - Added paramter "presoltiming" to SCIPpropCumulativeCondition()
7206  *
7207  * <br>
7208  * - <b>Domain Propagation</b>:
7209  *
7210  * <br>
7211  * - <b>Message Handler</b>:
7212  *
7213  * <br>
7214  * - <b>Variable Pricers</b>:
7215  *
7216  * <br>
7217  * - <b>Primal Heuristics</b>:
7218  * - Added paramter "freesubscip" to SCIPapplyProximity()
7219  *
7220  * <br>
7221  * @section CHGINTERFUNC8 Changed interface methods
7222  *
7223  * <br>
7224  * - <b>Branching Rules</b>:
7225  *
7226  * <br>
7227  * - <b>Constraint Handlers</b>:
7228  * - Removed method SCIPconshdlrIsPresolvingDelayed()
7229  * - Removed method SCIPconshdlrWasPresolvingDelayed()
7230  * - Renamed method SCIPconshdlrGetPropTimingmask() to SCIPconshdlrGetPropTiming()
7231  *
7232  * <br>
7233  * - <b>Domain Propagation</b>:
7234  *
7235  * <br>
7236  * - <b>LP and Cutting Planes</b>:
7237  * - Added parameter "inds" to SCIPgetLPBInvRow()
7238  * - Added parameter "ninds" to SCIPgetLPBInvRow()
7239  * - Added parameter "inds" to SCIPgetLPBInvCol()
7240  * - Added parameter "ninds" to SCIPgetLPBInvCol()
7241  * - Added parameter "inds" to SCIPgetLPBInvARow()
7242  * - Added parameter "ninds" to SCIPgetLPBInvARow()
7243  * - Added parameter "inds" to SCIPgetLPBInvACol()
7244  * - Added parameter "ninds" to SCIPgetLPBInvACol()
7245  * - Added parameter "maxweight" to SCIPcalcMIR()
7246  * - Added parameter "weightinds" to SCIPcalcMIR()
7247  * - Added parameter "nweightinds" to SCIPcalcMIR()
7248  * - Added parameter "rowlensum" to SCIPcalcMIR()
7249  * - Added parameter "inds" to SCIPcalcStrongCG()
7250  * - Added parameter "ninds" to SCIPcalcStrongCG()
7251  *
7252  * <br>
7253  * - <b>Message Handler</b>:
7254  *
7255  * <br>
7256  * - <b>Parameters</b>:
7257  *
7258  * <br>
7259  * - <b>Variables</b>:
7260  * - Removed method SCIPvarGetNBinImpls()
7261  *
7262  * <br>
7263  * - <b>Data structures</b>:
7264  * - Renamed method SCIPdigraphGetNodeDatas() to SCIPdigraphGetNodeData()
7265  * - Renamed method SCIPdigraphSetNodeDatas() to SCIPdigraphSetNodeData()
7266  * - Renamed method SCIPdigraphGetSuccessorsDatas() to SCIPdigraphGetSuccessorsData()
7267  *
7268  * <br>
7269  * - <b>Misc</b>:
7270  * - Removed parameter "delaypos" from SCIPincludeConshdlr()
7271  * - Added parameter "presoltiming" to SCIPincludeConshdlr()
7272  * - Added parameter "consgetdivebdchgs" to SCIPincludeConshdlr()
7273  * - Removed parameter "delaypos" from SCIPsetConshdlrPresol()
7274  * - Added parameter "presoltiming" to SCIPsetConshdlrPresol()
7275  * - Removed parameter "delaypos" from SCIPincludePresol()
7276  * - Added parameter "presoltiming" to SCIPincludePresol()
7277  * - Removed parameter "delaypos" from SCIPincludePresolBasic()
7278  * - Added parameter "presoltiming" to SCIPincludePresolBasic()
7279  * - Removed paramter "presoldelay" from SCIPincludePresol()
7280  * - Removed paramter "presoltiming" from SCIPincludePresol()
7281  * - Removed paramter "presoldelay" from SCIPsetPropPresol()
7282  * - Removed paramter "presoltiming" from SCIPsetPropPresol()
7283  * - Added parameter "ndomredsdown" to SCIPgetVarStrongbranchWithPropagation()
7284  * - Added parameter "ndomredsup" to SCIPgetVarStrongbranchWithPropagation()
7285  * - Added parameter "isequation" to SCIPaddClique()
7286  * - Removed parameter "writeimplications" from SCIPwriteCliqueGraph()
7287  * - Removed method SCIPallocBufferSize()
7288  * - Removed method SCIPduplicateBufferSize()
7289  * - Removed method SCIPreallocBufferSize()
7290  * - Removed method SCIPfreeBufferSize()
7291  * - Removed method callback SCIPdialogExecConflictgraph()
7292  *
7293  * <br>
7294  * @section MISCELLANEOUS7 Miscellaneous
7295  *
7296  * <br>
7297  * For further information we refer to the \ref RELEASENOTES "Release notes" and the \ref CHANGELOG "Changelog".
7298  */
7299 
7300 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
7301 /**@page COUNTER How to use SCIP to count/enumerate feasible solutions
7302  *
7303  * SCIP is capable of computing (count or enumerate) the number of feasible solutions of a given constraint integer
7304  * program. In case continuous variables are present, the number of feasible solutions for the projection to the
7305  * integral variables is counted/enumerated. This means, an assignment to the integer variables is counted if the
7306  * remaining problem (this is the one after fixing the integer variables w.r.t. to this assignment) is feasible.
7307  *
7308  * As a first step you have to load or create your problem in the usual way. In case of using the
7309  * interactive shell, you use the <code>read</code> command:
7310  *
7311  * <code>SCIP&gt; read &lt;file name&gt;</code>
7312  *
7313  * Afterwards you can count the number of feasible solution with the command <code>count</code>.
7314  *
7315  * <code>SCIP&gt; count</code>
7316  *
7317  * That means SCIP will count the number of solution but does not store (enumerate) them. If you are interested in that see
7318  * \ref COLLECTALLFEASEBLES.
7319  *
7320  * @note Since SCIP version 2.0.0 you do not have to worry about <tt>dual</tt> reductions anymore. These are
7321  * automatically turned off. The only thing you should switch off are restarts. These restarts can lead to a wrong
7322  * counting process. We recommend using the counting settings which can be set in the interactive shell as follows:
7323  *
7324  * <code>SCIP&gt; set emphasis counter</code>
7325  *
7326  * The SCIP callable library provides an interface method SCIPcount() which allows users to count the number of feasible
7327  * solutions to their problem. The method SCIPsetParamsCountsols(), which is also located in cons_countsols.h, loads the
7328  * predefined counting settings to ensure a safe count. The complete list of all methods that can be used for counting
7329  * via the callable library can be found in cons_countsols.h.
7330  *
7331  *
7332  * @section COUNTLIMIT Limit the number of solutions which should be counted
7333  *
7334  * It is possible to give a (soft) upper bound on the number solutions that should be counted. If this upper bound is
7335  * exceeded, SCIP will be stopped. The name of this parameter is <code>constraints/countsols/sollimit</code>. In
7336  * the interactive shell this parameter can be set as follows:
7337  *
7338  * <code>SCIP&gt; set constraints countsols sollimit 1000</code>
7339  *
7340  * In case you are using the callable library, this upper bound can be assigned by calling SCIPsetLongintParam() as follows:
7341  *
7342  * \code
7343  * SCIP_CALL( SCIPsetLongintParam( scip, "constraints/countsols/sollimit", 1000) );
7344  * \endcode
7345  *
7346  *
7347  * The reason why this upper bound is soft comes from the fact that, by default, SCIP uses a technique called unrestricted
7348  * subtree detection. Using this technique it is possible to detect several solutions at once. Therefore, it can happen
7349  * that the solution limit is exceeded before SCIP is stopped.
7350  *
7351  * @section COLLECTALLFEASEBLES Collect all feasible solution
7352  *
7353  * Per default SCIP only counts all feasible solutions. This means, these solutions are not stored. If you switch the
7354  * parameter <code>constraints/countsols/collect</code> to TRUE (the default value is FALSE) the detected solutions are
7355  * stored. Changing this parameter can be done in the interactive shell
7356  *
7357  * <code>SCIP&gt; set constraints countsols collect TRUE</code>
7358  *
7359  * as well as via the callable library
7360  *
7361  * \code
7362  * SCIP_CALL( SCIPsetBoolParam( scip, "constraints/countsols/collect", TRUE) );
7363  * \endcode
7364  *
7365  * @note The solution which are collected are stored w.r.t. the active variables. These are the variables which got not
7366  * removed during presolving.
7367  *
7368  * In case you are using the interactive shell you can write all collected solutions to a file as follows
7369  *
7370  * <code>SCIP&gt; write allsolutions &lt;file name&gt;</code>
7371  *
7372  * In that case the sparse solutions are unrolled and lifted back into the original variable space.
7373  *
7374  * The callable library provides a method which gives access to all collected sparse solutions. That is,
7375  * SCIPgetCountedSparseSolutions(). The sparse solutions you get are defined w.r.t. active variables. To get solutions
7376  * w.r.t. to the original variables. You have to do two things:
7377  *
7378  * -# unroll each sparse solution
7379  * -# lift each solution into original variable space by extending the solution by those variable which got removed
7380  * during presolving
7381  *
7382  * The get the variables which got removed during presolving, you can use the methods SCIPgetFixedVars() and
7383  * SCIPgetNFixedVars(). The method SCIPgetProbvarLinearSum() transforms given variables, scalars and constant to the
7384  * corresponding active variables, scalars and constant. Using this method for a single variable gives a representation
7385  * for that variable w.r.t. the active variables which can be used to compute the value for the considered solution (which
7386  * is defined w.r.t. active variables).
7387  *
7388  * For that complete procedure you can also check the source code of
7389  * \ref SCIP_DECL_DIALOGEXEC(SCIPdialogExecWriteAllsolutions) "SCIPdialogExecWriteAllsolutions()" cons_countsols.c which
7390  * does exactly that.
7391  *
7392  *
7393  * @section COUNTOPTIMAL Count number of optimal solutions
7394  *
7395  * If you are interested in counting the number of optimal solutions, this can be done with SCIP using the
7396  * <code>count</code> command by applying the following steps:
7397  *
7398  * -# Solve the original problem to optimality and let \f$c^*\f$ be the optimal value
7399  * -# Add the objective function as constraint with left and right hand side equal to \f$c^*\f$
7400  * -# load the adjusted problem into SCIP
7401  * -# use the predefined counting settings
7402  * -# start counting the number of feasible solutions
7403  *
7404  * If you do this, SCIP will collect all optimal solutions of the original problem.
7405  *
7406  */
7407 
7408 /**@page LICENSE License
7409  *
7410  * \verbinclude COPYING
7411  */
7412 
7413 /**@page FAQ Frequently Asked Questions (FAQ)
7414  * \htmlinclude faq.inc
7415  */
7416 
7417 
7418 /**@page AUTHORS SCIP Authors
7419  * \htmlinclude authors.inc
7420  */
7421 
7422 /**@page INSTALL Installation information
7423  * \verbinclude INSTALL
7424  */
7425 
7426 /**@page RELEASENOTES Release notes
7427  *
7428  * \verbinclude SCIP-release-notes-3.2
7429  *
7430  * \verbinclude SCIP-release-notes-3.1
7431  *
7432  * \verbinclude SCIP-release-notes-3.0.2
7433  *
7434  * \verbinclude SCIP-release-notes-3.0.1
7435  *
7436  * \verbinclude SCIP-release-notes-3.0
7437  *
7438  * \verbinclude SCIP-release-notes-2.1.1
7439  *
7440  * \verbinclude SCIP-release-notes-2.1
7441  *
7442  * \verbinclude SCIP-release-notes-2.0.2
7443  *
7444  * \verbinclude SCIP-release-notes-2.0.1
7445  *
7446  * \verbinclude SCIP-release-notes-2.0
7447  *
7448  * \verbinclude SCIP-release-notes-1.2
7449  *
7450  * \verbinclude SCIP-release-notes-1.1
7451  */
7452 
7453 /**@page CHANGELOG CHANGELOG
7454  *
7455  * \verbinclude CHANGELOG
7456  *
7457  */
7458 
7459 /**@defgroup PUBLICMETHODS Public Methods
7460  *
7461  * This page lists headers containing methods provided by the core of SCIP that can be used via the
7462  * callable library. If you are in the <a href="../html">User's Manual</a> you only find methods that are
7463  * public and, therefore, allowed to be used. The <a href="../html_devel">Developer's Manual</a> includes
7464  * all methods.
7465  *
7466  * All of the headers listed below include functions that are allowed to be called by external users. Besides those
7467  * functions it is also valid to call methods that are listed in one of the headers of the (default) plugins, e.g.,
7468  * cons_linear.h.
7469  *
7470  * If you are looking for information about a particular object of SCIP, such as a variable or a constraint, you should
7471  * first search the corresponding "pub_<...>.h" header. E.g., for constraints, look in pub_cons.h. If you need some
7472  * information about the overall problem, you should start searching in scip.h.
7473  *
7474  * Since there is a huge number of methods in scip.h, these methods are grouped into different categories. These
7475  * categories are:
7476  *
7477  * - Memory Management
7478  * - Miscellaneous Methods
7479  * - General SCIP Methods
7480  * - Message Output Methods
7481  * - Parameter Methods
7482  * - SCIP User Functionality Methods: Managing Plugins
7483  * - User Interactive Dialog Methods
7484  * - Global Problem Methods
7485  * - Local Subproblem Methods
7486  * - Solve Methods
7487  * - Variable Methods
7488  * - Conflict Analysis Methods
7489  * - Constraint Methods
7490  * - LP Methods
7491  * - LP Column Methods
7492  * - LP Row Methods
7493  * - Cutting Plane Methods
7494  * - LP Diving Methods
7495  * - Probing Methods
7496  * - Branching Methods
7497  * - Primal Solution Methods
7498  * - Event Methods
7499  * - Tree Methods
7500  * - Statistic Methods
7501  * - Timing Methods
7502  * - Numerical Methods
7503  * - Dynamic Arrays
7504  *
7505  */
7506 
7507 /**@defgroup TYPEDEFINITIONS Type Definitions
7508  * This page lists headers which contain type definitions of callback methods.
7509  *
7510  * All headers below include the descriptions of callback methods of
7511  * certain plugins. For more detail see the corresponding header.
7512  */
7513 
7514 /**@defgroup BRANCHINGRULES Branching Rules
7515  * @brief This page contains a list of all branching rule which are currently available.
7516  *
7517  * A detailed description what a branching rule does and how to add a branching rule to SCIP can be found
7518  * \ref BRANCH "here".
7519  */
7520 
7521 /**@defgroup CONSHDLRS Constraint Handler
7522  * @brief This page contains a list of all constraint handlers which are currently available.
7523  *
7524  * A detailed description what a constraint handler does and how to add a constraint handler to SCIP can be found
7525  * \ref CONS "here".
7526  */
7527 
7528 /**@defgroup DIALOGS Dialogs
7529  * @brief This page contains a list of all dialogs which are currently available.
7530  *
7531  * A detailed description what a dialog does and how to add a dialog to SCIP can be found
7532  * \ref DIALOG "here".
7533  */
7534 
7535 /**@defgroup DISPLAYS Displays
7536  * @brief This page contains a list of all displays (output columns) which are currently available.
7537  *
7538  * A detailed description what a display does and how to add a display to SCIP can be found
7539  * \ref DISP "here".
7540  *
7541  */
7542 
7543 /**@defgroup EXPRINTS Expression Interpreter
7544  * @brief This page contains a list of all expression interpreter which are currently available.
7545  *
7546  * A detailed description what a expression interpreter does and how to add a expression interpreter to SCIP can be found
7547  * \ref EXPRINT "here".
7548  */
7549 
7550 /**@defgroup FILEREADERS File Readers
7551  * @brief This page contains a list of all file readers which are currently available.
7552  *
7553  * @section AVAILABLEFORMATS List of readable file formats
7554  *
7555  * The \ref SHELL "interactive shell" and the callable library are capable of reading/parsing several different file
7556  * formats.
7557  *
7558  * <table>
7559  * <tr><td>\ref reader_cip.h "CIP format"</td> <td>for SCIP's constraint integer programming format</td></tr>
7560  * <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>
7561  * <tr><td>\ref reader_diff.h "DIFF format"</td> <td>for reading a new objective function for mixed-integer programs</td></tr>
7562  * <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>
7563  * <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>
7564  * <tr><td>\ref reader_lp.h "LP format"</td> <td>for mixed-integer (quadratically constrained quadratic) programs (CPLEX)</td></tr>
7565  * <tr><td>\ref reader_mps.h "MPS format"</td> <td>for mixed-integer (quadratically constrained quadratic) programs</td></tr>
7566  * <tr><td>\ref reader_opb.h "OPB format"</td> <td>for pseudo-Boolean optimization instances</td></tr>
7567  * <tr><td>\ref reader_osil.h "OSiL format"</td> <td>for mixed-integer nonlinear programs</td></tr>
7568  * <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>
7569  * <tr><td>\ref reader_sol.h "SOL format"</td> <td>for solutions; XML-format (read-only) or raw SCIP format</td></tr>
7570  * <tr><td>\ref reader_wbo.h "WBO format"</td> <td>for weighted pseudo-Boolean optimization instances</td></tr>
7571  * <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
7572  * programming problems [read only]</td></tr>
7573  * </table>
7574  *
7575  * @section ADDREADER How to add a file reader
7576  *
7577  * A detailed description what a file reader does and how to add a file reader to SCIP can be found
7578  * \ref READER "here".
7579  *
7580  */
7581 
7582 /**@defgroup LPIS LP Solver Interfaces
7583  * @brief This page contains a list of all LP solver interfaces which are currently available.
7584  */
7585 
7586 /**@defgroup NODESELECTORS Node Selectors
7587  * @brief This page contains a list of all node selectors which are currently available.
7588  *
7589  * A detailed description what a node selector does and how to add a node selector to SCIP can be found
7590  * \ref NODESEL "here".
7591  */
7592 
7593 /**@defgroup NLPIS NLP Solver Interfaces
7594  * @brief This page contains a list of all NLP solver interfaces which are currently available.
7595  *
7596  * A detailed description what a NLP solver interface does and how to add a NLP solver interface to SCIP can be found
7597  * \ref NLPI "here".
7598  */
7599 
7600 /**@defgroup PRESOLVERS Presolvers
7601  * @brief This page contains a list of all presolvers which are currently available.
7602  *
7603  * A detailed description what a presolver does and how to add a presolver to SCIP can be found
7604  * \ref PRESOL "here".
7605  */
7606 
7607 /**@defgroup PRICERS Pricers
7608  * @brief This page contains a list of all pricers which are currently available.
7609  *
7610  * Per default there exist no variable pricer. A detailed description what a variable pricer does and how to add a
7611  * variable pricer to SCIP can be found \ref PRICER "here".
7612  */
7613 
7614 /**@defgroup PRIMALHEURISTICS Primal Heuristics
7615  * @brief This page contains a list of all primal heuristics which are currently available.
7616  *
7617  * A detailed description what a primal heuristic does and how to add a primal heuristic to SCIP can be found
7618  * \ref HEUR "here".
7619  */
7620 
7621 /**@defgroup PROPAGATORS Propagators
7622  * @brief This page contains a list of all propagators which are currently available.
7623  *
7624  * A detailed description what a propagator does and how to add a propagator to SCIP can be found
7625  * \ref PROP "here".
7626  */
7627 
7628 /**@defgroup RELAXATORS Relaxation Handlers
7629  * @brief This page contains a list of all relaxation handlers which are currently available.
7630  *
7631  * Note that the linear programming relaxation is not implemented via the relaxation handler plugin. Per default there
7632  * exist no relaxation handler. A detailed description what a variable pricer does and how to add a A detailed
7633  * description what a relaxation handler does and how to add a relaxation handler to SCIP can be found \ref RELAX
7634  * "here".
7635  */
7636 
7637 /**@defgroup SEPARATORS Separators
7638  * @brief This page contains a list of all separators which are currently available.
7639  *
7640  * A detailed description what a separator does and how to add a separator to SCIP can be found
7641  * \ref SEPA "here".
7642  */
7643 
7644 /**@page PARAMETERS List of all SCIP parameters
7645  *
7646  * This page list all parameters of the current SCIP version. This list can
7647  * easily be generated by SCIP via the interactive shell using the following command:
7648  *
7649  * <code>SCIP&gt; set save &lt;file name&gt;</code>
7650  *
7651  * or via the function call:
7652  *
7653  * <code>SCIP_CALL( SCIPwriteParams(scip, &lt;file name&gt;, TRUE, FALSE) );</code>
7654  *
7655  * \verbinclude parameters.set
7656  */
7657 
7658 /**@page PYTHON_INTERFACE Python interface for the SCIP Optimization Suite
7659  *
7660  * This page shows how to install the Python interface that comes with SCIP. A short usage example is shown below.
7661  *
7662  * INSTALL:
7663  * \verbinclude interfaces/python/INSTALL
7664  *
7665  * Usage information (README):
7666  * \verbinclude interfaces/python/README
7667  */
7668 
7669 /**@page JNI_INTERFACE Java native interface for SCIP
7670  *
7671  * This page shows how to install and test the Java native interface (JNI) of SCIP.
7672  *
7673  * \verbinclude interfaces/jni/README
7674  */