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-2016 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  *
87  * Below you find for most plugin types a detailed description of how to implement and add them to \SCIP.
88  *
89  * - \ref CONS "Constraint handlers"
90  * - \ref PRICER "Variable pricers"
91  * - \ref PRESOL "Presolvers"
92  * - \ref SEPA "Separators"
93  * - \ref PROP "Propagators"
94  * - \ref BRANCH "Branching rules"
95  * - \ref NODESEL "Node selectors"
96  * - \ref HEUR "Primal heuristics"
97  * + \ref DIVINGHEUR "Diving heuristics"
98  * - \ref RELAX "Relaxation handlers"
99  * - \ref READER "File readers"
100  * - \ref DIALOG "Dialogs"
101  * - \ref DISP "Display columns"
102  * - \ref EVENT "Event handler"
103  * - \ref NLPI "Interfaces to NLP solvers"
104  * - \ref EXPRINT "Interfaces to expression interpreters"
105  * - \ref PARAM "additional user parameters"
106  *
107  * @subsection HOWTOUSESECTION How to use ...
108  *
109  * - \ref CONF "Conflict analysis"
110  * - \ref REOPT "Reoptimization"
111  * - \ref TEST "How to run automated tests with SCIP"
112  * - \ref COUNTER "How to use SCIP to count feasible solutions"
113  *
114  *
115  * @section FURTHERINFO Further information
116  *
117  * @subsection CHG Changes between different versions of SCIP
118  * - \ref CHANGELOG "Change log"
119  * - \ref RELEASENOTES "Release notes"
120  * - \ref CHG8 "Interface changes between version 3.1 and 3.2"
121  * - \ref CHG7 "Interface changes between version 3.0 and 3.1"
122  * - \ref CHG6 "Interface changes between version 2.1 and 3.0"
123  * - \ref CHG5 "Interface changes between version 2.0 and 2.1"
124  * - \ref CHG4 "Interface changes between version 1.2 and 2.0"
125  * - \ref CHG3 "Interface changes between version 1.1 and 1.2"
126  * - \ref CHG2 "Interface changes between version 1.0 and 1.1"
127  * - \ref CHG1 "Interface changes between version 0.9 and 1.0"
128  *
129  * @subsection AUTHORS SCIP Authors
130  * - <a class="el" href="http://scip.zib.de/#developers">Developers</a>
131  *
132  * @version 3.2.1
133  *
134  * \image html scippy.png
135  *
136  */
137 
138 /** @page EXAMPLES Example projects
139  *
140  * SCIP contains several examples that demonstrate its usage. They are contained in the &quot;examples&quot; directory
141  * in the source code distribution.
142  *
143  * @section BRANCHANDPRICE Branch-and-price
144  *
145  * <table>
146  * <tr>
147  * <td>
148  * <a href="http://scip.zib.de/doc/examples/Binpacking"><b>Binpacking</b></a>
149  * </td>
150  * <td>
151  * An implementation of the column generation approach for the binpacking problem. It includes a customized reader,
152  * Ryan/Foster branching rule, (global) problem data, variable data, and constraint handler.
153  * </td>
154  * </tr>
155  * <tr>
156  * <td>
157  * <a href="http://scip.zib.de/doc/examples/VRP"><b>VRP</b></a>
158  * </td>
159  * <td>
160  * A solver for a simple capacity-constrained vehicle routing problem, which is based on pricing tours via a dynamic
161  * programming algorithm.
162  * </td>
163  * </tr>
164  * </table>
165  *
166  * @section BRANCHANDCUT Branch-and-cut
167  *
168  * <table>
169  * <tr>
170  * <td>
171  * <a href="http://scip.zib.de/doc/examples/LOP"><b>LOP</b></a>
172  * </td>
173  * <td>
174  * An example for implementing a constraint handler.
175  * </td>
176  * </tr>
177  * <tr>
178  * <td>
179  * <a href="http://scip.zib.de/doc/examples/TSP"><b>TSP</b></a>
180  * </td>
181  * <td>
182  * A short implementations of a constraint handler, two easy combinatorial heuristics, a file reader, etc. which
183  * demonstrate the usage of SCIP as a branch-and-cut-framework for solving traveling salesman problem instances.
184  * </td>
185  * </tr>
186  * </table>
187  *
188  * @section CALLABLELIBRARY Callable library
189  *
190  * <table>
191  * <tr>
192  * <td>
193  * <a href="http://scip.zib.de/doc/examples/CallableLibrary"><b>CallableLibrary</b></a>
194  * </td>
195  * <td>
196  * An example showing how to setup constraints (esp. nonlinear ones) when using SCIP as callable library.
197  * </td>
198  * </tr>
199  * <tr>
200  * <td>
201  * <a href="http://scip.zib.de/doc/examples/MIPSolver"><b>MIPSolver</b></a>
202  * </td>
203  * <td>
204  * A minimal implementation for using SCIP included into another source code
205  * </td>
206  * </tr>
207  * <tr>
208  * <td>
209  * <a href="http://scip.zib.de/doc/examples/Queens/scip_intro.pdf"><b>Queen</b></a>
210  * </td>
211  * <td>
212  * An example showing the use of SCIP as callable library.
213  * </td>
214  * </tr>
215  * </table>
216  *
217  *
218  * @section OTHERPLUGINS Other plugins
219  *
220  * <table>
221  * <tr>
222  * <td>
223  * <a href="http://scip.zib.de/doc/examples/Eventhdlr"><b>Eventhdlr</b></a>
224  * </td>
225  * <td>
226  * A small example illustrating the use of an event handler.
227  * </td>
228  * </tr>
229  * <tr>
230  * <td>
231  * <a href="http://scip.zib.de/doc/examples/GMI"><b>GMI</b></a>
232  * </td>
233  * <td>
234  * An example about Gomory mixed-integer cuts.
235  * </td>
236  * </tr>
237  * </table>
238  *
239  */
240 
241 /** @page APPLICATIONS Application projects
242  *
243  * There are several extensions of SCIP for particular applications included in the release. They are contained in the &quot;applications&quot; directory
244  * in the source code distribution.
245  *
246  * <table>
247  * <tr>
248  * <td>
249  * <a href="http://scip.zib.de/doc/applications/Coloring"><b>Coloring</b></a>
250  * </td>
251  * <td>
252  * An implemenation of the column generation approach for graph coloring of Mehrotra and Trick.
253  * </td>
254  * </tr>
255  * <tr>
256  * <td>
257  * <a href="http://scip.zib.de/doc/applications/Scheduler"><b>Scheduler</b></a>
258  * </td>
259  * <td>
260  * A solver for scheduling problems.
261  * </td>
262  * </tr>
263  * <tr>
264  * <td>
265  * <a href="http://scip.zib.de/doc/applications/STP"><b>Steiner Tree Problem</b></a>
266  * </td>
267  * <td>
268  * A solver for Steiner Tree Problems in graphs, based on a branch-and-cut approach.
269  * </td>
270  * </tr>
271  * <tr>
272  * <td>
273  * <a href="http://scip.zib.de/doc/applications/PolySCIP"><b>PolySCIP</b></a>
274  * </td>
275  * <td>
276  * A solver for multi-objective optimization problems.
277  * </td>
278  * </tr>
279  * </table>
280  *
281  */
282 
283 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
284 /**@page CODE Coding style guidelines
285  *
286  * We follow the following coding style guidelines and recommend them for all developers.
287  *
288  * - Indentation is 3 spaces. No tabs anywhere in the code.
289  * - Always only one declaration in a line.
290  * - Braces are on a new line and not indented.
291  * - Spaces around all operators.
292  * - No spaces between control structure keywords like "if", "for", "while", "switch" and the corresponding brackets.
293  * - No spaces between a function name and the parenthesis in both the definition and function calls.
294  * - Use assert() to show preconditions for the parameters, invariants and postconditions.
295  * - All global functions start with "SCIP". In the usual naming scheme this is followed by the object and a method name
296  * like in SCIPlpAddRow(). Functions return TRUE or FALSE should be named like SCIPisFeasEQ().
297  * - Make all functions that are not used outside the module 'static'. Naming should start with a lower case letter.
298  * - Variable names should be all lower case.
299  * - For each structure there is a typedef with the name in all upper case.
300  * - Defines should be named all upper case.
301  * - Document functions, parameters, and variables in a doxygen conformed way.
302  *
303  * As an example, have a look at tree.c and see the examples below. We also provide settings for
304  * \ref XEMACS "(x)emacs" and \ref ECLIPSE "eclipse".
305  *
306  * @section CODEEXAMPLES Examples
307  *
308  * In this section we state a few examples illustrating the \SCIP code style.
309  *
310  * \code
311  * #ifdef __cplusplus
312  * extern "C" {
313  * #endif
314  *
315  * /** SCIP operation stage */
316  * enum SCIP_Stage
317  * {
318  * SCIP_STAGE_INIT = 0, /**< SCIP datastructures are initialized, no problem exists */
319  * SCIP_STAGE_PROBLEM = 1, /**< the problem is being created and modified */
320  * SCIP_STAGE_TRANSFORMING = 2, /**< the problem is being transformed into solving data space */
321  * SCIP_STAGE_TRANSFORMED = 3, /**< the problem was transformed into solving data space */
322  * SCIP_STAGE_PRESOLVING = 4, /**< the problem is being presolved */
323  * SCIP_STAGE_PRESOLVED = 5, /**< the problem was presolved */
324  * SCIP_STAGE_INITSOLVE = 6, /**< the solving process data is being initialized */
325  * SCIP_STAGE_SOLVING = 7, /**< the problem is being solved */
326  * SCIP_STAGE_SOLVED = 8, /**< the problem was solved */
327  * SCIP_STAGE_FREESOLVE = 9, /**< the solving process data is being freed */
328  * SCIP_STAGE_FREETRANS = 10 /**< the transformed problem is being freed */
329  * };
330  * typedef enum SCIP_Stage SCIP_STAGE;
331  *
332  * /** possible settings for enabling/disabling algorithms and other features */
333  * enum SCIP_Setting
334  * {
335  * SCIP_UNDEFINED = 0, /**< undefined setting */
336  * SCIP_DISABLED = 1, /**< feature is disabled */
337  * SCIP_AUTO = 2, /**< feature is set to automatic mode */
338  * SCIP_ENABLED = 3 /**< feature is enabled */
339  * };
340  * typedef enum SCIP_Setting SCIP_SETTING;
341  *
342  * #ifdef __cplusplus
343  * }
344  * #endif
345  * \endcode
346  *
347  * @section XEMACS Customize (x)emacs
348  *
349  * If you are using (x)emacs, you can use the following customization for the c++-mode. These settings satisfy the
350  * coding guidelines of \SCIP.
351  *
352  * \verbatim
353  (add-hook 'c++-mode-hook
354  (function
355  (lambda ()
356  ;; SCIP customizations for c-mode and c++-mode
357  (setq-default c-basic-offset 3)
358  (c-set-offset 'substatement-open 0)
359  (c-set-offset 'statement-case-open 0)
360  (c-set-offset 'brace-list-open '-)
361  (c-set-offset 'inextern-lang '0)
362  (c-set-offset 'arglist-intro '+)
363  (c-set-offset 'arglist-cont 0)
364  (c-set-offset 'arglist-cont-nonempty '+)
365  (c-set-offset 'arglist-close '+)
366  (set-variable 'fill-column 120)
367  ;; this will make sure spaces are used instead of tabs
368  (setq tab-width 8 indent-tabs-mode nil)
369  )))\endverbatim
370  *
371  * @section ECLIPSE Customize eclipse
372  *
373  *
374  * Eclipse user can use the profile below. This profile does not match the \SCIP coding guideline completely.
375  *
376  * \code
377  *
378  * <?xml version="1.0" encoding="UTF-8" standalone="no"?>
379  * <profiles version="1">
380  * <profile kind="CodeFormatterProfile" name="scip" version="1">
381  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_method_declaration" value="do not insert"/>
382  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_for" value="insert"/>
383  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_in_empty_block" value="insert"/>
384  * <setting id="org.eclipse.cdt.core.formatter.lineSplit" value="124"/>
385  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_base_types" value="do not insert"/>
386  * <setting id="org.eclipse.cdt.core.formatter.keep_else_statement_on_same_line" value="false"/>
387  * <setting id="org.eclipse.cdt.core.formatter.indent_switchstatements_compare_to_switch" value="false"/>
388  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_brace_in_array_initializer" value="insert"/>
389  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_method_declaration_parameters" value="do not insert"/>
390  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_if" value="insert"/>
391  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_exception_specification" value="do not insert"/>
392  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_parenthesized_expression" value="do not insert"/>
393  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_base_types" value="insert"/>
394  * <setting id="org.eclipse.cdt.core.formatter.indent_body_declarations_compare_to_access_specifier" value="true"/>
395  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_exception_specification" value="do not insert"/>
396  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_template_arguments" value="insert"/>
397  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_block" value="insert"/>
398  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_method_declaration" value="do not insert"/>
399  * <setting id="org.eclipse.cdt.core.formatter.use_tabs_only_for_leading_indentations" value="false"/>
400  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_colon_in_labeled_statement" value="do not insert"/>
401  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_colon_in_case" value="insert"/>
402  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_array_initializer" value="insert"/>
403  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_enum_declarations" value="insert"/>
404  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_expressions_in_array_initializer" value="16"/>
405  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_declarator_list" value="insert"/>
406  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_bracket" value="do not insert"/>
407  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_for" value="insert"/>
408  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_prefix_operator" value="do not insert"/>
409  * <setting id="org.eclipse.cdt.core.formatter.tabulation.size" value="3"/>
410  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_before_else_in_if_statement" value="insert"/>
411  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_enumerator_list" value="48"/>
412  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_parenthesized_expression" value="do not insert"/>
413  * <setting id="org.eclipse.cdt.core.formatter.insert_space_between_empty_parens_in_method_declaration" value="do not insert"/>
414  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_declarator_list" value="16"/>
415  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_switch" value="insert"/>
416  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_parenthesized_expression" value="do not insert"/>
417  * <setting id="org.eclipse.cdt.core.formatter.indent_empty_lines" value="false"/>
418  * <setting id="org.eclipse.cdt.core.formatter.indent_switchstatements_compare_to_cases" value="true"/>
419  * <setting id="org.eclipse.cdt.core.formatter.keep_empty_array_initializer_on_one_line" value="false"/>
420  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_method_declaration" value="insert"/>
421  * <setting id="org.eclipse.cdt.core.formatter.put_empty_statement_on_new_line" value="true"/>
422  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_switch" value="do not insert"/>
423  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_cast" value="do not insert"/>
424  * <setting id="org.eclipse.cdt.core.formatter.insert_space_between_empty_braces_in_array_initializer" value="do not insert"/>
425  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_method_declaration" value="next_line"/>
426  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_while" value="insert"/>
427  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_question_in_conditional" value="insert"/>
428  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_semicolon" value="do not insert"/>
429  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_closing_angle_bracket_in_template_arguments" value="insert"/>
430  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_colon_in_base_clause" value="do not insert"/>
431  * <setting id="org.eclipse.cdt.core.formatter.indent_breaks_compare_to_cases" value="true"/>
432  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_unary_operator" value="do not insert"/>
433  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_declarator_list" value="do not insert"/>
434  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_arguments_in_method_invocation" value="16"/>
435  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_while" value="do not insert"/>
436  * <setting id="org.eclipse.cdt.core.formatter.insert_space_between_empty_brackets" value="do not insert"/>
437  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_bracket" value="do not insert"/>
438  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_parameters_in_method_declaration" value="48"/>
439  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_before_closing_brace_in_array_initializer" value="do not insert"/>
440  * <setting id="org.eclipse.cdt.core.formatter.number_of_empty_lines_to_preserve" value="1"/>
441  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_method_invocation" value="do not insert"/>
442  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_brace_in_array_initializer" value="insert"/>
443  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_semicolon_in_for" value="do not insert"/>
444  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_block" value="next_line"/>
445  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_colon_in_conditional" value="insert"/>
446  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_type_declaration" value="next_line"/>
447  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_assignment_operator" value="insert"/>
448  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_angle_bracket_in_template_arguments" value="do not insert"/>
449  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_expression_list" value="do not insert"/>
450  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_angle_bracket_in_template_parameters" value="do not insert"/>
451  * <setting id="org.eclipse.cdt.core.formatter.continuation_indentation" value="1"/>
452  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_expression_list" value="0"/>
453  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_method_declaration" value="do not insert"/>
454  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_template_parameters" value="do not insert"/>
455  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_colon_in_default" value="do not insert"/>
456  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_binary_operator" value="insert"/>
457  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_conditional_expression" value="16"/>
458  * <setting id="org.eclipse.cdt.core.formatter.insert_space_between_empty_parens_in_method_invocation" value="do not insert"/>
459  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_array_initializer" value="do not insert"/>
460  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_if" value="insert"/>
461  * <setting id="org.eclipse.cdt.core.formatter.format_guardian_clause_on_one_line" value="false"/>
462  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_cast" value="do not insert"/>
463  * <setting id="org.eclipse.cdt.core.formatter.indent_access_specifier_compare_to_type_header" value="false"/>
464  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_type_declaration" value="insert"/>
465  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_colon_in_labeled_statement" value="insert"/>
466  * <setting id="org.eclipse.cdt.core.formatter.continuation_indentation_for_array_initializer" value="1"/>
467  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_method_declaration_parameters" value="insert"/>
468  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_semicolon_in_for" value="insert"/>
469  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_method_invocation" value="do not insert"/>
470  * <setting id="org.eclipse.cdt.core.formatter.indent_body_declarations_compare_to_namespace_header" value="false"/>
471  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_closing_brace_in_block" value="insert"/>
472  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_assignment_operator" value="insert"/>
473  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_compact_if" value="0"/>
474  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_array_initializer" value="insert"/>
475  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_at_end_of_file_if_missing" value="do not insert"/>
476  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_template_parameters" value="insert"/>
477  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_expression_list" value="insert"/>
478  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_question_in_conditional" value="insert"/>
479  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_exception_specification" value="insert"/>
480  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_binary_operator" value="insert"/>
481  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_before_identifier_in_function_declaration" value="do not insert"/>
482  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_base_clause_in_type_declaration" value="80"/>
483  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_method_declaration_throws" value="do not insert"/>
484  * <setting id="org.eclipse.cdt.core.formatter.insert_space_between_empty_parens_in_exception_specification" value="do not insert"/>
485  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_method_invocation_arguments" value="do not insert"/>
486  * <setting id="org.eclipse.cdt.core.formatter.indent_declaration_compare_to_template_header" value="false"/>
487  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_unary_operator" value="do not insert"/>
488  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_switch" value="do not insert"/>
489  * <setting id="org.eclipse.cdt.core.formatter.indent_statements_compare_to_body" value="true"/>
490  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_method_declaration_throws" value="insert"/>
491  * <setting id="org.eclipse.cdt.core.formatter.indent_statements_compare_to_block" value="true"/>
492  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_template_arguments" value="do not insert"/>
493  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_before_catch_in_try_statement" value="insert"/>
494  * <setting id="org.eclipse.cdt.core.formatter.alignment_for_throws_clause_in_method_declaration" value="48"/>
495  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_method_invocation" value="do not insert"/>
496  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_closing_paren_in_cast" value="do not insert"/>
497  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_paren_in_catch" value="insert"/>
498  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_angle_bracket_in_template_parameters" value="do not insert"/>
499  * <setting id="org.eclipse.cdt.core.formatter.tabulation.char" value="space"/>
500  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_angle_bracket_in_template_parameters" value="do not insert"/>
501  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_while" value="insert"/>
502  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_comma_in_method_invocation_arguments" value="insert"/>
503  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_block_in_case" value="next_line"/>
504  * <setting id="org.eclipse.cdt.core.formatter.compact_else_if" value="true"/>
505  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_postfix_operator" value="do not insert"/>
506  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_colon_in_base_clause" value="insert"/>
507  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_after_template_declaration" value="do not insert"/>
508  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_catch" value="insert"/>
509  * <setting id="org.eclipse.cdt.core.formatter.keep_then_statement_on_same_line" value="false"/>
510  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_switch" value="next_line"/>
511  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_if" value="do not insert"/>
512  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_paren_in_switch" value="insert"/>
513  * <setting id="org.eclipse.cdt.core.formatter.keep_imple_if_on_one_line" value="false"/>
514  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_after_opening_brace_in_array_initializer" value="do not insert"/>
515  * <setting id="org.eclipse.cdt.core.formatter.indentation.size" value="3"/>
516  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_namespace_declaration" value="end_of_line"/>
517  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_colon_in_conditional" value="insert"/>
518  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_comma_in_enum_declarations" value="do not insert"/>
519  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_prefix_operator" value="do not insert"/>
520  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_angle_bracket_in_template_arguments" value="do not insert"/>
521  * <setting id="org.eclipse.cdt.core.formatter.brace_position_for_array_initializer" value="end_of_line"/>
522  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_colon_in_case" value="do not insert"/>
523  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_catch" value="do not insert"/>
524  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_brace_in_namespace_declaration" value="insert"/>
525  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_postfix_operator" value="do not insert"/>
526  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_closing_bracket" value="do not insert"/>
527  * <setting id="org.eclipse.cdt.core.formatter.insert_new_line_before_while_in_do_statement" value="insert"/>
528  * <setting id="org.eclipse.cdt.core.formatter.insert_space_before_opening_paren_in_for" value="do not insert"/>
529  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_closing_angle_bracket_in_template_parameters" value="insert"/>
530  * <setting id="org.eclipse.cdt.core.formatter.insert_space_after_opening_angle_bracket_in_template_arguments" value="do not insert"/>
531  * </profile>
532  * </profiles>
533  * \endcode
534  */
535 
536 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
537 /**@page MAKE Makefiles / Installation information
538  *
539  *
540  * In most cases (LINUX and MAC) it is quite easy to compile and install SCIP. Therefore, reading the section
541  * \ref BRIEFINSTALL "Brief installation description" should usually be enough. If this is not the case you find
542  * \ref DETAILEDINSTALL "Detailed installation description" below as well as \ref EXAMPLE1 "Examples".
543 *
544  * @section BRIEFINSTALL Brief installation description
545  *
546  * The easiest way to install SCIP is to use the SCIP Optimization Suite which contains SCIP, SoPlex, and ZIMPL. For
547  * that we refer to the INSTALL file of the SCIP Optimization Suite (main advantage: there is no need
548  * to specify any directories, the compiling process is fully automated).
549  *
550  * Compiling SCIP directly can be done as follows:
551  *
552  * -# unpack the tarball <code>tar xvf scip-x.y.z.tgz</code>
553  * -# change to the directory <code>cd scip-x.y.z</code>
554  * -# start compiling SCIP by typing <code>make</code>
555  * -# (optional) install the header, libraries, and binary <code>make install INSTALLDIR="/usr/local/</code>
556  *
557  * During your first compilation you will be asked for some soft-link targets,
558  * depending on the LP solver you want to use. Usually, SCIP needs the
559  * following information
560  * -# the directory where the include files of the LP solver lie
561  * -# the library file(s) "lib*.a" or/and "lib*.so"
562  *
563  * Besides that, SCIP needs some soft-link targets, for ZIMPL
564  * -# the directory where the include files of ZIMPL lie
565  * -# the library file(s) "lib*.a" or/and "lib*.so"
566  *
567  * You will need either the .a or the .so files and can skip the others by
568  * just pressing return.
569  *
570  * The most common compiling issue is that some libraries are missing
571  * on your system or that they are outdated. SCIP per default requires
572  * zlib, gmp and readline. Try compiling with: <code> make ZLIB=false
573  * READLINE=false ZIMPL=false</code> or, better, install them. Note
574  * that under Linux-based systems, you need to install the
575  * developer-versions of gmp/zlib/readline, in order to also have the
576  * header-files available.
577  *
578  @section DETAILEDINSTALL Detailed installation description
579  *
580  * In this section we describe the use, and a few features, of the SCIP Makefile. We also give two examples for how to install
581  * SCIP. The \ref EXAMPLE1 "first example" illustrates the default installation. This means, with SoPleX and ZIMPL. The
582  * \ref EXAMPLE2 "second example" shows how to get CPLEX linked to SCIP without ZIMPL. This is followed by a section which
583  * gives some hints on what to do if the \ref COMPILERPROBLEMS "compilation throws an error". We give some comments on
584  * how to install SCIP under \ref WINDOWS "WINDOWS" and show \ref RUN "how to start SCIP".
585  *
586  * If you experience any problems during the installation, you will find help in the \ref INSTALL "INSTALL" file.
587  *
588  * SCIP contains a makefile system, which allows the individual setting of several parameters. For
589  * instance, the following settings are supported:
590  *
591  * - <code>OPT=<dbg|opt|opt-gccold></code> Here <code>dbg</code> turns on the debug mode of SCIP. This enables asserts
592  * and avoids macros for several function in order to ease debugging. The default is <code>opt</code>, which enables
593  * the optimized mode. The third option <code>opt-gccold</code> will work with older GCC compilers before version
594  * 4.2. We recommend using newer GCC versions.
595  *
596  * - <code>LPS=<clp|cpx|grb|msk|qso|spx|xprs|none></code> This determines the LP-solver, which should have been
597  * installed separately from SCIP. The options are the following:
598  * - <code>clp</code>: COIN-OR Clp LP-solver
599  * - <code>cpx</code>: CPLEX LP-solver
600  * - <code>grb</code>: Gurobi LP-solver (interface is in beta stage)
601  * - <code>msk</code>: Mosek LP-solver
602  * - <code>qso</code>: QSopt LP-solver
603  * - <code>spx</code>: SoPlex LP-solver (default)
604  * - <code>xprs</code>: XPress LP-solver
605  * - <code>none</code>: no LP-solver (you should set the parameter <lp/solvefreq> to <-1> to avoid solving LPs)
606  *
607  * - <code>LPSOPT=<dbg|opt|opt-gccold></code> Chooses the debug or optimized version (or old GCC optimized) version of
608  * the LP-solver. (currently only available for SoPlex and CLP)
609  *
610  * - <code>ZIMPL=<true|false></code> Turns direct support of ZIMPL in SCIP on (default) or off, respectively.
611  * - <code>ZIMPLOPT=<dbg|opt|opt-gccold></code> Chooses the debug or optimized (default) (or old GCC optimized)
612  * version of ZIMPL, if ZIMPL support is enabled. \n
613  * If the ZIMPL-support is disabled, the GMP-library is no longer needed for SCIP and therefore not linked to SCIP.
614  *
615  * - <code>READLINE=<true|false></code> Turns support via the readline library on (default) or off, respectively.
616  *
617  * - <code>IPOPT=<true|false></code> to enable or disable (default) IPOPT interface (needs IPOPT)
618  *
619  * - <code>EXPRINT=<cppad|none></code> to use CppAD as expressions interpreter (default) or no expressions interpreter
620  *
621  * - <code>GAMS=<true|false></code> to enable or disable (default) reading functionality in GAMS reader (needs GAMS)
622  *
623  * There are additional parameters for Linux/Gnu compilers:
624  *
625  * - <code>NOBLKBUFMEM=<true></code> turns off the internal SCIP block and buffer memory. This way the code can be checked by valgrind or
626  * similar tools. (The individual options <code>NOBLKMEM=<true></code> and <code>NOBUFMEM=<true></code> to turn off the SCIP block and
627  * buffer memory, respectively, exist as well).
628  *
629  * - <code>SHARED=<true></code> generates a shared object of the SCIP libraries. (The binary uses these shared
630  * libraries as well.)
631  * - <code>OPT=prf</code> generates a profiling version of SCIP providing a detailed statistic of the time usage of
632  * every method of SCIP.
633  *
634  * You can use other compilers - depending on the system:
635  *
636  * - <code>COMP=intel</code> Uses of the Intel compiler which is only available with the main optimization flags
637  * <code>OPT=<dbg|opt></code>. (Default is gcc/g++ represented through <code>COMP=gnu</code>.)
638  *
639  * There is the possibility to watch the compilation more precisely:
640  *
641  * - <code>VERBOSE=<true|false></code> Turns the extensive output on or off (default).
642  *
643  * The SCIP makefile supports several targets (used via <code>make ... "target"</code>):
644  *
645  * - <code>links</code> Reconfigures the links in the "lib" directory.
646  * - <code>doc</code> Creates documentation in the "doc" directory.
647  * - <code>clean</code> Removes all object files.
648  * - <code>depend</code> Creates dependencies files. This is only needed if you add files to SCIP.
649  * - <code>check</code> Runs the check script, see \ref TEST.
650  *
651  * The SCIP makefiles are structured as follows.
652  *
653  * - <code>Makefile</code> This is the basic makefile in the SCIP root directory. It loads
654  * additional makefile information depending on the parameters set.
655  * - <code>make/make.project</code> This file contains definitions that are useful for all codes
656  * that use SCIP, for instance, the examples.
657  * - <code>make.<sys>.<machine>.<compiler>.<dbg|opt|prf|opt-gccold></code> These file contain system/compiler specific
658  * definitions. If you have an unsupported compiler, you can copy one of these and modify it
659  * accordingly.
660  *
661  * If your platform or compiler is not supported by SCIP you might try and copy one of the existing
662  * makefiles in the <code>make</code> directory and modify it. If you succeed, we are always
663  * interested in including more Makefiles into the system.
664  *
665  *
666  * @section EXAMPLE1 Example 1 (defaults: SoPlex, with ZIMPL support):
667  *
668  * Typing <code>make</code> uses SoPlex as LP solver and includes support for the modeling language ZIMPL. You will be asked the
669  * following questions on the first call to "make" (example answers are already given):
670  *
671  * \verbatim
672  > make
673  make[1]: Entering directory `scip-1.2'
674 
675  - Current settings: LPS=spx OSTYPE=linux ARCH=x86_64 COMP=gnu SUFFIX= ZIMPL=true ZIMPLOPT=opt IPOPT=false IPOPTOPT=opt
676 
677  * SCIP needs some softlinks to external programs, in particular, LP-solvers.
678  * Please insert the paths to the corresponding directories/libraries below.
679  * The links will be installed in the 'lib' directory.
680  * For more information and if you experience problems see the INSTALL file.
681 
682  -> "spxinc" is the path to the SoPlex "src" directory, e.g., "../../soplex/src".
683  -> "libsoplex.*" is the path to the SoPlex library, e.g., "../../soplex/lib/libsoplex.linux.x86.gnu.opt.a"
684  -> "zimplinc" is a directory containing the path to the ZIMPL "src" directory, e.g., "../../zimpl/src".
685  -> "libzimpl.*" is the path to the ZIMPL library, e.g., "../../zimpl/lib/libzimpl.linux.x86.gnu.opt.a"
686 
687  - preparing missing soft-link "lib/spxinc":
688  > Enter soft-link target file or directory for "lib/spxinc" (return if not needed):
689  > ../../soplex/src/
690  -> creating softlink "lib/spxinc" -> "../../soplex/src"
691 
692 
693  - preparing missing soft-link "lib/libsoplex.linux.x86_64.gnu.opt.a":
694  > Enter soft-link target file or directory for "lib/libsoplex.linux.x86_64.gnu.opt.a" (return if not needed):
695  > ../../soplex/lib/libsoplex.linux.x86_64.gnu.opt.a
696  -> creating softlink "lib/libsoplex.linux.x86_64.gnu.opt.a" -> "../../soplex/lib/libsoplex.linux.x86_64.gnu.opt.a"
697 
698 
699  - preparing missing soft-link "lib/libsoplex.linux.x86_64.gnu.opt.so":
700  * this soft-link is not necessarily needed since "lib/libsoplex.linux.x86_64.gnu.opt.a" already exists - press return to skip
701  > Enter soft-link target file or directory for "lib/libsoplex.linux.x86_64.gnu.opt.so" (return if not needed):
702  >
703  * skipped creation of softlink "lib/libsoplex.linux.x86_64.gnu.opt.so". Call "make links" if needed later.
704 
705 
706  - preparing missing soft-link "lib/zimplinc/zimpl":
707  > Enter soft-link target file or directory for "lib/zimplinc/zimpl" (return if not needed):
708  ../../zimpl/src/
709  creating softlink "lib/zimplinc/zimpl" -> "../../zimpl/src"
710 
711 
712  - preparing missing soft-link "lib/libzimpl.linux.x86_64.gnu.opt.a":
713  > Enter soft-link target file or directory for "lib/libzimpl.linux.x86_64.gnu.opt.a" (return if not needed):
714  > ../../zimpl/lib/libzimpl.linux.x86_64.gnu.opt.a
715  -> creating softlink "lib/libzimpl.linux.x86_64.gnu.opt.a" -> "../../zimpl/lib/libzimpl.linux.x86_64.gnu.opt.a"
716 
717 
718  - preparing missing soft-link "lib/libzimpl.linux.x86_64.gnu.opt.so":
719  * this soft-link is not necessarily needed since "lib/libzimpl.linux.x86_64.gnu.opt.a" already exists - press return to skip
720  > Enter soft-link target file or directory for "lib/libzimpl.linux.x86_64.gnu.opt.so" (return if not needed):
721  >
722  * skipped creation of softlink "lib/libzimpl.linux.x86_64.gnu.opt.so". Call "make links" if needed later.
723 
724  ...
725 
726  -> generating library lib/libobjscip-1.2.0.linux.x86_64.gnu.opt.a
727  -> generating library lib/liblpispx-1.2.0.linux.x86_64.gnu.opt.a
728  -> generating library lib/libscip-1.2.0.linux.x86_64.gnu.opt.a
729  -> linking bin/scip-1.2.0.linux.x86_64.gnu.opt.spx
730 
731  \endverbatim
732  *
733  * @section EXAMPLE2 Example 2 (CPLEX, with no ZIMPL support):
734  *
735  * Typing <code>make LPS=cpx ZIMPL=false</code> uses CPLEX as LP solver. You will be asked the following questions on
736  * the first call to "make" (example answers are already given):
737  *
738  * \verbatim
739  > make LPS=cpx ZIMPL=false
740  make[1]: Entering directory `scip-1.2'
741 
742  - Current settings: LPS=cpx OSTYPE=linux ARCH=x86_64 COMP=gnu SUFFIX= ZIMPL=false ZIMPLOPT=opt IPOPT=false IPOPTOPT=opt
743 
744  * SCIP needs some softlinks to external programs, in particular, LP-solvers.
745  * Please insert the paths to the corresponding directories/libraries below.
746  * The links will be installed in the 'lib' directory.
747  * For more information and if you experience problems see the INSTALL file.
748 
749  -> "cpxinc" is the path to the CPLEX "include" directory, e.g., "<CPLEX-path>/include/ilcplex".
750  -> "libcplex.*" is the path to the CPLEX library, e.g., "<CPLEX-path>/lib/x86_rhel4.0_3.4/static_pic/libcplex.a"
751 
752  - preparing missing soft-link "lib/cpxinc":
753  > Enter soft-link target file or directory for "lib/cpxinc" (return if not needed):
754  > ../../cplex121/include
755  -> creating softlink "lib/cpxinc" -> "../../cplex121/include"
756 
757 
758  - preparing missing soft-link "lib/libcplex.linux.x86_64.gnu.a":
759  > Enter soft-link target file or directory for "lib/libcplex.linux.x86_64.gnu.a" (return if not needed):
760  > ../../cplex121/lib/x86-64_sles9.0_3.3/static_pic/libcplex.a
761  -> creating softlink "lib/libcplex.linux.x86_64.gnu.a" -> "../../../../adm_cple/cplex121/lib/x86-64_sles9.0_3.3/static_pic/libcplex.a"
762 
763 
764  - preparing missing soft-link "lib/libcplex.linux.x86_64.gnu.so":
765  > Enter soft-link target file or directory for "lib/libcplex.linux.x86_64.gnu.so" (return if not needed):
766  >
767  * skipped creation of softlink "lib/libcplex.linux.x86_64.gnu.so". Call "make links" if needed later.
768 
769  ...
770 
771  -> generating library lib/libobjscip-1.2.0.linux.x86_64.gnu.opt.a
772  -> generating library lib/liblpicpx-1.2.0.linux.x86_64.gnu.opt.a
773  -> generating library lib/libscip-1.2.0.linux.x86_64.gnu.opt.a
774  -> linking bin/scip-1.2.0.linux.x86_64.gnu.opt.cpx
775 
776  \endverbatim
777  *
778  * @section COMPILERPROBLEMS Compilation problems:
779  *
780  * - If the soft-link query script does not work on your machine, read step 2 in the \ref INSTALL "INSTALL" file for
781  * instructions on manually creating the soft-links.
782  *
783  * - If you get an error message of the type\n
784  * <code>make: *** No rule to make target `lib/???', needed by `obj/O.linux.x86.gnu.opt/lib/scip/???.o'. Stop.</code>\n
785  * the corresponding soft-link was not created or points to a wrong location. Check the soft-link targets in the "lib/"
786  * subdirectory. Try to delete all soft-links from the "lib/" directory\n and call "make links" to generate them
787  * again. If this still fails, read step 2 for instructions on manually\n creating the soft-links.
788  *
789  * - If you get an error message of the type\n
790  * <code>make: *** No rule to make target `make/make.?.?.?.?.?'. Stop.</code>,\n
791  * the corresponding machine dependent makefile for your architecture and compiler is missing.\n Create one of the given
792  * name in the "make/" subdirectory. You may take\n "make/make.linux.x86.gnu.opt" or any other file in the make
793  * subdirectory as example.\n
794  *
795  * - The readline library seems to differ slightly on different OS distributions. Some versions do
796  * not support the <code>remove_history()</code> call. In this case, you have to either add
797  * <code>-DNO_REMOVE_HISTORY</code> to the FLAGS in the appropriate "make/make.*" file, or to
798  * compile with <code>make USRFLAGS=-DNO_REMOVE_HISTORY</code>. Make sure, the file
799  * "src/scip/dialog.c" is recompiled. If this doesn't work either, disable the readline library
800  * with <code>make READLINE=false</code>.
801  *
802  * - On some systems, the <code>sigaction()</code> method is not available. In this case, you have
803  * to either add <code>-DNO_SIGACTION</code> to the FLAGS in the appropriate "make/make.*" file, or
804  * to compile with <code>make USRFLAGS=-DNO_SIGACTION</code>. Make sure, the file
805  * "src/scip/interrupt.c" is recompiled.
806  *
807  * - On some systems, the <code>rand_r()</code> method is not available. In this case, you have to either add
808  * <code>-DNO_RAND_R</code> to the FLAGS in the appropriate "make/make.*" file, or to compile with
809  * <code>make USRFLAGS=-DNO_RAND_R</code>. Make sure, the file "src/scip/misc.c" is recompiled.
810  *
811  * - On some systems, the <code>strtok_r()</code> method is not available. In this case, you have
812  * to either add <code>-DNO_STRTOK_R</code> to the FLAGS in the appropriate make/make.* file, or to
813  * compile with <code>make USRFLAGS=-DNO_STRTOK_R</code>. Make sure, the file "src/scip/misc.c" is
814  * recompiled.
815  *
816  * - On some systems, the <code>strerror_r()</code> method is not available. In this case, you have
817  * to either add <code>-DNO_STRERROR_R</code> to the FLAGS in the appropriate "make/make.*" file, or
818  * to compile with <code>make USRFLAGS=-DNO_STRERROR_R</code>. Make sure, the file
819  * "src/scip/misc.c" is recompiled.
820  *
821  * - On some systems, the option [-e] is not available for the read command. You have to compile with READ=read.
822  *
823  * - If you encounter other compiler or linker errors, you should recompile with <code>make
824  * VERBOSE=true ...</code> in order to get the full compiler invocation. This might help to fix the
825  * corresponding machine dependent makefile in the make subdirectory.
826  *
827  * @section WINDOWS Remarks on Installing under Windows using MinGW
828  *
829  * To build your own windows binaries under windows we recommend using the MinGW-Compiler with MSYS
830  * from <a href="http://www.mingw.org">www.mingw.org</a> .
831  *
832  * First install MSYS, then MinGW to the mingw folder inside the msys folder.
833  * Now you need to install the following packages to the mingw folder:
834  * - zlib (or use ZLIB=false)
835  * - pcre (here suffices the pcre7.0-lib.zip (or equivalent) to be extracted into the mingw-folder)
836  *
837  * After calling <code>make clean</code> in the ZIMPL folder you will also need flex and bison to
838  * remake ZIMPL. We recommend NOT to use <code>"make clean"</code> inside the ZIMPL-folder if you do
839  * not have these packages installed.
840  *
841  * You can download these additional packages from <a href="http://gnuwin32.sourceforge.net/packages.html">here</a>
842  * or compile the source on your own from their homepages.
843  *
844  * Second you need to copy the file <code>sh.exe</code> to <code>bash.exe</code> otherwise various
845  * scripts (including makefiles) will not work. Normally <code>unistd.h</code> covers also the
846  * getopt-options, but for mingw you need to add the entry <code>\#include <getopt.h></code> into
847  * "/mingw/include/unistd.h" after the other include-entries (if not present).
848  *
849  * Finally, there is one package you need to compile if you want to use ZIMPL and ZIMPL-support in
850  * SCIP (otherwise use <code>ZIMPL=false</code> as parameter with the make-call): the
851  * <code>gmplib</code> from <a href="http://www.gmplib.org">gmplib.org</a>. The command
852  * <code>./configure --prefix=/mingw ; make ; make install</code> should succeed without problems
853  * and installs the gmplib to the mingw folder.
854  *
855  * Now <code>make READLINE=false</code> should be compiling without errors. Please note that we
856  * do NOT support creating the doxygen documentation and readline-usage under windows.
857  *
858  *
859  * @section RUN How to run SCIP after successfully compiling SCIP
860  *
861  * To run the program, enter <code>bin/scip</code> for the last compiled version. If you have more than one compiled
862  * binary (i. e., one in debug and one in optimized mode) and wish to specify the binary, type
863  * <code>bin/scip.\$(OSTYPE).\$(ARCH).\$(COMP).\$(OPT).\$(LPS)</code>
864  * (e.g. <code>bin/scip.linux.x86_64.gnu.opt.spx</code>).
865  *
866  */
867 
868 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
869 /**@page START How to start a new project
870  *
871  * Once you succeeded installing SCIP together with an LP-solver on your system,
872  * you have a powerful tool for solving MIPs, MIQCPs,
873  * MINLPs, etc... at hand. SCIP can also be customized to the type of problems you
874  * are working on by additional plugins.
875  * Instructions on how to write a new plugin and include it in SCIP can be found in the corresponding
876  * \ref HOWTOADD "How to add ... pages".
877  *
878  * SCIP can also be used for writing your own branch-and-cut or branch-and-cut-and-price code. SCIP already
879  * provides a number of existing code examples which we suggest as both reference and starting point
880  * for these kinds of projects.
881  * Below, you find some hints of how to start such a project.
882  *
883  * - The example should be chosen
884  * depending on the programming language (<b>C</b> or <b>C++</b>) and the purpose
885  * (<b>branch-and-cut</b> or <b>branch-and-cut-and-price</b>) of your project.
886  * <br>
887  * We suggest the use one of the following examples:
888  * - 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
889  * in <b>C++</b>.
890  * - The <a href="http://scip.zib.de/doc/examples/Binpacking"><b>Binpacking</b></a>-example
891  * and the <a href="http://scip.zib.de/doc/applications/Coloring"><b>Coloring</b></a> application are
892  * <b>branch-and-cut-and-price</b> (column generation)-codes in <b>C</b>.
893  * - The <a href="http://scip.zib.de/doc/examples/TSP"><b>TSP</b></a>-example
894  * is a <b>branch-and-cut</b>-code in <b>C++</b>.
895  * - The <a href="http://scip.zib.de/doc/examples/LOP"><b>LOP</b></a>-example
896  * is a <b>branch-and-cut</b>-code in <b>C</b>.
897  * .
898  * - Copy one of the examples in the <code>examples</code> directory (in the SCIP root
899  * directory). For instance, type
900  * \verbatim
901  > cp -r examples/Binpacking/ ../SCIPProject/ ; cd ../SCIPProject
902  \endverbatim
903  * from the SCIP root directory for copying the content of the <code>Binpacking</code>-example into a fresh
904  * directory named SCIPProject in the parent directory of the SCIP root directory and jumping to
905  * the new SCIPProject directory rightafter.
906  * - Open the <code>Makefile</code> via
907  * \verbatim
908  > kate Makefile
909  \endverbatim
910  * and edit the following variables at the top to have a compilable code:
911  *
912  * - specify a correct path to the SCIP root (<code>SCIPDIR</code>)
913  * - rename the targets name (<code>MAINNAME</code>)
914  * - adjust the source file names (<code>MAINOBJ</code>).
915  * .
916  * - Once you have edited the makefile, you can use all the flags that can be used in SCIP to
917  * compile your code, see \ref MAKE.
918  * Note that you need to update the dependency files before compiling your project via <code>make depend</code>.
919  *
920  *
921  *
922  *
923  */
924 
925 
926 /**@page SHELL Tutorial: the interactive shell
927  *
928  * If are using SCIP as a black box solver, here you will find some tips and tricks what you can do.
929  *
930  * @section TUTORIAL_OPTIMIZE Read and optimize a problem instance
931  *
932  * First of all, we need a SCIP binary and an example problem file to work with. Therefore, you can either download the
933  * SCIP standard distribution (which includes problem files) and compile it on your own or you can download a
934  * 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).
935  *
936  * If you want to download the source code of the SCIP standard distribution, we recommend to go to the <a
937  * href="http://scip.zib.de/#download">SCIP download section</a>, download the latest release (version 3.0 as
938  * of this writing), inflate the tarball (e.g., with "tar xzf scipoptsuite-[version].tgz"), and follow the instructions
939  * in the INSTALL file. The instance stein27, which will serve as an example in this tutorial, can be found under
940  * scipoptsuite-[version]/scip-[version]/check/instances/MIP/stein27.mps.
941  *
942  * If you want to download a precompiled binary, go to the <a href="http://scip.zib.de/#download">SCIP download
943  * section</a> and download an appropriate binary for your operating system. The SCIP source code distribution already comes with
944  * the example problem instance used throughout this tutorial. To follow this tutorial with a precompiled binary, we recommend downloading the instance
945  * <a href="http://miplib.zib.de/miplib3/miplib3/stein27.mps.gz">stein27</a> from
946  * the <a href="http://miplib.zib.de/miplib3/miplib.html">MIPLIB 3.0</a> homepage.
947  *
948  * Now start your binary, without any arguments. This opens the interactive shell, which should look somehow like this:
949  *
950  * \code
951  * SCIP version 2.0.1 [precision: 8 byte] [memory: block] [mode: optimized] [LP solver: SoPlex 1.5.0]
952  * Copyright (c) 2002-2016 Konrad-Zuse-Zentrum fuer Informationstechnik Berlin (ZIB)
953  *
954  * External codes:
955  * SoPlex 1.5.0 Linear Programming Solver developed at Zuse Institute Berlin (soplex.zib.de)
956  * ZIMPL 3.1.0 Zuse Institute Mathematical Programming Language developed by T. Koch (zimpl.zib.de)
957  *
958  * user parameter file <scip.set> not found - using default parameters
959  *
960  * SCIP>
961  * \endcode
962  *
963  * First of all "help" shows you a list of all available shell commands. Brackets indicate a submenu with further options.
964  * \code
965  * SCIP> help
966 
967  * <display> display information
968  * <set> load/save/change parameters
969  * ...
970  * read read a problem
971  * \endcode
972  *
973  * Okay, let's solve some MIPs... use "read <path/to/file>" to parse a problem file, "optimize" to solve it and "display
974  * solution" to show the nonzero variables of the best found solution.
975 
976  * \code
977  * SCIP> read check/instances/MIP/stein27.fzn
978  * original problem has 27 variables (27 bin, 0 int, 0 impl, 0 cont) and 118 constraints
979  * SCIP> optimize
980  *
981  * feasible solution found by trivial heuristic, objective value 2.700000e+01
982  * presolving:
983  * (round 1) 0 del vars, 0 del conss, 0 chg bounds, 0 chg sides, 0 chg coeffs, 118 upgd conss, 0 impls, 0 clqs
984  * presolving (2 rounds):
985  * 0 deleted vars, 0 deleted constraints, 0 tightened bounds, 0 added holes, 0 changed sides, 0 changed coefficients
986  * 0 implications, 0 cliques
987  * presolved problem has 27 variables (27 bin, 0 int, 0 impl, 0 cont) and 118 constraints
988  * 1 constraints of type <knapsack>
989  * 117 constraints of type <logicor>
990  * transformed objective value is always integral (scale: 1)
991  * Presolving Time: 0.00
992  *
993  * time | node | left |LP iter|LP it/n| mem |mdpt |frac |vars |cons |cols |rows |cuts |confs|strbr| dualbound | primalbound | gap
994  * t 0.0s| 1 | 0 | 34 | - | 337k| 0 | 21 | 27 | 118 | 27 | 118 | 0 | 0 | 0 | 1.300000e+01 | 2.700000e+01 | 107.69%
995  * R 0.0s| 1 | 0 | 34 | - | 338k| 0 | 21 | 27 | 118 | 27 | 118 | 0 | 0 | 0 | 1.300000e+01 | 2.600000e+01 | 100.00%
996  * s 0.0s| 1 | 0 | 34 | - | 339k| 0 | 21 | 27 | 118 | 27 | 118 | 0 | 0 | 0 | 1.300000e+01 | 2.500000e+01 | 92.31%
997  * 0.0s| 1 | 0 | 44 | - | 392k| 0 | 21 | 27 | 118 | 27 | 120 | 2 | 0 | 0 | 1.300000e+01 | 2.500000e+01 | 92.31%
998  * b 0.0s| 1 | 0 | 44 | - | 393k| 0 | 21 | 27 | 118 | 27 | 120 | 2 | 0 | 0 | 1.300000e+01 | 1.900000e+01 | 46.15%
999  * ...
1000  * 0.1s| 1 | 2 | 107 | - | 920k| 0 | 24 | 27 | 118 | 27 | 131 | 13 | 0 | 24 | 1.300000e+01 | 1.900000e+01 | 46.15%
1001  * 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%
1002  * 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%
1003  * 0.1s| 200 | 86 | 1195 | 5.5 |1012k| 13 | - | 27 | 119 | 27 | 124 | 13 | 1 | 207 | 1.300000e+01 | 1.800000e+01 | 38.46%
1004  * time | node | left |LP iter|LP it/n| mem |mdpt |frac |vars |cons |cols |rows |cuts |confs|strbr| dualbound | primalbound | gap
1005  * 0.2s| 300 | 106 | 1686 | 5.3 |1024k| 13 | - | 27 | 119 | 27 | 124 | 13 | 1 | 207 | 1.350000e+01 | 1.800000e+01 | 33.33%
1006  * ...
1007  * 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%
1008  *
1009  * SCIP Status : problem is solved [optimal solution found]
1010  * Solving Time (sec) : 0.73
1011  * Solving Nodes : 4192
1012  * Primal Bound : +1.80000000000000e+01 (283 solutions)
1013  * Dual Bound : +1.80000000000000e+01
1014  * Gap : 0.00 %
1015  *
1016  * SCIP> display solution
1017  *
1018  * objective value: 18
1019  * x0001 1 (obj:1)
1020  * x0003 1 (obj:1)
1021  * ...
1022  * x0027 1 (obj:1)
1023  *
1024  * SCIP>
1025  * \endcode
1026  *
1027  * What do we see here? After "optimize", SCIP first goes into presolving. Not much is happening for this instance, just
1028  * the linear constraints get upgraded to more specific types. Each round of presolving will be displayed in a single
1029  * line, with a short summary at the end. Here, there has only been one round with actual changes, the second round did
1030  * not bring any further reductions. Thus, it is not displayed and presolving is stopped. Then, we see the actual
1031  * solving process. The first three output lines indicate that new incumbent solutions were found by the primal
1032  * heuristics with display characters "t", "R", and "s"; see, how the "primalbound" column goes down from 27 to 25. In
1033  * 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
1034  * resolve after adding cuts). Little later, the root node processing is finished. We see that there are now two open
1035  * nodes in the "left" column. From now on, we will see an output line every hundredth node or whenever a new incumbent
1036  * is found (e.g. at node 14 in the above output). After some more nodes, the "dualbound" starts moving, too. At one
1037  * point, both will be the same, and the solving process terminates, showing us some wrap-up information.
1038  *
1039  * The exact performance varies amongst different architectures, operating systems, and so on. Do not be worried if
1040  * your installation needs more or less time or nodes to solve. Also, this instance has more than 2000 different optimal
1041  * solutions. The optimal objective value always has to be 18, but the solution vector may differ. If you are interested
1042  * in this behavior, which is called "performance variability", you may have a look at the MIPLIB2010 paper.
1043  *
1044  * @section TUTORIAL_FILEIO Writing problems and solutions to a file
1045 
1046  * SCIP can also write information to files. E.g., we could store the incumbent solution to a file, or output the
1047  * problem instance in another file format (the LP format is much more human readable than the MPS format, for example).
1048  *
1049  * \code
1050  * SCIP> write solution stein27.sol
1051  *
1052  * written solution information to file <stein27.sol>
1053  *
1054  * SCIP> write problem stein27.lp
1055  * written original problem to file <stein27.lp>
1056  *
1057  * SCIP> q
1058  * ...
1059  * \endcode
1060  *
1061  * Passing starting solutions can increase the solving performance so that SCIP does not need to construct an initial feasible solution
1062  * by itself. After reading the problem instance, use the "read" command again, this time with a file containing solution information.
1063  * Solutions can be specified in a raw or xml-format and must have the file extension ".sol", see the documentation of the
1064  * <a href="http://scip.zib.de/doc/html/reader__sol_8h.php">solution reader of SCIP</a> for further information.
1065  *
1066  * Customized settings are not written or read with the "write" and "read" commands, but with the three commands
1067  *
1068  * \code
1069  * SCIP> set save _settingsfilename_
1070  * SCIP> set diffsave _settingsfilename_
1071  * SCIP> set load _settingsfilename_
1072  * \endcode
1073  *
1074  * See the section on parameters \ref TUTORIAL_PARAMETERS for more information.
1075  *
1076  * @section TUTORIAL_STATISTICS Displaying detailed solving statistics
1077  *
1078  * We might want to have some more information now. Which were the heuristics that found the solutions? What plugins
1079  * were called during the solutions process and how much time did they spend? How did the instance that we were solving
1080  * look? Information on certain plugin types (e.g., heuristics, branching rules, separators) we get by
1081  * "display <plugin-type>", information on the solution process, we get by "display statistics", and "display problem"
1082  * shows us the current instance.
1083  *
1084  \code
1085  * SCIP> display heuristics
1086  * primal heuristic c priority freq ofs description
1087  * ---------------- - -------- ---- --- -----------
1088  * trivial t 10000 0 0 start heuristic which tries some trivial solutions
1089  * ...
1090  * rounding R -1000 1 0 LP rounding heuristic with infeasibility recovering
1091  * shifting s -5000 10 0 LP rounding heuristic with infeasibility recovering also using continuous variables
1092  * ...
1093  * SCIP> display statistics
1094  * ...
1095  * gomory : 0.02 6 0 0 461 0
1096  * cgmip : 0.00 0 0 0 0 0
1097  * strongcg : 0.01 6 0 0 598 0
1098  * ...
1099  * oneopt : 0.01 4 1
1100  * coefdiving : 0.02 57 0
1101  * ...
1102  * primal LP : 0.00 0 0 0.00 -
1103  * dual LP : 0.20 4187 14351 3.43 71755.00
1104  * ...
1105  * \endcode
1106  *
1107  * We see that rounding and shifting were the heuristics producing the solutions in the beginning. Rounding is called at
1108  * every node, shifting only at every tenth level of the tree. The statistics are quite comprehensive, thus, we just
1109  * explain a few lines here. We get information for all types of plugins and for the overall solving process. Besides
1110  * others, we see that in six calls, the gomory cut separator and the strong Chv&aacute;tal-Gomory separator each produced
1111  * several hundred cuts (of which only a few entered the LP). The oneopt heuristic found one solution in 4 calls,
1112  * whereas coefdiving failed all 57 times it was called. All the LPs have been solved with the dual simplex algorithm, which
1113  * took about 0.2 seconds of the 0.7 seconds overall solving time.
1114  *
1115  * @section TUTORIAL_PARAMETERS Changing parameters from the interactive shell
1116  *
1117  * Now, we can start playing around with parameters. Rounding and shifting seem to be quite successful on this instance,
1118  * wondering what happens if we disable them? Or what happens, if we are even more rigorous and disable all heuristics?
1119  * Or if we do the opposite and use aggressive heuristics?
1120  *
1121  * \code
1122  * SCIP> set
1123  *
1124  * <branching> change parameters for branching rules
1125  * ...
1126  * <heuristics> change parameters for primal heuristics
1127  *
1128  * SCIP/set> heuristics
1129  *
1130  * <actconsdiving> LP diving heuristic that chooses fixings w.r.t. the active constraints
1131  * ...
1132  * <shifting> LP rounding heuristic with infeasibility recovering also using continuous variables
1133  * ...
1134  *
1135  * SCIP/set/heuristics> shifting
1136  *
1137  * <advanced> advanced parameters
1138  * freq frequency for calling primal heuristic <shifting> (-1: never, 0: only at depth freqofs) [10]
1139  * freqofs frequency offset for calling primal heuristic <shifting> [0]
1140  *
1141  * SCIP/set/heuristics/shifting> freq
1142  * current value: 10, new value [-1,2147483647]: -1
1143  * heuristics/shifting/freq = -1
1144  *
1145  * SCIP> se he rou freq -1
1146  * heuristics/rounding/freq = -1
1147  *
1148  * SCIP> re check/instances/MIP/stein27.mps
1149  * original problem has 27 variables (27 bin, 0 int, 0 impl, 0 cont) and 118 constraints
1150  * SCIP> o
1151  *
1152  * feasible solution found by trivial heuristic, objective value 2.700000e+01
1153  * ...
1154  * 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%
1155  * 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%
1156  * * 0.1s| 39 | 28 | 386 | 7.0 |1092k| 14 | - | 27 | 118 | 27 | 123 | 14 | 0 | 199 | 1.300000e+01 | 1.800000e+01 | 38.46%
1157  * ...
1158  * SCIP Status : problem is solved [optimal solution found]
1159  * Solving Time (sec) : 0.75
1160  * Solving Nodes : 4253
1161  * Primal Bound : +1.80000000000000e+01 (287 solutions)
1162  * Dual Bound : +1.80000000000000e+01
1163  * Gap : 0.00 %
1164  *
1165  * SCIP>
1166  * \endcode
1167  *
1168  * We can navigate through the menus step-by-step and get a list of available options and submenus. Thus, we select
1169  * "set" to change settings, "heuristics" to change settings of primal heuristics, "shifting" for that particular
1170  * heuristic. Then we see a list of parameters (and yet another submenu for advanced parameters), and disable this
1171  * heuristic by setting its calling frequency to -1. If we already know the path to a certain setting, we can directly
1172  * type it (as for the rounding heuristic in the above example). Note that we do not have to use the full names, but we
1173  * may use short versions, as long as they are unique.
1174  *
1175  * To solve a problem a second time, we have to read it and start the optimization process again.
1176  *
1177  * \code
1178  * SCIP> set default
1179  * reset parameters to their default values
1180  * SCIP> set heuristics emphasis
1181  *
1182  * aggressive sets heuristics <aggressive>
1183  * fast sets heuristics <fast>
1184  * off turns <off> all heuristics
1185  *
1186  * SCIP/set/heuristics/emphasis> aggr
1187  * heuristics/veclendiving/freq = 5
1188  * ...
1189  * heuristics/crossover/minfixingrate = 0.5
1190  * SCIP> read check/instances/MIP/stein27.mps
1191  * original problem has 27 variables (27 bin, 0 int, 0 impl, 0 cont) and 118 constraints
1192 
1193  * SCIP> opt
1194  * ...
1195  * D 0.1s| 1 | 0 | 107 | - | 971k| 0 | 24 | 27 | 122 | 27 | 131 | 13 | 4 | 0 | 1.300000e+01 | 1.800000e+01 | 38.46%
1196  * 0.1s| 1 | 0 | 107 | - | 971k| 0 | 24 | 27 | 122 | 27 | 131 | 13 | 4 | 0 | 1.300000e+01 | 1.800000e+01 | 38.46%
1197  * 0.1s| 1 | 0 | 119 | - |1111k| 0 | 24 | 27 | 122 | 27 | 132 | 14 | 4 | 0 | 1.300000e+01 | 1.800000e+01 | 38.46%
1198  * 0.1s| 1 | 2 | 119 | - |1112k| 0 | 24 | 27 | 122 | 27 | 132 | 14 | 4 | 24 | 1.300000e+01 | 1.800000e+01 | 38.46%
1199  * time | node | left |LP iter|LP it/n| mem |mdpt |frac |vars |cons |cols |rows |cuts |confs|strbr| dualbound | primalbound | gap
1200  * 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%
1201  * 0.2s| 200 | 91 | 1226 | 5.6 |1155k| 14 | - | 27 | 122 | 27 | 123 | 14 | 4 | 207 | 1.300000e+01 | 1.800000e+01 | 38.46%
1202  * ^Cpressed CTRL-C 1 times (5 times for forcing termination)
1203  *
1204  * SCIP Status : solving was interrupted [user interrupt]
1205  * Solving Time (sec) : 0.32
1206  * Solving Nodes : 216
1207  * Primal Bound : +1.80000000000000e+01 (283 solutions)
1208  * Dual Bound : +1.30000000000000e+01
1209  * Gap : 38.46 %
1210  *
1211  * SCIP>
1212  * \endcode
1213  *
1214  * Okay, what happened here? First, we reset all parameters to their default values, using "set default". Next, we
1215  * loaded some meta-parameter settings (also see <a href="http://scip.zib.de/#faq">the FAQ</a>), to apply primal heuristics
1216  * more aggressively. SCIP shows us, which single parameters it changed therefor. Now, the optimal solution is already
1217  * found at the root node, by a heuristic which is deactivated by default. Then, after node 200, the user pressed
1218  * CTRL-C which interrupts the solving process, We see that now in the short status report, primal and dual bound are
1219  * different, thus, the problem is not solved yet. Nevertheless, we could access statistics, see the current incumbent
1220  * solution, change parameters and so on. Entering "optimize" we continue the solving process from the point on at which
1221  * it has been interrupted.
1222  *
1223  * Once you found a non-default parameter setting that you wish to save and use in the future, use either the command
1224  * \code
1225  * SCIP> set save settingsfile.set
1226  * \endcode
1227  * to save <b>all</b> parameter values to the specified file, or
1228  * \code
1229  * SCIP> set diffsave settingsfile.set
1230  * \endcode
1231  * in order to save only the nondefault parameters. The latter has several advantages, you can, e.g., combine parameter
1232  * settings from multiple settings files stored by the latter command, as long as they only affect mutually exclusive
1233  * parameter values.
1234  *
1235  * For loading a previously stored settings file, use the "load" command:
1236  *
1237  * \code
1238  * SCIP> set load settingsfile.set
1239  * \endcode
1240  *
1241  * Special attention should be drawn to the reserved settings file name "scip.set"; whenever the SCIP interactive shell
1242  * is started from a working directory that contains a settings file with the name "scip.set", it will be automatically
1243  * replace the default settings.
1244  *
1245  * For using special settings for automated tests as described in \ref TEST, save your custom settings in a subdirectory
1246  * "SCIP_HOME/settings".
1247  *
1248  *
1249  * We hope this tutorial gave you an overview of what is possible using the SCIP interactive shell. Please also read our
1250  * \ref FAQ, in particular the section <a href="http://scip.zib.de/#faq">Using SCIP as a standalone MIP/MINLP-Solver</a>.
1251  */
1252 
1253 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
1254 /**@page DOC How to search the documentation for interface methods
1255  *
1256  * If you are looking for a method in order to perform a specific task, there are usually two places to look at:
1257  * - The file "scip.h" in the file list.
1258  * In this main header file, you find all methods that perform "complex" operations that affect or need data from
1259  * different components of SCIP.
1260  * For these methods, you always have to provide the SCIP pointer that is created by SCIPcreate().
1261  * The documentation of "scip.h" is grouped into several blocks, each dealing with methods for a specific kind of
1262  * object.
1263  * For example, all methods operating on variables are grouped together.
1264 
1265  * - The files \ref PUBLICMETHODS "pub_<...>.h" contain methods that perform "easy" operations that only
1266  * affect the corresponding objects.
1267  * Usually, with these methods you can access the data of the object.
1268  * For example, in "pub_var.h" you find methods to get information about a variable.
1269  *
1270  * The file "pub_misc.h" contains methods for data structures like priority queues, hash tables, and hash maps,
1271  * as well as methods for sorting, numerics, random numbers, string operations, and file operations.
1272  *
1273  * If you are looking for a description of a callback method of a plugin that you want to implement, you have to
1274  * look at the corresponding \ref TYPEDEFINITIONS "type_<...>.h".
1275  */
1276 
1277 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
1278 /**@page CONS How to add constraint handlers
1279  *
1280  * A constraint handler defines the semantics and the algorithms to process constraints of a certain class. A single
1281  * constraint handler is responsible for all constraints belonging to its constraint class. For example, there is
1282  * one \ref cons_knapsack.h "knapsack constraint handler" that ensures solutions are only accepted if they satisfy all
1283  * knapsack constraints in the model. \n A complete list of all constraint handlers contained in this release can be
1284  * found \ref CONSHDLRS "here".
1285  *
1286  * We now explain how users can add their own constraint handlers.
1287  * For an example, look into the subtour constraint handler (examples/TSP/src/ConshdlrSubtour.cpp) of the
1288  * <a href="http://scip.zib.de/doc/examples/TSP">TSP </a> example project.
1289  * The example is written in C++ and uses the C++ wrapper classes.
1290  * However, we will explain the implementation of a constraint handler using the C interface.
1291  * It is very easy to transfer the C explanation to C++; whenever a method should be implemented using the
1292  * SCIP_DECL_CONS... notion, reimplement the corresponding virtual member function of the abstract scip::ObjConshdlr
1293  * base class.
1294  *
1295  * Additional documentation for the callback methods of a constraint handler can be found in the file
1296  * type_cons.h.
1297  *
1298  * Here is what you have to do (assuming your constraint handler should be named "subtour"):
1299  * -# Copy the template files src/scip/cons_xyz.c and src/scip/cons_xyz.h into files "cons_subtour.c"
1300  * and "cons_subtour.h".
1301  * \n
1302  * Make sure to <b>adjust your Makefile</b> such that these files are compiled and linked to your project.
1303  * -# Use SCIPincludeConsSubtour() in order to include the constraint handler into your SCIP instance,
1304  * e.g., in the main file of your project (see, e.g., src/cppmain.cpp in the TSP example).
1305  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "subtour".
1306  * -# Adjust the \ref CONS_PROPERTIES "properties of the constraint handler".
1307  * -# Define the \ref CONS_DATA "constraint data and the constraint handler data". This is optional.
1308  * -# Implement the \ref CONS_INTERFACE "interface methods".
1309  * -# Implement the \ref CONS_FUNDAMENTALCALLBACKS "fundamental callback methods".
1310  * -# Implement the \ref CONS_ADDITIONALCALLBACKS "additional callback methods". This is optional.
1311  *
1312  *
1313  * @section CONS_PROPERTIES Properties of a Constraint Handler
1314  *
1315  * At the top of the new file "cons_subtour.c" you can find the constraint handler properties.
1316  * These are given as compiler defines. Some of them are optional, as, e.g., separation-related properties,
1317  * which only have to be defined if the constraint handler supports the related callbacks.
1318  * In the C++ wrapper class, you have to provide the constraint handler properties by calling the constructor
1319  * of the abstract base class scip::ObjConshdlr from within your constructor (see the TSP example).
1320  * The properties you have to set have the following meaning:
1321  *
1322  * @subsection CONS_FUNDAMENTALPROPERTIES Fundamental Constraint Handler properties
1323  *
1324  * \par CONSHDLR_NAME: the name of the constraint handler.
1325  * This name is used in the interactive shell to address the constraint handler.
1326  * Additionally, if you are searching for a constraint handler with SCIPfindConshdlr(), this name is looked up.
1327  * Names have to be unique: no two constraint handlers may have the same name.
1328  *
1329  * \par CONSHDLR_DESC: the description of the constraint handler.
1330  * This string is printed as a description of the constraint handler in the interactive shell of SCIP.
1331  *
1332  * \par CONSHDLR_ENFOPRIORITY: the priority of the constraint handler for constraint enforcing.
1333  * Like the separation priority, the enforcement priorities define the order in which the different constraint handlers
1334  * are called in the constraint enforcement step of the subproblem processing.
1335  * The constraint enforcement is called after the price-and-cut loop is executed (in the case that the LP is solved
1336  * at the current subproblem).
1337  * \n
1338  * The integrality constraint handler has an enforcement priority of 0.
1339  * That means, if a constraint handler has negative enforcement priority, it only has to deal with integral solutions
1340  * in its enforcement methods, because for fractional solutions, the integrality constraint handler would have
1341  * created a branching, thereby aborting the enforcement step.
1342  * If you want to implement a constraint-depending branching rule (for example, SOS branching on special ordered
1343  * set constraints), you have to assign a positive enforcement priority to your constraint handler.
1344  * In this case, you have to be able to deal with fractional solutions.
1345  * \n
1346  * See \ref CONSENFOLP and \ref CONSENFOPS for further details of the separation callback.
1347  *
1348  * \par CONSHDLR_CHECKPRIORITY: the priority of the constraint handler for checking feasibility.
1349  * Like the separation priority, the checking priorities define the order in which the different constraint handlers
1350  * are called to check the feasibility of a given primal solution candidate.
1351  * The integrality constraint handler has a checking priority of 0.
1352  * That means, constraint handlers with negative checking priorities only have to deal with integral solutions.
1353  *
1354  * \par CONSHDLR_EAGERFREQ: the default frequency for using all instead of only the useful constraints in separation, propagation and enforcement.
1355  * If \em constraint \em aging is activated, some constraints that were not useful in the past for propagation or
1356  * separation are marked to be \em obsolete.
1357  * Usually, the obsolete constraints are not presented to the separation and propagation methods of the constraint
1358  * handlers, such that the constraint handlers only process the non-obsolete constraints.
1359  * However, every n'th call, with n being the EAGERFREQ of the constraint handler, all constraints are presented to the
1360  * separation and propagation methods of the constraint handler.
1361  * This gives obsolete constraints the chance of becoming non-obsolete again.
1362  * \n
1363  * If the eager evaluation frequency is set to -1, obsolete constraints are never presented to the separation and
1364  * propagation methods.
1365  * A frequency of 0 means, that obsolete constraints are only used in the first call of each method.
1366  *
1367  * \par CONSHDLR_NEEDSCONS: indicates whether the constraint handler should be skipped, if no constraints are available.
1368  * Usually, a constraint handler is only executed if there are constraints of its corresponding class in the model.
1369  * For those constraint handlers, the NEEDSCONS flag should be set to TRUE.
1370  * However, some constraint handlers must be called without having a constraint of the class in the model, because
1371  * the constraint is only implicitly available.
1372  * For example, the integrality constraint handler has the NEEDSCONS flag set to FALSE, because there is no explicit
1373  * integrality constraint in the model.
1374  * The integrality conditions are attached to the variables, and the integrality constraint handler has to check
1375  * all variables that are marked to be integer for integral values.
1376  *
1377  * @subsection CONS_ADDITIONALPROPERTIES Optional Constraint Handler properties
1378  *
1379  * The following properties are optional and only need to be defined if the constraint handlers support
1380  * separation, presolving, propagation, and/or upgrade functionality.
1381  *
1382  * \par LINCONSUPGD_PRIORITY: priority of the constraint handler for upgrading of linear constraints
1383  * This property is only needed if a certain linear constraint can be upgraded to a more specific one. In one of
1384  * the first presolving rounds SCIP tries to upgrade linear constraints to more specialized constraints, such as
1385  * knapsack constraints. The upgrading calls are processed in the order of decreasing priority.
1386  *
1387  * \par NONLINCONSUPGD_PRIORITY: priority of the constraint handler for upgrading of nonlinear constraints
1388  * This property has the same effect as the LINCONSUPGD_PRIORITY parameter, see above, and should be set whenever
1389  * an upgrade functionality from a general nonlinear constraint to the more specific one is defined.
1390  *
1391  * \par CONSHDLR_SEPAFREQ: the default frequency for separating cuts.
1392  * The separation frequency defines the depth levels at which the constraint handler's separation methods \ref CONSSEPALP
1393  * and \ref CONSSEPASOL are called.
1394  * For example, a separation frequency of 7 means, that the separation callback is executed for subproblems that are
1395  * in depth 0, 7, 14, ... of the branching tree.
1396  * A separation frequency of 0 means, that the separation method is only called at the root node.
1397  * A separation frequency of -1 disables the separation method of the constraint handler.
1398  * \n
1399  * The separation frequency can be adjusted by the user.
1400  * This property of the constraint handler only defines the default value of the frequency.
1401  * If you want to have a more flexible control of when to execute the separation algorithm, you have to assign
1402  * a separation frequency of 1 and implement a check at the beginning of your separation algorithm whether you really
1403  * want to execute the separator or not.
1404  * If you do not want to execute the method, set the result code to SCIP_DIDNOTRUN.
1405  *
1406  * \par CONSHDLR_SEPAPRIORITY: the priority of the constraint handler for separation. (optional: to be set only if the constraint handler supports separation)
1407  * In each separation round during the price-and-cut loop of the subproblem processing or during the separation loop
1408  * of the primal solution separation, the separators and separation methods of the constraint handlers are called in
1409  * a predefined order, which is given by the priorities of the separators and the separation priorities of the
1410  * constraint handlers.
1411  * First, the separators with non-negative priority are called in the order of decreasing priority.
1412  * Next, the separation methods of the different constraint handlers are called in the order of decreasing separation
1413  * priority.
1414  * Finally, the separators with negative priority are called in the order of decreasing priority.
1415  * \n
1416  * The separation priority of the constraint handler should be set according to the complexity of the cut separation
1417  * algorithm and the impact of the resulting cuts:
1418  * Constraint handlers that provide fast algorithms that usually have a high impact (i.e., cut off a large portion of
1419  * the LP relaxation) should have a high priority.
1420  * See \ref CONSSEPALP and \ref CONSSEPASOL for further details of the separation callbacks.
1421  *
1422  * \par CONSHDLR_DELAYSEPA: the default for whether the separation method should be delayed, if other separators found cuts.
1423  * If the constraint handler's separation method is marked to be delayed, it is only executed after no other separator
1424  * or constraint handler found a cut during the price-and-cut loop.
1425  * If the separation method of the constraint handler is very expensive, you may want to mark it to be delayed until all
1426  * cheap separation methods have been executed.
1427  *
1428  * \par CONSHDLR_PROPFREQ: the default frequency for propagating domains.
1429  * This default frequency has the same meaning as the CONSHDLR_SEPAFREQ with respect to the domain propagation
1430  * callback of the constraint handler.
1431  * A propagation frequency of 0 means that propagation is only applied in preprocessing and at the root node.
1432  * A propagation frequency of -1 disables the propagation method of the constraint handler.
1433  *
1434  * \par CONSHDLR_DELAYPROP: the default for whether the propagation method should be delayed, if other propagators found reductions.
1435  * This property is analogous to the DELAYSEPA flag, but deals with the propagation method of the constraint handler.
1436  *
1437  * \par CONSHDLR_PROP_TIMING: the propagation timing mask of the constraint handler.
1438  * SCIP calls the domain propagation routines at different places in the node processing loop.
1439  * This property indicates at which places the propagation routine of the constraint handler is called.
1440  * Possible values are defined in type_timing.h and can be concatenated, e.g., as in SCIP_PROPTIMING_ALWAYS.
1441  *
1442  * \par CONSHDLR_PRESOLTIMING: the timing of the constraint handler's presolving method (FAST, MEDIUM, or EXHAUSTIVE).
1443  * Every presolving round starts with the FAST presolving methods. MEDIUM presolvers are only called, if FAST presolvers did not find
1444  * enough reductions in this round so far, and EXHAUSTIVE presolving steps are only performed if all presolvers called before
1445  * in this round were unsuccessful.
1446  * Presolving methods should be assigned a timing based on how expensive they are, e.g., presolvers that provide fast algorithms that
1447  * usually have a high impact (i.e., remove lots of variables or tighten bounds of many variables) should have a timing FAST.
1448  * If a presolving method implements different algorithms of different complexity, it may also get multiple timings and check the timing
1449  * internally in the \ref CONSPRESOL callback to decide which algorithms to run.
1450  *
1451  * \par CONSHDLR_MAXPREROUNDS: the default maximal number of presolving rounds the constraint handler participates in.
1452  * The preprocessing is executed in rounds.
1453  * If enough changes have been applied to the model, an additional preprocessing round is performed.
1454  * The MAXPREROUNDS parameter of a constraint handler denotes the maximal number of preprocessing rounds the constraint
1455  * handler participates in.
1456  * A value of -1 means that there is no limit on the number of rounds.
1457  * A value of 0 means the preprocessing callback of the constraint handler is disabled.
1458  *
1459  *
1460  *
1461  * @section CONS_DATA Constraint Data and Constraint Handler Data
1462  *
1463  * Below the header "Data structures" you can find two structs called "struct SCIP_ConsData" and
1464  * "struct SCIP_ConshdlrData".
1465  * If you are using C++, you only need to define the "struct SCIP_ConsData".
1466  * The constraint handler data must be implemented as member variables of your constraint handler class.
1467  * \n
1468  * The constraint data are the information that is needed to define a single constraint of the constraint handler's
1469  * constraint class.
1470  * For example, the data of a knapsack constraint would consist of a list of variables, a list of weights, and
1471  * the capacity of the knapsack.
1472  * The data of a subtour constraint consists of the graph on which the problem is defined.
1473  * In the graph, each edge should be linked to the corresponding binary problem variable.
1474  * \n
1475  * The constraint handler data are additional variables, that belong to the constraint handler itself and which are
1476  * not specific to a single constraint.
1477  * For example, you can use these data to store parameters of the constraint handler or statistical information.
1478  * The constraint handler data are optional.
1479  * You can leave the struct empty.
1480  *
1481  *
1482  * @section CONS_INTERFACE Interface Methods
1483  *
1484  * At the bottom of "cons_subtour.c" you can find three interface methods, that also appear in "cons_subtour.h".
1485  * These are SCIPincludeConshdlrSubtour(), SCIPcreateConsSubtour(), and SCIPcreateConsSubtourBasic().
1486  * \n
1487  * The method SCIPincludeConshdlrSubtour() only has to be adjusted slightly.
1488  * It is responsible for notifying SCIP of the presence of the constraint handler by calling the method
1489  * SCIPincludeConshdlr().
1490  * It is called by the user, if (s)he wants to include the constraint handler, i.e., if (s)he wants to make
1491  * the constraint handler available to the model, and looks like this:
1492  * -# If you are using constraint handler data, you have to <b>allocate the memory for the data</b> at this point.
1493  * You also have to initialize the fields in struct SCIP_ConshdlrData afterwards.
1494  * \code
1495  * SCIP_RETCODE SCIPincludeConshdlrKnapsack(
1496  * ...
1497  * )
1498  * {
1499  * SCIP_EVENTHDLRDATA* eventhdlrdata;
1500  * SCIP_CONSHDLRDATA* conshdlrdata;
1501  * SCIP_CONSHDLR* conshdlr;
1502  *
1503  * SCIP_CALL( SCIPallocMemory(scip, &conshdlrdata) );
1504  * ...
1505  * \endcode
1506  * -# Now, <b>SCIP gets notified</b> of the presence of the constraint handler together with its \ref CONS_FUNDAMENTALCALLBACKS "basic callbacks".
1507  * \code
1508  * SCIP_CALL( SCIPincludeConshdlrBasic(scip, &conshdlr, CONSHDLR_NAME, CONSHDLR_DESC,
1509  * CONSHDLR_ENFOPRIORITY, CONSHDLR_CHECKPRIORITY, CONSHDLR_EAGERFREQ, CONSHDLR_NEEDSCONS,
1510  * consEnfolpKnapsack, consEnfopsKnapsack, consCheckKnapsack, consLockKnapsack,
1511  * conshdlrdata) );
1512  * assert(conshdlr != NULL);
1513  * \endcode
1514  * -# All \ref CONS_ADDITIONALCALLBACKS "additional callbacks" are added via their setter functions.
1515  * \code
1516  * SCIP_CALL( SCIPsetConshdlrCopy(scip, conshdlr, conshdlrCopyKnapsack, consCopyKnapsack) );
1517  * SCIP_CALL( SCIPsetConshdlrTrans(scip, conshdlr, consTransKnapsack) );
1518  * \endcode
1519  * -# If the constraint handler is a specialization of a general linear or nonlinear constraint, we want to include an <b>automatic
1520  * upgrading mechanism</b> by calling the interface method
1521  * \code
1522  * if( SCIPfindConshdlr(scip,"linear") != NULL )
1523  * {
1524  * SCIP_CALL( SCIPincludeLinconsUpgrade(scip, linconsUpgdKnapsack, LINCONSUPGD_PRIORITY, CONSHDLR_NAME) );
1525  * }
1526  * \endcode
1527  * or
1528  * \code
1529  * SCIP_CALL( SCIPincludeNonlinconsUpgrade(scip, nonlinconsUpgdSubtour, NULL, NONLINCONSUPGD_PRIORITY, TRUE, CONSHDLR_NAME) );
1530  * \endcode
1531  * in the nonlinear case.
1532  * See also cons_nonlinear.h for further information about the general upgrade procedure in the nonlinear case.
1533  * -# You may also add <b>user parameters</b> for your constraint handler.
1534  * Some parameters which are important to play with are added to every constraint automatically, as, e.g.,
1535  * propagation or separation frequency.
1536  * \code
1537  * SCIP_CALL( SCIPaddIntParam(scip,
1538  * "constraints/knapsack/sepacardfreq",
1539  * "multiplier on separation frequency, how often knapsack cuts are separated (-1: never, 0: only at root)",
1540  * &conshdlrdata->sepacardfreq, TRUE, DEFAULT_SEPACARDFREQ, -1, INT_MAX, NULL, NULL) );
1541  * ...
1542  * return SCIP_OKAY;
1543  * }
1544  * \endcode
1545  *
1546  *
1547  *
1548  *
1549  * The methods SCIPcreateConsSubtour() and SCIPcreateConsSubtourBasic() are called to create a single constraint of the constraint
1550  * handler's constraint class.
1551  * It should allocate and fill the constraint data, and call SCIPcreateCons().
1552  * Take a look at the following example from the \ref cons_knapsack.h "knapsack constraint handler":
1553  *
1554  * \code
1555  * SCIP_RETCODE SCIPcreateConsKnapsack(
1556  * SCIP* scip,
1557  * SCIP_CONS** cons,
1558  * const char* name,
1559  * int nvars,
1560  * SCIP_VAR** vars,
1561  * SCIP_Longint* weights,
1562  * SCIP_Longint capacity,
1563  * SCIP_Bool initial,
1564  * SCIP_Bool separate,
1565  * SCIP_Bool enforce,
1566  * SCIP_Bool check,
1567  * SCIP_Bool propagate,
1568  * SCIP_Bool local,
1569  * SCIP_Bool modifiable,
1570  * SCIP_Bool dynamic,
1571  * SCIP_Bool removable,
1572  * SCIP_Bool stickingatnode
1573  * )
1574  * {
1575  * SCIP_CONSHDLRDATA* conshdlrdata;
1576  * SCIP_CONSHDLR* conshdlr;
1577  * SCIP_CONSDATA* consdata;
1578  *
1579  * conshdlr = SCIPfindConshdlr(scip, CONSHDLR_NAME);
1580  * if( conshdlr == NULL )
1581  * {
1582  * SCIPerrorMessage("knapsack constraint handler not found\n");
1583  * return SCIP_PLUGINNOTFOUND;
1584  * }
1585  *
1586  * conshdlrdata = SCIPconshdlrGetData(conshdlr);
1587  * assert(conshdlrdata != NULL);
1588  * assert(conshdlrdata->eventhdlr != NULL);
1589  *
1590  * SCIP_CALL( consdataCreate(scip, &consdata, conshdlrdata->eventhdlr, nvars, vars, weights, capacity) );
1591  *
1592  * SCIP_CALL( SCIPcreateCons(scip, cons, name, conshdlr, consdata, initial, separate, enforce, check, propagate,
1593  * local, modifiable, dynamic, removable, stickingatnode) );
1594  *
1595  * return SCIP_OKAY;
1596  * }
1597  * \endcode
1598  *
1599  * In this example, consdataCreate() is a local method that allocates memory for the given consdata
1600  * and fills the data with the given <code>vars</code> array. For allocating memory for the constraint data, you
1601  * can use SCIP memory allocation:
1602  * \code
1603  * SCIP_CALL( SCIPallocBlockMemory(scip, consdata) );
1604  * \endcode
1605  *
1606  *
1607  * @section CONS_CALLBACKS Callback methods of Constraint handlers
1608  *
1609  * Besides the various functions which you will implement inside your constraint handler there exists a number
1610  * of <b> callback methods </b> associated with your constraint handler. Callback methods can be regarded as
1611  * tasks which your constraint handler is able to provide to the solver. They are grouped into two
1612  * categories:
1613  *
1614  * \ref CONS_FUNDAMENTALCALLBACKS "Fundamental Callback methods" are mandatory to implement
1615  * such that your code will work. For example, every constraint handler has to provide the
1616  * functionality to state whether all of its constraints are
1617  * fulfilled by a given variable assignment. Hence, the \ref CONSCHECK "CONSCHECK" callback is
1618  * one of the fundamental (or \a basic) callbacks of a constraint handler.
1619  *
1620  * Callbacks which are not necessarily implemented are grouped together as
1621  * \ref CONS_ADDITIONALCALLBACKS "additional callbacks". Such callbacks can be used to allocate and free memory
1622  * at different stages of the solving process. Although not mandatory, it might be useful to implement
1623  * some of these callbacks, e.g., to extend your constraint handler by a
1624  * \ref CONSSEPALP "separation" or \ref CONSPRESOL "presolving" functionality.
1625  *
1626  * All callbacks should be passed to SCIP during the SCIPinclude<PLUGINTYPE><PLUGINNAME> method
1627  * (e.g., SCIPincludeConshdlrKnapsack() for the \ref cons_knapsack.h "knapsack constraint handler").
1628  * Since SCIP version 3.0, two ways of setting callbacks can be used, either via SCIPincludeConshdlr()
1629  * (all at once, as it always was), or via SCIPincludeConshdlrBasic() and setter functions for additional callbacks.
1630  * Since the basic inclusion methods are very unlikely to change and will thus
1631  * make your code more stable towards future versions of SCIP with more callbacks,
1632  * we recommend the latter choice, as explained in the \ref CONS_INTERFACE "interface" section.
1633  *
1634  * @section CONS_FUNDAMENTALCALLBACKS Fundamental Callback Methods
1635  *
1636  * By implementing the fundamental callbacks, you define the semantics of the constraint class the constraint handler
1637  * deals with.
1638  * If these methods are implemented, the resulting code is already correct and finds the optimal solution to the
1639  * given problem instance.
1640  * However, it might be very slow because the additional features, like cut separation and domain propagation, are
1641  * missing.
1642  * In the C++ wrapper class scip::ObjConshdlr, the fundamental callback methods are virtual abstract member functions.
1643  * You have to implement them in order to be able to construct an object of your constraint handler class.
1644  *
1645  * There are three fundamental callback methods that are all dealing with the feasibility of a given solution.
1646  * They are called at different places in the algorithm and have slightly different meaning.
1647  * However, it is usually reasonable to implement a single local method that is called by all of the three callback
1648  * methods with slightly modified parameters.
1649  * The fourth method provides dual information that is used for example in preprocessing.
1650  *
1651  * Additional documentation for the callback methods can be found in type_cons.h.
1652  *
1653  * @subsection CONSCHECK
1654  *
1655  * The CONSCHECK callback gets a primal solution candidate in a SCIP_SOL* data structure
1656  * and has to check this solution for global feasibility.
1657  * It has to return a result SCIP_FEASIBLE, if the solution satisfies all the constraints of the constraint handler,
1658  * and a result SCIP_INFEASIBLE if there is at least one constraint that is violated.
1659  * The callback is used by primal heuristics to check a constructed solution for feasibility.
1660  * That means, the constraint handler has to deal with arbitrary solutions that do not necessarily satisfy the bounds
1661  * and constraints of the local subproblem.
1662  *
1663  * The value of a variable \em var in the given solution \em sol can be accessed by calling
1664  * \code
1665  * SCIPgetSolVal(scip, sol, var)
1666  * \endcode
1667  *
1668  * For example, the \ref cons_knapsack.h "knapsack constraint handler" loops over its constraints and
1669  * calculates the scalar product \f$w^T x\f$ of weights \f$w\f$ with the solution vector \f$x\f$.
1670  * This scalar product is compared with the capacity of the knapsack constraint.
1671  * If it exceeds the capacity, the CONSCHECK method is immediately aborted with the result SCIP_INFEASIBLE.
1672  * If all knapsack constraints are satisfied, a result SCIP_FEASIBLE is returned.
1673  *
1674  * @subsection CONSENFOLP
1675  *
1676  * The CONSENFOLP method is called after the price-and-cut loop was finished and an LP solution is available.
1677  * Like the CHECK call, the ENFOLP method should return a result SCIP_FEASIBLE, if the solution satisfies all the
1678  * constraints.
1679  * However, the behavior should be different, if the solution violates some of the associated constraints.
1680  * The constraint handler may return a result SCIP_INFEASIBLE in this situation, but this is not the best what
1681  * one can do.
1682  * The ENFOLP method has the possibility of \em resolving the infeasibility by
1683  * - stating that the current subproblem is infeasible (result SCIP_CUTOFF),
1684  * - adding an additional constraint that resolves the infeasibility (result SCIP_CONSADDED),
1685  * - reducing the domain of a variable (result SCIP_REDUCEDDOM),
1686  * - adding a cutting plane (result SCIP_SEPARATED),
1687  * - performing a branching (result SCIP_BRANCHED).
1688  *
1689  * However, the solution is not given as a SCIP_SOL* data structure.
1690  *
1691  * The value of a variable <code>var</code> in the LP solution can be accessed by calling
1692  * \code
1693  * SCIPgetVarSol(scip, var)
1694  * \endcode
1695  * or by
1696  * \code
1697  * SCIPgetSolVal(scip, NULL, var)
1698  * \endcode
1699  * By using the latter method, you can have a single local method to check a solution for feasibility by passing
1700  * the given <code>sol</code> to the CONSCHECK call and by passing a NULL pointer as <code>sol</code> to
1701  * the CONSENFOLP and CONSENFOPS calls.
1702  *
1703  *
1704  * @subsection CONSENFOPS
1705  *
1706  * The CONSENFOPS callback is similar to the CONSENFOLP callback, but deals with \em pseudo \em solutions instead
1707  * of LP solutions.
1708  *
1709  * If the LP was not solved at the current subproblem (either because the user did not want to solve it, or because
1710  * numerical difficulties in the LP solving process were detected) no LP solution is available.
1711  * In this situation, the pseudo solution is used instead.
1712  * In this solution, the variables are set to the local bound which is best with respect to the objective function.
1713  * You can think of the pseudo solution as solution to the LP relaxation with all constraints except the bounds
1714  * being removed.
1715  *
1716  * Like the ENFOLP callback, the ENFOPS callback has to check whether the pseudo solution satisfies all the constraints
1717  * of the constraint handler.
1718  * The pseudo solution can be accessed by the same methods as the LP solution (SCIP knows, if the LP was solved at the
1719  * current subproblem, and returns either the LP solution or the pseudo solution).
1720  *
1721  * Unlike the ENFOLP callback, the ENFOPS callback must not add cuts and cannot return the result SCIP_SEPARATED.
1722  * It is, however, possible to force the solving of the LP by returning the result SCIP_SOLVELP.
1723  * For example, the infeasibility of a linear constraint that contains continuous variables cannot be resolved,
1724  * if all integer variables in the constraint are already fixed.
1725  * In this case, the LP has to be solved in order to get a solution that satisfies the linear constraint.
1726  *
1727  * @subsection CONSLOCK
1728  *
1729  * The CONSLOCK callback provides dual information for a single constraint.
1730  * It has to tell SCIP, which variables are existing in the given constraint, and in which way modifications of these
1731  * variables may affect the feasibility of the constraint.
1732  *
1733  * For each variable that is affected by the constraint, the callback should call SCIPaddVarLocks():
1734  * - If the constraint may become violated by decreasing the value of a variable, it should call
1735  * SCIPaddVarLocks(scip, var, nlockspos, nlocksneg), saying that rounding down is potentially rendering the
1736  * (positive) constraint infeasible and rounding up is potentially rendering the negation of the constraint
1737  * infeasible.
1738  * - If the constraint may become violated by increasing the value of a variable, it should call
1739  * SCIPaddVarLocks(scip, var, nlocksneg, nlockspos), saying that rounding up is potentially rendering the
1740  * constraint's negation infeasible and rounding down is potentially rendering the constraint itself
1741  * infeasible.
1742  * - If the constraint may become violated by changing the variable in any direction, it should call
1743  * SCIPaddVarLocks(scip, var, nlockspos + nlocksneg, nlockspos + nlocksneg).
1744  *
1745  * <b>Note:</b> You do not have to worry about nlockspos and nlocksneg. These integer values are given as
1746  * parameter of the CONSLOCK callback (see type_cons.h). Just use these variables in the above described
1747  * fashion <b>without</b> adding or subtracting anything to them. In case of the knapsack constraints this
1748  * method looks like this.
1749  *
1750  * \code
1751  * static
1752  * SCIP_DECL_CONSLOCK(consLockKnapsack)
1753  * {
1754  * SCIP_CONSDATA* consdata;
1755  * int i;
1756  *
1757  * consdata = SCIPconsGetData(cons);
1758  * assert(consdata != NULL);
1759  *
1760  * for( i = 0; i < consdata->nvars; i++)
1761  * {
1762  * SCIP_CALL( SCIPaddVarLocks(scip, consdata->vars[i], nlocksneg, nlockspos) );
1763  * }
1764  *
1765  * return SCIP_OKAY;
1766  * }
1767  * \endcode
1768  *
1769  * To give same more intuition, consider the linear constraint \f$3x -5y +2z \leq 7\f$ as an example.
1770  * The CONSLOCK callback method of the linear constraint handler should call
1771  * SCIPaddVarLocks(scip, x, nlocksneg, nlockspos), SCIPaddVarLocks(scip, y, nlockspos, nlocksneg),
1772  * and SCIPaddVarLocks(scip, z, nlocksneg, nlockspos) to tell SCIP, that rounding up of \f$x\f$
1773  * and \f$z\f$ and rounding down of \f$y\f$ can destroy the feasibility of the constraint, while rounding
1774  * down of \f$x\f$ and \f$z\f$ and rounding up of \f$y\f$ can destroy the feasibility of the
1775  * constraint's negation \f$3x -5y +2z > 7\f$.
1776  * \n
1777  * A linear constraint \f$2 \leq 3x -5y +2z \leq 7\f$ should call
1778  * SCIPaddVarLocks(scip, ..., nlockspos + nlocksneg, nlockspos + nlocksneg) on all variables,
1779  * since rounding in both directions of each variable can destroy both the feasibility of the
1780  * constraint and it's negation \f$3x -5y +2z < 2\f$ or \f$3x -5y +2z > 7\f$.
1781  *
1782  *
1783  * @section CONS_ADDITIONALCALLBACKS Additional Callback Methods
1784  *
1785  * The additional callback methods do not need to be implemented in every case, but provide useful functionality
1786  * for many applications. They can be added to your constraint handler via setter functions, see
1787  * \ref CONS_INTERFACE "here".
1788  *
1789  * @subsection CONSFREE
1790  *
1791  * If you are using constraint handler data, you have to implement this method in order to free the
1792  * constraint handler data. This can be done by the following procedure (which is taken from the
1793  * \ref cons_knapsack.h "knapsack constraint handler"):
1794  *
1795  * \code
1796  * static
1797  * SCIP_DECL_CONSFREE(consFreeKnapsack)
1798  * {
1799  * SCIP_CONSHDLRDATA* conshdlrdata;
1800  *
1801  * conshdlrdata = SCIPconshdlrGetData(conshdlr);
1802  * assert(conshdlrdata != NULL);
1803  *
1804  * SCIPfreeMemory(scip, &conshdlrdata);
1805  *
1806  * SCIPconshdlrSetData(conshdlr, NULL);
1807  *
1808  * return SCIP_OKAY;
1809  * }
1810  * \endcode
1811  *
1812  * If you have allocated memory for fields in your constraint handler data, remember to free this memory
1813  * before freeing the constraint handler data itself.
1814  * If you are using the C++ wrapper class, this method is not available.
1815  * Instead, just use the destructor of your class to free the member variables of your class.
1816  *
1817  * @subsection CONSHDLRCOPY
1818  *
1819  * The CONSHDLRCOPY callback is executed when the SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this
1820  * callback as <code>NULL</code> the user disables the inclusion of the specified constraint handler into all copied SCIP
1821  * instances. This may deteriorate the performance of primal heuristics solving sub-SCIPs, since these constitute only
1822  * relaxations of the original problem if constraint handlers are missing.
1823  *
1824  * A usual implementation just
1825  * calls the interface method which includes the constraint handler to the model. For example, this callback is
1826  * implemented for the knapsack constraint handler as follows:
1827  *
1828  * \code
1829  * static
1830  * SCIP_DECL_CONSHDLRCOPY(conshdlrCopyKnapsack)
1831  * {
1832  * assert(scip != NULL);
1833  * assert(conshdlr != NULL);
1834  * assert(strcmp(SCIPconshdlrGetName(conshdlr), CONSHDLR_NAME) == 0);
1835  *
1836  * SCIP_CALL( SCIPincludeConshdlrKnapsack(scip) );
1837  *
1838  * *valid = TRUE;
1839  *
1840  * return SCIP_OKAY;
1841  * }
1842  * \endcode
1843  *
1844  * <b>Note:</b> If you implement this callback, take care when setting the valid pointer. The valid pointer should be
1845  * set to TRUE if (and only if!) you can make sure that all necessary data of the constraint handler are copied
1846  * correctly. If the complete problem is validly copied, i.e. if the copy methods of all problem defining plugins
1847  * (constraint handlers and pricers) return <code>*valid = TRUE</code>, then dual reductions found for the copied problem can be
1848  * transferred to the original SCIP instance. Thus, if the valid pointer is wrongly set to TRUE, it might happen that
1849  * optimal solutions are cut off.
1850  *
1851  * <b>Note:</b> If you implement this callback and the constraint handler needs constraints (see CONSHDLR_NEEDSCONS),
1852  * then you also need to implement the callback \ref CONSCOPY.
1853  *
1854  * @subsection CONSINIT
1855  *
1856  * The CONSINIT callback is executed after the problem is transformed.
1857  * The constraint handler may, e.g., use this call to replace the original variables in its constraints by transformed
1858  * variables, or to initialize its statistical constraint handler data.
1859  *
1860  * @subsection CONSEXIT
1861  *
1862  * The CONSEXIT callback is executed before the transformed problem is freed.
1863  * In this method, the constraint handler should free all resources that were allocated for the solving process.
1864  *
1865  * @subsection CONSINITPRE
1866  *
1867  * The CONSINITPRE callback is executed before the preprocessing is started, even if presolving is turned off.
1868  * The constraint handler may use this call to initialize its presolving data, or to modify its constraints
1869  * before the presolving process begins.
1870  * Necessary constraint modifications that have to be performed even if presolving is turned off should be done here
1871  * or in the presolving deinitialization call.
1872  *
1873  * @subsection CONSEXITPRE
1874  *
1875  * The CONSEXITPRE callback is executed after the preprocessing has been finished, even if presolving is turned off.
1876  * The constraint handler may use this call e.g. to clean up its presolving data, or to finally modify its constraints
1877  * before the branch-and-bound process begins.
1878  * Necessary constraint modifications that have to be performed even if presolving is turned off should be done here
1879  * or in the presolving initialization call.
1880  * Besides necessary modifications and clean up, no time consuming operations should be done.
1881  *
1882  * @subsection CONSINITSOL
1883  *
1884  * The CONSINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
1885  * begin.
1886  * The constraint handler may use this call to initialize its branch-and-bound specific data.
1887  *
1888  * @subsection CONSEXITSOL
1889  *
1890  * The CONSEXITSOL callback is executed before the branch-and-bound process is freed.
1891  * The constraint handler should use this call to clean up its branch-and-bound data, in particular to release
1892  * all LP rows that it has created or captured.
1893  *
1894  * @subsection CONSDELETE
1895  *
1896  * The CONSDELETE callback is executed if a constraint should be freed.
1897  * You can think of it as the destructor of a single constraint.
1898  * In the callback, you have to free the given constraint data.
1899  * The CONSDELETE callback is therefore the counterpart of the SCIPcreateCons...() interface method and the CONSTRANS
1900  * method.
1901  *
1902  * @subsection CONSTRANS
1903  *
1904  * The CONSTRANS method is called for each constraint of the constraint handler, when the user starts the solving
1905  * process.
1906  * It has to copy the original constraint data of the constraint to the memory for the transformed problem.
1907  * You can think of it as a copy constructor for a single constraint.
1908  *
1909  * The original model is copied in order to protect it from transformations that are applied during the solving process,
1910  * in particular during preprocessing.
1911  * Preprocessing and solving always operates on the transformed problem.
1912  * If the solving process data are freed, the original data still exist and the user can, e.g., modify the problem and
1913  * restart the solving process.
1914  *
1915  * If you do not implement the CONSTRANS method, a transformed constraint is created with the same flags and the
1916  * same constraint data pointer.
1917  * That means, the transformed constraint points to the original constraint data.
1918  * This is okay, as long as the constraint data is not changed during the solving process.
1919  * If you want to implement preprocessing methods or other methods that modify the constraint data, you have to
1920  * implement the CONSTRANS method and create a copy of the constraint data.
1921  *
1922  * Here is an example, which is taken from the \ref cons_knapsack.h "knapsack constraint handler":
1923  * \code
1924  * static
1925  * SCIP_DECL_CONSTRANS(consTransKnapsack)
1926  * {
1927  * SCIP_CONSHDLRDATA* conshdlrdata;
1928  * SCIP_CONSDATA* sourcedata;
1929  * SCIP_CONSDATA* targetdata;
1930  *
1931  * assert(conshdlr != NULL);
1932  * assert(strcmp(SCIPconshdlrGetName(conshdlr), CONSHDLR_NAME) == 0);
1933  * assert(SCIPgetStage(scip) == SCIP_STAGE_TRANSFORMING);
1934  * assert(sourcecons != NULL);
1935  * assert(targetcons != NULL);
1936  *
1937  * sourcedata = SCIPconsGetData(sourcecons);
1938  * assert(sourcedata != NULL);
1939  * assert(sourcedata->row == NULL);
1940  *
1941  * conshdlrdata = SCIPconshdlrGetData(conshdlr);
1942  * assert(conshdlrdata != NULL);
1943  * assert(conshdlrdata->eventhdlr != NULL);
1944  *
1945  * SCIP_CALL( consdataCreate(scip, &targetdata, conshdlrdata->eventhdlr,
1946  * sourcedata->nvars, sourcedata->vars, sourcedata->weights, sourcedata->capacity) );
1947  *
1948  * SCIP_CALL( SCIPcreateCons(scip, targetcons, SCIPconsGetName(sourcecons), conshdlr, targetdata,
1949  * SCIPconsIsInitial(sourcecons), SCIPconsIsSeparated(sourcecons), SCIPconsIsEnforced(sourcecons),
1950  * SCIPconsIsChecked(sourcecons), SCIPconsIsPropagated(sourcecons),
1951  * SCIPconsIsLocal(sourcecons), SCIPconsIsModifiable(sourcecons),
1952  * SCIPconsIsDynamic(sourcecons), SCIPconsIsRemovable(sourcecons), SCIPconsIsStickingAtNode(sourcecons)) );
1953  *
1954  * return SCIP_OKAY;
1955  * }
1956  * \endcode
1957  *
1958  * @subsection CONSINITLP
1959  *
1960  * The CONSINITLP callback is executed before the first LP relaxation is solved.
1961  * It should add the LP relaxations of all "initial" constraints to the LP. The method should scan the constraints
1962  * array for constraints that are marked initial via calls to SCIPconsIsInitial() and put the LP relaxation
1963  * of all initial constraints to the LP with calls to SCIPaddCut().
1964  *
1965  * @subsection CONSSEPALP
1966  *
1967  * The CONSSEPALP callback is executed during the price-and-cut loop of the subproblem processing.
1968  * It should try to generate cutting planes for the constraints of the constraint handler in order to separate
1969  * the current LP solution.
1970  * The method is called in the LP solution loop, which means that a valid LP solution exists.
1971  *
1972  * Usually, a separation callback searches and produces cuts, that are added with a call to SCIPaddCut().
1973  * If the cut should be remembered in the global cut pool, it may also call SCIPaddPoolCut().
1974  * However, the callback may also produce domain reductions or add other constraints.
1975  *
1976  * The CONSSEPALP callback has the following options:
1977  * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
1978  * - adding an additional constraint (result SCIP_CONSADDED)
1979  * - reducing a variable's domain (result SCIP_REDUCEDDOM)
1980  * - adding a cutting plane to the LP (result SCIP_SEPARATED)
1981  * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
1982  * (result SCIP_DIDNOTFIND)
1983  * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
1984  * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
1985  * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
1986  *
1987  * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1988  * CONSHDLR_SEPAFREQ, CONSHDLR_SEPAPRIORITY, and CONSHDLR_DELAYSEPA, which influence the behaviour of SCIP
1989  * calling CONSSEPALP.
1990  *
1991  * @subsection CONSSEPASOL
1992  *
1993  * The CONSSEPASOL callback is executed during separation loop on arbitrary primal solutions.
1994  * It should try to generate cutting planes for the constraints of the constraint handler in order to separate
1995  * the given primal solution.
1996  * The method is not called in the LP solution loop, which means that there is no valid LP solution.
1997  *
1998  * Usually, a separation callback searches and produces cuts, that are added with a call to SCIPaddCut().
1999  * If the cut should be remembered in the global cut pool, it may also call SCIPaddPoolCut().
2000  * However, the callback may also produce domain reductions or add other constraints.
2001  *
2002  * The CONSSEPASOL callback has the following options:
2003  * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
2004  * - adding an additional constraint (result SCIP_CONSADDED)
2005  * - reducing a variable's domain (result SCIP_REDUCEDDOM)
2006  * - adding a cutting plane to the LP (result SCIP_SEPARATED)
2007  * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
2008  * (result SCIP_DIDNOTFIND)
2009  * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
2010  * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
2011  * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
2012  *
2013  * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
2014  * CONSHDLR_SEPAFREQ, CONSHDLR_SEPAPRIORITY, and CONSHDLR_DELAYSEPA, which influence the behaviour of SCIP
2015  * calling CONSSEPASOL.
2016  *
2017  * @subsection CONSPROP
2018  *
2019  * The CONSPROP callback is called during the subproblem processing.
2020  * It should propagate the constraints, which means that it should infer reductions in the variables' local bounds
2021  * from the current local bounds.
2022  * This technique, which is the main workhorse of constraint programming, is called "node preprocessing" in the
2023  * Integer Programming community.
2024  *
2025  * The CONSPROP callback has the following options:
2026  * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
2027  * - reducing a variable's domain (result SCIP_REDUCEDDOM)
2028  * - stating that the propagator searched, but did not find domain reductions, cutting planes, or cut constraints
2029  * (result SCIP_DIDNOTFIND)
2030  * - stating that the propagator was skipped (result SCIP_DIDNOTRUN)
2031  * - stating that the propagator was skipped, but should be called again (result SCIP_DELAYED)
2032  *
2033  * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
2034  * CONSHDLR_PROPFREQ, CONSHDLR_DELAYPROP, and CONSHDLR_PROP_TIMING, which influence the behaviour of SCIP
2035  * calling CONSPROP.
2036  *
2037  * @subsection CONSRESPROP
2038  *
2039  * If the constraint handler should support \ref CONF "conflict analysis", it has to supply a CONSRESPROP method.
2040  * It also should call SCIPinferVarLbCons() or SCIPinferVarUbCons() in domain propagation instead of SCIPchgVarLb() or
2041  * SCIPchgVarUb() in order to deduce bound changes on variables.
2042  * In the SCIPinferVarLbCons() and SCIPinferVarUbCons() calls, the handler provides the constraint that deduced the
2043  * variable's bound change, and an integer value <code>inferinfo</code> that can be arbitrarily chosen.
2044  *
2045  * The propagation conflict resolving method CONSRESPROP must then be implemented to provide the "reasons" for the bound
2046  * changes, i.e., the bounds of variables at the time of the propagation, which forced the constraint to set the
2047  * conflict variable's bound to its current value. It can use the <code>inferinfo</code> tag to identify its own propagation rule
2048  * and thus identify the "reason" bounds. The bounds that form the reason of the assignment must then be provided by
2049  * calls to SCIPaddConflictLb() and SCIPaddConflictUb() in the propagation conflict resolving method.
2050  *
2051  * <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
2052  * need more information to efficiently infer the original propagation steps that lead to the conflict. This would,
2053  * however, require too much space. In the extreme, the original propagation steps have to be repeated.
2054  *
2055  * 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
2056  * 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
2057  * variables are 0.0). It uses <code>SCIPinferVarLbCons(scip, z, 1.0, c, 0)</code> to apply this assignment (an
2058  * inference information tag is not needed by the constraint handler and is set to 0). In the conflict analysis, the
2059  * constraint handler may be asked to resolve the lower bound change on \f$z\f$ with constraint \f$c\f$, that was
2060  * applied at a time given by a bound change index "bdchgidx". With a call to <code>SCIPvarGetLbAtIndex(z,
2061  * bdchgidx)</code>, the handler can find out, that the lower bound of variable \f$z\f$ was set to 1.0 at the given
2062  * point of time, and should call <code>SCIPaddConflictUb(scip, x, bdchgidx)</code> and <code>SCIPaddConflictUb(scip, y,
2063  * 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
2064  * the deduction of the lower bound of \f$z\f$.
2065  *
2066  * If conflict analysis should not be supported, the method has to set the result code to SCIP_DIDNOTFIND. Although
2067  * this is a viable approach to circumvent the implementation of the usually rather complex conflict resolving method, it
2068  * will make the conflict analysis less effective. We suggest to first omit the conflict resolving method and check how
2069  * effective the \ref CONSPROP "propagation method" is. If it produces a lot of propagations for your application, you definitely should
2070  * consider implementing the conflict resolving method.
2071  *
2072  * @subsection CONSPRESOL
2073  *
2074  * The CONSPRESOL callback is called during preprocessing.
2075  * It should try to tighten the domains of the variables, tighten the coefficients of the constraints of the constraint
2076  * handler, delete redundant constraints, aggregate and fix variables if possible, and upgrade constraints to more
2077  * specific types.
2078  *
2079  * If the CONSPRESOL callback applies changes to the constraint data, you also have to implement the \ref CONSTRANS callback
2080  * in order to copy the constraint data to the transformed problem space and protect the original problem from the
2081  * preprocessing changes.
2082  *
2083  * To inform SCIP that the presolving method found a reduction the result pointer has to be set in a proper way.
2084  * The following options are possible:
2085  *
2086  * - SCIP_UNBOUNDED : at least one variable is not bounded by any constraint in objective direction
2087  * - SCIP_CUTOFF : at least one constraint is infeasible in the variable's bounds
2088  * - SCIP_SUCCESS : the presolver found a reduction
2089  * - SCIP_DIDNOTFIND : the presolver searched, but did not find a presolving change
2090  * - SCIP_DIDNOTRUN : the presolver was skipped
2091  * - SCIP_DELAYED : the presolver was skipped, but should be called again
2092  *
2093  * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
2094  * CONSHDLR_PRESOLTIMING and CONSHDLR_MAXPREROUNDS, which influence the behaviour of SCIP
2095  * calling CONSPRESOL.
2096  *
2097  * @subsection CONSACTIVE
2098  *
2099  * The CONSACTIVE callback method is called each time a constraint of the constraint handler is activated.
2100  * For example, if a constraint is added locally to a subproblem, the CONSACTIVE callback is called whenever the
2101  * search enters the subtree where the constraint exists.
2102  *
2103  * @subsection CONSDEACTIVE
2104  *
2105  * The CONSDEACTIVE callback method is called each time a constraint of the constraint handler is deactivated.
2106  * For example, if a constraint is added locally to a subproblem, the CONSDEACTIVE callback is called whenever the
2107  * search leaves the subtree where the constraint exists.
2108  *
2109  * @subsection CONSENABLE
2110  *
2111  * The CONSENABLE callback method is called each time a constraint of the constraint handler is enabled.
2112  * Constraints might be active without being enabled. In this case, only the feasibility checks are executed,
2113  * but domain propagation and separation is skipped.
2114  *
2115  * @subsection CONSDISABLE
2116  *
2117  * The CONSDISABLE callback method is called each time a constraint of the constraint handler is disabled.
2118  *
2119  * @subsection CONSPRINT
2120  *
2121  * The CONSPRINT callback method is called, when the user asks SCIP to display the problem to the screen
2122  * or save the problem into a file. This is, however, only the case if the user requested the CIP format.
2123  * For more details about reading and writing with SCIP we refer to the \ref READER "file readers". In this
2124  * callback method the constraint handler should display the data of the constraint in an appropriate form.
2125  * The output format that is defined by the CONSPRINT callbacks is called CIP format.
2126  * In later versions of SCIP, the constraint handlers should also be able to parse (i.e., read) constraints
2127  * which are given in CIP format.
2128  *
2129  * @subsection CONSCOPY
2130  *
2131  * The CONSCOPY callback method is used whenever constraints should be copied from one SCIP instance into another SCIP
2132  * instance. This method comes with the necessary parameters to do so, most importantly with a mapping of the variables of the
2133  * source SCIP instance to the corresponding variables of the target SCIP instance, and a mapping for the constraints
2134  * in the same way. For a complete list of all arguments of this callback method see type_cons.h.
2135  *
2136  * To get the corresponding target variable of a given source variable, you can use the variable map directly:
2137  *
2138  * \code
2139  * targetvar = (SCIP_VAR*) (size_t) SCIPhashmapGetImage(varmap, sourcevar);
2140  * \endcode
2141  *
2142  * We recommend, however, to use the method SCIPgetVarCopy() which gets besides others the variable map and the constraint map as input
2143  * and returns the requested target variable. The advantage of using SCIPgetVarCopy() is that in the case
2144  * the required variable does not yet exist, it is created and added to the copy automatically:
2145  *
2146  * \code
2147  * SCIP_CALL( SCIPgetVarCopy(sourcescip, scip, sourcevar, &targetvar, varmap, consmap, global) );
2148  * \endcode
2149  *
2150  * Finally, the result pointer <code>valid</code> has to be set to TRUE if (and only if!) the copy process was successful.
2151  *
2152  * <b>Note:</b> Be careful when setting the valid pointer. If you set the valid pointer to TRUE, but the constraint was
2153  * not copied one-to-one, then optimal solutions might be cut off during the search (see section
2154  * CONSHDLRCOPY above).
2155  *
2156  * For an example implementation we refer to cons_linear.h. Additional documentation and the complete list of all
2157  * parameters can be found in the file in type_cons.h.
2158  *
2159  * @subsection CONSPARSE
2160  *
2161  * This method is the counter part to CONSPRINT. The ideal idea is that a constraint handler is able to parse the output
2162  * which it generated via the CONSPRINT method and creates the corresponding constraint. If the parsing was successfully
2163  * the result pointer success should be set to TRUE. An example implementation can be found in the \ref cons_linear.h
2164  * "linear constraint handler".
2165  *
2166  * @subsection CONSDELVARS
2167  *
2168  * This method should iterate over the given constraints and delete all variables that were marked for deletion by SCIPdelVar().
2169  * Variable deletion is especially interesting for branch-cut-and-price applications. If your constraint handler allows
2170  * the addition of variables during the solving process (see "modifiable" attribute of constraints), then you might also want to
2171  * implement this callback. This would allow you to not only create variables during solving, but also remove them dynamically
2172  * from the problem to reduce memory consumption in case they are no longer necessary.
2173  * During presolving, SCIP may also find that some variables are not needed anymore and then try
2174  * to delete them. Thus, if you do not implement this callback, the constraint handler should capture its variables via
2175  * SCIPcaptureVar() to prevent SCIP from erroneously deleting them.
2176  *
2177  * Additional documentation and the complete list of all parameters can be found in the file type_cons.h.
2178  *
2179  * @subsection CONSGETVARS
2180  *
2181  * The CONSGETVARS callback of a constraint handler can be implemented to give access to the constraint variables
2182  * as array, independently from the internal data structure of the constraint. The buffer array
2183  * is already passed, together with its length. Consider implementing @ref CONSGETNVARS, too, to have
2184  * information about the number of variables in this constraint.
2185  *
2186  * @subsection CONSGETNVARS
2187  *
2188  * This callback can be implemented to return the number of variables involved into a particular constraint.
2189  * In order to have access to the variable pointers, consider implementing @ref CONSGETVARS.
2190  *
2191  * @subsection CONSGETDIVEBDCHGS
2192  *
2193  * This callback is used inside the various diving heuristics of SCIP and does not affect the normal branching
2194  * of the actual search.
2195  * The constraint handler can provide this callback to render a current working solution (even more) infeasible by
2196  * suggesting one or several variable bound changes.
2197  *
2198  * @section CONS_FURTHERINFO Further documentation
2199  *
2200  * Further documentation can be found in @ref type_cons.h for callback descriptions and a complete
2201  * list of all callback parameters, or in @ref scip.h
2202  * for globally available functions.
2203  */
2204 
2205 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
2206 /**@page PRICER How to add variable pricers
2207  *
2208  * A pricer performs the dynamic generation of new variables in a column generation algorithm.
2209  * It is an algorithmic representation of a (usually exponential) number of variables.
2210  * The \ref PRICERREDCOST and \ref PRICERFARKAS methods are called after each LP solve to generate additional
2211  * variables which may improve the objective value or decrease the LP infeasibility, respectively.
2212  * \n
2213  * A complete list of all pricers contained in this release can be found \ref PRICERS "here".
2214  *
2215  * If the pricer finds one or more variables with negative reduced costs or negative Farkas value, it should
2216  * call SCIPcreateVar() and SCIPaddPricedVar() to create and add the variable to the problem. Additionally,
2217  * the pricer has to add the variable to all constraints in which it appears. Therefore, a pricer needs to
2218  * know the constraints of the model and their meaning. Note that all constraints for which additional variables
2219  * are generated by a pricer have to be flagged as "modifiable" in the SCIPcreateCons() call.
2220  *
2221  * We now explain how users can add their own pricers.
2222  * For example, look into the variable pricer for the binpacking problem (examples/Binpacking/src/pricer_binpacking.c) of the
2223  * Binpacking example project.
2224  * The example is written in C. C++ users can easily adapt the code by using the scip::scip::ObjPricer wrapper base class and
2225  * implement the scip_...() virtual methods instead of the SCIP_DECL_PRICER... callback methods.
2226  *
2227  * Additional documentation for the callback methods of a pricer can be found in the file
2228  * type_pricer.h.
2229  *
2230  * Notice that if your pricer cannot cope with variable bounds other than 0 and infinity, you have to mark
2231  * all constraints containing priced variables as modifiable, and you may have to disable reduced cost
2232  * strengthening by setting propagating/rootredcost/freq to -1.
2233  *
2234  * Here is what you have to do to implement a pricer:
2235  * -# Copy the template files src/scip/pricer_xyz.c and src/scip/pricer_xyz.h into files "pricer_mypricer.c"
2236  * and "pricer_mypricer.h".
2237  * \n
2238  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2239  * -# Use SCIPincludePricerMypricer() in order to include the pricer into your SCIP instance,
2240  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
2241  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mypricer".
2242  * -# Adjust the properties of the pricer (see \ref PRICER_PROPERTIES).
2243  * -# Define the pricer data (see \ref PRICER_DATA). This is optional.
2244  * -# Implement the interface methods (see \ref PRICER_INTERFACE).
2245  * -# Implement the fundamental callback methods (see \ref PRICER_FUNDAMENTALCALLBACKS).
2246  * -# Implement the additional callback methods (see \ref PRICER_ADDITIONALCALLBACKS). This is optional.
2247  *
2248  *
2249  * @section PRICER_PROPERTIES Properties of a Pricer
2250  *
2251  * At the top of the new file "pricer_mypricer.c" you can find the pricer properties.
2252  * These are given as compiler defines.
2253  * In the C++ wrapper class, you have to provide the pricer properties by calling the constructor
2254  * of the abstract base class scip::ObjPricer from within your constructor.
2255  * The properties you have to set have the following meaning:
2256  *
2257  * \par PRICER_NAME: the name of the pricer.
2258  * This name is used in the interactive shell to address the pricer.
2259  * Additionally, if you are searching for a pricer with SCIPfindPricer(), this name is looked up.
2260  * Names have to be unique: no two pricers may have the same name.
2261  *
2262  * \par PRICER_DESC: the description of the pricer.
2263  * This string is printed as a description of the pricer in the interactive shell.
2264  *
2265  * \par PRICER_PRIORITY: the priority of the pricer.
2266  * In each pricing round during the price-and-cut loop of the subproblem processing, the included pricers are
2267  * called in a predefined order, which is given by the priorities of the pricers.
2268  * The higher the priority, the earlier the pricer is called.
2269  * Usually, you will have only one pricer in your application and the priority is therefore irrelevant.
2270  *
2271  * \par PRICER_DELAY: the default for whether the pricer should be delayed, if other variables with negative reduced
2272  * costs have already been found in the current pricing round.
2273  * Variables may be declared to be "removable" in the SCIPcreateVar() call. This means that SCIP may remove the variable
2274  * from the LP if it was inactive (i.e., sitting at zero) for a number of LP solves. Nevertheless, after the removal of the
2275  * column from the LP, the variable still exists, and SCIP can calculate reduced costs and add it to the LP again if
2276  * necessary.
2277  * \n
2278  * If the PRICER_DELAY flag is set to TRUE (which is the common setting), all those existing variables with negative reduced costs
2279  * are added to the LP, and the LP is resolved before the pricer is called. Thus, the pricer can assume that all existing variables
2280  * have non-negative reduced costs if the \ref PRICERREDCOST method is called or non-positive Farkas value if the \ref PRICERFARKAS
2281  * method is called.
2282  * \n
2283  * In some applications, this inner pricing loop on the already existing variables can significantly slow down the solving process,
2284  * since it may lead to the addition of only very few variables in each pricing round. If this is an issue in your application,
2285  * you should consider setting the PRICER_DELAY flag to FALSE. You must, however, be aware of the fact that there may be already
2286  * existing variables with negative reduced costs. For example, this may lead to the issue that your pricer generates the same
2287  * variable twice. In some models, this is not critical because an optimal solution would choose only one of the two identical
2288  * variables anyway, but for other models this can lead to wrong results because the duplication of a variable essentially doubles
2289  * the upper bound of the variable.
2290  *
2291  *
2292  * @section PRICER_DATA Pricer Data
2293  *
2294  * Below the header "Data structures" you can find a struct which is called "struct SCIP_PricerData".
2295  * In this data structure, you can store the data of your pricer. For example, it may be convenient to store pointers to the
2296  * constraints of the problem instance here, because the pricer has to add variables to those constraints.
2297  * If you are using C++, you can add pricer data, as usual, as object variables to your class.
2298  * \n
2299  * Defining pricer data is optional. You can leave the struct empty.
2300  *
2301  *
2302  * @section PRICER_INTERFACE Interface Methods
2303  *
2304  * At the bottom of "pricer_mypricer.c" you can find the interface method SCIPincludePricerMypricer(), which also appears in "pricer_mypricer.h".
2305  * 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
2306  * be generated by this pricer.
2307  *
2308  * This method only has to be adjusted slightly.
2309  * It is responsible for notifying SCIP of the presence of the pricer. For this, you can either call SCIPincludePricer(),
2310  * or SCIPincludePricerBasic() since SCIP version 3.0. In the latter variant, \ref PRICER_ADDITIONALCALLBACKS "additional callbacks"
2311  * must be added via setter functions as, e.g., SCIPsetPricerCopy(). We recommend this latter variant because
2312  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
2313  * variant must be manually adjusted with every SCIP release containing new callbacks for pricers in order to compile.
2314  *
2315  *
2316  * In addition, the pricer has to be activated before the solution process starts, like it is done
2317  * in the pricer of the Coloring application (applications/Coloring/src/reader_col.c) by calling
2318  * \code
2319  * SCIP_CALL( SCIPactivatePricer(scip, SCIPfindPricer(scip, "coloring")) );
2320  * \endcode
2321  *
2322  * If you are using pricer data, you have to allocate the memory for the data at this point.
2323  * You can do this by calling:
2324  * \code
2325  * SCIP_CALL( SCIPallocMemory(scip, &pricerdata) );
2326  * \endcode
2327  * You also have to initialize the fields in struct SCIP_PricerData afterwards.
2328  *
2329  * You may also add user parameters for your pricer, see the method SCIPincludePricerColoring() in the pricer of the Coloring application
2330  * for an example of how to add user parameters.
2331  *
2332  *
2333  * @section PRICER_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Pricer
2334  *
2335  * The fundamental callback methods have to be implemented in order to obtain an operational algorithm.
2336  * They are passed together with the pricer itself to SCIP using SCIPincludePricer() or SCIPincludePricerBasic(),
2337  * see @ref PRICER_INTERFACE.
2338  *
2339  * In the case of a pricer, there are two fundamental callback methods, namely the @ref PRICERREDCOST and the
2340  * @ref PRICERFARKAS callbacks, which both search for new variables and add them to the problem.
2341  * These methods have to be implemented for every pricer; the other callback methods are optional.
2342  * In the C++ wrapper class scip::ObjPricer, the scip_redcost() method (which corresponds to the PRICERREDCOST callback)
2343  * is a virtual abstract member function. You have to implement it in order to be able to construct an object of your
2344  * pricer class.
2345  *
2346  * Additional documentation for the callback methods can be found in type_pricer.h.
2347  *
2348  * @subsection PRICERREDCOST
2349  *
2350  * The PRICERREDCOST callback is called inside the price-and-cut loop of the subproblem solving process if the current LP relaxation
2351  * is feasible.
2352  * It should search for additional variables that can contribute to improve the current LP's solution value.
2353  * In standard branch-and-price, these are variables with negative dual feasibility, that is negative
2354  * reduced costs for non-negative variables, positive reduced costs for non-positive variables,
2355  * and non-zero reduced costs for variables that can be negative and positive.
2356  *
2357  * Whenever the pricer finds a variable with negative dual feasibility, it should call SCIPcreateVar()
2358  * and SCIPaddPricedVar() to add the variable to the problem. Furthermore, it should call the appropriate
2359  * methods of the constraint handlers to add the necessary variable entries to the constraints, see pub_cons.h.
2360  *
2361  * In the usual case that the pricer either adds a new variable or ensures that there are no further variables with negative dual feasibility,
2362  * the result pointer should be set to SCIP_SUCCESS. Only if the pricer aborts pricing without creating a new variable, but
2363  * there might exist additional variables with negative dual feasibility, the result pointer should be set to SCIP_DIDNOTRUN.
2364  * In this case, which sometimes is referred to as "early branching", the LP solution will not be used as a lower bound.
2365  * The pricer can, however, store a valid lower bound in the <code>lowerbound</code> pointer.
2366  *
2367  * Pricers usually need the dual LP solution as input for the pricing algorithm.
2368  * Since SCIP does not know the semantics of the individual constraints in the problem, the dual solution
2369  * has to be provided by the constraint handlers.
2370  * For example, the \ref cons_setppc.h "setppc constraint handler", which deals with set partitioning, packing, and covering constraints, provides
2371  * the method SCIPgetDualsolSetppc() to access the dual solution value for a single constraint.
2372  * Similarly, the dual solution of a linear constraint can be queried with the method SCIPgetDualsolLinear() of cons_linear.h.
2373  * The reduced costs of the existing variables can be accessed with the method SCIPgetVarRedcost().
2374  *
2375  * @subsection PRICERFARKAS
2376  *
2377  * If the current LP relaxation is infeasible, it is the task of the pricer to generate additional variables that can
2378  * potentially render the LP feasible again. In standard branch-and-price, these are variables with positive Farkas values,
2379  * and the PRICERFARKAS method should identify those variables.
2380  *
2381  * If the LP was proven to be infeasible, we have an infeasibility proof by the dual Farkas multipliers \f$y\f$.
2382  * 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
2383  * by the sides of the LP rows and the sign of \f$y\f$:
2384  * - if \f$y_i\f$ is positive, \f$b_i\f$ is the left hand side of the row,
2385  * - if \f$y_i\f$ is negative, \f$b_i\f$ is the right hand side of the row.
2386  *
2387  * \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$,
2388  * especially by the (for this inequality least infeasible solution) \f$x'\f$ defined by
2389  * - \f$x'_i := ub_i\f$, if \f$y^T A_i \ge 0\f$
2390  * - \f$x'_i := lb_i\f$, if \f$y^T A_i < 0\f$.
2391  * 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$.
2392  *
2393  * To apply Farkas pricing, the pricer needs to know the Farkas values of the constraints. Like the dual solution values for
2394  * feasible LP solutions, the dual Farkas values for infeasible solutions can be obtained by constraint handler interface
2395  * methods such as the SCIPgetDualfarkasLinear() method of the linear constraint handler.
2396  * The Farkas values for the bounds of the variables are just the regular reduced costs and can be accessed with SCIPgetVarRedcost().
2397  *
2398  * It is useful to note that Farkas pricing is the same as the regular pricing with a zero objective function.
2399  * Therefore, a typical implementation of a pricer would consist of a generic pricing algorithm that gets a dual solution and an
2400  * objective function vector as input and generates variables by calling SCIPcreateVar() and SCIPaddPricedVar().
2401  * The PRICERREDCOST callback would call this function with the regular objective function and the regular dual solution vector,
2402  * while the PRICERFARKAS callback would call this function with a zero objective function and the Farkas vector.
2403  * From a practical point of view, it is usually the simplest approach to provide just one Boolean flag to the generic pricing
2404  * algorithm in order to identify whether it is reduced cost or Farkas pricing. Then, the algorithm would just call the appropriate
2405  * methods to access the dual solution or objective function, depending on the Boolean flag.
2406  *
2407  * @section PRICER_ADDITIONALCALLBACKS Additional Callback Methods of a Pricer
2408  *
2409  * The additional callback methods do not need to be implemented in every case.
2410  * However, some of them have to be implemented for most applications. They can either be passed directly with
2411  * SCIPincludePricer() to SCIP or via specific <b>setter functions</b> after a call of SCIPincludePricerBasic(),
2412  * see also @ref PRICER_INTERFACE.
2413  *
2414  * @subsection PRICERFREE
2415  *
2416  * If you are using pricer data, you have to implement this method in order to free the pricer data.
2417  * This can be done by the following procedure:
2418  * \code
2419  * static
2420  * SCIP_DECL_PRICERFREE(pricerFreeMypricer)
2421  * {
2422  * SCIP_PRICERDATA* pricerdata;
2423  *
2424  * pricerdata = SCIPpricerGetData(pricer);
2425  * assert(pricerdata != NULL);
2426  *
2427  * SCIPfreeMemory(scip, &pricerdata);
2428  *
2429  * SCIPpricerSetData(pricer, NULL);
2430  *
2431  * return SCIP_OKAY;
2432  * }
2433  * \endcode
2434  * If you have allocated memory for fields in your pricer data, remember to free this memory
2435  * before freeing the pricer data itself.
2436  * If you are using the C++ wrapper class, this method is not available.
2437  * Instead, just use the destructor of your class to free the member variables of your class.
2438  *
2439  * @subsection PRICERCOPY
2440  *
2441  * The PRICERCOPY callback is executed when the SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this
2442  * callback as <code>NULL</code> the user disables the inclusion of the pricer into all copied SCIP
2443  * instances. This means that primal heuristics will work on a sub-SCIP that contains only a part of the variables
2444  * and no variables are priced in during the solving process of the sub-SCIP. Therefore, primal solutions found in the
2445  * copied problem are typically still valid for the original problem and used for its solving process,
2446  * but dual reductions cannot be transferred to the original problem.
2447  *
2448  * <b>Note:</b> If you implement this callback, be careful when setting the valid pointer. The valid pointer should be
2449  * set to TRUE if (and only if!) you can make sure that all necessary data of the pricer are copied
2450  * correctly. If the complete problem is validly copied, i.e. if the copy methods of all problem defining plugins
2451  * (constraint handlers and pricers) return <code>*valid = TRUE</code>, then dual reductions found for the copied problem can be
2452  * transferred to the original SCIP instance. Thus, if the valid pointer is wrongly set to TRUE, it might happen that
2453  * optimal solutions are cut off.
2454  *
2455  * @subsection PRICERINIT
2456  *
2457  * The PRICERINIT callback is executed after the problem is transformed.
2458  * The pricer may, e.g., use this call to replace the original constraints stored in its pricer data by transformed
2459  * constraints, or to initialize other elements of its pricer data.
2460  *
2461  * @subsection PRICEREXIT
2462  *
2463  * The PRICEREXIT callback is executed before the transformed problem is freed.
2464  * In this method, the pricer should free all resources that have been allocated for the solving process in PRICERINIT.
2465  *
2466  * @subsection PRICERINITSOL
2467  *
2468  * The PRICERINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to begin.
2469  * The pricer may use this call to initialize its branch-and-bound specific data.
2470  *
2471  * @subsection PRICEREXITSOL
2472  *
2473  * The PRICEREXITSOL callback is executed before the branch-and-bound process is freed.
2474  * The pricer should use this call to clean up its branch-and-bound data, which was allocated in PRICERINITSOL.
2475  *
2476  * @section PRICER_REMARKS Further remarks
2477  *
2478  * 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".
2479  * Otherwise, SCIP will use its default branching rules, if necessary (which all branch on variables). This
2480  * could disturb the pricing problem or branching might not even be possible, e.g., if all variables created thus far have already been fixed.
2481  *
2482  * Note that if the original problem is a maximization problem, SCIP will transform the problem into a minimization
2483  * problem by multiplying the objective function by -1. The pricer has to take care of this by multiplying
2484  * the original objective function value of all variables created during the solving process by -1.
2485  *
2486  * In some cases, bounds on variables are implicitly enforced by constraints of the problem and the objective function.
2487  * 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
2488  * care about the corresponding dual values.
2489  * We call these bounds lazy bounds, they may be set by SCIPchgVarLbLazy() and SCIPchgVarUbLazy() for upper or lower bounds, respectively.
2490  * If the lazy bound is tighter than the local bound, the corresponding bound is not put into the LP.
2491  * In diving mode, lazy bounds are explicitly put into the LP, because changing the objective (which is only possible in diving)
2492  * might reverse the implicitly given bounds. When diving is finished, the bounds are again removed from the LP.
2493  */
2494 
2495 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
2496 /**@page PRESOL How to add presolvers
2497  *
2498  * Presolvers are used to reduce the size of the model by removing irrelevant information like redundant constraints,
2499  * to strengthen the LP relaxation by exploiting integrality information, and to extract useful information in the
2500  * presolving step.
2501  * Constraint based presolving is done in the CONSPRESOL callback methods of the constraint handlers, see \ref CONSPRESOL.
2502  * Some propagation steps can already be applied in presolving via the PROPRESOL callback methods of propagators, see \ref PROPPRESOL.
2503  * The presolver plugins complement these by additional, usually optimality based, presolving reductions.
2504  * \n
2505  * A complete list of all presolvers contained in this release can be found \ref PRESOLVERS "here".
2506  *
2507  * We now explain how users can add their own presolvers.
2508  * Take the trivial presolver (src/scip/presol_trivial.c) as an example.
2509  * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjPresol wrapper
2510  * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_PRESOL... callback methods.
2511  *
2512  * Additional documentation for the callback methods of a presolver, in particular for their input parameters,
2513  * can be found in the file type_presol.h.
2514  *
2515  * Here is what you have to do to implement a presolver:
2516  * -# Copy the template files src/scip/presol_xyz.c and src/scip/presol_xyz.h into files named "presol_mypresolver.c"
2517  * and "presol_mypresolver.h".
2518  * \n
2519  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2520  * -# Use SCIPincludePresolMypresolver() in order to include the presolver into your SCIP instance,
2521  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
2522  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mypresolver".
2523  * -# Adjust the properties of the presolver (see \ref PRESOL_PROPERTIES).
2524  * -# Define the presolver data (see \ref PRESOL_DATA). This is optional.
2525  * -# Implement the interface methods (see \ref PRESOL_INTERFACE).
2526  * -# Implement the fundamental callback methods (see \ref PRESOL_FUNDAMENTALCALLBACKS).
2527  * -# Implement the additional callback methods (see \ref PRESOL_ADDITIONALCALLBACKS). This is optional.
2528  *
2529  *
2530  * @section PRESOL_PROPERTIES Properties of a Presolver
2531  *
2532  * At the top of the new file "presol_mypresolver.c", you can find the presolver properties.
2533  * These are given as compiler defines.
2534  * In the C++ wrapper class, you have to provide the presolver properties by calling the constructor
2535  * of the abstract base class scip::ObjPresol from within your constructor.
2536  * The properties you have to set have the following meaning:
2537  *
2538  * \par PRESOL_NAME: the name of the presolver.
2539  * This name is used in the interactive shell to address the presolver.
2540  * Additionally, if you are searching for a presolver with SCIPfindPresol(), this name is looked up.
2541  * Names have to be <b>unique</b>: no two presolvers may have the same name.
2542  *
2543  * \par PRESOL_DESC: the description of the presolver.
2544  * This string is printed as a description of the presolver in the interactive shell.
2545  *
2546  * \par PRESOL_TIMING: the default timing of the presolver.
2547  * There are three presolving timings: FAST, MEDIUM, and EXHAUSTIVE.
2548  * Every presolving round starts with the FAST presolvers. MEDIUM presolvers are only called, if FAST presolvers did not find
2549  * enough reductions in this round so far, and EXHAUSTIVE presolving steps are only performed if all presolvers called before
2550  * in this round were unsuccessful.
2551  * Presolvers should be assigned a timing based on how expensive they are, e.g., presolvers that provide fast algorithms that
2552  * usually have a high impact (i.e., remove lots of variables or tighten bounds of many variables) should have a timing FAST.
2553  * If a presolver implements different algorithms of different complexity, it may also get multiple timings and check the timing
2554  * internally in the \ref PRESOLEXEC callback to decide which algorithms to run.
2555  *
2556  * \par PRESOL_PRIORITY: the priority of the presolver.
2557  * Within a presolving round, when calling all presolvers and presolving methods of propagators and constraint handlers
2558  * with a given timing, those are called in
2559  * a predefined order, which is given by the priorities of the presolvers and the check priorities of the
2560  * constraint handlers, see \ref CONS_PROPERTIES.
2561  * First, the presolvers with non-negative priority are called in the order of decreasing priority.
2562  * Next, the presolving methods of the different constraint handlers are called in the order of decreasing check
2563  * priority.
2564  * Finally, the presolvers with negative priority are called in the order of decreasing priority.
2565  * \n
2566  * Again, presolvers that provide fast algorithms that usually have a high impact (i.e., remove lots of variables or tighten
2567  * bounds of many variables) should have a high priority.
2568  * An easy way to list the timings and
2569  * priorities of all presolvers, propagators, and constraint handlers is to type "display presolvers", "display propagators",
2570  * and "display conshdlrs" in the interactive shell of SCIP.
2571  *
2572  * \par PRESOL_MAXROUNDS: the default maximal number of rounds the presolver participates in.
2573  * The presolving is conducted in rounds: the presolvers and presolving methods of the constraint handlers
2574  * are called iteratively until no more reductions have been found or some other abort criterion applies.
2575  * The "maxrounds" parameter of a presolver imposes a limit on the number of presolving rounds in which the
2576  * presolver is called. The PRESOL_MAXROUNDS property specifies the default value for this parameter.
2577  * A value of -1 represents an unlimited number of rounds.
2578  *
2579  *
2580  * @section PRESOL_DATA Presolver Data
2581  *
2582  * Below the header "Data structures" you can find a struct which is called "struct SCIP_PresolData".
2583  * In this data structure, you can store the data of your presolver. For example, you should store the adjustable parameters
2584  * of the presolver in this data structure.
2585  * If you are using C++, you can add presolver data as usual as object variables to your class.
2586  * \n
2587  * Defining presolver data is optional. You can leave this struct empty.
2588  *
2589  *
2590  * @section PRESOL_INTERFACE Interface Methods
2591  *
2592  * At the bottom of "presol_mypresolver.c", you can find the interface method SCIPincludePresolMypresolver(),
2593  * which also appears in "presol_mypresolver.h"
2594  * SCIPincludePresolMypresolver() is called by the user, if (s)he wants to include the presolver,
2595  * i.e., if (s)he wants to use the presolver in his/her application.
2596  *
2597  * This method only has to be adjusted slightly.
2598  * It is responsible for notifying SCIP of the presence of the presolver. For this, you can either call SCIPincludePresol(),
2599  * or SCIPincludePresolBasic() since SCIP version 3.0. In the latter variant, \ref PRESOL_ADDITIONALCALLBACKS "additional callbacks"
2600  * must be added via setter functions as, e.g., SCIPsetPresolCopy(). We recommend this latter variant because
2601  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
2602  * variant must be manually adjusted with every SCIP release containing new callbacks for presolvers in order to compile.
2603  *
2604  * If you are using presolver data, you have to allocate the memory for the data at this point.
2605  * You can do this by calling:
2606  * \code
2607  * SCIP_CALL( SCIPallocMemory(scip, &presoldata) );
2608  * \endcode
2609  * You also have to initialize the fields in struct SCIP_PresolData afterwards. For freeing the
2610  * presolver data, see \ref PRESOLFREE.
2611  *
2612  * You may also add user parameters for your presolver, see \ref PARAM for how to add user parameters and
2613  * the method SCIPincludePresolTrivial() in src/scip/presol_trivial.c for an example.
2614  *
2615  *
2616  * @section PRESOL_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Presolver
2617  *
2618  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
2619  * an operational algorithm.
2620  * They are passed together with the presolver itself to SCIP using SCIPincludePresol() or SCIPincludePresolBasic(),
2621  * see @ref PRESOL_INTERFACE.
2622  *
2623  * Presolver plugins have only one fundamental callback method, namely the @ref PRESOLEXEC method.
2624  * This method has to be implemented for every presolver; the other callback methods are optional.
2625  * In the C++ wrapper class scip::ObjPresol, the scip_exec() method (which corresponds to the PRESOLEXEC callback) is a virtual
2626  * abstract member function.
2627  * You have to implement it in order to be able to construct an object of your presolver class.
2628  *
2629  * Additional documentation for the callback methods, in particular to their input parameters,
2630  * can be found in type_presol.h.
2631  *
2632  * @subsection PRESOLEXEC
2633  *
2634  * The PRESOLEXEC callback is called inside the presolving loop and should perform the actual presolving reductions.
2635  * It should inspect the problem instance at hand and simplify it by tightening bounds of variables, aggregating or fixing
2636  * variables, changing the type of variables, modifying the graph that represents the instance of your application, and
2637  * the like.
2638  *
2639  * Typical methods called by a presolver are, for example, SCIPchgVarType(), SCIPfixVar(), SCIPaggregateVars(), SCIPtightenVarLb(),
2640  * and SCIPtightenVarUb().
2641  *
2642  *
2643  * @section PRESOL_ADDITIONALCALLBACKS Additional Callback Methods of a Presolver
2644  *
2645  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
2646  * implemented for most applications, they can be used, for example, to initialize and free private data.
2647  * Additional callbacks can either be passed directly with SCIPincludePresol() to SCIP or via specific
2648  * <b>setter functions</b> after a call of SCIPincludePresolBasic(), see also @ref PRESOL_INTERFACE.
2649  *
2650  * @subsection PRESOLFREE
2651  *
2652  * 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.
2653  * This can be done by the following procedure:
2654  * \code
2655  * static
2656  * SCIP_DECL_PRESOLFREE(presolFreeMypresolver)
2657  * {
2658  * SCIP_PRESOLDATA* presoldata;
2659  *
2660  * presoldata = SCIPpresolGetData(presol);
2661  * assert(presoldata != NULL);
2662  *
2663  * SCIPfreeMemory(scip, &presoldata);
2664  *
2665  * SCIPpresolSetData(presol, NULL);
2666  *
2667  * return SCIP_OKAY;
2668  * }
2669  * \endcode
2670  * If you have allocated memory for fields in your presolver data, remember to free this memory
2671  * before freeing the presolver data itself.
2672  * If you are using the C++ wrapper class, this method is not available.
2673  * Instead, just use the destructor of your class to free the member variables of your class.
2674  *
2675  * @subsection PRESOLINIT
2676  *
2677  * The PRESOLINIT callback is executed after the problem is transformed.
2678  * The presolver may, e.g., use this call to initialize its presolver data.
2679  * The difference between the original and the transformed problem is explained in
2680  * "What is this thing with the original and the transformed problem about?" on \ref FAQ.
2681  *
2682  * @subsection PRESOLCOPY
2683  *
2684  * The PRESOLCOPY callback is executed when a SCIP instance is copied, e.g. to
2685  * solve a sub-SCIP. By
2686  * defining this callback as
2687  * <code>NULL</code> the user disables the execution of the specified
2688  * presolver for all copied SCIP instances. This may deteriorate the performance
2689  * of primal heuristics using sub-SCIPs.
2690  *
2691  * @subsection PRESOLEXIT
2692  *
2693  * The PRESOLEXIT callback is executed before the transformed problem is freed.
2694  * In this method, the presolver should free all resources that have been allocated for the solving process in PRESOLINIT.
2695  *
2696  * @subsection PRESOLINITPRE
2697  *
2698  * The PRESOLINITPRE callback is executed when the presolving is about to begin.
2699  * The presolver may use this call to initialize its presolving data which only need to exist during the presolving stage.
2700  *
2701  * @subsection PRESOLEXITPRE
2702  *
2703  * The PRESOLEXITPRE callback is executed after presolving finishes and before the branch-and-bound process begins.
2704  * The presolver should use this call to clean up its presolving data, which was allocated in PRESOLINITPRE.
2705  */
2706 
2707 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
2708 /**@page SEPA How to add separators
2709  *
2710  * Separators are used to generate general purpose cutting planes.
2711  * Constraint based cutting planes, the second type of cutting planes in SCIP, are separated in the CONSSEPALP and
2712  * CONSSEPASOL callback methods of the constraint handlers, see \ref CONSSEPALP and \ref CONSSEPASOL. These cuts are
2713  * valid inequalities or even facets of the polyhedron described by a single constraint or a subset of the constraints of
2714  * a single constraint class. In contrast, general purpose cuts do not require or exploit any knowledge about the
2715  * underlying problem structure but use only the current LP relaxation and the integrality conditions. See also
2716  * "When should I implement a constraint handler, when should I implement a separator?" on \ref FAQ.
2717  * \n
2718  * A complete list of all separators contained in this release can be found \ref SEPARATORS "here".
2719  *
2720  * We now explain how users can add their own separators.
2721  * Take the separator for the class of Gomory mixed integer inequalities (src/scip/sepa_gomory.c) as an example.
2722  * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjSepa wrapper
2723  * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_SEPA... callback methods.
2724  *
2725  * Additional documentation for the callback methods of a separator, in particular for the input parameters,
2726  * can be found in the file type_sepa.h.
2727  *
2728  * Here is what you have to do to implement a separator:
2729  * -# Copy the template files src/scip/sepa_xyz.c and src/scip/sepa_xyz.h into files "sepa_myseparator.c"
2730  * and "sepa_myseparator.h".
2731  \n
2732  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2733  * -# Use SCIPincludeSepaMyseparator() in order to include the separator into your SCIP instance,
2734  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
2735  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "myseparator".
2736  * -# Adjust the properties of the separator (see \ref SEPA_PROPERTIES).
2737  * -# Define the separator data (see \ref SEPA_DATA). This is optional.
2738  * -# Implement the interface methods (see \ref SEPA_INTERFACE).
2739  * -# Implement the fundamental callback methods (see \ref SEPA_FUNDAMENTALCALLBACKS).
2740  * -# Implement the additional callback methods (see \ref SEPA_ADDITIONALCALLBACKS). This is optional.
2741  *
2742  *
2743  * @section SEPA_PROPERTIES Properties of a Separator
2744  *
2745  * At the top of the new file "sepa_myseparator.c", you can find the separator properties.
2746  * These are given as compiler defines.
2747  * In the C++ wrapper class, you have to provide the separator properties by calling the constructor
2748  * of the abstract base class scip::ObjSepa from within your constructor.
2749  * The properties you have to set have the following meaning:
2750  *
2751  * \par SEPA_NAME: the name of the separator.
2752  * This name is used in the interactive shell to address the separator.
2753  * Additionally, if you are searching for a separator with SCIPfindSepa(), this name is looked up.
2754  * Names have to be unique: no two separators may have the same name.
2755  *
2756  * \par SEPA_DESC: the description of the separator.
2757  * This string is printed as a description of the separator in the interactive shell.
2758  *
2759  * \par SEPA_PRIORITY: the priority of the separator.
2760  * In each separation round during the price-and-cut loop of the subproblem processing or the separation loop
2761  * of the primal solution separation, the separators and separation methods of the constraint handlers are called in
2762  * a predefined order, which is given by the priorities of the separators and the separation priorities
2763  * of the constraint handlers (see \ref CONS_PROPERTIES).
2764  * First, the separators with non-negative priority are called in the order of decreasing priority.
2765  * Next, the separation methods of the constraint handlers are called in the order of decreasing separation
2766  * priority.
2767  * Finally, the separators with negative priority are called in the order of decreasing priority. An easy way to list the
2768  * priorities of all separators and constraint handlers is to type "display separators" and "display conshdlrs" in
2769  * the interactive shell.
2770  * \n
2771  * The priority of the separator should be set according to the complexity of the cut separation algorithm and the
2772  * impact of the resulting cuts: separators that provide fast algorithms that usually have a high impact (i.e., cut off
2773  * a large portion of the LP relaxation) should have a high priority.
2774  * See \ref SEPAEXECLP and \ref SEPAEXECSOL for further details of the separation callbacks.
2775  *
2776  * \par SEPA_FREQ: the default frequency for separating cuts.
2777  * The frequency defines the depth levels at which the separation methods \ref SEPAEXECLP and \ref SEPAEXECSOL are called.
2778  * For example, a frequency of 7 means, that the separation callback is executed for subproblems that are in depth
2779  * 0, 7, 14, ... of the branching tree. A frequency of 0 means, that the separation method is only called at the root node.
2780  * A frequency of -1 disables the separator.
2781  * \n
2782  * The frequency can be adjusted by the user. This property of the separator only defines the default value of the frequency.
2783  * If you want to have a more flexible control of when to execute the separation algorithm, you have to assign
2784  * a frequency of 1 and implement a check at the beginning of your separation methods whether you really want to execute
2785  * the separation or not. If you do not want to execute it, set the result code of
2786  * \ref SEPAEXECLP and \ref SEPAEXECSOL to SCIP_DIDNOTRUN.
2787  *
2788  * \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.
2789  * At the current branch-and-bound node, the relative distance from its dual bound (local dual bound)
2790  * to the primal bound compared to the best node's dual bound (global dual bound) is considered. The separation method
2791  * of the separator will only be applied at the current node if this relative distance does not exceed SEPA_MAXBOUNDDIST.
2792  * \n
2793  * For example, if the global dual bound is 50 and the primal bound is 60, SEPA_MAXBOUNDDIST = 0.25 means that separation
2794  * 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
2795  * than or equal to 52.5.
2796  * \n
2797  * In particular, the values 0.0 and 1.0 mean that separation is applied at the current best node only or at all
2798  * nodes, respectively. Since separation seems to be most important to apply at nodes that define to the global
2799  * dual bound, 0.0 is probably a good choice for SEPA_MAXBOUNDDIST.
2800  * Note that separators with a frequency of SEPA_FREQ = 0 are only applied at the root node.
2801  * Obviously, at the root node the local dual bound is equal to the global dual bound and thus, the separator is called
2802  * for any value of SEPA_MAXBOUNDDIST.
2803  *
2804  * \par SEPA_USESSUBSCIP: Does the separator use a secondary SCIP instance?
2805  * Some heuristics and separators solve MIPs or SAT problems and use a secondary SCIP instance. Examples are
2806  * Large Neighborhood Search heuristics such as RINS and Local Branching or the CGMIP separator. To avoid recursion,
2807  * these plugins usually deactivate all other plugins that solve MIPs. If a separator uses a secondary SCIP instance,
2808  * this parameter has to be TRUE and it is recommended to call SCIPsetSubscipsOff() for the secondary SCIP instance.
2809  *
2810  * \par SEPA_DELAY: the default for whether the separation method should be delayed, if other separators or constraint handlers found cuts.
2811  * If the separator's separation method is marked to be delayed, it is only executed after no other separator
2812  * or constraint handler found a cut during the price-and-cut loop.
2813  * If the separation method of the separator is very expensive, you may want to mark it to be delayed until all cheap
2814  * separation methods have been executed.
2815  *
2816  * @section SEPA_DATA Separator Data
2817  *
2818  * Below the header "Data structures" you can find a struct which is called "struct SCIP_SepaData".
2819  * In this data structure, you can store the data of your separator. For example, you should store the adjustable
2820  * parameters of the separator in this data structure. In a separator, user parameters for the maximal number of
2821  * separation rounds per node and for the maximal number of cuts separated per separation round might be useful.
2822  * If you are using C++, you can add separator data as usual as object variables to your class.
2823  * \n
2824  * Defining separator data is optional. You can leave the struct empty.
2825  *
2826  * @section SEPA_INTERFACE Interface Methods
2827  *
2828  * At the bottom of "sepa_myseparator.c", you can find the interface method SCIPincludeSepaMyseparator(),
2829  * which also appears in "sepa_myseparator.h"
2830  * SCIPincludeSepaMyseparator() is called by the user, if (s)he wants to include the separator,
2831  * i.e., if (s)he wants to use the separator in his/her application.
2832  *
2833  * This method only has to be adjusted slightly.
2834  * It is responsible for notifying SCIP of the presence of the separator. For this, you can either call SCIPincludeSepa(),
2835  * or SCIPincludeSepaBasic() since SCIP version 3.0. In the latter variant, \ref SEPA_ADDITIONALCALLBACKS "additional callbacks"
2836  * must be added via setter functions as, e.g., SCIPsetSepaCopy(). We recommend this latter variant because
2837  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
2838  * variant must be manually adjusted with every SCIP release containing new callbacks for separators in order to compile.
2839  *
2840  * If you are using separator data, you have to allocate the memory
2841  * for the data at this point. You can do this by calling:
2842  * \code
2843  * SCIP_CALL( SCIPallocMemory(scip, &sepadata) );
2844  * \endcode
2845  * You also have to initialize the fields in "struct SCIP_SepaData" afterwards. For freeing the
2846  * separator data, see \ref SEPAFREE.
2847  *
2848  * You may also add user parameters for your separator, see \ref PARAM for how to add user parameters and
2849  * the method SCIPincludeSepaGomory() in src/scip/sepa_gomory.c for an example.
2850  *
2851  *
2852  * @section SEPA_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Separator
2853  *
2854  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
2855  * an operational algorithm.
2856  * They are passed together with the separator itself to SCIP using SCIPincludeSepa() or SCIPincludeSepaBasic(),
2857  * see @ref SEPA_INTERFACE.
2858  *
2859  * Separator plugins have two callbacks, @ref SEPAEXECLP and @ref SEPAEXECSOL, of which at least one must be implemented.
2860  *
2861  * Additional documentation for the callback methods, in particular to their input parameters,
2862  * can be found in type_sepa.h.
2863  *
2864  * @subsection SEPAEXECLP
2865  *
2866  * The SEPAEXECLP callback is executed during the price-and-cut loop of the subproblem processing.
2867  * It should try to generate general purpose cutting planes in order to separate the current LP solution.
2868  * The method is called in the LP solution loop, which means that a valid LP solution exists.
2869  *
2870  * Usually, the callback searches and produces cuts, that are added with a call to SCIPaddCut().
2871  * If the cut should be added to the global cut pool, it calls SCIPaddPoolCut().
2872  * In addition to LP rows, the callback may also produce domain reductions or add additional constraints.
2873  *
2874  * Overall, the SEPAEXECLP callback has the following options, which is indicated by the possible return values of
2875  * the 'result' variable (see type_sepa.h):
2876  * - detecting that the node is infeasible in the variable's bounds and can be cut off (result SCIP_CUTOFF)
2877  * - adding an additional constraint (result SCIP_CONSADDED)
2878  * - reducing a variable's domain (result SCIP_REDUCEDDOM)
2879  * - adding a cutting plane to the LP (result SCIP_SEPARATED)
2880  * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
2881  * (result SCIP_DIDNOTFIND)
2882  * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
2883  * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
2884  * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
2885  *
2886  * @subsection SEPAEXECSOL
2887  *
2888  * The SEPAEXECSOL callback is executed during the separation loop on arbitrary primal solutions.
2889  * It should try to generate general purpose cutting planes in order to separate the given primal solution.
2890  * The method is not called in the LP solution loop, which means that there is no valid LP solution.
2891  *
2892  * In the standard SCIP environment, the SEPAEXECSOL callback is not used because only LP solutions are
2893  * separated. The SEPAEXECSOL callback provides means to support external relaxation handlers like semidefinite
2894  * relaxations that want to separate an intermediate primal solution vector. Thus, if you do not want to support
2895  * such external plugins, you do not need to implement this callback method.
2896  *
2897  * Usually, the callback searches and produces cuts, that are added with a call to SCIPaddCut().
2898  * If the cut should be added to the global cut pool, it calls SCIPaddPoolCut().
2899  * In addition to LP rows, the callback may also produce domain reductions or add other constraints.
2900  *
2901  * Overall, the SEPAEXECSOL callback has the following options, which is indicated by the possible return values of
2902  * the 'result' variable (see type_sepa.h):
2903  * - detecting that the node is infeasible in the variable's bounds and can be cut off (result SCIP_CUTOFF)
2904  * - adding an additional constraint (result SCIP_CONSADDED)
2905  * - reducing a variable's domain (result SCIP_REDUCEDDOM)
2906  * - adding a cutting plane to the LP (result SCIP_SEPARATED)
2907  * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
2908  * (result SCIP_DIDNOTFIND)
2909  * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
2910  * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
2911  * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
2912  *
2913  *
2914  * @section SEPA_ADDITIONALCALLBACKS Additional Callback Methods of a Separator
2915  *
2916  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
2917  * implemented for most applications, they can be used, for example, to initialize and free private data.
2918  * Additional callbacks can either be passed directly with SCIPincludeSepa() to SCIP or via specific
2919  * <b>setter functions</b> after a call of SCIPincludeSepaBasic(), see also @ref SEPA_INTERFACE.
2920  *
2921  * @subsection SEPAFREE
2922  *
2923  * If you are using separator data (see \ref SEPA_DATA and \ref SEPA_INTERFACE), you have to implement this method
2924  * in order to free the separator data. This can be done by the following procedure:
2925  * \code
2926  * static
2927  * SCIP_DECL_SEPAFREE(sepaFreeMyseparator)
2928  * {
2929  * SCIP_SEPADATA* sepadata;
2930  *
2931  * sepadata = SCIPsepaGetData(sepa);
2932  * assert(sepadata != NULL);
2933  *
2934  * SCIPfreeMemory(scip, &sepadata);
2935  *
2936  * SCIPsepaSetData(sepa, NULL);
2937  *
2938  * return SCIP_OKAY;
2939  * }
2940  * \endcode
2941  * If you have allocated memory for fields in your separator data, remember to free this memory
2942  * before freeing the separator data itself.
2943  * If you are using the C++ wrapper class, this method is not available.
2944  * Instead, just use the destructor of your class to free the member variables of your class.
2945  *
2946  * @subsection SEPACOPY
2947  *
2948  * The SEPACOPY callback is executed when a SCIP instance is copied, e.g. to
2949  * solve a sub-SCIP. By
2950  * defining this callback as
2951  * <code>NULL</code> the user disables the execution of the specified
2952  * separator for all copied SCIP instances. This may deteriorate the performance
2953  * of primal heuristics using sub-SCIPs.
2954  *
2955  * @subsection SEPAINIT
2956  *
2957  * The SEPAINIT callback is executed after the problem is transformed.
2958  * The separator may, e.g., use this call to initialize its separator data.
2959  * The difference between the original and the transformed problem is explained in
2960  * "What is this thing with the original and the transformed problem about?" on \ref FAQ.
2961  *
2962  * @subsection SEPAEXIT
2963  *
2964  * The SEPAEXIT callback is executed before the transformed problem is freed.
2965  * In this method, the separator should free all resources that have been allocated for the solving process in SEPAINIT.
2966  *
2967  * @subsection SEPAINITSOL
2968  *
2969  * The SEPAINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
2970  * begin. The separator may use this call to initialize its branch-and-bound specific data.
2971  *
2972  * @subsection SEPAEXITSOL
2973  *
2974  * The SEPAEXITSOL callback is executed before the branch-and-bound process is freed. The separator should use this call
2975  * to clean up its branch-and-bound data, in particular to release all LP rows that it has created or captured.
2976  */
2977 
2978 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
2979 /**@page PROP How to add propagators
2980  *
2981  * Propagators are used to tighten the domains of the variables. Like for cutting planes, there are two different types
2982  * of domain propagations. Constraint based (primal) domain propagation algorithms are part of the corresponding
2983  * constraint handlers, see \ref CONSPROP. In contrast, domain propagators usually provide dual propagations, i.e.,
2984  * propagations that can be applied using the objective function and the current best known primal solution. This
2985  * section deals with such propagators.
2986  *
2987  * A complete list of all propagators contained in this release can be found \ref PROPAGATORS "here".
2988  *
2989  * We now explain how users can add their own propagators. Take the pseudo objective function propagator
2990  * (src/scip/prop_pseudoobj.c) as an example. As all other default plugins, it is written in C. C++ users can easily
2991  * adapt the code by using the scip::ObjProp wrapper base class and implement the @c scip_...() virtual methods instead
2992  * of the @c SCIP_DECL_PROP... callback methods.
2993  *
2994  * Additional documentation for the callback methods of a propagator can be found in the file type_prop.h.
2995  *
2996  * Here is what you have to do to implement a propagator:
2997  * -# Copy the template files src/scip/prop_xyz.c and src/scip/prop_xyz.h into files named "prop_mypropagator.c"
2998  * and "prop_mypropagator.h".
2999  * \n
3000  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
3001  * -# Use SCIPincludePropMypropagator() in order to include the propagator into your SCIP instance,
3002  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
3003  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mypropagator".
3004  * -# Adjust the properties of the propagator (see \ref PROP_PROPERTIES).
3005  * -# Define the propagator data (see \ref PROP_DATA). This is optional.
3006  * -# Implement the interface methods (see \ref PROP_INTERFACE).
3007  * -# Implement the fundamental callback methods (see \ref PROP_FUNDAMENTALCALLBACKS).
3008  * -# Implement the additional callback methods (see \ref PROP_ADDITIONALCALLBACKS). This is optional.
3009  *
3010  * @section PROP_PROPERTIES Properties of a Propagator
3011  *
3012  * At the top of the new file "prop_mypropagator.c" you can find the propagator properties. These are given as compiler
3013  * defines. The presolving-related properties are optional,
3014  * they only have to be defined if the propagator supports presolving routines.
3015  * In the C++ wrapper class, you have to provide the propagator properties by calling the constructor of the
3016  * abstract base class scip::ObjProp from within your constructor. The properties you have the following meaning:
3017  *
3018  * @subsection PROP_FUNDAMENTALPROPERTIES Fundamental properties of a propagator
3019  *
3020  * \par PROP_NAME: the name of the propagator.
3021  * This name is used in the interactive shell to address the propagator. Additionally, if you are searching for a
3022  * propagator with SCIPfindProp(), this name is searched for. Names have to be unique: no two propagators may have the
3023  * same name.
3024  *
3025  * \par PROP_DESC: the description of the propagator.
3026  * This string is printed as a description of the propagator in the interactive shell.
3027  *
3028  * \par PROP_PRIORITY: the priority of the propagator.
3029  * In each propagation round, the propagators and propagation methods of the constraint handlers are called in a
3030  * predefined order, which is given by the priorities of the propagators and the check priorities of the constraint
3031  * handlers. First, the propagators with non-negative priority are called in order of decreasing priority. Next, the
3032  * propagation methods of the different constraint handlers are called in order of decreasing check priority. Finally,
3033  * the propagators with negative priority are called in order of decreasing priority. \n The priority of the
3034  * propagators should be set according to the complexity of the propagation algorithm and the impact of the domain
3035  * propagations: propagators providing fast algorithms that usually have a high impact (i.e., tighten many bounds)
3036  * should have a high priority.
3037  *
3038  * \par PROP_FREQ: the default frequency for propagating domains.
3039  * The frequency defines the depth levels at which the propagation method \ref PROPEXEC is called. For example, a
3040  * frequency of 7 means, that the propagation callback is executed for subproblems that are in depth 0, 7, 14, ... of
3041  * the branching tree. A frequency of 0 means that propagation is only applied in preprocessing and at the root node. A
3042  * frequency of -1 disables the propagator.
3043  * \n
3044  * The frequency can be adjusted by the user. This property of the propagator only defines the default value of the
3045  * frequency.\n
3046  * <b>Note:</b> If you want to have a more flexible control of when to execute the propagation algorithm, you have to
3047  * assign a frequency of 1 and implement a check at the beginning of your propagation algorithm whether you really want
3048  * to execute the domain propagation or not. If you do not want to execute it, set the result code to SCIP_DIDNOTRUN.
3049  *
3050  * \par PROP_DELAY: the default for whether the propagation method should be delayed, if other propagators or constraint handlers found domain reductions.
3051  * If the propagator's propagation method is marked to be delayed, it is only executed after no other propagator or
3052  * constraint handler found a domain reduction in the current iteration of the domain propagation loop. If the
3053  * propagation method of the propagator is very expensive, you may want to mark it to be delayed until all cheap
3054  * propagation methods have been executed.
3055  *
3056  * \par PROP_TIMING: the timing mask of the propagator.
3057  * SCIP calls the domain propagation routines at different places in the node processing loop.
3058  * This property indicates at which places the propagator is called.
3059  * Possible values are defined in type_timing.h and can be concatenated, e.g., as in SCIP_PROPTIMING_ALWAYS.
3060  *
3061  * @subsection PROP_ADDITIONALPROPERTIES Optional propagator properties
3062  *
3063  * The following properties are optional and only need to be defined if the propagator supports
3064  * presolving, that is, if the \ref PROPPRESOL "presolving callback" is implemented.
3065 
3066  * \par PROP_PRESOLTIMING: the timing of the presolving method (FAST, MEDIUM, or EXHAUSTIVE).
3067  * Every presolving round starts with the FAST presolving methods. MEDIUM presolvers are only called, if FAST presolvers did not find
3068  * enough reductions in this round so far, and EXHAUSTIVE presolving steps are only performed if all presolvers called before
3069  * in this round were unsuccessful.
3070  * Presolving methods should be assigned a timing based on how expensive they are, e.g., presolvers that provide fast algorithms that
3071  * usually have a high impact (i.e., remove lots of variables or tighten bounds of many variables) should have a timing FAST.
3072  * If a presolving method implements different algorithms of different complexity, it may also get multiple timings and check the timing
3073  * internally in the \ref PROPPRESOL callback to decide which algorithms to run.
3074  *
3075  * \par PROP_PRESOL_PRIORITY: the priority of the presolving method.
3076  * This attribute is analogous to the PROP_PRIORITY flag, but deals with the preprocessing method of the presolver.
3077  *
3078  * \par PROP_PRESOL_MAXROUNDS: the default maximal number of presolving rounds the propagator participates in.
3079  * The preprocessing is executed in rounds.
3080  * If enough changes have been applied to the model, an additional preprocessing round is performed.
3081  * The MAXROUNDS parameter of a propagator denotes the maximal number of preprocessing rounds, the propagator
3082  * participates in.
3083  * A value of -1 means, that there is no limit on the number of rounds.
3084  * A value of 0 means, the preprocessing callback of the propagator is disabled.
3085  *
3086  * @section PROP_DATA Propagator Data
3087  *
3088  * Below the title "Data structures" you can find a struct called <code>struct SCIP_PropData</code>. In this data
3089  * structure, you can store the data of your propagator. For example, you should store the adjustable parameters of the
3090  * propagator in this data structure. If you are using C++, you can add propagator data as object variables to your
3091  * class as usual .
3092  * \n
3093  * Defining propagator data is optional. You can leave the struct empty.
3094  *
3095  *
3096  * @section PROP_INTERFACE Interface Methods
3097  *
3098  * At the bottom of "prop_mypropagator.c", you can find the interface method SCIPincludeSepaMypropagator(),
3099  * which also appears in "prop_mypropagator.h"
3100  * SCIPincludePropMypropagator() is called by the user, if (s)he wants to include the propagator,
3101  * i.e., if (s)he wants to use the propagator in his/her application.
3102  *
3103  * This method only has to be adjusted slightly.
3104  * It is responsible for notifying SCIP of the presence of the propagator. For this, you can either call SCIPincludeProp(),
3105  * or SCIPincludePropBasic() since SCIP version 3.0. In the latter variant, \ref PROP_ADDITIONALCALLBACKS "additional callbacks"
3106  * must be added via setter functions as, e.g., SCIPsetPropCopy(). We recommend this latter variant because
3107  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
3108  * variant must be manually adjusted with every SCIP release containing new callbacks for separators in order to compile.
3109  *
3110  *
3111  * If you are using propagator data, you have to allocate the memory for the data at this point. You can do this by
3112  * calling
3113  * \code
3114  * SCIP_CALL( SCIPallocMemory(scip, &propdata) );
3115  * \endcode
3116  * You also have to initialize the fields in <code>struct SCIP_PropData</code> afterwards.
3117  *
3118  * You may also add user parameters for your propagator, see the method SCIPincludePropPseudoobj() in
3119  * src/scip/prop_pseudoobj.c for an example.
3120  *
3121  *
3122  * @section PROP_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Propagator
3123  *
3124  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
3125  * an operational algorithm.
3126  * They are passed together with the propagator itself to SCIP using SCIPincludeProp() or SCIPincludePropBasic(),
3127  * see @ref PROP_INTERFACE.
3128  *
3129  * Propagator plugins have one fundamental callback method, namely the \ref PROPEXEC method
3130  * method. This method has to be implemented for every propagator; the other callback methods are optional. In the
3131  * C++ wrapper class scip::ObjProp, the scip_exec() method (which corresponds to the \ref PROPEXEC
3132  * callback) is a virtual abstract member function. You have to
3133  * implement it in order to be able to construct an object of your propagator class.
3134  *
3135  * Additional documentation for the callback methods can be found in type_prop.h.
3136  *
3137  * @subsection PROPEXEC
3138  *
3139  * The PROPEXEC callback is called during presolving and during the subproblem processing. It should perform the actual
3140  * domain propagation, which means that it should tighten the variables' bounds. The technique of domain propagation,
3141  * which is the main workhorse of constraint programming, is called "node preprocessing" in the Integer Programming
3142  * community.
3143  *
3144  * The PROPEXEC callback has the following options:
3145  * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
3146  * - reducing (i.e, tightening) the domains of some variables (result SCIP_REDUCEDDOM)
3147  * - stating that the propagator searched, but did not find domain reductions, cutting planes, or cut constraints
3148  * (result SCIP_DIDNOTFIND)
3149  * - stating that the propagator was skipped (result SCIP_DIDNOTRUN)
3150  * - stating that the propagator was skipped, but should be called again (result SCIP_DELAYED)
3151  *
3152  *
3153  *
3154  * @section PROP_ADDITIONALCALLBACKS Additional Callback Methods of a Propagator
3155  *
3156  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
3157  * implemented for most applications, they can be used, for example, to initialize and free private data.
3158  * Additional callbacks can either be passed directly with SCIPincludeProp() to SCIP or via specific
3159  * <b>setter functions</b> after a call of SCIPincludePropBasic(), see also @ref PROP_INTERFACE.
3160  *
3161  * @subsection PROPRESPROP
3162  *
3163  * If the propagator wants to support \ref CONF "conflict analysis", it has to supply the PROPRESPROP method. It also should call
3164  * SCIPinferVarLbProp() or SCIPinferVarUbProp() in the domain propagation instead of SCIPchgVarLb() or SCIPchgVarUb() in
3165  * order to deduce bound changes on variables. In the SCIPinferVarLbProp() and SCIPinferVarUbProp() calls, the
3166  * propagator provides a pointer to itself and an integer value "inferinfo" that can be arbitrarily chosen.
3167  *
3168  * The propagation conflict resolving method PROPRESPROP must then be implemented to provide the "reasons" for the bound
3169  * changes, i.e., the bounds of variables at the time of the propagation, which forced the propagator to set the
3170  * conflict variable's bound to its current value. It can use the "inferinfo" tag to identify its own propagation rule
3171  * and thus identify the "reason" bounds. The bounds that form the reason of the assignment must then be provided by
3172  * calls to SCIPaddConflictLb() and SCIPaddConflictUb() in the propagation conflict resolving method.
3173  *
3174  * See the description of the propagation conflict resolving method \ref CONSRESPROP of constraint handlers for
3175  * further details.
3176  *
3177  * Omitting the PROPRESPROP callback circumvents the implementation of the usually rather complex conflict resolving method.
3178  * Yet, it
3179  * will make the conflict analysis less effective. We suggest to first omit the conflict resolving method and check how
3180  * effective the propagation method is. If it produces a lot of propagations for your application, you definitely should
3181  * consider implementing the conflict resolving method.
3182  *
3183  *
3184  * @subsection PROPFREE
3185  *
3186  * If you are using propagator data, you have to implement this method in order to free the propagator data.
3187  * This can be done by the following procedure:
3188  * \code
3189  * static
3190  * SCIP_DECL_PROPFREE(propFreeMypropagator)
3191  * {
3192  * SCIP_PROPDATA* propdata;
3193  *
3194  * propdata = SCIPpropGetData(prop);
3195  * assert(propdata != NULL);
3196  *
3197  * SCIPfreeMemory(scip, &propdata);
3198  *
3199  * SCIPpropSetData(prop, NULL);
3200  *
3201  * return SCIP_OKAY;
3202  * }
3203  * \endcode
3204  * If you have allocated memory for fields in your propagator data, remember to free this memory
3205  * before freeing the propagator data itself.
3206  * If you are using the C++ wrapper class, this method is not available.
3207  * Instead, just use the destructor of your class to free the member variables of your class.
3208  *
3209  * @subsection PROPINIT
3210  *
3211  * The PROPINIT callback is executed after the problem is transformed. The propagator may, e.g., use this call to
3212  * initialize its propagator data.
3213  *
3214  * @subsection PROPCOPY
3215  *
3216  * The PROPCOPY callback is executed when a SCIP instance is copied, e.g. to
3217  * solve a sub-SCIP. By
3218  * defining this callback as
3219  * <code>NULL</code> the user disables the execution of the specified
3220  * propagator for all copied SCIP instances. This may deteriorate the performance
3221  * of primal heuristics using sub-SCIPs.
3222  *
3223  * @subsection PROPEXIT
3224  *
3225  * The PROPEXIT callback is executed before the transformed problem is freed.
3226  * In this method, the propagator should free all resources that have been allocated for the solving process in PROPINIT.
3227  *
3228  * @subsection PROPINITPRE
3229  *
3230  * The PROPINITPRE callback is executed before the preprocessing is started, even if presolving is turned off.
3231  * The propagator may use this call to initialize its presolving data before the presolving process begins.
3232  *
3233  * @subsection PROPEXITPRE
3234  *
3235  * The PROPEXITPRE callback is executed after the preprocessing has been finished, even if presolving is turned off.
3236  * The propagator may use this call, e.g., to clean up its presolving data.
3237  * Besides clean up, no time consuming operations should be done.
3238  *
3239  * @subsection PROPINITSOL
3240  *
3241  * The PROPINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
3242  * begin.
3243  * The propagator may use this call to initialize its branch-and-bound specific data.
3244  *
3245  * @subsection PROPEXITSOL
3246  *
3247  * The PROPEXITSOL callback is executed before the branch-and-bound process is freed.
3248  * The propagator should use this call to clean up its branch-and-bound data.
3249  *
3250  * @subsection PROPPRESOL
3251  *
3252  * Seaches for domain propagations, analogous to the \ref PROPEXEC callback.
3253  * However, this callback is called during preprocessing.
3254  *
3255  * To inform SCIP that the presolving method found a reduction the result pointer has to be set in a proper way.
3256  * The following options are possible:
3257  *
3258  * - SCIP_UNBOUNDED : at least one variable is not bounded by any constraint in objective direction
3259  * - SCIP_CUTOFF : at least one domain reduction that renders the problem infeasible has been found
3260  * - SCIP_SUCCESS : the presolver found a domain reduction
3261  * - SCIP_DIDNOTFIND : the presolver searched, but did not find a presolving change
3262  * - SCIP_DIDNOTRUN : the presolver was skipped
3263  * - SCIP_DELAYED : the presolver was skipped, but should be called again
3264  *
3265  *
3266  * Please see also the @ref PROP_ADDITIONALPROPERTIES section to learn about the properties
3267  * PROP_PRESOLTIMING and PROP_PRESOL_MAXROUNDS, which influence the behaviour of SCIP
3268  * calling PROPPRESOL.
3269  *
3270  */
3271 
3272 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
3273 /**@page BRANCH How to add branching rules
3274  *
3275  * Branching rules are used to split the problem at the current node into smaller subproblems. Branching rules can be called at three
3276  * different occasions, which is why they have three different execution methods (see \ref
3277  * BRANCHRULE_ADDITIONALCALLBACKS). Branching is performed if:
3278  * - the LP solution of the current problem is fractional. In this case, the integrality constraint handler calls the
3279  * \ref BRANCHEXECLP methods of the branching rules.
3280  * - the list of external branching candidates is not empty. This will only be the case if branching candidates were added
3281  * by a user's \ref RELAX "relaxation handler" or \ref CONS "constraint handler" plugin, calling SCIPaddExternBranchCand().
3282  * These branching candidates should be processed by the \ref BRANCHEXECEXT method.
3283  * - if an integral solution violates one or more constraints and this infeasibility could not be resolved in the callback methods
3284  * \ref CONSENFOLP and \ref CONSENFOPS of the corresponding constraint handlers. In this case, the \ref BRANCHEXECPS method will be called. This is the
3285  * 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
3286  * branching on pseudo solutions works as a last resort.
3287  *
3288  * The idea of branching rules is to take a global view on the problem. In contrast, branching paradigms which are
3289  * specific to one type of constraint are best implemented within the enforcement callbacks of your constraint handler.
3290  * See, e.g., the constraint specific branching rules provided by the constraint handlers for special ordered sets
3291  * (src/scip/cons_sos{1,2}.c)).
3292  * \n
3293  * All branching rules that come with the default distribution of SCIP create two subproblems by splitting a single
3294  * variable's domain. It is, however, fully supported to implement much more general branching schemes, for example by
3295  * creating more than two subproblems, or by adding additional constraints to the subproblems instead of tightening the
3296  * domains of the variables.
3297  * \n
3298  * A complete list of all branching rules contained in this release can be found \ref BRANCHINGRULES "here".
3299  *
3300  * We now explain how users can add their own branching rules. Take the most infeasible LP branching rule
3301  * (src/scip/branch_mostinf.c) as an example. As all other default plugins, it is written in C. C++ users can easily
3302  * adapt the code by using the scip::ObjBranchrule wrapper base class and implement the scip_...() virtual methods instead of
3303  * the SCIP_DECL_BRANCH... callback methods.
3304  *
3305  * Additional documentation for the callback methods of a branching rule can be found in the file type_branch.h.
3306  *
3307  * Here is what you have to do to implement a branching rule:
3308  * -# Copy the template files src/scip/branch_xyz.c and src/scip/branch_xyz.h into files named
3309  * "branch_mybranchingrule.c" and "branch_mybranchingrule.h".
3310  * \n
3311  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
3312  * -# Use SCIPincludeBranchruleMybranchingrule() in order to include the branching rule into your SCIP instance,
3313  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
3314  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mybranchingrule".
3315  * -# Adjust the properties of the branching rule (see \ref BRANCHRULE_PROPERTIES).
3316  * -# Define the branching rule data (see \ref BRANCHRULE_DATA). This is optional.
3317  * -# Implement the interface methods (see \ref BRANCHRULE_INTERFACE).
3318  * -# Implement the fundamental callback methods (see \ref BRANCHRULE_FUNDAMENTALCALLBACKS).
3319  * -# Implement the additional callback methods (see \ref BRANCHRULE_ADDITIONALCALLBACKS). This is optional.
3320  *
3321  *
3322  * @section BRANCHRULE_PROPERTIES Properties of a Branching Rule
3323  *
3324  * At the top of the new file "branch_mybranchingrule.c" you can find the branching rule properties.
3325  * These are given as compiler defines.
3326  * In the C++ wrapper class, you have to provide the branching rule properties by calling the constructor
3327  * of the abstract base class scip::ObjBranchrule from within your constructor.
3328  * The properties you have to set have the following meaning:
3329  *
3330  * \par BRANCHRULE_NAME: the name of the branching rule.
3331  * This name is used in the interactive shell to address the branching rule.
3332  * Additionally, if you are searching for a branching rule with SCIPfindBranchrule(), this name is looked up.
3333  * Names have to be unique: no two branching rules may have the same name.
3334  *
3335  * \par BRANCHRULE_DESC: the description of the branching rule.
3336  * This string is printed as a description of the branching rule in the interactive shell.
3337  *
3338  * \par BRANCHRULE_PRIORITY: the default value for the priority of the branching rule.
3339  * In the subproblem processing, the branching rules are called in decreasing order of their priority until
3340  * one succeeded to branch. Since most branching rules are able to generate a branching in all situations,
3341  * only the rule of highest priority is used. In combination with the BRANCHRULE_MAXDEPTH and
3342  * BRANCHRULE_MAXBOUNDDIST settings, however, interesting strategies can be easily employed. For example,
3343  * the user can set the priority of the "full strong branching" strategy to the highest value and assign the
3344  * second highest value to the "reliable pseudo cost" rule. If (s)he also sets the maximal depth for the
3345  * "full strong branching" to 5, in the top 5 depth levels of the search tree the "full strong branching" is
3346  * applied, while in the deeper levels "reliable pseudo cost branching" is used.
3347  * \n
3348  * Note that the BRANCHRULE_PRIORITY property only specifies the default value of the priority. The user can
3349  * change this value arbitrarily.
3350  *
3351  * \par BRANCHRULE_MAXDEPTH: the default value for the maximal depth level of the branching rule.
3352  * This parameter denotes the maximal depth level in the branch-and-bound tree up to which the branching method of the
3353  * branching rule will be applied. Use -1 for no limit.
3354  * \n
3355  * Note that this property only specifies the default value. The user can change this value arbitrarily.
3356  *
3357  * \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.
3358  * At the current branch-and-bound node, the relative distance from its dual bound (local dual bound)
3359  * to the primal bound compared to the best node's dual bound (global dual bound) is considered. The branching method of
3360  * the branching rule will only be applied at the node if this relative distance does not exceed BRANCHRULE_MAXBOUNDDIST.
3361  * \n
3362  * For example, if the global dual bound is 50 and the primal bound is 60, BRANCHRULE_MAXBOUNDDIST = 0.25 means that
3363  * 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
3364  * 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
3365  * current best node only or at all nodes, respectively.
3366  * \n
3367  * Note that the BRANCHRULE_MAXBOUNDDIST property only specifies the default value of the maximal bound distance.
3368  * The user can change this value arbitrarily.
3369  *
3370  *
3371  * @section BRANCHRULE_DATA Branching Rule Data
3372  *
3373  * Below the header "Data structures" you can find a struct which is called "struct SCIP_BranchruleData".
3374  * In this data structure, you can store the data of your branching rule. For example, you should store the adjustable
3375  * parameters of the branching rule in this data structure.
3376  * If you are using C++, you can add branching rule data as usual as object variables to your class.
3377  * \n
3378  * Defining branching rule data is optional. You can leave the struct empty.
3379  *
3380  *
3381  * @section BRANCHRULE_INTERFACE Interface Methods
3382  *
3383  * At the bottom of "branch_mybranchingrule.c", you can find the interface method SCIPincludeBranchruleMybranchingrule(),
3384  * which also appears in "branch_mybranchingrule.h"
3385  * SCIPincludeBranchruleMybranchingrule() is called by the user, if (s)he wants to include the branching rule,
3386  * i.e., if (s)he wants to use the branching rule in his/her application.
3387  *
3388  * This method only has to be adjusted slightly.
3389  * It is responsible for notifying SCIP of the presence of the branching rule. For this, you can either call
3390  * SCIPincludeBranchrule(),
3391  * or SCIPincludeBranchruleBasic() since SCIP version 3.0. In the latter variant, \ref BRANCHRULE_ADDITIONALCALLBACKS "additional callbacks"
3392  * must be added via setter functions as, e.g., SCIPsetBranchruleCopy(). We recommend this latter variant because
3393  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
3394  * variant must be manually adjusted with every SCIP release containing new callbacks for branchrule in order to compile.
3395  *
3396  *
3397  * If you are using branching rule data, you have to allocate the memory for the data at this point.
3398  * You can do this by calling:
3399  * \code
3400  * SCIP_CALL( SCIPallocMemory(scip, &branchruledata) );
3401  * \endcode
3402  * You also have to initialize the fields in struct SCIP_BranchruleData afterwards.
3403  *
3404  * You may also add user parameters for your branching rule, see the method SCIPincludeBranchruleRelpscost() in
3405  * src/scip/branch_relpscost.c for an example.
3406  *
3407  *
3408  * @section BRANCHRULE_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Branching Rule
3409  *
3410  * Branching rules do not have any fundamental callback methods, i.e., all callback methods are optional.
3411  * In most cases, however, you want to implement the \ref BRANCHEXECLP method and sometimes the \ref BRANCHEXECPS method.
3412  *
3413  *
3414  * @section BRANCHRULE_ADDITIONALCALLBACKS Additional Callback Methods of a Branching Rule
3415  *
3416  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
3417  * implemented for most applications, they can be used, for example, to initialize and free private data.
3418  * Additional callbacks can either be passed directly with SCIPincludeBranchrule() to SCIP or via specific
3419  * <b>setter functions</b> after a call of SCIPincludeBranchruleBasic(), see also @ref BRANCHRULE_INTERFACE.
3420  *
3421  * The most important callback methods are the \ref BRANCHEXECLP, \ref BRANCHEXECEXT,
3422  * and \ref BRANCHEXECPS methods, which perform the actual task of generating a branching.
3423  *
3424  * Additional documentation for the callback methods can be found in type_branch.h.
3425  *
3426  * @subsection BRANCHEXECLP
3427  *
3428  * The BRANCHEXECLP callback is executed during node processing if a fractional LP solution is available. It should
3429  * split the current problem into smaller subproblems. Usually, the branching is done in a way such that the current
3430  * fractional LP solution is no longer feasible in the relaxation of the subproblems. It is, however, possible to
3431  * create a child node for which the fractional LP solution is still feasible in the relaxation, for example, by
3432  * branching on a variable with integral LP value. In every case, you have to make sure that each subproblem is a
3433  * proper restriction of the current problem. Otherwise, you risk to produce an infinite path in the search tree.
3434  *
3435  * The user gains access to the branching candidates, i.e., to the fractional variables, and their LP solution values by
3436  * calling the method SCIPgetLPBranchCands(). Furthermore, SCIP provides two methods for performing the actual
3437  * branching, namely SCIPbranchVar() and SCIPcreateChild().
3438  *
3439  * Given an integral variable \f$x\f$ with fractional LP solution value \f$x^*\f$, the method SCIPbranchVar() creates
3440  * two child nodes; one contains the bound \f$x \le \lfloor x^* \rfloor\f$ and the other one contains the bound \f$x \ge
3441  * \lceil x^* \rceil\f$, see the BRANCHEXECLP callback in src/scip/branch_mostinf.c for an example. In addition, if a
3442  * proven lower objective bound of a created child node is known, like after strong branching has been applied, the user
3443  * may call the method SCIPupdateNodeLowerbound() in order to update the child node's lower bound.
3444  *
3445  * Please also see the \ref BRANCHEXEC "further information for the three execution methods".
3446  *
3447  * @subsection BRANCHEXECEXT
3448  *
3449  * The BRANCHEXECEXT callback is executed during node processing if no LP solution is available and the list of
3450  * external branching candidates is not empty. It should split the current problem into smaller subproblems. If you
3451  * do not use relaxation handlers or constraints handlers that provide external branching candidates, you do not need to
3452  * implement this callback.
3453  *
3454  * In contrast to the LP branching candidates and the pseudo branching candidates, the list of external branching
3455  * candidates will not be generated automatically. The user has to add all variables to the list by calling
3456  * SCIPaddExternBranchCand() for each of them. Usually, this will happen in the execution method of a relaxation handler or in the
3457  * enforcement methods of a constraint handler.
3458  *
3459  * The user gains access to these branching candidates by calling the method SCIPgetExternBranchCands(). Furthermore,
3460  * SCIP provides two methods for performing the actual branching with a given solution value, namely SCIPbranchVarVal()
3461  * and SCIPcreateChild(). SCIPbranchVarVal() allows users to specify the branching point for a variable in contrast to
3462  * SCIPbranchVar(), which will always use the current LP or pseudo solution.
3463  *
3464  * This paragraph contains additional information regarding how the method SCIPbranchVarVal() works. For external branching candidates,
3465  * there are three principle possibilities:
3466  * - Given a continuous variable \f$x\f$ with solution value \f$x^*\f$, the method SCIPbranchVarVal() creates
3467  * two child nodes; one contains the bound \f$x \le x^* \f$ and the other one contains the bound \f$x \ge x^* \f$.
3468  * - Given an integer variable \f$x\f$ with fractional solution value \f$x^*\f$, the method
3469  * SCIPbranchVarVal() creates two child nodes; one contains the bound \f$x \le \lfloor x^* \rfloor\f$ and the other
3470  * one contains the bound \f$x \ge \lceil x^* \rceil\f$.
3471  * - Given an integer variable \f$x\f$ with integral solution value \f$x^*\f$, the method SCIPbranchVarVal()
3472  * creates three child nodes; one contains the bound \f$x \le x^* -1\f$, one contains the bound \f$x \ge x^* +1\f$,
3473  * one contains the fixing \f$x = x^*\f$.
3474  *
3475  * See the BRANCHEXECEXT callback in src/scip/branch_random.c for an example. In addition, if a proven lower bound of a
3476  * created child node is known the user may call the method SCIPupdateNodeLowerbound() in order to update the child
3477  * node's lower bound.
3478  *
3479  * Please also see the \ref BRANCHEXEC "further information for the three execution methods".
3480  *
3481  * @subsection BRANCHEXECPS
3482  *
3483  * The BRANCHEXECPS callback is executed during node processing if no LP solution is available and at least one of the
3484  * integer variables is not yet fixed. It should split the current problem into smaller subproblems. PS stands for
3485  * pseudo solution which is the vector of all variables set to their locally best (w.r.t. the objective function)
3486  * bounds.
3487  *
3488  * The user gains access to the branching candidates, i.e., to the non-fixed integer variables, by calling the method
3489  * SCIPgetPseudoBranchCands(). Furthermore, SCIP provides two methods for performing the actual branching, namely
3490  * SCIPbranchVar() and SCIPcreateChild().
3491  *
3492  * Given an integer variable \f$x\f$ with bounds \f$[l,u]\f$ and not having solved the LP, the method SCIPbranchVar()
3493  * creates two child nodes:
3494  * - If both bounds are finite, then the two children will contain the domain reductions \f$x \le x^*\f$, and \f$x \ge
3495  * x^*+1\f$ with \f$x^* = \lfloor \frac{l + u}{2}\rfloor\f$. The current pseudo solution will remain feasible in one
3496  * of the branches, but the hope is that halving the domain's size leads to good propagations.
3497  * - If only one of the bounds is finite, the variable will be fixed to that bound in one of the child nodes. In the
3498  * other child node, the bound will be shifted by one.
3499  * - 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$.
3500 
3501  *
3502  * See the BRANCHEXECPS callback in src/scip/branch_random.c for an example. In addition, if a proven lower bound of a
3503  * created child node is known, the user may call the method SCIPupdateNodeLowerbound() in order to update the child
3504  * node's lower bound.
3505  *
3506  * Please also see the \ref BRANCHEXEC "further information for the three execution methods".
3507  *
3508  * @subsection BRANCHEXEC Further information for the three execution methods
3509  *
3510  * In order to apply more general branching schemes, one should use the method SCIPcreateChild().
3511  * After having created a child node, the additional restrictions of the child node have to be added with calls to
3512  * SCIPaddConsNode(), SCIPchgVarLbNode(), or SCIPchgVarUbNode().
3513  * \n
3514  * In the method SCIPcreateChild(), the branching rule has to assign two values to the new nodes: a node selection
3515  * priority for each node and an estimate for the objective value of the best feasible solution contained in the subtree
3516  * after applying the branching. If the method SCIPbranchVar() is used, these values are automatically assigned. For
3517  * variable based branching schemes, one might use the methods SCIPcalcNodeselPriority() and the method
3518  * SCIPcalcChildEstimate().
3519  *
3520  * In some cases, the branching rule can tighten the current subproblem instead of producing a branching. For example,
3521  * strong branching might have proven that rounding up a variable would lead to an infeasible LP relaxation and thus,
3522  * the variable must be rounded down. Therefore, the BRANCHEXECLP, BRANCHEXECPS and BRANCHEXECREL callbacks may also
3523  * produce domain reductions or add additional constraints to the current subproblem.
3524  *
3525  * The execution callbacks have the following options:
3526  * - detecting that the node is infeasible and can be cut off (result SCIP_CUTOFF)
3527  * - adding an additional constraint (e.g. a conflict constraint) (result SCIP_CONSADDED; note that this action
3528  * must not be performed if the input "allowaddcons" is FALSE)
3529  * - reducing the domain of a variable such that the current LP solution becomes infeasible (result SCIP_REDUCEDDOM)
3530  * - applying a branching (result SCIP_BRANCHED)
3531  * - stating that the branching rule was skipped (result SCIP_DIDNOTRUN).
3532  *
3533  * Only the BRANCHEXECLP callback has the possibility to add a cutting plane to the LP (result SCIP_SEPARATED).
3534  *
3535  * @subsection BRANCHFREE
3536  *
3537  * If you are using branching rule data, you have to implement this method in order to free the branching rule data.
3538  * This can be done by the following procedure:
3539  * \code
3540  * static
3541  * SCIP_DECL_BRANCHFREE(branchFreeMybranchingrule)
3542  * {
3543  * SCIP_BRANCHRULEDATA* branchruledata;
3544  *
3545  * branchruledata = SCIPbranchruleGetData(branchrule);
3546  * assert(branchruledata != NULL);
3547  *
3548  * SCIPfreeMemory(scip, &branchruledata);
3549  *
3550  * SCIPbranchruleSetData(branchrule, NULL);
3551  *
3552  * return SCIP_OKAY;
3553  * }
3554  * \endcode
3555  * If you have allocated memory for fields in your branching rule data, remember to free this memory
3556  * before freeing the branching rule data itself.
3557  * If you are using the C++ wrapper class, this method is not available.
3558  * Instead, just use the destructor of your class to free the member variables of your class.
3559  *
3560  * @subsection BRANCHINIT
3561  *
3562  * The BRANCHINIT callback is executed after the problem is transformed.
3563  * The branching rule may, e.g., use this call to initialize its branching rule data.
3564  *
3565  * @subsection BRANCHCOPY
3566  *
3567  * The BRANCHCOPY callback is executed when a SCIP instance is copied, e.g. to
3568  * solve a sub-SCIP. By
3569  * defining this callback as
3570  * <code>NULL</code> the user disables the execution of the specified
3571  * branching rule for all copied SCIP instances. This may deteriorate the performance
3572  * of primal heuristics using sub-SCIPs.
3573  *
3574  * @subsection BRANCHEXIT
3575  *
3576  * The BRANCHEXIT callback is executed before the transformed problem is freed.
3577  * In this method, the branching rule should free all resources that have been allocated for the solving process in
3578  * BRANCHINIT.
3579  *
3580  * @subsection BRANCHINITSOL
3581  *
3582  * The BRANCHINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
3583  * begin.
3584  * The branching rule may use this call to initialize its branch-and-bound specific data.
3585  *
3586  * @subsection BRANCHEXITSOL
3587  *
3588  * The BRANCHEXITSOL callback is executed before the branch-and-bound process is freed.
3589  * The branching rule should use this call to clean up its branch-and-bound data.
3590  */
3591 
3592 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
3593 /**@page NODESEL How to add node selectors
3594  *
3595  * Node selectors are used to decide which of the leaves in the current branching tree is selected as next subproblem
3596  * to be processed. The ordering relation of the tree's leaves for storing them in the leaf priority queue is also
3597  * defined by the node selectors.
3598  * \n
3599  * A complete list of all node selectors contained in this release can be found \ref NODESELECTORS "here".
3600  *
3601  * We now explain how users can add their own node selectors.
3602  * Take the node selector for depth first search (src/scip/nodesel_dfs.c) as an example.
3603  * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjNodesel wrapper
3604  * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_NODESEL... callback methods.
3605  *
3606  * Additional documentation for the callback methods of a node selector can be found in the file type_nodesel.h.
3607  *
3608  * Here is what you have to do to implement a node selector:
3609  * -# Copy the template files src/scip/nodesel_xyz.c and src/scip/nodesel_xyz.h into files named "nodesel_mynodeselector.c"
3610  * and "nodesel_mynodeselector.h".
3611  * \n
3612  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
3613  * -# Use SCIPincludeNodeselMynodeselector() in oder to include the node selector into your SCIP instance,
3614  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
3615  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mynodeselector".
3616  * -# Adjust the properties of the node selector (see \ref NODESEL_PROPERTIES).
3617  * -# Define the node selector data (see \ref NODESEL_DATA). This is optional.
3618  * -# Implement the interface methods (see \ref NODESEL_INTERFACE).
3619  * -# Implement the fundamental callback methods (see \ref NODESEL_FUNDAMENTALCALLBACKS).
3620  * -# Implement the additional callback methods (see \ref NODESEL_ADDITIONALCALLBACKS). This is optional.
3621  *
3622  *
3623  * @section NODESEL_PROPERTIES Properties of a Node Selector
3624  *
3625  * At the top of the new file "nodesel_mynodeselector.c" you can find the node selector properties.
3626  * These are given as compiler defines.
3627  * In the C++ wrapper class, you have to provide the node selector properties by calling the constructor
3628  * of the abstract base class scip::ObjNodesel from within your constructor.
3629  * The properties you have to set have the following meaning:
3630  *
3631  * \par NODESEL_NAME: the name of the node selector.
3632  * This name is used in the interactive shell to address the node selector.
3633  * Additionally, if you are searching for a node selector with SCIPfindNodesel(), this name is looked up.
3634  * Names have to be unique: no two node selectors may have the same name.
3635  *
3636  * \par NODESEL_DESC: the description of the node selector.
3637  * This string is printed as a description of the node selector in the interactive shell.
3638  *
3639  * \par NODESEL_STDPRIORITY: the default priority of the node selector in the standard mode.
3640  * The first step of each iteration of the main solving loop is the selection of the next subproblem to be processed.
3641  * The node selector of highest priority (the active node selector) is called to do this selection.
3642  * In particular, if you implemented your own node selector plugin which you want to be applied, you should choose a priority
3643  * which is greater then all priorities of the SCIP default node selectors.
3644  * Note that SCIP has two different operation modes: the standard mode and the memory saving mode. If the memory
3645  * limit - given as a parameter by the user - is almost reached, SCIP switches from the standard mode to the memory saving
3646  * mode in which different priorities for the node selectors are applied. NODESEL_STDPRIORITY is the priority of the
3647  * node selector used in the standard mode.
3648  * \n
3649  * Note that this property only defines the default value of the priority. The user may change this value arbitrarily by
3650  * adjusting the corresponding parameter setting.
3651  *
3652  * \par NODESEL_MEMSAVEPRIORITY: the default priority of the node selector in the memory saving mode.
3653  * The priority NODESEL_MEMSAVEPRIORITY of the node selector has the same meaning as the priority NODESEL_STDPRIORITY, but
3654  * is used in the memory saving mode.
3655  * Usually, you want the best performing node selector, for example best estimate search, to have maximal
3656  * standard priority, while you want a node selector which tends to keep the growth of the search tree limited, for example
3657  * depth first search, to have maximal memory saving priority.
3658  * \n
3659  * Note that this property only defines the default value of the priority. The user may change this value arbitrarily by
3660  * adjusting the corresponding parameter setting.
3661  *
3662  *
3663  * @section NODESEL_DATA Node Selector Data
3664  *
3665  * Below the header "Data structures" you can find a struct which is called "struct SCIP_NodeselData".
3666  * In this data structure, you can store the data of your node selector. For example, you should store the adjustable
3667  * parameters of the node selector in this data structure.
3668  * If you are using C++, you can add node selector data as usual as object variables to your class.
3669  * \n
3670  * Defining node selector data is optional. You can leave the struct empty.
3671  *
3672  *
3673  * @section NODESEL_INTERFACE Interface Methods
3674  *
3675  * At the bottom of "nodesel_mynodeselector.c", you can find the interface method SCIPincludeNodeselMynodeselector(),
3676  * which also appears in "nodesel_mynodeselector.h"
3677  * SCIPincludeNodeselMynodeselector() is called by the user, if (s)he wants to include the node selector,
3678  * i.e., if (s)he wants to use the node selector in his/her application.
3679  *
3680  * This method only has to be adjusted slightly.
3681  * It is responsible for notifying SCIP of the presence of the node selector. For this, you can either call
3682  * SCIPincludeNodesel(),
3683  * or SCIPincludeNodeselBasic() since SCIP version 3.0. In the latter variant, \ref NODESEL_ADDITIONALCALLBACKS "additional callbacks"
3684  * must be added via setter functions as, e.g., SCIPsetNodeselCopy(). We recommend this latter variant because
3685  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
3686  * variant must be manually adjusted with every SCIP release containing new callbacks for node selectors in order to compile.
3687  *
3688  *
3689  * If you are using node selector data, you have to allocate the memory for the data at this point.
3690  * You can do this by calling:
3691  * \code
3692  * SCIP_CALL( SCIPallocMemory(scip, &nodeseldata) );
3693  * \endcode
3694  * You also have to initialize the fields in struct SCIP_NodeselData afterwards.
3695  *
3696  * You may also add user parameters for your node selector, see the method SCIPincludeNodeselRestartdfs() in
3697  * src/scip/nodesel_restartdfs.c for an example.
3698  *
3699  *
3700  * @section NODESEL_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Node Selector
3701  *
3702  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
3703  * an operational algorithm.
3704  * They are passed together with the node selector itself to SCIP using SCIPincludeNodesel() or SCIPincludeNodeselBasic(),
3705  * see @ref NODESEL_INTERFACE.
3706  *
3707  * Node selector plugins have two fundamental callback methods, namely the NODESELSELECT method and the NODESELCOMP method.
3708  * These methods have to be implemented for every node selector; the other callback methods are optional.
3709  * They implement the two requirements every node selector has to fulfill: Selecting a node from the queue to be processed
3710  * next and, given two nodes, deciding which of both is favored by the node selector's selection rule. The first
3711  * task is implemented in the NODESELSELECT callback, the second one in the NODESELCOMP callback.
3712  * In the C++ wrapper class scip::ObjNodesel, the scip_select() method and the scip_comp() method (which correspond to the
3713  * NODESELSELECT callback and the NODESELCOMP callback, respectively) are virtual abstract member functions.
3714  * You have to implement them in order to be able to construct an object of your node selector class.
3715  *
3716  * Additional documentation for the callback methods can be found in type_nodesel.h.
3717  *
3718  * @subsection NODESELSELECT
3719  *
3720  * The NODESELSELECT callback is the first method called in each iteration in the main solving loop. It should decide
3721  * which of the leaves in the current branching tree is selected as the next subproblem to be processed.
3722  * It can arbitrarily decide between all leaves stored in the tree, but for performance reasons,
3723  * the current node's children and siblings are often treated different from the remaining leaves.
3724  * This is mainly due to the warm start capabilities of the simplex algorithm and the expectation that the bases of
3725  * neighboring vertices in the branching tree very similar.
3726  * The node selector's choice of the next node to process can
3727  * have a large impact on the solver's performance, because it influences the finding of feasible solutions and the
3728  * development of the global dual bound.
3729  *
3730  * Besides the ranking of the node selector, every node gets assigned a node selection priority by the branching rule
3731  * that created the node. See the \ref BRANCHEXECLP and \ref BRANCHEXECPS callbacks of the branching rules for details.
3732  * For example, the node where the branching went in the same way as the deviation from the branching variable's
3733  * root solution could be assigned a higher priority than the node where the branching went in the opposite direction.
3734  *
3735  * The following methods provide access to the various types of leaf nodes:
3736  * - SCIPgetPrioChild() returns the child of the current node with the largest node selection priority, as assigned by the
3737  * branching rule.
3738  * If no child is available (for example, because the current node was pruned), a NULL pointer is returned.
3739  * - SCIPgetBestChild() returns the best child of the current node with respect to the node selector's ordering relation as
3740  * defined by the \ref NODESELCOMP callback. If no child is available, a NULL pointer is returned.
3741  * - SCIPgetPrioSibling() returns the sibling of the current node with the largest node selection priority.
3742  * If no sibling is available (for example, because all siblings of the current node have already been processed), a NULL
3743  * pointer is returned.
3744  * Note that in binary branching every node has at most one sibling, but since SCIP supports arbitrary branching rules,
3745  * this might not always be the case.
3746  * - SCIPgetBestSibling() returns the best sibling of the current node with respect to the node selector's ordering relation
3747  * as defined by the \ref NODESELCOMP callback. If no sibling is available, a NULL pointer is returned.
3748  * - SCIPgetBestNode() returns the best leaf from the tree (children, siblings, or other leaves) with respect to the node
3749  * selector's ordering relation as defined by the \ref NODESELCOMP callback. If no open leaf exists, a NULL pointer is
3750  * returned. In this case, the optimization is finished, and the node selector should return a NULL pointer as 'selnode'.
3751  * - SCIPgetBestboundNode() returns a leaf from the tree (children, siblings, or other leaves) with the smallest lower (dual)
3752  * objective bound. If the queue is empty, a NULL pointer is returned. In this case, the optimization is finished, and the
3753  * node selector should return a NULL pointer as 'selnode'.
3754  *
3755  *
3756  * @subsection NODESELCOMP
3757  *
3758  * The NODESELCOMP callback is called to compare two leaves of the current branching tree (say node 1 and node 2)
3759  * regarding their ordering relation.
3760  *
3761  * The NODESELCOMP should return the following values:
3762  * - value < 0, if node 1 comes before (is better than) node 2
3763  * - value = 0, if both nodes are equally good
3764  * - value > 0, if node 1 comes after (is worse than) node 2.
3765  *
3766  * @section NODESEL_ADDITIONALCALLBACKS Additional Callback Methods of a Node Selector
3767  *
3768  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
3769  * implemented for most applications, they can be used, for example, to initialize and free private data.
3770  * Additional callbacks can either be passed directly with SCIPincludeNodesel() to SCIP or via specific
3771  * <b>setter functions</b> after a call of SCIPincludeNodeselBasic(), see also @ref NODESEL_INTERFACE.
3772  *
3773  * @subsection NODESELFREE
3774  *
3775  * If you are using node selector data, you have to implement this method in order to free the node selector data.
3776  * This can be done by the following procedure:
3777  * \code
3778  * static
3779  * SCIP_DECL_NODESELFREE(nodeselFreeMynodeselector)
3780  * {
3781  * SCIP_NODESELDATA* nodeseldata;
3782  *
3783  * nodeseldata = SCIPnodeselGetData(nodesel);
3784  * assert(nodeseldata != NULL);
3785  *
3786  * SCIPfreeMemory(scip, &nodeseldata);
3787  *
3788  * SCIPnodeselSetData(nodesel, NULL);
3789  *
3790  * return SCIP_OKAY;
3791  * }
3792  * \endcode
3793  * If you have allocated memory for fields in your node selector data, remember to free this memory
3794  * before freeing the node selector data itself.
3795  * If you are using the C++ wrapper class, this method is not available.
3796  * Instead, just use the destructor of your class to free the member variables of your class.
3797  *
3798  * @subsection NODESELINIT
3799  *
3800  * The NODESELINIT callback is executed after the problem is transformed.
3801  * The node selector may, e.g., use this call to initialize its node selector data.
3802  *
3803  * @subsection NODESELCOPY
3804  *
3805  * The NODESELCOPY callback is executed when a SCIP instance is copied, e.g. to
3806  * solve a sub-SCIP. By
3807  * defining this callback as
3808  * <code>NULL</code> the user disables the execution of the specified
3809  * node selector for all copied SCIP instances. This may deteriorate the performance
3810  * of primal heuristics using sub-SCIPs.
3811  *
3812  * @subsection NODESELEXIT
3813  *
3814  * The NODESELEXIT callback is executed before the transformed problem is freed.
3815  * In this method, the node selector should free all resources that have been allocated for the solving process
3816  * in NODESELINIT.
3817  *
3818  * @subsection NODESELINITSOL
3819  *
3820  * The NODESELINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
3821  * begin.
3822  * The node selector may use this call to initialize its branch-and-bound specific data.
3823  *
3824  * @subsection NODESELEXITSOL
3825  *
3826  * The NODESELEXITSOL callback is executed before the branch-and-bound process is freed.
3827  * The node selector should use this call to clean up its branch-and-bound data.
3828  */
3829 
3830 
3831 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
3832 /**@page HEUR How to add primal heuristics
3833  *
3834  * Feasible solutions can be found in two different ways during the traversal of the branch-and-bound tree. On one
3835  * hand, the solution of a node's relaxation may be feasible with respect to the constraints (including the integrality).
3836  * On the other hand, feasible solutions can be discovered by primal heuristics.
3837  * \n
3838  * A complete list of all primal heuristics contained in this release can be found \ref PRIMALHEURISTICS "here".
3839  * \n
3840  * Diving heuristics are primal heuristics that explore an auxiliary search tree in a depth-first manner. Since SCIP
3841  * version 3.2, it is easy to integrate further diving heuristics by using a special controller for the scoring,
3842  * see \ref DIVINGHEUR "here" for information on how to implement a diving heuristic.
3843  * \n
3844  * We now explain how users can add their own primal heuristics.
3845  * Take the simple and fast LP rounding heuristic (src/scip/heur_simplerounding.c) as an example.
3846  * The idea of simple rounding is to iterate over all fractional variables of an LP solution and round them down,
3847  * if the variables appears only with nonnegative coefficients in the system Ax <= b and round them up if
3848  * the variables appears only with nonpositive coefficients.
3849  * If one of both conditions applies for each of the fractional variables, this will give a feasible solution.
3850  * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjHeur wrapper
3851  * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_HEUR... callback methods.
3852  *
3853  * Additional documentation for the callback methods of a primal heuristic can be found in the file type_heur.h.
3854  *
3855  * Here is what you have to do to implement a primal heuristic:
3856  * -# Copy the template files src/scip/heur_xyz.c and src/scip/heur_xyz.h into files named "heur_myheuristic.c"
3857  * and "heur_myheuristic.h".
3858  * \n
3859  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
3860  * -# Use SCIPincludeHeurMyheuristic() in order to include the heuristic into your SCIP instance,
3861  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
3862  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "myheuristic".
3863  * -# Adjust the properties of the primal heuristic (see \ref HEUR_PROPERTIES).
3864  * -# Define the primal heuristic data (see \ref HEUR_DATA). This is optional.
3865  * -# Implement the interface methods (see \ref HEUR_INTERFACE).
3866  * -# Implement the fundamental callback methods (see \ref HEUR_FUNDAMENTALCALLBACKS).
3867  * -# Implement the additional callback methods (see \ref HEUR_ADDITIONALCALLBACKS). This is optional.
3868  *
3869  *
3870  * @section HEUR_PROPERTIES Properties of a Primal Heuristic
3871  *
3872  * At the top of the new file "heur_myheuristic.c" you can find the primal heuristic properties.
3873  * These are given as compiler defines.
3874  * In the C++ wrapper class, you have to provide the primal heuristic properties by calling the constructor
3875  * of the abstract base class scip::ObjHeur from within your constructor.
3876  * Of course, all of them are of relevant, but the most important ones for controlling the performance
3877  * are usually HEUR_FREQ and HEUR_TIMING.
3878  * The properties you have to set have the following meaning:
3879  *
3880  * \par HEUR_NAME: the name of the primal heuristic.
3881  * This name is used in the interactive shell to address the primal heuristic.
3882  * Additionally, if you are searching for a primal heuristic with SCIPfindHeur(), this name is looked up.
3883  * Names have to be unique: no two primal heuristics may have the same name.
3884  *
3885  * \par HEUR_DESC: the description of the primal heuristic.
3886  * This string is printed as a description of the primal heuristic in the interactive shell when you call "display heuristics".
3887  *
3888  * \par HEUR_DISPCHAR: the display character of the primal heuristic.
3889  * In the interactive shell, this character is printed in the first column of a status information row, if the primal
3890  * heuristic found the feasible solution belonging to the primal bound. Note that a star '*' stands for an integral
3891  * LP-relaxation.
3892  * In order to avoid confusion, display characters should be unique: no two primal heuristics should have the same display character.
3893  * You can get a list of all primal heuristics along with their display characters by entering "display heuristics" in the
3894  * SCIP interactive shell.
3895  *
3896  * \par HEUR_PRIORITY: the priority of the primal heuristic.
3897  * At each of the different entry points of the primal heuristics during the solving process (see HEUR_TIMING), they are
3898  * called in decreasing order of their priority.
3899  * \n
3900  * The priority of a primal heuristic should be set according to the complexity of the heuristic and the likelihood to find
3901  * feasible solutions: primal heuristics that provide fast algorithms that often succeed in finding a feasible solution should have
3902  * a high priority (like simple rounding). In addition, the interaction between different types of primal heuristics should be taken into account.
3903  * For example, improvement heuristics, which try to generate improved solutions by inspecting one or more of the feasible
3904  * solutions that have already been found, should have a low priority (like Crossover which by default needs at least 3 feasible solutions).
3905  *
3906  * \par HEUR_FREQ: the default frequency for executing the primal heuristic.
3907  * The frequency together with the frequency offset (see HEUR_FREQOFS) defines the depth levels at which the execution
3908  * method of the primal heuristic \ref HEUREXEC is called. For example, a frequency of 7 together with a frequency offset
3909  * of 5 means, that the \ref HEUREXEC callback is executed for subproblems that are in depth 5, 12, 19, ... of the branching tree. A
3910  * frequency of 0 together with a frequency offset of 3 means, that the execution method is only called at those nodes that are in
3911  * depth level 3 (i.e., at most for \f$2^3 = 8\f$ nodes if binary branching is applied).
3912  * Typical cases are: A frequency of 0 and an offset of 0 which means that
3913  * the heuristic is only called at the root node and a frequency of -1 which disables the heuristic.
3914  * \n
3915  * The frequency can be adjusted by the user. This property of the primal heuristic only defines the default value of the
3916  * frequency. If you want to have a more flexible control of when to execute the primal heuristic, you have to assign
3917  * a frequency of 1 and implement a check at the beginning of your execution method whether you really want to search for feasible
3918  * solutions or not. If you do not want to execute the method, set the result code to SCIP_DIDNOTRUN.
3919  *
3920  * \par HEUR_FREQOFS: the frequency offset for executing the primal heuristic.
3921  * The frequency offset defines the depth of the branching tree at which the primal heuristic is executed for the first
3922  * time. For example, a frequency of 7 (see HEUR_FREQ) together with a frequency offset of 10 means, that the
3923  * callback is executed for subproblems that are in depth 10, 17, 24, ... of the branching tree. In particular, assigning
3924  * different offset values to heuristics of the same type, like diving heuristics, can be useful for evenly spreading the
3925  * application of these heuristics across the branch-and-bound tree.
3926  * Note that if the frequency is equal to 1, the heuristic is applied for all nodes with depth level larger or equal to
3927  * the frequency offset.
3928  *
3929  * \par HEUR_MAXDEPTH: the maximal depth level for executing the primal heuristic.
3930  * This parameter denotes the maximal depth level in the branching tree up to which the execution method of the primal
3931  * heuristic is called. Use -1 for no limit (a usual case).
3932  *
3933  * \par HEUR_TIMING: the execution timing of the primal heuristic.
3934  * Primal heuristics have different entry points during the solving process and the execution timing parameter defines the
3935  * entry point at which the primal heuristic is executed first.
3936  * \n
3937  * The primal heuristic can be called first:
3938  * - before the processing of the node starts (SCIP_HEURTIMING_BEFORENODE)
3939  * - after each LP solve during the cut-and-price loop (SCIP_HEURTIMING_DURINGLPLOOP)
3940  * - after the cut-and-price loop was finished (SCIP_HEURTIMING_AFTERLPLOOP)
3941  * - after the processing of a node <em>with solved LP</em> was finished (SCIP_HEURTIMING_AFTERLPNODE)
3942  * - after the processing of a node <em>without solved LP</em> was finished (SCIP_HEURTIMING_AFTERPSEUDONODE)
3943  * - after the processing of the last node in the current plunge was finished, <em>and only if the LP was solved for
3944  * this node</em> (SCIP_HEURTIMING_AFTERLPPLUNGE)
3945  * - after the processing of the last node in the current plunge was finished, <em>and only if the LP was not solved
3946  * for this node</em> (SCIP_HEURTIMING_AFTERPSEUDOPLUNGE).
3947  * \par
3948  * A plunge is the successive solving of child and sibling nodes in the search tree.
3949  * The flags listed above can be combined to call the heuristic at multiple times by concatenating them with a bitwise OR.
3950  * Two useful combinations are already predefined:
3951  * - after the processing of a node was finished (SCIP_HEURTIMING_AFTERNODE; combines SCIP_HEURTIMING_AFTERLPNODE and
3952  * SCIP_HEURTIMING_AFTERPSEUDONODE)
3953  * - after the processing of the last node in the current plunge was finished (SCIP_HEURTIMING_AFTERPLUNGE; combines
3954  * SCIP_HEURTIMING_AFTERLPPLUNGE and SCIP_HEURTIMING_AFTERPSEUDOPLUNGE)
3955  * \par
3956  * Calling a primal heuristic "before the processing of the node starts" is particularly useful for heuristics
3957  * that do not need to access the LP solution of the current node. If such a heuristic finds a feasible solution, the
3958  * leaves of the branching tree exceeding the new primal bound are pruned. It may happen that even the current node can
3959  * be cut off without solving the LP relaxation. Combinatorial heuristics, like the farthest insert heuristic for the TSP
3960  * (see examples/TSP/src/HeurFarthestInsert.cpp), are often applicable at this point.
3961  * \n
3962  * Very fast primal heuristics that require an LP solution can also be called "after each LP solve during the
3963  * cut-and-price loop". Rounding heuristics, like the simple and fast LP rounding heuristic
3964  * (src/scip/heur_simplerounding.c), belong to this group of primal heuristics.
3965  * \n
3966  * Most heuristics, however, are called either after a node was completely processed
3967  * (e.g. expensive rounding heuristics like RENS), or even only after a full plunge was finished (e.g., diving heuristics).
3968  *
3969  * \par HEUR_USESSUBSCIP: Does the heuristic use a secondary SCIP instance?
3970  * Some heuristics and separators solve MIPs or SAT problems using a secondary SCIP instance. Examples are
3971  * Large Neighborhood Search heuristics such as RINS and Local Branching or the CGMIP separator. To avoid recursion,
3972  * these plugins usually deactivate all other plugins that solve MIPs. If a heuristic uses a secondary SCIP instance,
3973  * this parameter has to be TRUE and it is recommended to call SCIPsetSubscipsOff() for the secondary SCIP instance.
3974  *
3975  * Computational experiments indicate that for the overall performance of a MIP solver, it is important to evenly
3976  * spread the application of the heuristics across the branch-and-bound tree. Thus, the assignment of the parameters
3977  * HEUR_FREQ, HEUR_FREQOFS, and HEUR_TIMING should contribute to this aim.
3978  *
3979  * Note that all diving heuristics in the SCIP distribution (see, e.g., src/scip/heur_guideddiving.c) check whether other diving
3980  * heuristics have already been called at the current node. This can be done by comparing SCIPgetLastDivenode(scip) and
3981  * SCIPgetNNodes(scip). If the two are equal, and if the current node is not the root node (SCIPgetDepth(scip) > 0), diving
3982  * heuristics should be delayed by returning the result code 'SCIP_DELAYED'. This is an additional contribution to the goal of
3983  * not calling multiple similar heuristics at the same node.
3984  *
3985  *
3986  * @section HEUR_DATA Primal Heuristic Data
3987  *
3988  * Below the header "Data structures" you can find a struct which is called "struct SCIP_HeurData".
3989  * In this data structure, you can store the data of your primal heuristic. For example, you should store the adjustable
3990  * parameters of the primal heuristic or a working solution in this data structure.
3991  * If you are using C++, you can add primal heuristic data as usual as object variables to your class.
3992  * \n
3993  * Defining primal heuristic data is optional. You can leave the struct empty.
3994  *
3995  *
3996  * @section HEUR_INTERFACE Interface Methods
3997  *
3998  * At the bottom of "heur_myheuristic.c", you can find the interface method SCIPincludeHeurMyheuristic(),
3999  * which also appears in "heur_myheuristic.h"
4000  * SCIPincludeHeurMyheuristic() is called by the user, if (s)he wants to include the heuristic,
4001  * i.e., if (s)he wants to use the heuristic in his/her application.
4002  *
4003  * This method only has to be adjusted slightly.
4004  * It is responsible for notifying SCIP of the presence of the heuristic. For this, you can either call
4005  * SCIPincludeHeur(),
4006  * or SCIPincludeHeurBasic() since SCIP version 3.0. In the latter variant, \ref HEUR_ADDITIONALCALLBACKS "additional callbacks"
4007  * must be added via setter functions as, e.g., SCIPsetHeurCopy(). We recommend this latter variant because
4008  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
4009  * variant must be manually adjusted with every SCIP release containing new callbacks for heuristics in order to compile.
4010  *
4011  * If you are using primal heuristic data, you have to allocate the memory for the data at this point.
4012  * You can do this by calling:
4013  * \code
4014  * SCIP_CALL( SCIPallocMemory(scip, &heurdata) );
4015  * \endcode
4016  * You also have to initialize the fields in struct SCIP_HeurData afterwards.
4017  *
4018  * You may also add user parameters for your primal heuristic, see the method SCIPincludeHeurFeaspump() in
4019  * src/scip/heur_oneopt.c for an example where a single Boolean parameter is added.
4020  *
4021  *
4022  * @section HEUR_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Primal Heuristic
4023  *
4024  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
4025  * an operational algorithm.
4026  * They are passed together with the primal heuristic itself to SCIP using SCIPincludeHeur() or SCIPincludeHeurBasic(),
4027  * see @ref HEUR_INTERFACE.
4028  *
4029  *
4030  * Primal heuristic plugins have only one fundamental callback method, namely the HEUREXEC method.
4031  * This method has to be implemented for every primal heuristic; the other callback methods are optional.
4032  * In the C++ wrapper class scip::ObjHeur, the scip_exec() method (which corresponds to the HEUREXEC callback) is a virtual
4033  * abstract member function. You have to implement it in order to be able to construct an object of your primal heuristic
4034  * class.
4035  *
4036  * Additional documentation for the callback methods can be found in type_heur.h.
4037  *
4038  * @subsection HEUREXEC
4039  *
4040  * The HEUREXEC callback is called at different positions during the node processing loop, see HEUR_TIMING. It should
4041  * search for feasible solutions and add them to the solution pool. For creating a new feasible solution, the
4042  * methods SCIPcreateSol() and SCIPsetSolVal() can be used. Afterwards, the solution can be added to the storage by
4043  * calling the method SCIPtrySolFree() (or SCIPtrySol() and SCIPfreeSol()).
4044  *
4045  * The HEUREXEC callback gets a SCIP pointer, a pointer to the heuristic itself, the current point in the
4046  * solve loop and a result pointer as input (see type_heur.h).
4047  *
4048  * The heuristic has to set the result pointer appropriately!
4049  * Therefore it has the following options:
4050  * - finding at least one feasible solution (result SCIP_FOUNDSOL)
4051  * - stating that the primal heuristic searched, but did not find a feasible solution (result SCIP_DIDNOTFIND)
4052  * - stating that the primal heuristic was skipped (result SCIP_DIDNOTRUN)
4053  * - stating that the primal heuristic was skipped, but should be called again (result SCIP_DELAYED).
4054  *
4055  *
4056  * @section HEUR_ADDITIONALCALLBACKS Additional Callback Methods of a Primal Heuristic
4057  *
4058  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
4059  * implemented for most applications, they can be used, for example, to initialize and free private data.
4060  * Additional callbacks can either be passed directly with SCIPincludeHeur() to SCIP or via specific
4061  * <b>setter functions</b> after a call of SCIPincludeHeurBasic(), see also @ref HEUR_INTERFACE.
4062  *
4063  * @subsection HEURFREE
4064  *
4065  * If you are using primal heuristic data, you have to implement this method in order to free the primal heuristic data.
4066  * This can be done by the following procedure:
4067  * \code
4068  * static
4069  * SCIP_DECL_HEURFREE(heurFreeMyheuristic)
4070  * {
4071  * SCIP_HEURDATA* heurdata;
4072  *
4073  * heurdata = SCIPheurGetData(heur);
4074  * assert(heurdata != NULL);
4075  *
4076  * SCIPfreeMemory(scip, &heurdata);
4077  *
4078  * SCIPheurSetData(heur, NULL);
4079  *
4080  * return SCIP_OKAY;
4081  * }
4082  * \endcode
4083  * If you have allocated memory for fields in your primal heuristic data, remember to free this memory
4084  * before freeing the primal heuristic data itself.
4085  * If you are using the C++ wrapper class, this method is not available.
4086  * Instead, just use the destructor of your class to free the member variables of your class.
4087  *
4088  * @subsection HEURINIT
4089  *
4090  * The HEURINIT callback is executed after the problem is transformed.
4091  * The primal heuristic may, e.g., use this call to initialize its primal heuristic data.
4092  *
4093  * @subsection HEURCOPY
4094  *
4095  * The HEURCOPY callback is executed when a SCIP instance is copied, e.g. to
4096  * solve a sub-SCIP. By
4097  * defining this callback as
4098  * <code>NULL</code> the user disables the execution of the specified
4099  * heuristic for all copied SCIP instances. This may deteriorate the performance
4100  * of primal heuristics using sub-SCIPs.
4101  *
4102  * @subsection HEUREXIT
4103  *
4104  * The HEUREXIT callback is executed before the tDIVINGHEURransformed problem is freed.
4105  * In this method, the primal heuristic should free all resources that have been allocated for the solving process in
4106  * HEURINIT.
4107  *
4108  * @subsection HEURINITSOL
4109  *
4110  * The HEURINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
4111  * begin. The primal heuristic may use this call to initialize its branch-and-bound specific data.
4112  *
4113  * @subsection HEUREXITSOL
4114  *
4115  * The HEUREXITSOL callback is executed before the branch-and-bound process is freed. The primal heuristic should use this
4116  * call to clean up its branch-and-bound data, which was allocated in HEURINITSOL.
4117  */
4118 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
4119 
4120 /**@page DIVINGHEUR How to implement a diving heuristic
4121  *
4122  * Diving heuristics are an important addon to the branch-and-cut search. A diving heuristic explores a single probing
4123  * path down the search tree. In contrast to the regular search guided by branching rule(s) and the selected
4124  * node selector, the diving is performed in an auxiliary tree originating from the focus node of the main
4125  * search tree where the heuristic was called. The advantage of this approach is that many different scoring mechanisms
4126  * can be safely tried as diving heuristic and may probably lead to better solutions. SCIP has a lot of diving heuristics
4127  * included in its default plugin set.
4128  * \n
4129  *
4130  * Since SCIP version 3.2, the diving heuristics have been redesigned to contain mainly the scoring function used by the
4131  * heuristic. In order to implement a user-defined diving heuristic, it is possible to create one (or several)
4132  * divesets that control the scoring mechanism and add them to the primal heuristic. This has the advantage that
4133  * less code is necessary to create a working diving heuristic. The SCIP statistics now also display some interesting statistics
4134  * about every diveset together in the section 'Diving Statistics'.
4135  * \n
4136  *
4137  * This page contains the necessary steps to understand and include a diveset into ones primal diving heuristic plugin. As
4138  * a prerequisite, you should understand the basic implementation steps for a primal heuristic, see \ref HEUR.
4139  * In order to make use of divesets, they must be included _after_ the primal heuristic to which they should belong
4140  * has been included, by using SCIPincludeDiveset(). This will create the data structure for the diveset and
4141  * append it to the list of divesets belonging to the heuristic, which can be retrieved later together with their number
4142  * by using SCIPheurGetDivesets() and SCIPheurGetNDivesets(), respectively. No further memory allocation or deletion is needed;
4143  * As a member of the heuristic, SCIP automatically takes care of freeing the diveset when it is exiting.
4144  * \n
4145  *
4146  * Before the inclusion, one may think of adjusting the various properties that a diveset offers to control
4147  * the behavior of the algorithm. These are subject to the following section.
4148  * \n
4149  *
4150  * It is mandatory to implement the fundamental scoring callback of the diveset, which is explained in more detail
4151  * in Section \ref DIVING_FUNDAMENTALCALLBACKS.
4152  * \n
4153  *
4154  * Once the properties have been carefully adjusted and the scoring
4155  * has been defined, use the method SCIPperformGenericDivingAlgorithm() inside the execution callback (\ref HEUREXEC) of the primal
4156  * heuristic to which the diveset belongs, after checking possible preliminaries that may not be met at all times of the search.
4157  * \n
4158  *
4159  * For a code example, we refer to \ref heur_guideddiving.h, which guides the diving into the direction of the current incumbent solution.
4160  * Before it calls SCIPperformGenericDivingAlgorithm(), it checks whether an incumbent is available, and returns if there is none.
4161  *
4162  *
4163  * @section DIVING_PARAMETERS User parameters and properties for every diveset
4164  *
4165  * Every diveset controls the diving behavior through a set of user-defined parameters, which are explained in the following:
4166  *
4167  * \par MINRELDEPTH
4168  * the minimal relative depth (to the maximum depth explored during regular search) of the current focus node to start diving
4169  *
4170  * \par MAXRELDEPTH
4171  * the maximal relative depth (to the maximum depth explored during regular search) of the current focus node to start diving
4172  *
4173  * \par MAXLPITERQUOT
4174  * maximal fraction of diving LP iterations compared to node LP iterations that this dive controller may consume
4175  *
4176  * \par MAXLPITEROFS
4177  * an additional number of allowed LP iterations
4178  *
4179  * \par MAXDIVEUBQUOT
4180  * maximal quotient (curlowerbound - lowerbound)/(cutoffbound - lowerbound)
4181  * where diving is performed (0.0: no limit)
4182  *
4183  * \par MAXDIVEAVGQUOT
4184  * maximal quotient (curlowerbound - lowerbound)/(avglowerbound - lowerbound)
4185  * where diving is performed (0.0: no limit)
4186  *
4187  * \par MAXDIVEUBQUOTNOSOL
4188  * maximal UBQUOT when no solution was found yet (0.0: no limit)
4189  *
4190  * \par MAXDIVEAVGQUOTNOSOL
4191  * maximal AVGQUOT when no solution was found yet (0.0: no limit)
4192  *
4193  * \par BACKTRACK
4194  * use one level of backtracking if infeasibility is encountered?
4195  *
4196  * \par LPRESOLVEDOMCHGQUOT
4197  * parameter to control LP resolve dynamically based on this percentage of observed bound changes relative to all variables or
4198  * the LP branching candidates (integer variables with fractional solution values) from the last node where an LP has been solved.
4199  * This property has no effect when the LPSOLVEFREQ is set to 1.
4200  *
4201  * \par LPSOLVEFREQ
4202  * 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
4203  * diveset to solve _all_ intermediate LPs) or 0 to only resolve the LP relaxation after propagation found at least a certain percentage
4204  * domain changes, see also the previous LPRESOLVEDOMCHGQUOT parameter.
4205  *
4206  * \par ONLYLPBRANCHCANDS
4207  * Set this property to TRUE if only LP branching candidates be considered for the execution of the diving algorithm instead of the slower but
4208  * more general constraint handler diving variable selection.
4209  *
4210  * \par DIVETYPES
4211  * bit mask that represents all supported dive types. Irrelevant if only LP branching candidates should be scored, otherwise, different
4212  * constraint handlers may ask the diveset if it supports their preferred divetype. See \ref type_heur.h for a list of
4213  * available dive types.
4214  *
4215  * @section DIVING_FUNDAMENTALCALLBACKS Fundamental callbacks of a diveset
4216  *
4217  * Only one callback is necessary to complete a diveset to guide the diving search performed:
4218  *
4219  * @subsection DIVESETGETSCORE
4220  *
4221  * The scoring callback expects a candidate variable and calculates a score value and a preferred direction. The selected
4222  * variable for diving will be one that _maximizes_ the score function provided by the diveset.
4223  * If the diveset should support more than one possible type of diving, it may use the divetype argument as a hint how
4224  * the caller of the score function (could be the diving algorithm itself or one of the constraint handlers that
4225  * implement diving variable selection) intends to perform the search.
4226  *
4227  * @section DIVING_FURTHERINFO Further information
4228  *
4229  * This is all there is to extend the SCIP set of diving heuristics by a new one. For further information, please see
4230  * diveset related methods in \ref type_heur.h, \ref pub_heur.h, \ref pub_dive.h, and \ref heur_guideddiving.h or
4231  * other diving heuristics that implement diving through a diveset.
4232  */
4233 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
4234 
4235 /**@page RELAX How to add relaxation handlers
4236  *
4237  * SCIP provides specific support for LP relaxations of constraint integer programs. In addition, relaxation handlers,
4238  * also called relaxators, can be used to include other relaxations, e.g. Lagrange relaxations or semidefinite
4239  * relaxations. The relaxation handler manages the necessary data structures and calls the relaxation solver to generate dual
4240  * bounds and primal solution candidates.
4241  * \n
4242  * However, the data to define a single relaxation must either be extracted by the relaxation handler itself (e.g., from
4243  * the user defined problem data, the LP information, or the integrality conditions), or be provided by the constraint
4244  * handlers. In the latter case, the constraint handlers have to be extended to support this specific relaxation.
4245  * \n
4246  *
4247  * We now explain how users can add their own relaxation handlers using the C interface. It is very easy to
4248  * transfer the C explanation to C++: whenever a method should be implemented using the SCIP_DECL_RELAX... notion,
4249  * reimplement the corresponding virtual member function of the abstract scip::ObjRelax wrapper base class.
4250  * Unfortunately, SCIP does not contain a default relaxation handler plugin, which could be used as an example.
4251  *
4252  * Additional documentation for the callback methods of a relaxation handler can be found in the file type_relax.h.
4253  *
4254  * Here is what you have to do to implement a relaxation handler:
4255  * -# Copy the template files src/scip/relax_xyz.c and src/scip/relax_xyz.h into files named "relax_myrelaxator.c"
4256  * and "relax_myrelaxator.h".
4257  * \n
4258  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
4259  * -# Use SCIPincludeRelaxMyrelaxator() in order to include the relaxation handler into your SCIP instance,
4260  * e.g, in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
4261  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "myrelaxator".
4262  * -# Adjust the properties of the relaxation handler (see \ref RELAX_PROPERTIES).
4263  * -# Define the relaxation handler data (see \ref RELAX_DATA). This is optional.
4264  * -# Implement the interface methods (see \ref RELAX_INTERFACE).
4265  * -# Implement the fundamental callback methods (see \ref RELAX_FUNDAMENTALCALLBACKS).
4266  * -# Implement the additional callback methods (see \ref RELAX_ADDITIONALCALLBACKS). This is optional.
4267  *
4268  *
4269  * @section RELAX_PROPERTIES Properties of a Relaxation Handler
4270  *
4271  * At the top of the new file "relax_myrelaxator.c" you can find the relaxation handler properties.
4272  * These are given as compiler defines.
4273  * In the C++ wrapper class, you have to provide the relaxation handler properties by calling the constructor
4274  * of the abstract base class scip::ObjRelax from within your constructor.
4275  * The properties you have to set have the following meaning:
4276  *
4277  * \par RELAX_NAME: the name of the relaxation handler.
4278  * This name is used in the interactive shell to address the relaxation handler.
4279  * Additionally, if you are searching for a relaxation handler with SCIPfindRelax(), this name is looked up.
4280  * Names have to be unique: no two relaxation handlers may have the same name.
4281  *
4282  * \par RELAX_DESC: the description of the relaxation handler.
4283  * This string is printed as a description of the relaxation handler in the interactive shell.
4284  *
4285  * \par RELAX_PRIORITY: the priority of the relaxation handler.
4286  * During each relaxation solving round, the included relaxation handlers and the
4287  * price-and-cut loop for solving the LP relaxation are called in a predefined order, which is given by the priorities
4288  * of the relaxation handlers.
4289  * First, the relaxation handlers with non-negative priority are called in the order of decreasing priority.
4290  * Next, the price-and-cut loop for solving the LP relaxation is executed.
4291  * Finally, the relaxation handlers with negative priority are called in the order of decreasing priority.
4292  * \n
4293  * Usually, you will have only one relaxation handler in your application and thus only have to decide whether it should
4294  * be called before or after solving the LP relaxation. For this decision you should consider the complexity of
4295  * the relaxation solving algorithm and the impact of the resulting solution: if your relaxation handler provides a fast
4296  * algorithm that usually has a high impact (i.e. the relaxation is a good approximation of the
4297  * feasible region of the subproblem and the solution severely improves the dual bound), it should have a non-negative
4298  * priority.
4299  * \n
4300  * Note that for certain applications, it is useful to disable the LP relaxation and only use your custom relaxation.
4301  * This can easily be achieved by setting the "lp/solvefreq" parameter to -1.
4302  *
4303  * \par RELAX_FREQ: the default frequency for solving the relaxation.
4304  * The frequency defines the depth levels at which the relaxation solving method \ref RELAXEXEC is called.
4305  * For example, a frequency of 7 means, that the relaxation solving callback is executed for subproblems that are in depth
4306  * 0, 7, 14, ... of the branching tree. A frequency of 0 means that the callback is only executed at the root node, i.e.,
4307  * only the relaxation of the root problem is solved. A frequency of -1 disables the relaxation handler.
4308  *
4309  *
4310  * @section RELAX_DATA Relaxation Handler Data
4311  *
4312  * Below the header "Data structures" you can find a struct which is called "struct SCIP_RelaxData".
4313  * In this data structure, you can store the data of your relaxation handler. For example, you should store the adjustable
4314  * parameters of the relaxation handler in this data structure.
4315  * If you are using C++, you can add relaxation handler data as usual as object variables to your class.
4316  * \n
4317  * Defining relaxation handler data is optional. You can leave the struct empty.
4318  *
4319  *
4320  * @section RELAX_INTERFACE Interface Methods
4321  *
4322  * At the bottom of "relax_myrelaxator.c", you can find the interface method SCIPincludeRelaxMyrelaxator(),
4323  * which also appears in "relax_myrelaxator.h".
4324  * SCIPincludeRelaxMyrelaxator() is called by the user, if (s)he wants to include the relaxation handler,
4325  * i.e., if (s)he wants to use the relaxation handler in his/her application.
4326  *
4327  * This method only has to be adjusted slightly.
4328  * It is responsible for notifying SCIP of the presence of the relaxation handler. For this, you can either call
4329  * SCIPincludeRelax(),
4330  * or SCIPincludeRelaxBasic() since SCIP version 3.0. In the latter variant, \ref RELAX_ADDITIONALCALLBACKS "additional callbacks"
4331  * must be added via setter functions as, e.g., SCIPsetRelaxCopy(). We recommend this latter variant because
4332  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
4333  * variant must be manually adjusted with every SCIP release containing new callbacks for relaxation handlers in order to compile.
4334  *
4335  * If you are using relaxation handler data, you have to allocate the memory for the data at this point.
4336  * You can do this by calling:
4337  * \code
4338  * SCIP_CALL( SCIPallocMemory(scip, &relaxdata) );
4339  * \endcode
4340  * You also have to initialize the fields in struct SCIP_RelaxData afterwards.
4341  *
4342  * You may also add user parameters for your relaxation handler, see the method SCIPincludeConshdlrKnapsack() in
4343  * the \ref cons_knapsack.h "knapsack constraint handler" for an example of how to add user parameters.
4344  *
4345  *
4346  * @section RELAX_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Relaxation Handler
4347  *
4348  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
4349  * an operational algorithm.
4350  * They are passed together with the relaxation handler itself to SCIP using SCIPincludeRelax() or SCIPincludeRelaxBasic(),
4351  * see @ref RELAX_INTERFACE.
4352  *
4353  *
4354  * Relaxation handler plugins have only one fundamental callback method, namely the \ref RELAXEXEC method.
4355  * This method has to be implemented for every relaxation handler; the other callback methods are optional.
4356  * In the C++ wrapper class scip::ObjRelax, the scip_exec() method (which corresponds to the \ref RELAXEXEC callback) is a virtual
4357  * abstract member function.
4358  * You have to implement it in order to be able to construct an object of your relaxation handler class.
4359  *
4360  * Additional documentation for the callback methods can be found in type_relax.h.
4361  *
4362  * @subsection RELAXEXEC
4363  * The RELAXEXEC is called in each relaxation solving round. It should solve the current
4364  * subproblem's relaxation.
4365  *
4366  * Note that, like the LP relaxation, the relaxation handler should only operate on variables for which the corresponding
4367  * column exists in the transformed problem. Typical methods called by a relaxation handler are SCIPconstructLP() and SCIPflushLP() to
4368  * make sure that the LP of the current node is constructed and its data can be accessed via calls to SCIPgetLPRowsData()
4369  * and SCIPgetLPColsData(), SCIPseparateSol() to call the cutting plane separators for a given primal solution, and
4370  * SCIPupdateLocalLowerbound() to update the current node's dual bound after having solved the relaxation.
4371  * In addition, you may want to call SCIPtrySolFree() if you think that you have found a feasible primal solution.
4372  *
4373  * The primal solution of the relaxation can be stored inside the data structures of SCIP with
4374  * <code>SCIPsetRelaxSolVal()</code> and <code>SCIPsetRelaxSolVals()</code> and later accessed by
4375  * <code>SCIPgetRelaxSolVal()</code>.
4376  * Furthermore, there is a list of external branching candidates, that can be filled by relaxation handlers and constraint handlers,
4377  * allowing branching rules to take these candidates as a guide on how to split the problem into subproblems.
4378  * Relaxation handlers should store appropriate candidates in this list using the method <code>SCIPaddExternBranchCand()</code>.
4379  *
4380  * Usually, the RELAXEXEC callback only solves the relaxation and provides a lower (dual) bound with a call to
4381  * SCIPupdateLocalLowerbound().
4382  * However, it may also produce domain reductions, add additional constraints or generate cutting planes. It has the
4383  * following options:
4384  * - detecting that the node is infeasible in the variable's bounds and can be cut off (result SCIP_CUTOFF)
4385  * - adding an additional constraint and stating that the relaxation handler should not be called again on the same
4386  * relaxation (result SCIP_CONSADDED)
4387  * - reducing a variable's domain and stating that the relaxation handler should not be called again on the same
4388  * relaxation (result SCIP_REDUCEDDOM)
4389  * - adding a cutting plane to the LP and stating that the relaxation handler should not be called again on the same
4390  * relaxation (result SCIP_SEPARATED)
4391  * - stating that the relaxation handler solved the relaxation and should not be called again on the same relaxation
4392  * (result SCIP_SUCCESS)
4393  * - interrupting the solving process to wait for additional input, e.g., cutting planes (result SCIP_SUSPENDED)
4394  * - stating that the separator was skipped (result SCIP_DIDNOTRUN).
4395  *
4396  * In the above criteria, "the same relaxation" means that the LP relaxation stayed unmodified. This means in particular
4397  * that no row has been added and no bounds have been modified. For example, changing the bounds of a variable will, as
4398  * long as it was a COLUMN variable, lead to a modification in the LP such that the relaxation handler is called again
4399  * after it returned with the result code SCIP_REDUCEDDOM.
4400  *
4401  *
4402  * @section RELAX_ADDITIONALCALLBACKS Additional Callback Methods of a Relaxation Handler
4403  *
4404  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
4405  * implemented for most applications, they can be used, for example, to initialize and free private data.
4406  * Additional callbacks can either be passed directly with SCIPincludeRelax() to SCIP or via specific
4407  * <b>setter functions</b> after a call of SCIPincludeRelaxBasic(), see also @ref RELAX_INTERFACE.
4408  *
4409  * @subsection RELAXFREE
4410  *
4411  * If you are using relaxation handler data, you have to implement this method in order to free the relaxation handler
4412  * data. This can be done by the following procedure:
4413  * \code
4414  * static
4415  * SCIP_DECL_RELAXFREE(relaxFreeMyrelaxator)
4416  * {
4417  * SCIP_RELAXDATA* relaxdata;
4418  *
4419  * relaxdata = SCIPrelaxGetData(relax);
4420  * assert(relaxdata != NULL);
4421  *
4422  * SCIPfreeMemory(scip, &relaxdata);
4423  *
4424  * SCIPrelaxSetData(relax, NULL);
4425  *
4426  * return SCIP_OKAY;
4427  * }
4428  * \endcode
4429  * If you have allocated memory for fields in your relaxation handler data, remember to free this memory
4430  * before freeing the relaxation handler data itself.
4431  * If you are using the C++ wrapper class, this method is not available.
4432  * Instead, just use the destructor of your class to free the member variables of your class.
4433  *
4434  * @subsection RELAXINIT
4435  *
4436  * The RELAXINIT callback is executed after the problem is transformed.
4437  * The relaxation handler may, e.g., use this call to initialize its relaxation handler data.
4438  *
4439  * @subsection RELAXCOPY
4440  *
4441  * The RELAXCOPY callback is executed when a SCIP instance is copied, e.g. to
4442  * solve a sub-SCIP. By
4443  * defining this callback as
4444  * <code>NULL</code> the user disables the execution of the specified
4445  * relaxation handler for all copied SCIP instances. This may deteriorate the performance
4446  * of primal heuristics using sub-SCIPs.
4447  *
4448  * @subsection RELAXEXIT
4449  *
4450  * The RELAXEXIT callback is executed before the transformed problem is freed.
4451  * In this method, the relaxation handler should free all resources that have been allocated for the solving process in
4452  * RELAXINIT.
4453  *
4454  * @subsection RELAXINITSOL
4455  *
4456  * The RELAXINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
4457  * begin. The relaxation handler may use this call to initialize its branch-and-bound specific data.
4458  *
4459  * @subsection REALXEXITSOL
4460  *
4461  * The RELAXEXITSOL callback is executed before the branch-and-bound process is freed.
4462  * The relaxation handler should use this call to clean up its branch-and-bound data.
4463  */
4464 
4465 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
4466 /**@page READER How to add file readers
4467  *
4468  * Mainly, file readers are called to parse an input file and generate a constraint integer programming model. They
4469  * create constraints and variables and activate variable pricers if necessary. However, they can also be called, for
4470  * example, to parse an input file containing information about a primal solution or fixing of variables. Besides that
4471  * it is possible to use some of them for writing (exporting) the problem in a specific format. \n A complete list of
4472  * all file readers contained in this release can be found \ref FILEREADERS "here".
4473  *
4474  * Since a file reader is also responsible for writing a file, the user may
4475  * ask why the readers have not the name "filehandler". This name would
4476  * represent this plugin much better than the used one.
4477  * \n
4478  * The used name "readers" is historically grown. In the beginning of SCIP
4479  * there was no need to write/export problems. Therefore, the the plugin
4480  * name "readers" was best fitting for this plugin since only reading was essential.
4481  * It turned out, however, that it is quite nice to write/export certain subproblem during
4482  * the solving process mainly for debugging. Therefore, a writing callback
4483  * was added to the "readers" plugin.
4484  *
4485  * We now explain how users can add their own file readers.
4486  * Take the file reader for MIPs in IBM's Mathematical Programming System format (src/scip/reader_mps.c) as an example.
4487  * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjReader wrapper
4488  * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_READER... callback methods.
4489  *
4490  * Additional documentation for the callback methods of a file reader can be found in the file type_reader.h.
4491  *
4492  * Here is what you have to do to implement a file reader named "myreader" in C:
4493  * -# Copy the template files src/scip/reader_xyz.c and src/scip/reader_xyz.h into files named
4494  * "reader_myreader.c" and "reader_myreader.h".
4495  * \n
4496  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
4497  * -# Use SCIPincludeReaderMyreader() in order to include the file reader into your SCIP instance,
4498  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
4499  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "myreader".
4500  * -# Adjust the \ref READER_PROPERTIES "properties of the file reader".
4501  * -# Define the \ref READER_DATA "file reader data". This is optional.
4502  * -# Implement the \ref READER_INTERFACE "interface methods".
4503  * -# Implement the \ref READER_FUNDAMENTALCALLBACKS "fundamental callback methods".
4504  * -# Implement the \ref READER_ADDITIONALCALLBACKS "additional callback methods". This is optional.
4505  *
4506  *
4507  * @section READER_PROPERTIES Properties of a File Reader
4508  *
4509  * At the top of the new file "reader_myreader.c" you can find the file reader properties.
4510  * These are given as compiler defines.
4511  * In the C++ wrapper class, you have to provide the file reader properties by calling the constructor
4512  * of the abstract base class scip::ObjReader from within your constructor.
4513  * The properties you have to set have the following meaning:
4514  *
4515  * \par READER_NAME: the name of the file reader.
4516  * This name is used in the interactive shell to address the file reader.
4517  * Additionally, if you are searching for a file reader with SCIPfindReader(), this name is looked up.
4518  * Names have to be unique: no two file readers may have the same name.
4519  *
4520  * \par READER_DESC: the description of the file reader.
4521  * This string is printed as a description of the file reader in the interactive shell.
4522  *
4523  * \par READER_EXTENSION: the file name extension of the file reader.
4524  * Each file reader is hooked to a single file name extension. It is automatically called if the user wants to read in a
4525  * file of corresponding name. The extensions of the different file readers have to be unique.
4526  * Note that the additional extension '.gz', '.z', or '.Z' (indicating a gzip compressed file) are ignored for assigning
4527  * an input file to a reader.
4528  * \n
4529  * It is not possible to hook up a (single) file reader with more than one file extension.
4530  * It is, however, not necessary to implement the same (parsing/writing) methods more than once, if you want to
4531  * support several file extension with the same parser. To do so look at the files reader_lp.c
4532  * and reader_rlp.c. Both support the LP format.
4533  *
4534  *
4535  * @section READER_DATA File Reader Data
4536  *
4537  * Below the header "Data structures" you can find a struct which is called "struct SCIP_ReaderData".
4538  * In this data structure, you can store the data of your file reader. For example, you should store the adjustable
4539  * parameters of the file reader in this data structure.
4540  * If you are using C++, you can add file reader data as usual as object variables to your class.
4541  * \n
4542  * Defining file reader data is optional. You can leave the struct empty.
4543  *
4544  *
4545  * @section READER_INTERFACE Interface Methods
4546  *
4547  * At the bottom of "reader_myreader.c", you can find the interface method SCIPincludeReaderMyreader(),
4548  * which also appears in "reader_myreader.h".
4549  * SCIPincludeReaderMyreader() is called by the user, if (s)he wants to include the reader,
4550  * i.e., if (s)he wants to use the reader in his/her application.
4551  *
4552  * This method only has to be adjusted slightly.
4553  * It is responsible for notifying SCIP of the presence of the reader. For this, you can either call
4554  * SCIPincludeReader(),
4555  * or SCIPincludeReaderBasic() since SCIP version 3.0. In the latter variant, \ref READER_ADDITIONALCALLBACKS "additional callbacks"
4556  * must be added via setter functions as, e.g., SCIPsetReaderCopy(). We recommend this latter variant because
4557  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
4558  * variant must be manually adjusted with every SCIP release containing new callbacks for readers in order to compile.
4559  *
4560  * If you are using file reader data, you have to allocate the memory for the data at this point.
4561  * You can do this by calling:
4562  * \code
4563  * SCIP_CALL( SCIPallocMemory(scip, &readerdata) );
4564  * \endcode
4565  * You also have to initialize the fields in struct SCIP_ReaderData afterwards.
4566  *
4567  * You may also add user parameters for your file reader, see the method SCIPincludeReaderLp() in
4568  * src/scip/reader_lp.c for an example.
4569  *
4570  *
4571  * @section READER_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a File Reader
4572  *
4573  * File reader plugins have no fundamental callback methods. This is due to
4574  * the fact that a file reader can be used for reading and/or writing a
4575  * file. A file reader is only useful if the reader method \ref READERREAD
4576  * and/or the writing method \ref READERWRITE is implemented. One of these
4577  * methods should be implemented for every file reader; the other callback
4578  * methods \ref READERCOPY and \ref READERFREE are optional. In the C++ wrapper class scip::ObjReader, the
4579  * scip_read() and scip_write() methods (which corresponds to the \ref
4580  * READERREAD and \ref READERWRITE callback) are virtual member
4581  * functions. At least one of them should be implemented.
4582  *
4583  * Additional documentation for the callback methods can be found in type_reader.h.
4584  *
4585  *
4586  * @section READER_ADDITIONALCALLBACKS Additional Callback Methods of a File Reader
4587  *
4588  * Additional callbacks can either be passed directly with SCIPincludeReader() to SCIP or via specific
4589  * <b>setter functions</b> after a call of SCIPincludeReaderBasic(), see also @ref READER_INTERFACE.
4590  *
4591  *
4592  * File reader plugins contain only additional callback methods, namely the methods \ref READERREAD,
4593  * \ref READERWRITE, \ref READERFREE, and \ref READERCOPY. Therefore, these are not needed to be implemented. However,
4594  * at least \ref READERREAD and/or \ref READERWRITE should be implemented (see notes
4595  * \ref READER_FUNDAMENTALCALLBACKS "above").
4596  *
4597  *
4598  * @subsection READERREAD
4599  *
4600  * The READERREAD callback is called when the user invokes SCIP to read in a file with file name extension
4601  * corresponding to the READER_EXTENSION property of the file reader. This is usually triggered by a call to the method
4602  * SCIPreadProb() or by an interactive shell command.
4603  * The READERREAD callback should parse the input file and perform the desired action, which usually means
4604  * generating a constraint integer programming model, adding a primal solution, fixing variables
4605  * in an existing model.
4606  * \n
4607  * Typical methods called by a file reader that is used to read/generate constraint
4608  * integer programming models are, for example,
4609  *
4610  * - creating an empty problem: SCIPcreateProb()
4611  * - creating the variables: SCIPcreateVar(), SCIPchgVarType(), SCIPchgVarLb(), SCIPchgVarUb(), SCIPaddVar(), and
4612  * SCIPreleaseVar()
4613  * - modifying the objective function: SCIPchgVarObj() and SCIPsetObjsense().
4614  * - creating the constraints: SCIPcreateConsLinear(), SCIPaddCoefLinear(), SCIPchgLhsLinear(), SCIPchgRhsLinear(),
4615  * SCIPaddCons(), and SCIPreleaseCons()
4616  *
4617  * Primal solutions can only be created for the transformed problem. Therefore, the user has to call SCIPtransformProb()
4618  * before (s)he reads in the file containing the solution and adds it to the solution pool via the method SCIPreadSol().
4619  *
4620  *
4621  * @subsection READERWRITE
4622  *
4623  * The READERWRITE callback is called when the user invokes SCIP to write a problem (original or transformed)
4624  * in the format the reader supports. This is only possible if this callback is implemented. To write the problem
4625  * all necessary information is given through the parameters of this callback method (see type_reader.h). This
4626  * information should be used to output the problem in the requested format. This callback method is usually
4627  * triggered by the call of the methods SCIPwriteOrigProblem(), SCIPwriteTransProblem(), SCIPprintOrigProblem(),
4628  * or SCIPprintTransProblem().
4629  * \n
4630  * A typical method called by a file reader which is used to write/export a constraint
4631  * integer programming model is SCIPinfoMessage(). This method outputs a given string into a file
4632  * or into stdout.
4633  * \n
4634  * For an example we refer to the writing method of the MPS reader (see reader_mps.c).
4635  *
4636  *
4637  * @subsection READERCOPY
4638  *
4639  * The READERCOPY callback is executed when a SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this
4640  * callback as <code>NULL</code> the user disables the execution of the specified reader for all copied SCIP
4641  * instances. The question might arise why to copy that plugin. In case of debugging it is nice to be able to
4642  * write/display the copied instances. Since the reader is in charge of that, you might want to copy the plugin. Below
4643  * you see a standard implementation.
4644  *
4645  * \code
4646  * static
4647  * SCIP_DECL_READERCOPY(readerCopyMyreader)
4648  * {
4649  * assert(scip != NULL);
4650  * assert(reader != NULL);
4651  * assert(strcmp(SCIPreaderGetName(reader), READER_NAME) == 0);
4652  *
4653  * SCIP_CALL( SCIPincludeReaderMyreader(scip) );
4654  *
4655  * return SCIP_OKAY;
4656  * }
4657  * \endcode
4658  *
4659  * @subsection READERFREE
4660  *
4661  * If you are using file reader data, you have to implement this method in order to free the file reader data.
4662  * This can be done by the following procedure:
4663  * \code
4664  * static
4665  * SCIP_DECL_READERFREE(readerFreeMyreader)
4666  * {
4667  * SCIP_READERDATA* readerdata;
4668  *
4669  * readerdata = SCIPreaderGetData(reader);
4670  * assert(readerdata != NULL);
4671  *
4672  * SCIPfreeMemory(scip, &readerdata);
4673  *
4674  * SCIPreaderSetData(reader, NULL);
4675  *
4676  * return SCIP_OKAY;
4677  * }
4678  * \endcode
4679  * If you have allocated memory for fields in your file reader data, remember to free this memory
4680  * before freeing the file reader data itself.
4681  * If you are using the C++ wrapper class, this method is not available.
4682  * Instead, just use the destructor of your class to free the member variables of your class.
4683  *
4684  */
4685 
4686 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
4687 /**@page DIALOG How to add dialogs
4688  *
4689  * SCIP comes with a command line shell which allows the user to read in problem instances, modify the solver's
4690  * parameters, initiate the optimization and display certain statistics and solution information. This shell consists
4691  * of dialogs, which are organized as a tree in SCIP. A node of this tree which is not a leaf represents a menu in
4692  * the shell and the children of this node correspond to the entries of this menu (which can again be menus). All
4693  * different dialogs are managed by a dialog handler, which, in particular, is responsible for executing the dialog
4694  * corresponding to the user's command in the shell. The concept of a dialog handler is different to that
4695  * of a constraint handler, which is used to manage objects of the same structure, see \ref CONS. In particular, SCIP
4696  * features only one dialog handler (dialog_default.h), whereas there may exist different constraint handlers.
4697  * \n
4698  * A complete list of all dialogs contained in this release can be found \ref DIALOGS "here".
4699  *
4700  * We now explain how users can extend the interactive shell by adding their own dialog.
4701  * We give the explanation for creating your own source file for each additional dialog. Of course, you can collect
4702  * different dialogs in one source file. Take src/scip/dialog_default.c, where all default dialog plugins are collected, as an
4703  * example.
4704  * As all other default plugins, the default dialog plugin and the template dialog are written in C. C++ users can easily
4705  * adapt the code by using the scip::ObjDialog wrapper base class and implement the scip_...() virtual methods instead of the
4706  * SCIP_DECL_DIALOG... callback methods.
4707  *
4708  * Additional documentation for the callback methods of a dialog can be found in the file type_dialog.h.
4709  *
4710  * Here is what you have to do to add a dialog (assuming your dialog is named "mydialog"):
4711  * -# Copy the template files src/scip/dialog_xyz.c and src/scip/dialog_xyz.h into files named "dialog_mydialog.c"
4712  * and "dialog_mydialog.h".
4713  * \n
4714  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
4715  * -# Use SCIPincludeDialogMydialog() in order to include the dialog handler into your SCIP instance,
4716  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
4717  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mydialog".
4718  * -# Adjust the \ref DIALOG_PROPERTIES "properties of the dialog".
4719  * -# Define the \ref DIALOG_DATA "dialog data". This is optional.
4720  * -# Implement the \ref DIALOG_INTERFACE "interface methods".
4721  * -# Implement the \ref DIALOG_FUNDAMENTALCALLBACKS "fundamental callback methods".
4722  * -# Implement the \ref DIALOG_ADDITIONALCALLBACKS "additional callback methods". This is optional.
4723  *
4724  *
4725  * @section DIALOG_PROPERTIES Properties of a Dialog
4726  *
4727  * At the top of the new file "dialog_mydialog.c" you can find the dialog properties.
4728  * These are given as compiler defines.
4729  * In the C++ wrapper class, you have to provide the dialog properties by calling the constructor
4730  * of the abstract base class scip::ObjDialog from within your constructor.
4731  * The properties you have to set have the following meaning:
4732  *
4733  * \par DIALOG_NAME: the name of the dialog.
4734  * In the interactive shell, this name appears as the command name of the dialog in the parent dialog.
4735  * Additionally, if you are searching an entry in a menu with SCIPdialogFindEntry(), this name is looked up.
4736  * Names within one menu have to be unique: no two dialogs in the same menu may have the same name.
4737  *
4738  * \par DIALOG_DESC: the description of the dialog.
4739  * This string is printed as a description of the dialog in the interactive shell if the additional
4740  * callback method \ref DIALOGDESC is not implemented.
4741  *
4742  * \par DIALOG_ISSUBMENU: whether the dialog is a (sub)menu.
4743  * This parameter states whether the dialog is a menu in the interactive shell, i.e., is the parent of further
4744  * dialogs.
4745  *
4746  *
4747  * @section DIALOG_DATA Dialog Data
4748  *
4749  * Below the header "Data structures" you can find a struct which is called "struct SCIP_DialogData".
4750  * In this data structure, you can store the data of your dialog.
4751  * If you are using C++, you can add dialog data as usual as object variables to your class.
4752  * \n
4753  * Defining dialog data is optional. You can leave the struct empty.
4754  *
4755  *
4756  * @section DIALOG_INTERFACE Interface Methods
4757  *
4758  * At the bottom of "dialog_mydialog.c" you can find the interface method SCIPincludeDialogMydialog(), which also appears
4759  * in "dialog_mydialog.h".
4760  * \n
4761  * This method only has to be adjusted slightly.
4762  * It is responsible for notifying SCIP of the presence of the dialog, which can be done by the following lines of code:
4763  * \code
4764  * if( !SCIPdialogHasEntry(parentdialog, DIALOG_NAME) )
4765  * {
4766  * SCIP_CALL( SCIPcreateDialog(scip, &dialog, dialogExecMydialog, dialogDescMydialog, dialogFreeMydialog,
4767  * DIALOG_NAME, DIALOG_DESC, DIALOG_ISSUBMENU, dialogdata) );
4768  *
4769  * SCIP_CALL( SCIPaddDialogEntry(scip, parentdialog, dialog) );
4770  *
4771  * SCIP_CALL( SCIPreleaseDialog(scip, &dialog) );
4772  * }
4773  * \endcode
4774  * Here "parentdialog" has to be an existing dialog which is defined to be a menu (see DIALOG_ISSUBMENU), e.g.,
4775  * the default root dialog. The method SCIPgetRootDialog() returns the root dialog.
4776  *
4777  * 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
4778  * his/her application.
4779  * Note that in order to be able to link the new dialog to an existing default dialog
4780  * (except the root dialog) it has to be included <b>after the
4781  * default dialogs plugin</b>, i.e., the SCIPincludeDialogMydialog() call has to occur after the
4782  * SCIPincludeDialogDefault() call. The SCIPincludeDialogDefault() method is called from within the SCIPincludeDefaultPlugins()
4783  * method. Therefore, it suffices to include your dialog plugins after you have called SCIPincludeDefaultPlugins().
4784  * In case you want to add a dialog to the <b>root dialog</b>, you just use the following
4785  * lines of code to get/create the root dialog.
4786  *
4787  * \code
4788  * SCIP_DIALOG* root;
4789  *
4790  * root = SCIPgetRootDialog(scip);
4791  * if( root == NULL )
4792  * {
4793  * SCIP_CALL( SCIPcreateRootDialog(scip, &root) );
4794  * }
4795  * assert( root != NULL );
4796  * \endcode
4797  *
4798  * Therefore, in this case you do not have to worry about the calls of
4799  * SCIPincludeDialogDefault() and SCIPincludeDefaultPlugins() .
4800  *
4801  * If you are using dialog data, you have to allocate the memory for the data at this point.
4802  * You can do this by calling:
4803  * \code
4804  * SCIP_CALL( SCIPallocMemory(scip, &dialogdata) );
4805  * \endcode
4806  * You also have to initialize the fields in struct SCIP_DialogData afterwards.
4807  *
4808  * Consider the following example. The user wants to add a "drawgraph" command to the root menu of SCIP.
4809  * (S)he copies the "dialog_xyz.c" and "dialog_xyz.h" files into files "dialog_drawgraph.c" and "dialog_drawgraph.h", respectively.
4810  * Then, (s)he puts the following code into the SCIPincludeDialogDrawgraph() method, compare SCIPincludeDialogDefault() in
4811  * src/scip/dialog_default.c:
4812  * \code
4813  * SCIP_RETCODE SCIPincludeDialogDrawgraph(
4814  * SCIP* scip
4815  * )
4816  * {
4817  * SCIP_DIALOG* root;
4818  * SCIP_DIALOG* dialog;
4819  *
4820  * root = SCIPgetRootDialog(scip);
4821  * if( root == NULL )
4822  * {
4823  * SCIP_CALL( SCIPcreateRootDialog(scip, &root) );
4824  * }
4825  * assert( root != NULL );
4826  *
4827  * if( !SCIPdialogHasEntry(root, "drawgraph") )
4828  * {
4829  * SCIP_CALL( SCIPcreateDialog(scip, &dialog, SCIPdialogExecDrawgraph, NULL, NULL,
4830  * "drawgraph", "draws the graph for the current problem instance", FALSE, NULL) );
4831  * SCIP_CALL( SCIPaddDialogEntry(scip, root, dialog) );
4832  * SCIP_CALL( SCIPreleaseDialog(scip, &dialog) );
4833  * }
4834  *
4835  * return SCIP_OKAY;
4836  * }
4837  * \endcode
4838  *
4839  * Using this code, it is even possible to call SCIPincludeDialogDrawgraph() before including the default dialog plugins,
4840  * and you can also call it multiple times without causing inconsistencies in the dialog structure.
4841  *
4842  *
4843  * @section DIALOG_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Dialog
4844  *
4845  * Dialogs have only one fundamental callback method, namely the \ref DIALOGEXEC method.
4846  * This method has to be implemented for every dialog; the other callback methods are optional.
4847  * In the C++ wrapper class scip::ObjDialog, the scip_exec() method (which corresponds to the \ref DIALOGEXEC callback) is a virtual
4848  * abstract member function.
4849  * You have to implement it in order to be able to construct an object of your dialog class.
4850  *
4851  * Additional documentation for the callback methods can be found in type_dialog.h.
4852  *
4853  * @subsection DIALOGEXEC
4854  *
4855  * The DIALOGEXEC method is invoked, if the user selected the dialog's command name in the parent's menu. It should
4856  * execute what is stated in DIALOG_DESC, e.g., the display constraint handlers dialog should display information about
4857  * the constraint handlers included in SCIP, see src/scip/dialog_default.c.
4858  *
4859  * For typical methods called by the execution method, have a look at src/scip/dialog_default.c.
4860  *
4861  * The callback has to return which dialog should be processed next. This can be, for example, the root dialog
4862  * (SCIPdialoghdlrGetRoot()), the parent dialog (SCIPdialogGetParent()) or NULL, which stands for closing the interactive
4863  * shell.
4864  *
4865  *
4866  * @section DIALOG_ADDITIONALCALLBACKS Additional Callback Methods of a Dialog
4867  *
4868  * The additional callback methods do not need to be implemented in every case.
4869  * They can be used, for example, to free private data.
4870  *
4871  * @subsection DIALOGPFREE
4872  *
4873  * If you are using dialog data, you have to implement this method in order to free the dialog data.
4874  * This can be done by the following procedure:
4875  * \code
4876  * static
4877  * SCIP_DECL_DIALOGFREE(dialogFreeMydialog)
4878  * {
4879  * SCIP_DIALOGDATA* dialogdata;
4880  *
4881  * dialogdata = SCIPdialogGetData(dialog);
4882  * assert(dialogdata != NULL);
4883  *
4884  * SCIPfreeMemory(scip, &dialogdata);
4885  *
4886  * SCIPdialogSetData(dialog, NULL);
4887  *
4888  * return SCIP_OKAY;
4889  * }
4890  * \endcode
4891  * If you have allocated memory for fields in your dialog data, remember to free this memory
4892  * before freeing the dialog data itself.
4893  * If you are using the C++ wrapper class, this method is not available.
4894  * Instead, just use the destructor of your class to free the member variables of your class.
4895  *
4896  * @subsection DIALOGDESC
4897  *
4898  * This method is called when the help menu of the parent is displayed. It should output (usually a single line of)
4899  * information describing the meaning of the dialog.
4900  * \n
4901  * If this callback is not implemented, the description string of the dialog (DIALOG_DESC) is displayed instead.
4902  *
4903  * @subsection DIALOGCOPY
4904  *
4905  * The DIALOGCOPY callback is executed when a SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this
4906  * callback as <code>NULL</code> the user disables the execution of this dialog for all copied SCIP instances. In
4907  * general there is no need to copy any dialog since it is most unlikely to start the interactive shell of the copied
4908  * instances.
4909  *
4910  */
4911 
4912 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
4913 /**@page DISP How to add display columns
4914  *
4915  * While solving a constraint integer program, SCIP displays status information in a column-like fashion. The current
4916  * number of processed branching tree nodes, the solving time, and the relative gap between primal and dual bound are
4917  * examples of such display columns. There already exists a wide variety of display columns which can be activated or
4918  * deactivated on demand, see src/scip/disp_default.c. Additionally, the user can implement his/her own display columns
4919  * in order to track problem or algorithm specific values.
4920  * \n
4921  * A complete list of all displays contained in this release can be found \ref DISPLAYS "here".
4922  *
4923  * We now explain users can add their own display columns.
4924  * We give the explanation for creating your own source file for each additional display column. Of course, you can collect
4925  * different additional display columns in one source file.
4926  * Take src/scip/disp_default.c, where all default display columns are collected, as an example.
4927  * As all other default plugins, the default display column plugins and the display column template are written in C.
4928  * C++ users can easily adapt the code by using the scip::ObjDisp wrapper base class and implement the scip_...() virtual methods
4929  * instead of the SCIP_DECL_DISP... callback methods.
4930  *
4931  *
4932  * Additional documentation for the callback methods of a display column can be found in the file type_disp.h.
4933  *
4934  * Here is what you have to do to implement a display column (assuming your display column is named "mydisplaycolumn"):
4935  * -# Copy the template files src/scip/disp_xyz.c and src/scip/disp_xyz.h into files named "disp_mydisplaycolumn.c"
4936  * and "disp_mydisplaycolumn.h".
4937  \n
4938  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
4939  * -# Use SCIPincludeDispMydisplaycolumn() in order to include the display column into your SCIP instance,
4940  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
4941  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mydisplaycolumn".
4942  * -# Adjust the \ref DISP_PROPERTIES "properties of the display column".
4943  * -# Define the \ref DISP_DATA "display column data". This is optional.
4944  * -# Implement the \ref DISP_INTERFACE "interface methods".
4945  * -# Implement the \ref DISP_FUNDAMENTALCALLBACKS "fundamental callback methods".
4946  * -# Implement the \ref DISP_ADDITIONALCALLBACKS "additional callback methods". This is optional.
4947  *
4948  *
4949  * @section DISP_PROPERTIES Properties of a Display Column
4950  *
4951  * At the top of the new file "disp_mydisplaycolumn.c" you can find the display column properties.
4952  * These are given as compiler defines.
4953  * In the C++ wrapper class, you have to provide the display column properties by calling the constructor
4954  * of the abstract base class scip::ObjDisp from within your constructor.
4955  * The properties you have to set have the following meaning:
4956  *
4957  * \par DISP_NAME: the name of the display column.
4958  * This name is used in the interactive shell to address the display column.
4959  * Additionally, if you are searching for a display column with SCIPfindDisp(), this name is looked up.
4960  * Names have to be unique: no two display columns may have the same name.
4961  *
4962  * \par DISP_DESC: the description of the display column.
4963  * This string is printed as a description of the display column in the interactive shell.
4964  *
4965  * \par DISP_HEADER: the header of the display column.
4966  * This string is printed as the header of the display column in the status information display.
4967  *
4968  * \par DISP_WIDTH: the width of the display column.
4969  * This parameter defines the width (number of characters) of the display column. The value of the parameter has to be
4970  * greater than or equal to the number of characters in the header string.
4971  *
4972  * \par DISP_PRIORITY: the priority of the display column.
4973  * The total width of status information lines is bounded by the parameter "display width". The display columns actually contained
4974  * in the status information display are selected in decreasing order of their priority. Furthermore, the user can force
4975  * columns to be displayed or not to be displayed in the status information display. For that, (s)he has to switch the value
4976  * of the display column's parameter "active" from "auto" (its default value) to "on" or "off", respectively.
4977  *
4978  * \par DISP_POSITION: the relative position of the display column.
4979  * In the status information display, the display columns are arranged from left to right in increasing order of their
4980  * relative position.
4981  *
4982  * \par DISP_STRIPLINE: the default for whether the display column should be separated with a line from its right neighbor.
4983  * This parameter states whether the display column should be separated with the string "|" from its right neighbor. In so
4984  * doing, the clearness of the status information display may improve.
4985  *
4986  * @section DISP_DATA Display Column Data
4987  *
4988  * Below the header "Data structures" you can find a struct which is called "struct SCIP_DispData".
4989  * In this data structure, you can store the data of your display column. For example, you should store the adjustable
4990  * parameters of the display column in this data structure.
4991  * If you are using C++, you can add display column data as usual as object variables to your class.
4992  * \n
4993  * Defining display column data is optional. You can leave the struct empty.
4994  *
4995  *
4996  * @section DISP_INTERFACE Interface Methods
4997  *
4998  * At the bottom of "disp_mydisplaycolumn.c" you can find the interface method SCIPincludeDispMydisplaycolumn(), which also
4999  * appears in "disp_mydisplaycolumn.h".
5000  * \n
5001  * This method only has to be adjusted slightly.
5002  * It is responsible for notifying SCIP of the presence of the display column by calling the method
5003  * SCIPincludeDisp().
5004  *
5005  * 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
5006  * application.
5007  *
5008  * If you are using display column data, you have to allocate the memory for the data at this point.
5009  * You can do this by calling:
5010  * \code
5011  * SCIP_CALL( SCIPallocMemory(scip, &dispdata) );
5012  * \endcode
5013  * You also have to initialize the fields in struct SCIP_DispData afterwards.
5014  *
5015  * Although this is very uncommon, you may also add user parameters for your display column, see the method
5016  * SCIPincludeConshdlrKnapsack() in the \ref cons_knapsack.h "knapsack constraint handler" for an example.
5017  *
5018  *
5019  * @section DISP_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Display Column
5020  *
5021  * Display column plugins have only one fundamental callback method, namely the \ref DISPOUTPUT method.
5022  * This method has to be implemented for every display column; the other callback methods are optional.
5023  * In the C++ wrapper class scip::ObjDisp, the scip_output() method (which corresponds to the \ref DISPOUTPUT callback) is a virtual
5024  * abstract member function.
5025  * You have to implement it in order to be able to construct an object of your display column class.
5026  *
5027  * Additional documentation for the callback methods can be found in type_disp.h.
5028  *
5029  * @subsection DISPOUTPUT
5030  *
5031  * The DISPOUTPUT callback is called after each pricing loop during node processing and after a node has been processed.
5032  * In addition, at the root node, the callback is executed after each iteration of the price-and-cut loop.
5033  * It should write the display column information for the current node to a given output file stream.
5034  *
5035  * Typical methods called by a display column are, for example, SCIPdispLongint(), SCIPdispInt(), SCIPdispTime(), and
5036  * SCIPinfoMessage().
5037  *
5038  *
5039  * @section DISP_ADDITIONALCALLBACKS Additional Callback Methods of a Display Column
5040  *
5041  * The additional callback methods do not need to be implemented in every case.
5042  * They can be used, for example, to initialize and free private data.
5043  *
5044  * @subsection DISPCOPY
5045  *
5046  * The DISPCOPY callback is executed when a SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this callback
5047  * as <code>NULL</code> the user disables the execution of the specified column. In general it is probably not needed to
5048  * implement that callback since the output of the copied instance is usually suppressed. In the other case or for
5049  * debugging the callback should be implement.
5050  *
5051  *
5052  * @subsection DISPFREE
5053  *
5054  * If you are using display column data, you have to implement this method in order to free the display column data.
5055  * This can be done by the following procedure:
5056  * \code
5057  * static
5058  * SCIP_DECL_DISPFREE(dispFreeMydisplaycolumn)
5059  * {
5060  * SCIP_DISPDATA* dispdata;
5061  *
5062  * dispdata = SCIPdispGetData(disp);
5063  * assert(dispdata != NULL);
5064  *
5065  * SCIPfreeMemory(scip, &dispdata);
5066  *
5067  * SCIPdispSetData(disp, NULL);
5068  *
5069  * return SCIP_OKAY;
5070  * }
5071  * \endcode
5072  * If you have allocated memory for fields in your display column data, remember to free this memory
5073  * before freeing the display column data itself.
5074  * If you are using the C++ wrapper class, this method is not available.
5075  * Instead, just use the destructor of your class to free the member variables of your class.
5076  *
5077  * @subsection DISPINIT
5078  *
5079  * The DISPINIT callback is executed after the problem is transformed.
5080  * The display column may, e.g., use this call to initialize its display column data.
5081  *
5082  * @subsection DISPEXIT
5083  *
5084  * The DISPEXIT callback is executed before the transformed problem is freed.
5085  * In this method, the display column should free all resources that have been allocated for the solving process in
5086  * \ref DISPINIT.
5087  *
5088  * @subsection DISPINITSOL
5089  *
5090  * The DISPINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
5091  * begin. The display column may use this call to initialize its branch-and-bound specific data.
5092  *
5093  * @subsection DISPEXITSOL
5094  *
5095  * The DISPEXITSOL callback is executed before the branch-and-bound process is freed. The display column should use this
5096  * call to clean up its branch-and-bound data specific data.
5097  */
5098 
5099 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5100 /**@page EVENT How to add event handler
5101  *
5102  * While solving a constraint integer program, SCIP drops thousands of events such as SCIP_EVENTTYPE_VARFIXED (a
5103  * complete list of all events is given in type_event.h). These events can be caught and used to do something after a
5104  * certain event happens. Events can be used to speed up the solution process. For example, the set partitioning
5105  * constraint is only worth propagating if one of the involved variables is fixed. This can be detected by
5106  * catching the event SCIP_EVENTTYPE_VARFIXED. To be able to catch an event it is necessary to write an event handler
5107  * which defines what to do after a certain event was caught.
5108  *
5109  * We now explain how users can add their own event handlers. We give the explanation for creating your own
5110  * source file for each additional event handler. Of course, you can collect different event handlers in one source file
5111  * or you can put the event handler directly into the constraint handler. In a \ref EVENTUSAGE "second step" we discuss
5112  * the usage of an event handler. This means how to catch and drop events. \ref EVENTTYPES "Finally", we give some notes on the existing
5113  * types of events.
5114  *
5115  * Take src/scip/cons_logior.c, where the event handler is directly included into the constraint handler. As all other
5116  * default plugins, the event handlers are written in C. C++ users can easily adapt the code by using the scip::ObjEventhdlr
5117  * wrapper base class and implement the scip_...() virtual methods instead of the SCIP_DECL_EVENT... callback methods.
5118  *
5119  * Additional documentation for the callback methods of an event handler can be found in the file type_event.h. There is
5120  * also an example written in C which deals with an event handler. You find this example in the directory
5121  * "examples/Eventhdlr/". An C++ example can be found within the TSP project (examples/TSP/src/EventhdlrNewSol.cpp).
5122  *
5123  * Here is what you have to do to implement an event handler (assuming your event handler is named "bestsol"):
5124  * -# Copy the template files src/scip/event_xyz.c and src/scip/event_xyz.h into files named "event_bestsol.c"
5125  * and "event_bestsol.h".
5126  \n
5127  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
5128  * -# Use SCIPincludeEventBestsol() in order to include the event handler into your SCIP instance,
5129  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Eventhdlr example).
5130  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "bestsol".
5131  * -# Adjust the \ref EVENTHDLR_PROPERTIES "properties of the event handler".
5132  * -# Implement the \ref EVENT_INTERFACE "interface methods".
5133  * -# Implement the \ref EVENT_FUNDAMENTALCALLBACKS "fundamental callback methods".
5134  * -# Implement the \ref EVENT_ADDITIONALCALLBACKS "additional callback methods". This is optional.
5135  *
5136  *
5137  * @section EVENTHDLR_PROPERTIES Properties of a Event Handler
5138  *
5139  * At the top of the new file "event_bestsol.c" you can find the event handler properties.
5140  * These are given as compiler defines.
5141  * In the C++ wrapper class, you have to provide the event handler properties by calling the constructor
5142  * of the abstract base class scip::ObjEventhdlr from within your constructor.
5143  * The properties you have to set have the following meaning:
5144  *
5145  * \par EVENT_NAME: the name of the event handler.
5146  * This name has to be unique with respect to all other event handlers. If you are searching for an event handler with
5147  * SCIPfindEventhdlr(), this name is looked up.
5148  *
5149  * \par EVENT_DESC: the description of the event handler.
5150  * This string is printed as a description of the event handler.
5151  *
5152  * @section EVENTHDLR_DATA Event Handler Data
5153  *
5154  * Below the header "Data structures" you can find a struct which is called "struct SCIP_EventhdlrData".
5155  * In this data structure, you can store the data of your event handler. For example, you should store the adjustable
5156  * parameters of the event handler in this data structure.
5157  * If you are using C++, you can add event handler data as usual as object variables to your class.
5158  * \n
5159  * Defining event handler data is optional. You can leave the struct empty.
5160  *
5161  *
5162  * @section EVENT_INTERFACE Interface Methods
5163  *
5164  * At the bottom of "event_bestsol.c", you can find the interface method SCIPincludeEventBestsol(),
5165  * which also appears in "event_bestsol.h".
5166  * SCIPincludeEventBestsol() is called by the user, if (s)he wants to include the event handler,
5167  * i.e., if (s)he wants to use the event handler in his/her application.
5168  *
5169  * This method only has to be adjusted slightly.
5170  * It is responsible for notifying SCIP of the presence of the event handler. For this, you can either call
5171  * SCIPincludeEventhdlr(),
5172  * or SCIPincludeEventhdlrBasic() since SCIP version 3.0. In the latter variant, \ref EVENT_ADDITIONALCALLBACKS "additional callbacks"
5173  * must be added via setter functions as, e.g., SCIPsetReaderCopy(). We recommend this latter variant because
5174  * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
5175  * variant must be manually adjusted with every SCIP release containing new callbacks for event handlers in order to compile.
5176  *
5177  * If you are using event handler data, you have to allocate the memory for the data at this point.
5178  * You can do this by calling:
5179  * \code
5180  * SCIP_CALL( SCIPallocMemory(scip, &eventhdlrdata) );
5181  * \endcode
5182  * You also have to initialize the fields in struct SCIP_EventhdlrData afterwards.
5183  *
5184  * Although this is very uncommon, you may also add user parameters for your event handler, see the method
5185  * SCIPincludeConshdlrKnapsack() in the \ref cons_knapsack.h "knapsack constraint handler" for an example.
5186  *
5187  *
5188  * @section EVENT_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Event Handler
5189  *
5190  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
5191  * an operational algorithm.
5192  * They are passed together with the event handler itself to SCIP using SCIPincludeEventhdlr() or SCIPincludeEventhdlrBasic(),
5193  * see @ref EVENT_INTERFACE.
5194  *
5195  *
5196  * Event handler plugins have only one fundamental callback method, namely the \ref EVENTEXEC method. This method has
5197  * to be implemented for every event handler; the other callback methods are optional. In the C++ wrapper class
5198  * scip::ObjEventhdlr, the scip_exec() method (which corresponds to the \ref EVENTEXEC callback) is a virtual abstract member
5199  * function. You have to implement it in order to be able to construct an object of your event handler class.
5200  *
5201  * Additional documentation for the callback methods can be found in type_event.h.
5202  *
5203  * @subsection EVENTEXEC
5204  *
5205  * The EVENTEXEC callback is called after the requested event happened. Then the event handler can do some action in
5206  * reaction to the event.
5207  *
5208  * Typical the execution method sets a parameter to TRUE to indicate later in solving process that something happened
5209  * which should be analyzed further. In the \ref cons_knapsack.h "knapsack constraint handler" you find such a typical
5210  * example.
5211  *
5212  * @section EVENT_ADDITIONALCALLBACKS Additional Callback Methods of a Event Handler
5213  *
5214  * The additional callback methods do not need to be implemented in every case. However, some of them have to be
5215  * implemented for most applications, they can be used, for example, to initialize and free private data.
5216  * Additional callbacks can either be passed directly with SCIPincludeEventhdlr() to SCIP or via specific
5217  * <b>setter functions</b> after a call of SCIPincludeEventhdlrBasic(), see also @ref EVENT_INTERFACE.
5218  *
5219  * @subsection EVENTCOPY
5220  *
5221  * The EVENTCOPY callback is executed when a SCIP instance is copied, e.g. to solve a sub-SCIP. By defining this
5222  * callback as <code>NULL</code> the user disables the execution of the specified event handler for all copied SCIP
5223  * instances. Note that in most cases the event handler in the copied instance will be initialize by those objects (such
5224  * as constraint handlers or propagators) which need this event handler (see \ref cons_knapsack.h). In these cases the copy
5225  * callback can be ignored. In case of general events, such as a new best solution being found
5226  * (SCIP_EVENTTYPE_BESTSOLFOUND), you might want to implement that callback. The event handler example which you find
5227  * in the directory "examples/Eventhdlr/" uses that callback.
5228  *
5229  * \code
5230  * static
5231  * SCIP_DECL_EVENTCOPY(eventCopyBestsol)
5232  * {
5233  * assert(scip != NULL);
5234  * assert(eventhdlr != NULL);
5235  * assert(strcmp(SCIPeventhdlrGetName(eventhdlr), EVENTHDLR_NAME) == 0);
5236  *
5237  * SCIP_CALL( SCIPincludeEventHdlrBestsol(scip) );
5238  *
5239  * return SCIP_OKAY;
5240  * }
5241  * \endcode
5242  *
5243  *
5244  * @subsection EVENTFREE
5245  *
5246  * If you are using event handler data, you have to implement this method in order to free the event handler data.
5247  * This can be done by the following procedure:
5248  * \code
5249  * static
5250  * SCIP_DECL_EVENTFREE(eventFreeBestsol)
5251  * {
5252  * SCIP_EVENTHDLRDATA* eventhdlrdata;
5253  *
5254  * eventhdlrdata = SCIPeventhdlrGetData(eventhdlr);
5255  * assert(eventhdlrdata != NULL);
5256  *
5257  * SCIPfreeMemory(scip, &eventhdlrdata);
5258  *
5259  * SCIPeventhdlrSetData(eventhdlr, NULL);
5260  *
5261  * return SCIP_OKAY;
5262  * }
5263  * \endcode
5264  * If you have allocated memory for fields in your event handler data, remember to free this memory
5265  * before freeing the event handler data itself.
5266  * If you are using the C++ wrapper class, this method is not available.
5267  * Instead, just use the destructor of your class to free the member variables of your class.
5268  *
5269  *
5270  * @subsection EVENTINIT
5271  *
5272  * The EVENTINIT callback is executed after the problem is transformed.
5273  * The event handler may, e.g., use this call to initialize its event handler data.
5274  *
5275  * @subsection EVENTEXIT
5276  *
5277  * The EVENTEXIT callback is executed before the transformed problem is freed.
5278  * In this method, the event handler should free all resources that have been allocated for the solving process in
5279  * \ref EVENTINIT.
5280  *
5281  * @subsection EVENTINITSOL
5282  *
5283  * The EVENTINITSOL callback is executed when the presolving is finished and the branch-and-bound process is about to
5284  * begin. The event handler may use this call to initialize its branch-and-bound specific data.
5285  *
5286  * @subsection EVENTEXITSOL
5287  *
5288  * The EVENTEXITSOL callback is executed before the branch-and-bound process is freed. The event handler should use this
5289  * call to clean up its branch-and-bound data specific data.
5290  *
5291  * @section EVENTUSAGE Catching and Dropping Events
5292  *
5293  * After you have implemented the event handler, you have to tell SCIP for which events this event handler should be
5294  * used. This can be a general events, such as <code>SCIP_EVENTTYPE_BESTSOLFOUND</code>, or a variable event which is the most common
5295  * way.
5296  *
5297  * In case of a general (not variable) event you use the function SCIPcatchEvent() to attach to an event and
5298  * SCIPdropEvent() to release this event later.
5299  *
5300  * \code
5301  * SCIP_CALL( SCIPcatchEvent( scip, SCIP_EVENTTYPE_BESTSOLFOUND, eventhdlr, NULL, NULL) );
5302  * \endcode
5303  *
5304  * \code
5305  * SCIP_CALL( SCIPdropEvent( scip, SCIP_EVENTTYPE_BESTSOLFOUND, eventhdlr, NULL, NULL) );
5306  * \endcode
5307  *
5308  * If you want trigger some variable event, you use the method SCIPcatchVarEvent() to attach the variable event and
5309  * SCIPdropVarEvent() to drop it later.
5310  *
5311  * \code
5312  * SCIP_CALL( SCIPcatchVarEvent( scip, var, SCIP_EVENTTYPE_VARFIXED, eventhdlr, NULL, NULL) );
5313  * \endcode
5314  *
5315  * \code
5316  * SCIP_CALL( SCIPdropVarEvent( scip, var, SCIP_EVENTTYPE_VARFIXED, eventhdlr, NULL, NULL) );
5317  * \endcode
5318  *
5319  * @section EVENTTYPES Event types
5320  *
5321  * All available events are listed in type_event.h. There are atomic events such as <code>SCIP_EVENTTYPE_VARFIXED</code>
5322  * and combined events such as <code>SCIP_EVENTTYPE_VARCHANGED</code>. The events are encoded via bit masks. Each atomic
5323  * event has a unique power of two. This enables combination of the atomic events.
5324  *
5325  * SCIP only throws atomic events. However, an event handler might be interested in bunch of events. Through the
5326  * underlying bit masks it is possible to combine the atomic events. For example, <code>SCIP_EVENTTYPE_VARCHANGED</code>
5327  * is an event which combines the events <code>SCIP_EVENTTYPE_VARFIXED</code>, <code>SCIP_EVENTTYPE_VARUNLOCKED</code>,
5328  * <code>SCIP_EVENTTYPE_OBJCHANGED</code>, <code>SCIP_EVENTTYPE_GBDCHANGED</code>,
5329  * <code>SCIP_EVENTTYPE_DOMCHANGED</code>, and <code>SCIP_EVENTTYPE_IMPLADDED</code>.
5330  *
5331  * \code
5332  * #define SCIP_EVENTTYPE_VARCHANGED (SCIP_EVENTTYPE_VARFIXED | SCIP_EVENTTYPE_VARUNLOCKED | SCIP_EVENTTYPE_OBJCHANGED
5333  * | SCIP_EVENTTYPE_GBDCHANGED | SCIP_EVENTTYPE_DOMCHANGED | SCIP_EVENTTYPE_IMPLADDED)
5334  * \endcode
5335  *
5336  * Depending on the event type, the event offers different information. The methods which can be used to gain
5337  * access to this information are given in pub_event.h.
5338  *
5339  */
5340 
5341 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5342 /**@page NLPI How to add interfaces to nonlinear programming solvers
5343  *
5344  * NLPIs are used to interface a solver for nonlinear programs (NLP).
5345  * It is used, e.g., to solve convex relaxations of the problem or to find locally optimal solutions of
5346  * nonlinear relaxations or subproblems.
5347  * The NLPI has been designed such that it can be used independently from SCIP.
5348  *
5349  * While the NLPI itself corresponds to the solver interface, the NLPIPROBLEM corresponds to the
5350  * (solver specific) representation of a concrete nonlinear program.
5351  * An NLP is specified as a set of indexed variables with variable bounds, an objective function,
5352  * and a set of constraints, where each constraint is specified as a function which is restricted to lie
5353  * between given left and right hand sides (possibly infinite).
5354  * A function consists of a linear, quadratic, and general nonlinear part.
5355  * The linear and quadratic parts are specified via variable indices and coefficients, while the
5356  * general nonlinear part is specified via an expression tree.
5357  * That is, the user of the NLPI does not provide function evaluation callbacks but an algebraic representation of the NLP.
5358  * Interfaces for solvers that require function evaluations can make use of the NLPIORACLE, which
5359  * provides a set of methods to compute functions values, gradients, Jacobians, and Hessians for a given NLP.
5360  * See the interface to Ipopt for an example on how to use the NLPIORACLE.
5361  *
5362  * A complete list of all NLPIs contained in this release can be found \ref NLPIS "here".
5363  *
5364  * We now explain how users can add their own NLP solver interface.
5365  * Take the interface to Ipopt (src/nlpi/nlpi_ipopt.cpp) as an example.
5366  * Unlike most other plugins, it is written in C++.
5367  * Additional documentation for the callback methods of an NLPI, in particular for their input parameters,
5368  * can be found in the file type_nlpi.h.
5369  *
5370  * Here is what you have to do to implement an NLPI:
5371  * -# Copy the template files src/nlpi/nlpi_xyz.c and src/nlpi/nlpi_xyz.h into files named "nlpi_mynlpi.c"
5372  * and "nlpi_mynlpi.h".
5373  * \n
5374  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
5375  * -# Use SCIPcreateNlpSolverMynlpi() in order to include the NLPI into your SCIP instance,
5376  * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
5377  * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mynlpi".
5378  * -# Adjust the properties of the nlpi (see \ref NLPI_PROPERTIES).
5379  * -# Define the NLPI and NLPIPROBLEM data (see \ref NLPI_DATA).
5380  * -# Implement the interface methods (see \ref NLPI_INTERFACE).
5381  * -# Implement the fundamental callback methods (see \ref NLPI_FUNDAMENTALCALLBACKS).
5382  *
5383  *
5384  * @section NLPI_PROPERTIES Properties of an NLPI
5385  *
5386  * At the top of the new file "nlpi_mynlpi.c", you can find the NLPI properties.
5387  * These are given as compiler defines.
5388  * The properties you have to set have the following meaning:
5389  *
5390  * \par NLPI_NAME: the name of the NLP solver interface.
5391  * This name is used in the interactive shell to address the NLPI.
5392  * Additionally, if you are searching for an NLPI with SCIPfindNLPI(), this name is looked up.
5393  * Names have to be unique: no two NLPIs may have the same name.
5394  *
5395  * \par NLPI_DESC: the description of the NLPI.
5396  * This string is printed as a description of the NLPI in the interactive shell.
5397  *
5398  * \par NLPI_PRIORITY: the priority of the NLPI.
5399  * If an NLP has to be solved, an NLP solver has to be selected.
5400  * By default, the solver with the NLPI with highest priority is selected.
5401  * The priority of an NLPI should be set according to performance of the solver:
5402  * solvers that provide fast algorithms that are usually successful on a wide range of problems should have a high priority.
5403  * An easy way to list the priorities of all NLPIs is to type "display nlpis" in the interactive shell of SCIP.
5404  *
5405  * @section NLPI_DATA NLPI Data
5406  *
5407  * Below the header "Data structures" you can find structs which are called "struct SCIP_NlpiData" and "struct SCIP_NlpiProblem".
5408  * In this data structure, you can store the data of your solver interface and of a specific NLP problem.
5409  * For example, you could store a pointer to the block memory data structure in the SCIP_NlpiData data structure
5410  * and store a pointer to an NLPIoracle in the SCIP_NlpiProblem data structure.
5411  *
5412  * @section NLPI_INTERFACE Interface Methods
5413  *
5414  * At the bottom of "nlpi_mynlpi.c", you can find the interface method SCIPcreateNlpSolverXyz(),
5415  * which also appears in "nlpi_mynlpi.h".
5416  * \n
5417  * This method only has to be adjusted slightly.
5418  * It is responsible for creating an NLPI that contains all properties and callback methods of your
5419  * solver interface by calling the method SCIPnlpiCreate().
5420  * SCIPcreateNlpSolverXyz() is called by the user (e.g., SCIP), if (s)he wants to use this solver interface in his/her application.
5421  *
5422  * If you are using NLPI data, you have to allocate the memory for the data at this point.
5423  * You can do this by calling:
5424  * \code
5425  * SCIP_CALL( SCIPallocMemory(scip, &nlpidata) );
5426  * \endcode
5427  * You also have to initialize the fields in struct SCIP_NlpiData afterwards. For freeing the
5428  * NLPI data, see \ref NLPIFREE.
5429  *
5430  *
5431  * @section NLPI_FUNDAMENTALCALLBACKS Fundamental Callback Methods of an NLPI
5432  *
5433  * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
5434  * an operational algorithm. Currently, all NLPI callbacks are fundamental.
5435  *
5436  * Additional documentation of the callback methods, in particular to their input parameters,
5437  * can be found in type_nlpi.h.
5438  *
5439  * @subsection NLPICOPY
5440  *
5441  * The NLPICOPY callback is executed if the plugin should be copied, e.g., when a SCIP instance is copied.
5442  *
5443  * @subsection NLPIFREE
5444  *
5445  * The NLPIFREE callback is executed if the NLP solver interface data structure should be freed, e.g., when a SCIP instance is freed.
5446  *
5447  * @subsection NLPIGETSOLVERPOINTER
5448  *
5449  * The NLPIGETSOLVERPOINTER callback can be used to pass a pointer to a solver specific data structure to the user.
5450  *
5451  * @subsection NLPICREATEPROBLEM
5452  *
5453  * The NLPICREATEPROBLEM callback is executed if a particular NLP problem is to be created.
5454  * The callback method should initialize a SCIP_NlpiProblem struct here that corresponds to an empty NLP.
5455  *
5456  * @subsection NLPIFREEPROBLEM
5457  *
5458  * The NLPIFREEPROBLEMPOINTER callback is executed if a particular NLP problem is to be freed.
5459  * The callback method should free a SCIP_NlpiProblem struct here.
5460  *
5461  * @subsection NLPIGETPROBLEMPOINTER
5462  *
5463  * The NLPIGETPROBLEMPOINTER callback can be used to pass a pointer to a solver specific data structure of the NLP to the user.
5464  *
5465  * @subsection NLPIADDVARS
5466  *
5467  * The NLPIADDVARS callback is executed if a set of variables with lower and upper bounds and names should be added to a particular NLP.
5468  * The callback method must add the new variables behind the previously added variables, if any.
5469  * If NULL is given for the lower bounds arguments, -infinity is assumed as lower bound for each new variable.
5470  * If NULL is given for the upper bounds arguments, +infinity is assumed as upper bound for each new variable.
5471  * It is also permitted to use NULL for the names argument.
5472  *
5473  * @subsection NLPIADDCONSTRAINTS
5474  *
5475  * The NLPIADDCONSTRAINTS callback is executed if a set of constraints should be added to a particular NLP.
5476  * Constraints are specified by providing left and right hand sides, linear and quadratic coefficients, expression trees, and constraint names.
5477  * All of these arguments are optional, giving NULL for left hand sides corresponds to -infinity, giving NULL for right hand sides corresponds to +infinity.
5478  *
5479  * @subsection NLPISETOBJECTIVE
5480  *
5481  * The NLPISETOBJECTIVE callback is executed to set the objective function of a particular NLP.
5482  *
5483  * @subsection NLPICHGVARBOUNDS
5484  *
5485  * The NLPICHGVARBOUNDS callback is executed to change the bounds on a set of variables of an NLP.
5486  *
5487  * @subsection NLPICHGCONSSIDES
5488  *
5489  * The NLPICHGCONSSIDES callback is executed to change the sides on a set of constraints of an NLP.
5490  *
5491  * @subsection NLPIDELVARSET
5492  *
5493  * The NLPIDELVARSET callback is executed to delete a set of variables from an NLP.
5494  * The caller provides an array in which for each variable it is marked whether it should be deleted.
5495  * In the same array, the method should return the new position of each variable in the NLP, or -1 if it was deleted.
5496  *
5497  * @subsection NLPIDELCONSSET
5498  *
5499  * The NLPIDELCONSSET callback is executed to delete a set of constraints from an NLP.
5500  * The caller provides an array in which for each constraint it is marked whether it should be deleted.
5501  * In the same array, the method should return the new position of each constraint in the NLP, or -1 if it was deleted.
5502  *
5503  * @subsection NLPICHGLINEARCOEFS
5504  *
5505  * The NLPICHGLINEARCOEFS callback is executed to change the coefficients in the linear part of the objective function or a constraint of an NLP.
5506  *
5507  * @subsection NLPICHGQUADCOEFS
5508  *
5509  * The NLPICHGQUADCOEFS callback is executed to change the coefficients in the quadratic part of the objective function or a constraint of an NLP.
5510  *
5511  * @subsection NLPICHGEXPRTREE
5512  *
5513  * The NLPICHGEXPRTREE callback is executed to replace the expression tree of the objective function or a constraint of an NLP.
5514  *
5515  * @subsection NLPICHGNONLINCOEF
5516  *
5517  * 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.
5518  *
5519  * @subsection NLPICHGOBJCONSTANT
5520  *
5521  * The NLPICHGOBJCONSTANT callback is executed to change the constant offset of the objective function of an NLP.
5522  *
5523  * @subsection NLPISETINITIALGUESS
5524  *
5525  * The NLPISETINITIALGUESS callback is executed to provide primal and dual initial values for the variables and constraints of an NLP.
5526  * For a local solver, these values can be used as a starting point for the search.
5527  * 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).
5528  * In this case, the solver should clear previously set starting values and setup its own starting point.
5529  *
5530  * @subsection NLPISOLVE
5531  *
5532  * The NLPISOLVE callback is executed when an NLP should be solved.
5533  * The solver may use the initial guess provided by \ref NLPISETINITIALGUESS as starting point.
5534  * The status of the solving process and solution can be requested by
5535  * \ref NLPIGETSOLSTAT, \ref NLPIGETTERMSTAT, \ref NLPIGETSOLUTION, and \ref NLPIGETSTATISTICS.
5536  *
5537  * @subsection NLPIGETSOLSTAT
5538  *
5539  * The NLPIGETSOLSTAT callback can be used to request the solution status (solved, infeasible, ...) after an NLP has been solved.
5540  *
5541  * @subsection NLPIGETTERMSTAT
5542  *
5543  * The NLPIGETTERMSTAT callback can be used to request the termination reason (normal, iteration limit, ...) after an NLP has been solved.
5544  *
5545  * @subsection NLPIGETSOLUTION
5546  *
5547  * The NLPIGETSOLUTION callback can be used to request the primal and dual solution values after an NLP solve.
5548  * The method should pass pointers to arrays of variable values to the caller.
5549  * 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.
5550  *
5551  * @subsection NLPIGETSTATISTICS
5552  *
5553  * The NLPIGETSTATISTICS callback can be used to request the statistical values (number of iterations, time, ...) after an NLP solve.
5554  * The method should fill the provided NLPSTATISTICS data structure.
5555  *
5556  * <!-- NLPIGETWARMSTARTSIZE, NLPIGETWARMSTARTMEMO, NLPISETWARMSTARTMEMO are not documented,
5557  since they are currently not used, not implemented, and likely to change with a next version. -->
5558  *
5559  * @subsection NLPIGETINTPAR
5560  *
5561  * The NLPIGETINTPAR callback can be used to request the value of an integer valued NLP parameter.
5562  *
5563  * @subsection NLPISETINTPAR
5564  *
5565  * The NLPISETINTPAR callback is executed to set the value of an integer valued NLP parameter.
5566  *
5567  * @subsection NLPIGETREALPAR
5568  *
5569  * The NLPIGETREALPAR callback can be used to request the value of a real valued NLP parameter.
5570  *
5571  * @subsection NLPISETREALPAR
5572  *
5573  * The NLPISETREALPAR callback is executed to set the value of a real valued NLP parameter.
5574  *
5575  * @subsection NLPIGETSTRINGPAR
5576  *
5577  * The NLPIGETSTRINGPAR callback can be used to request the value of a string valued NLP parameter.
5578  *
5579  * @subsection NLPISETSTRINGPAR
5580  *
5581  * The NLPISETSTRINGPAR callback is executed to set the value of a string valued NLP parameter.
5582  */
5583 
5584 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5585 /**@page EXPRINT How to add interfaces to expression interpreters
5586  *
5587  * An expression interpreter is a tool to compute point-wise and interval-wise the function values, gradients, and
5588  * derivatives of algebraic expressions which are given in the form of an expression tree.
5589  * It is used, e.g., by an NLP solver interface to compute Jacobians and Hessians for the solver.
5590  *
5591  * The expression interpreter interface in SCIP has been implemented similar to those of the LP solver interface (LPI).
5592  * For one binary, exactly one expression interpreter has to be linked.
5593  * The expression interpreter API has been designed such that it can be used independently from SCIP.
5594  *
5595  * A complete list of all expression interpreters contained in this release can be found \ref EXPRINTS "here".
5596  *
5597  * We now explain how users can add their own expression interpreters.
5598  * Take the interface to CppAD (\ref exprinterpret_cppad.cpp) as an example.
5599  * Unlike most other plugins, it is written in C++.
5600  *
5601  * Additional documentation for the callback methods of an expression interpreter, in particular for their input parameters,
5602  * can be found in the file \ref exprinterpret.h
5603  *
5604  * Note that the expression interpreter API has <b>BETA status</b> and thus may change in the next version.
5605  *
5606  * Here is what you have to do to implement an expression interpreter:
5607  * -# Copy the file \ref exprinterpret_none.c into a file named "exprinterpreti_myexprinterpret.c".
5608  * \n
5609  * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
5610  * -# Open the new files with a text editor.
5611  * -# Define the expression interpreter data (see \ref EXPRINT_DATA).
5612  * -# Implement the interface methods (see \ref EXPRINT_INTERFACE).
5613  *
5614  *
5615  * @section EXPRINT_DATA Expression Interpreter Data
5616  *
5617  * In "struct SCIP_ExprInt", you can store the general data of your expression interpreter.
5618  * For example, you could store a pointer to the block memory data structure.
5619  *
5620  * @section EXPRINT_INTERFACE Interface Methods
5621  *
5622  * The expression interpreter has to implement a set of interface method.
5623  * In your "exprinterpret_myexprinterpret.c", these methods are mostly dummy methods that return error codes.
5624  *
5625  * @subsection SCIPexprintGetName
5626  *
5627  * The SCIPexprintGetName method should return the name of the expression interpreter.
5628  *
5629  * @subsection SCIPexprintGetDesc
5630  *
5631  * The SCIPexprintGetDesc method should return a short description of the expression interpreter, e.g., the name of the developer of the code.
5632  *
5633  * @subsection SCIPexprintGetCapability
5634  *
5635  * The SCIPexprintGetCapability method should return a bitmask that indicates the capabilities of the expression interpreter,
5636  * i.e., whether it can evaluate gradients, Hessians, or do interval arithmetic.
5637  *
5638  * @subsection SCIPexprintCreate
5639  *
5640  * The SCIPexprintCreate method is called to create an expression interpreter data structure.
5641  * The method should initialize a "struct SCIP_ExprInt" here.
5642  *
5643  * @subsection SCIPexprintFree
5644  *
5645  * The SCIPexprintFree method is called to free an expression interpreter data structure.
5646  * The method should free a "struct SCIP_ExprInt" here.
5647  *
5648  * @subsection SCIPexprintCompile
5649  *
5650  * The SCIPexprintCompile method is called to initialize the data structures that are required to evaluate
5651  * a particular expression tree.
5652  * The expression interpreter can store data that is particular to a given expression tree in the tree by using
5653  * SCIPexprtreeSetInterpreterData().
5654  *
5655  * @subsection SCIPexprintFreeData
5656  *
5657  * The SCIPexprintFreeData method is called when an expression tree is freed.
5658  * The expression interpreter should free the given data structure.
5659  *
5660  * @subsection SCIPexprintNewParametrization
5661  *
5662  * The SCIPexprintNewParametrization method is called when the values of the parameters in a parametrized expression tree have changed.
5663  *
5664  * @subsection SCIPexprintEval
5665  *
5666  * The SCIPexprintEval method is called when the value of an expression represented by an expression tree should be computed for a point.
5667  *
5668  * @subsection SCIPexprintEvalInt
5669  *
5670  * 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.
5671  *
5672  * @subsection SCIPexprintGrad
5673  *
5674  * The SCIPexprintGrad method is called when the gradient of an expression represented by an expression tree should be computed for a point.
5675  *
5676  * @subsection SCIPexprintGradInt
5677  *
5678  * 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.
5679  *
5680  * @subsection SCIPexprintHessianSparsityDense
5681  *
5682  * The SCIPexprintHessianSparsityDense method is called when the sparsity structure of the Hessian matrix should be computed and returned in dense form.
5683  *
5684  * @subsection SCIPexprintHessianDense
5685  *
5686  * The SCIPexprintHessianDense method is called when the Hessian of an expression represented by an expression tree should be computed for a point.
5687  */
5688 
5689 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5690 /**@page CONF How to use conflict analysis
5691  *
5692  * Conflict analysis is a way to automatically use the information obtained from infeasible nodes
5693  * in the branch-and-bound tree.
5694  *
5695  * Once a node is declared infeasible, SCIP automatically tries to infer a constraint that explains the reason for the
5696  * infeasibility, in order to avoid similar situations later in the search. This explanation essentially consists of a
5697  * constraint stating that at least one of its variables should have a bound different from the current infeasible node,
5698  * because the current setting led to infeasibility. Clearly, all variables that are fixed in the current infeasible
5699  * node would yield such a constraint (since this leads to infeasibility). The key point rather is to infer a "small"
5700  * constraint that does the same job. SCIP handles this by several heuristics. For this, SCIP sets up a
5701  * so-called (directed) conflict graph. The nodes in this graph correspond to bound changes of variables and an arc (@a
5702  * 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
5703  * will have several ingoing arcs which represent all bound changes that have been used to infer (propagate) the bound
5704  * change in question. The graph also contains source nodes for each bound that has been changed during branching and an
5705  * artificial target node representing the conflict, i.e., the infeasibility. Essentially, SCIP heuristically constructs
5706  * a cut in this graph that involves few "branching nodes". For details on the techniques that SCIP uses,
5707  * we refer to the paper @par
5708  * Tobias Achterberg, Conflict Analysis in Mixed Integer Programming@n
5709  * Discrete Optimization, 4, 4-20 (2007)
5710  *
5711  * For conflict analysis to work well, the author of a \ref CONS "Constraint Handler" or a
5712  * \ref PROP "Propagator" has to implement three kinds of functionality:
5713  *
5714  * -# If one detects infeasibility, one should initiate conflict analysis, see \ref INITCONFS "below".
5715  * -# During propagation, one should call the right functions to fix variables.
5716  * -# One should implement the <em>so-called reverse propagation</em>.
5717  *
5718  * If this functionality is not implemented, SCIP will still work correctly, but cannot use the information of the constraint
5719  * handler or the propagator for conflict analysis. In this case, each bound reduction performed by the constraint
5720  * handler/propagator will be treated as if it had been a branching decision.
5721  *
5722  * @section INITCONFS Initiating Conflict Analysis
5723  *
5724  * If one detects infeasibility within propagation, one should do the following:
5725  * -# Call SCIPinitConflictAnalysis().
5726  * -# Inform SCIP about the variable bounds that are the reason for the detection of infeasibility
5727  * via the functions SCIPaddConflictLb(), SCIPaddConflictUb(), SCIPaddConflictBd(), or
5728  * SCIPaddConflictBinvar(). If there is more than one valid explanation of infeasibility, either one can be used.
5729  * Typically, smaller explanations tend to be better.
5730  * -# Call SCIPanalyzeConflict() from a propagator or SCIPanalyzeConflictCons() from a constraint
5731  * handler.
5732  *
5733  * This functionality allows SCIP to set up the conflict graph and perform a conflict analysis.
5734  *
5735  * @section Propagation
5736  *
5737  * When propagating variable domains, SCIP needs to be informed that the deduced variable bounds should be
5738  * used in conflict analysis. This can be done by the functions SCIPinferVarLbCons(),
5739  * SCIPinferVarUbCons(), and SCIPinferBinvarCons() for constraint handlers and SCIPinferVarLbProp(),
5740  * SCIPinferVarUbProp(), and SCIPinferBinvarProp() for propagators. You can pass one integer of
5741  * information that should indicate the reason of the propagation and can be used in reverse
5742  * propagation, see the next section.
5743  *
5744  * @section RESPROP Reverse Propagation
5745  *
5746  * Reverse Propagation is used to build up the conflict graph. Essentially, it provides an algorithm to detect the arcs
5747  * leading to a node in the conflict graph, i.e., the bound changes responsible for the new bound change deduced during
5748  * propagation. Reverse Propagation needs to be implemented in the RESPROP callback functions of
5749  * \ref CONSRESPROP "constraint handlers" or \ref PROPRESPROP "propagators".
5750  * These callbacks receive the following information: the variable which is under investigation (@p
5751  * infervar), the corresponding bound change (@p bdchgidx, @p boundtype), and the integer (@p inferinfo) that has been
5752  * supplied during propagation.
5753  *
5754  * One can use SCIPvarGetUbAtIndex() or SCIPvarGetLbAtIndex() to detect the bounds before or after the propagation that
5755  * should be investigated. Then the bounds that were involved should be passed to SCIP via SCIPaddConflictLb() and
5756  * SCIPaddConflictUb(). If there is more than one valid explanation of infeasibility, either one can be used.
5757  * Typically, smaller explanations tend to be better.
5758  *
5759  * Details and (more) examples are given in Sections @ref CONSRESPROP and @ref PROPRESPROP.
5760  *
5761  *
5762  * @section Example
5763  *
5764  * Consider the constraint handler @p cons_linearordering.c in the
5765  * <a href="http://scip.zib.de/doc/examples/LOP"><b>linear ordering example</b></a>
5766  * (see @p example/LOP directory). This constraint handler propagates the equations \f$x_{ij} + x_{ji} =
5767  * 1\f$ and triangle inequalities \f$x_{ij} + x_{jk} + x_{ki} \leq 2\f$.
5768  *
5769  * When propagating the equation and <code>vars[i][j]</code> is fixed to 1, the constraint handler uses
5770  * \code
5771  * SCIP_CALL( SCIPinferBinvarCons(scip, vars[j][i], FALSE, cons, i*n + j, &infeasible, &tightened) );
5772  * \endcode
5773  * Thus, variable <code>vars[j][i]</code> is fixed to 0 (@p FALSE), and it passes <code>i*n + j </code> as @p inferinfo.
5774  *
5775  * When it propagates the triangle inequality and both <code>vars[i][j]</code> and <code>vars[j][k]</code>
5776  * are fixed to 1, the constraint handler uses
5777  * \code
5778  * SCIP_CALL( SCIPinferBinvarCons(scip, vars[k][i], FALSE, cons, n*n + i*n*n + j*n + k, &infeasible, &tightened) );
5779  * \endcode
5780  * 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
5781  * passed as <code>inferinfo</code>.
5782  *
5783  * In reverse propagation, the two cases can be distinguished by @p inferinfo: if it is less than @p n*n,
5784  * we deal with an equation, otherwise with a triangle inequality. The constraint handler can then extract the
5785  * indices @p i, @p j (and @p k in the second case) from inferinfo.
5786  *
5787  * In the first case, it has to distinguish whether <code>vars[i][j]</code> is fixed to 0 or 1 &ndash;
5788  * by calling SCIPaddConflictLb()
5789  * or SCIPaddConflictUb(), respectively, with variable <code>vars[j][i]</code>. In the second case, it is clear that the only
5790  * 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>
5791  * are fixed to 1. It then calls
5792  * SCIPaddConflictLb() for both <code>vars[k][i]</code> and <code>vars[j][k]</code>.
5793  */
5794 
5795 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5796 /**@page REOPT How to use reoptimization
5797  *
5798  * The reoptimization feature of SCIP can be used to solve a sequence of optimization problems \f$(P_{i})_{i \in I}\f$ with
5799  * \f[
5800  * (P_i) \quad \min \{ c_i^T x \;|\; A^ix \geq b^i,\; x_{j} \in \{0,1\}^{n}\;\forall j \in \mathcal{I} \}
5801  * \f]
5802  * 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
5803  * fuction changes. To use reoptimization the user has to change the parameter <code>reoptimization/enable</code> to
5804  * <code>TRUE</code> before the solving process of the first problem of the sequence starts, i.e., in stage
5805  * <code>SCIP_STAGE_INIT</code> or <code>SCIP_STAGE_PROBLEM</code>. This can be done via the interactive shell or by
5806  * calling SCIPenableReoptimization(). In both cases SCIP changes some parameters and fixes them:
5807  * -# disable conflict analysis based on dual information
5808  * -# set the limit <code>maxorigsol</code> of stored solutions to zero because this is handled by a special solution tree provided
5809  * by the reoptimization feature itself
5810  * -# disable restarts (<code>presolving/maxrestarts = 0</code>)
5811  * -# disable multi-aggegations (<code>presolving/donotmultaggr = TRUE</code>)
5812  * -# disable dual reductions within presolvers and propagators (<code>misc/allowdualreds = FALSE</code>)
5813  * -# disable propagation with current cutoff bound (<code>misc/allowobjprop = FALSE</code>)
5814  *
5815  * In contrast to the presolving and propagating methods that are using dual information, performing strong branching is
5816  * allowed. The bound tightenings resulting from strong branching are handeled in a special way. After changing the objective
5817  * function and solving the modified problem the feasible region that was pruned by strong branching will be reconstructed
5818  * within the tree.
5819  *
5820  * If the reoptimization feature is enabled SCIP tries to reuse the search tree, especially the search frontier at the end
5821  * of the solving process, to speed up the solving process of the following problems. Therefore, the current release
5822  * provides the branching rule <code>branch_nodereopt</code> to reconstruct the tree. SCIP triggers a restart of the
5823  * reoptimization, i.e., solving the problem from scratch, if
5824  *
5825  * -# the stored search tree is too large,
5826  * -# the objective functions changed too much, or
5827  * -# the last \f$n\f$ optimal solution are updated solution of previous runs.
5828  *
5829  * The thresholds to trigger a restart can be set by the user:
5830  *
5831  * -# <code>reoptimization/maxsavednodes</code>
5832  * -# <code>reoptimization/delay</code>
5833  * -# <code>reoptimization/forceheurrestart</code>
5834  *
5835  * Before SCIP discards all the stored information and solves the problem from scratch it tries to compress the search
5836  * tree. Therefore, the current release provides compression heuristics that try to find a good and much smaller
5837  * representation of the current search tree.
5838  *
5839  * After a problem in the sequence of optimization problems was solved, the objective function can be changed in two ways:
5840  * -# Using the provided reader <code>reader_diff</code> the objective function can be changed via using the interactive
5841  * shell
5842  * \code
5843  * SCIP> read new_obj.diff
5844  * \endcode
5845  * or by calling SCIPreadDiff().
5846  * -# The objective function can be changed within the code. Therefore, the transformed problem needs to be freed by
5847  * calling SCIPfreeTransform(). Afterwards, the objective coefficient of each variable can be changed by calling
5848  * SCIPchgVarObj().
5849  *
5850  * After changing the objective function the modified problem can be solved as usal.
5851  *
5852  * \note Currently, the reoptimization feature only supports pure binary and mixed binary programs. In case the original
5853  * problem containts integer and implicit integer variables, reoptimization will be automatically disabled if there are
5854  * still (implicit) integer variables after presolving the problem.
5855  *
5856  * For more information on reoptimization we refer to@par
5857  * Jakob Witzig@n
5858  * Reoptimization Techniques in MIP Solvers@n
5859  * Master's Thesis, Technical University of Berlin, 2014.
5860  */
5861 
5862 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5863 /**@page OBJ Creating, capturing, releasing, and adding data objects
5864  *
5865  * Data objects (variables, constraints, rows, ... ) are subject to reference counting
5866  * to avoid expensive copying operations. This concept is similar to smart pointers.
5867  * Creating such an object (e.g., by calling SCIPcreateVar()) will set the
5868  * reference counter to one. Capturing an object (e.g., by calling SCIPcaptureVar()) increases the reference counter,
5869  * releasing it (e.g., by calling SCIPreleaseVar()) decreases the counter. If the reference counter gets zero, the
5870  * object will be destroyed automatically.
5871  *
5872  * Remember that a created data object is automatically captured. If the user
5873  * doesn't need the object anymore, (s)he has to call the object's release method.
5874  *
5875  * When a data object is added to SCIP (e.g., by calling SCIPaddVar()) , it is captured again, such that a
5876  * release call does not destroy the object. If SCIP doesn't need the object
5877  * anymore, it is automatically released.
5878  *
5879  * E.g., if the user calls
5880  * \code
5881  * SCIPcreateVar(); // reference counter 1
5882  * SCIPaddVar(); // reference counter 2
5883  * SCIPreleaseVar(); // reference counter 1
5884  * \endcode
5885  * the reference counter will be 1 afterwards, and the variable will be destroyed, if SCIP frees the problem.
5886  * If the user wants to use this variable, e.g. for extracting statistics after SCIP was finished, the user must not call
5887  * SCIPreleaseVar() right after adding the variable, but before terminating the program.
5888  */
5889 
5890 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5891 /**@page PARAM How to add additional user parameters
5892  *
5893  * Users may add their own parameters to SCIP by calling SCIPaddXyzParam(). Using
5894  * this method, there are two possibilities for where to store the actual parameter value:
5895  * - If the given valueptr is NULL, SCIP stores the parameter value internally, and
5896  * the user can only access the value with the SCIPgetXyzParam() and
5897  * SCIPsetXyzParam() calls.
5898  * - If the given valueptr is not NULL, SCIP stores the parameter value at the given
5899  * address, and the user can directly manipulate the value at this address.
5900  * (S)he has to be careful with memory management in string parameters: when the
5901  * SCIPaddStringParam() method is called, the given address must hold a char*
5902  * pointer with value NULL. The default value is then copied into this pointer,
5903  * allocating memory with BMSallocMemoryArray(). If the parameter is changed, the
5904  * old string is freed with BMSfreeMemoryArray() and the new one is copied to a new
5905  * memory area allocated with BMSallocMemoryArray(). When the parameter is freed,
5906  * the memory is freed with BMSfreeMemoryArray().
5907  * The user should not interfere with this internal memory management. Accessing
5908  * the string parameter through the given valueptr is okay as long as it does not
5909  * involve reallocating memory for the string.
5910  *
5911  * In some cases, it is necessary to keep track of changes in a parameter.
5912  * If this is the case, the user can define a method by the PARAMCHGD callback and use this method as
5913  * the @c paramchgd parameter of the @c SCIPaddXyzParam() method, also giving a pointer to the data, which is
5914  * needed in this method, as @c paramdata. If this method is not NULL, it is called every time
5915  * the value of the parameter is changed.
5916  */
5917 
5918 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5919 /**@page MEMORY Using the memory functions of SCIP
5920  *
5921  * SCIP provides three ways for allocating memory.
5922  *
5923  * @section STDMEM Standard memory
5924  *
5925  * SCIP provides an access to the standard C functions @c malloc and @c free with the additional feature of tracking
5926  * memory in debug mode. In this way, memory leaks can be easily detected. This feature is automatically activated in
5927  * debug mode.
5928  *
5929  * The most important functions are
5930  * - SCIPallocMemory(), SCIPallocMemoryArray() to allocate memory
5931  * - SCIPfreeMemory(), SCIPfreeMemoryArray() to free memory
5932  *
5933  * @section BLKMEM Block memory
5934  *
5935  * SCIP offers its own block memory handling, which allows efficient handling of smaller blocks of memory in cases in
5936  * which many blocks of the same (small) size appear. This is adaquate for branch-and-cut codes in which small blocks
5937  * of the same size are allocated and freed very often (for data structures used to store rows or branch-and-bound
5938  * nodes). Actually, most blocks allocated within SCIP have small sizes like 8, 16, 30, 32, 64. The idea is simple:
5939  * There is a separate list of memory blocks for each interesting small size. When allocating memory, the list is
5940  * checked for a free spot in the list; if no such spot exists the list is enlarged. Freeing just sets the block to be
5941  * available. Very large blocks are handled separatedly. See the dissertation of Tobias Achterberg for more details.
5942  *
5943  * One important comment is that freeing block memory requires the size of the block in order to find the right list.
5944  *
5945  * The most important functions are
5946  * - SCIPallocBlockMemory(), SCIPallocBlockMemoryArray() to allocate memory
5947  * - SCIPfreeBlockMemory(), SCIPfreeBlockMemoryArray() to free memory
5948  *
5949  * An example code is:
5950  * \code
5951  * SCIP_RETCODE dosomething(
5952  * SCIP* scip
5953  * )
5954  * {
5955  * int nvars;
5956  * int* array;
5957  *
5958  * nvars = SCIPgetNVars(scip);
5959  * SCIP_CALL( SCIPallocBlockMemoryArray(scip, &array, nvars) );
5960  *
5961  * do something ...
5962  *
5963  * SCIPfreeBlockMemoryArray(scip, &array, nvars);
5964  * }
5965  * \endcode
5966  *
5967  * @section BUFMEM Buffer memory
5968  *
5969  * In addition to block memory, SCIP offers buffer memory. This should be used if memory is locally
5970  * used within a function and freed within the same function. For this purpose, SCIP has a list of memory buffers
5971  * that are reused for this purpose. In this way, a very efficient allocation/freeing is possible.
5972  *
5973  * The most important functions are
5974  * - SCIPallocBufferMemory(), SCIPallocBufferArray() to allocate memory
5975  * - SCIPfreeBufferMemory(), SCIPfreeBufferArray() to free memory
5976  *
5977  * SCIP 3.2 introduced a new type of buffer memory, the clean buffer. It provides memory which is initialized to zero
5978  * and requires the user to reset the memory to zero before freeing it. This can be used at performance-critical
5979  * places where only few nonzeros are added to a dense array and removing these nonzeros individually is much faster
5980  * than clearing the whole array. Same as the normal buffer array, the clean buffer should be used for temporary memory
5981  * allocated and freed within the same function.
5982  *
5983  * The most important functions are
5984  * - SCIPallocCleanBufferArray() to allocate memory
5985  * - SCIPfreeCleanBufferArray() to free memory
5986  *
5987  * @section GENMEM General notes
5988  *
5989  * The following holds for all three types of memory functions:
5990  * - In debug mode the arguments are checked for overly large allocations (negative sizes are converted into very large values of type @c size_t).
5991  * - The functions always allocate at least one byte, so that freeing is always possible.
5992  * - The freeing methods set the pointer to the memory to NULL.
5993  * - For maximum speed you should free memory in the reverse order in which it was allocated.
5994  * For block and buffer memory this @b significantly speeds up the code.
5995  */
5996 
5997 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
5998 /**@page DEBUG Debugging
5999  *
6000  * If you need to debug your own code that uses SCIP, here are some tips and tricks:
6001  *
6002  * - Use <b>asserts</b> in your code to show preconditions for the parameters, invariants and postconditions.
6003  * Assertions are boolean expressions which inevitably have to evaluate to <code>TRUE</code>. Consider the
6004  * following example, taken from the file src/scip/cons_linear.c:
6005  * \code
6006  * SCIP_RETCODE consdataCatchEvent(
6007  * SCIP* scip, /**< SCIP data structure */
6008  * SCIP_CONSDATA* consdata, /**< linear constraint data */
6009  * SCIP_EVENTHDLR* eventhdlr, /**< event handler to call for the event processing */
6010  * int pos /**< array position of variable to catch bound change events for */
6011  * )
6012  * {
6013  * assert(scip != NULL);
6014  * assert(consdata != NULL);
6015  * assert(eventhdlr != NULL);
6016  * assert(0 <= pos && pos < consdata->nvars);
6017  * ...
6018  * }
6019  * \endcode
6020  * As you can see, both pointers and integers are checked for valid values at the beginning of the
6021  * function <code>consdataCatchEvent()</code>. This is particularly important for, e.g., array indices like
6022  * the variable <code>pos</code> in this example, where using the <code>consdata->nvars[pos]</code>
6023  * pointer could result in unexspected behaviour
6024  * if the asserted precondition on <code>pos</code> were not matched and <pos> were an arbitrary index
6025  * outside the array range.
6026  *
6027  * - In order to activate assertions, use the <b>Debug mode</b> by compiling SCIP via
6028  * \code
6029  * make OPT=dbg
6030  * \endcode and run the code. See \ref MAKE for further information about compiler options for SCIP.
6031  *
6032  * - Spending only little extra time on
6033  * asserting preconditions saves most of the time spent on debugging!
6034  *
6035  * - Turn on <b>additional debug output</b> by adding the line
6036  * \code
6037  * #define SCIP_DEBUG
6038  * \endcode
6039  * at the top of SCIP files you want to analyze. This will output messages included in the code using
6040  * <code>SCIPdebugMessage()</code> (see \ref EXAMPLE_1).
6041  * We recommend to also use <code>SCIPdebugMessage()</code> in your own code for being able to activate
6042  * debug output in the same way.
6043  * - If available on your system, we recommend to use a debugger like <code>gdb</code>
6044  * to trace all function calls on the stack,
6045  * display values of certain expressions, manually break the running code, and so forth.
6046  * - If available on your system, you can use software like <a href="http://valgrind.org">valgrind</a> to check for uninitialized
6047  * values or segmentation faults.
6048  * - For checking the usage of SCIP memory, you can use
6049  * <code>SCIPprintMemoryDiagnostic()</code>. This outputs memory that is currently in use,
6050  * which can be useful after a <code>SCIPfree()</code> call.
6051  * - If there are memory leaks for which you cannot detect the origin, you can remake your code with the option NOBLKBUFMEM=true
6052  * (do not forget to clean your code before with <code>make OPT=... LPS=... clean</code>). After that valgrind (or similar) helps
6053  * to detect leaked memory.
6054  * - If your code cuts off a feasible solution, but you do not know which component is responsible,
6055  * you can define <code>SCIP_DEBUG_SOLUTION</code> in the file <code>debug.h</code> to be a filename
6056  * containing a solution in SCIP format (see \ref EXAMPLE_2).
6057  * This solution is then read and it is checked for every cut, whether the solution violates the cut.
6058  *
6059  * @section EXAMPLE_1 How to activate debug messages
6060  * For example, if we include a <code>\#define SCIP_DEBUG</code> at the top of \ref heur_oneopt.h, recompile SCIP
6061  * in DBG mode, and run the SCIP interactive shell to solve p0033.mps from the
6062  * <a href="http://miplib.zib.de/miplib3/miplib.html">MIPLIB 3.0</a> , we get some output like:
6063  * \code
6064  * SCIP version 1.1.0 [precision: 8 byte] [memory: block] [mode: debug] [LP solver: SoPlex 1.4.0]
6065  * Copyright (c) 2002-2016 Konrad-Zuse-Zentrum fuer Informationstechnik Berlin (ZIB)
6066  *
6067  * user parameter file <scip.set> not found - using default parameters
6068  *
6069  * SCIP> read check/IP/miplib/p0033.mps
6070  * original problem has 33 variables (33 bin, 0 int, 0 impl, 0 cont) and 16 constraints
6071  * SCIP> optimize
6072  * ...
6073  * 0.1s| 1 | 0 | 132 | 257k| 0 | 14 | 30 | 13 | 13 | 30 | 51 | 39 | 0 | 0 | 3.026472e+03 | 3.347000e+03 | 10.59%
6074  * [src/scip/heur_oneopt.c:332] debug: Row <R122> has activity 110
6075  * [src/scip/heur_oneopt.c:332] debug: Row <R123> has activity 216
6076  * ...
6077  * [src/scip/heur_oneopt.c:101] debug: Try to shift down variable <t_C157> with
6078  * [src/scip/heur_oneopt.c:102] debug: lb:<-0> <= val:<1> <= ub:<1> and obj:<171> by at most: <1>
6079  * [src/scip/heur_oneopt.c:135] debug: -> The shift value had to be reduced to <0>, because of row <R122>.
6080  * [src/scip/heur_oneopt.c:137] debug: lhs:<-1e+20> <= act:<110> <= rhs:<148>, colval:<-60>
6081  * ...
6082  * [src/scip/heur_oneopt.c:383] debug: Only one shiftcand found, var <t_C167>, which is now shifted by<-1.0>
6083  * 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%
6084  * [src/scip/heur_oneopt.c:436] debug: found feasible shifted solution:
6085  * objective value: 3164.00000000012
6086  * C157 1 (obj:171)
6087  * C163 1 (obj:163)
6088  * C164 1 (obj:69)
6089  * C170 1 (obj:49)
6090  * C172 1 (obj:258)
6091  * C174 1 (obj:250)
6092  * C175 1 (obj:500)
6093  * C179 1 (obj:318)
6094  * C181 1 (obj:318)
6095  * C182 1 (obj:159)
6096  * C183 1.00000000000038 (obj:318)
6097  * C184 1 (obj:159)
6098  * C185 1 (obj:318)
6099  * C186 1 (obj:114)
6100  * [src/scip/heur_oneopt.c:498] debug: Finished 1-opt heuristic
6101  * ...
6102  * \endcode
6103  *
6104  * @section EXAMPLE_2 How to add a debug solution
6105  *
6106  * Continuing the example above, we finish the solving process.
6107  * The optimal solution can now be written to a file:
6108  * \code
6109  * SCIP> display solution
6110  *
6111  * objective value: 3089
6112  * C157 1 (obj:171)
6113  * C163 1 (obj:163)
6114  * C164 1 (obj:69)
6115  * C166 1 (obj:183)
6116  * C170 1 (obj:49)
6117  * C174 1 (obj:250)
6118  * C177 1 (obj:500)
6119  * C179 1 (obj:318)
6120  * C181 1 (obj:318)
6121  * C182 1 (obj:159)
6122  * C183 1 (obj:318)
6123  * C184 1 (obj:159)
6124  * C185 1 (obj:318)
6125  * C186 1 (obj:114)
6126  *
6127  * SCIP> write solution check/p0033.sol
6128  *
6129  * written solution information to file <check/p0033.sol>
6130  * \endcode
6131  *
6132  * If we afterwards use
6133  * <code>\#define SCIP_DEBUG_SOLUTION "check/p0033.sol"</code> in debug.h, recompile and run SCIP,
6134  * it will output:
6135  * \code
6136  * SCIP> read check/IP/miplib/p0033.mps
6137  * original problem has 33 variables (33 bin, 0 int, 0 impl, 0 cont) and 16 constraints
6138  * SCIP> optimize
6139  *
6140  * presolving:
6141  * ***** debug: reading solution file <check/p0033.sol>
6142  * ***** debug: read 15 non-zero entries
6143  * \endcode
6144  * Further debug output would only appear, if the solution was cut off in the solving process.
6145  * Of course, this is not the case! Hopefully...otherwise, please send a bug report ;-)
6146  */
6147 
6148 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6149 /**@page TEST How to run automated tests with SCIP
6150  *
6151  * SCIP comes along with a set of useful tools that allow to perform automated tests. The
6152  * following is a step-by-step guide from setting up the test environment for evaluation and
6153  * customization of test runs.
6154  *
6155  *
6156  * @section SETUP Setting up the test environment
6157  *
6158  * At first you should create a file listing all problem instances that should be part of the test.
6159  * This file has to be located in the the directory <code>scip/check/testset/</code>
6160  * and has to have the file extension <code>.test</code>, e.g., <code>testrun.test</code>,
6161  * in order to be found by the <code>scip/check/check.sh</code> script.
6162  * \n
6163  * All test problems can be listed in the <code>test</code>-file by a relative path,
6164  * e.g., <code>../../problems/instance1.lp</code> or absolute path, e.g., <code>/home/problems/instance2.mps</code>
6165  * in this file. Only one problem should be listed on every line (since the command <code>cat</code> is used to parse this file).
6166  * Note that these problems have to be readable for SCIP in order to solve them.
6167  * However, you can use different file formats.
6168  *
6169  * Optionally, you can provide a solution file in the <code>scip/check/testset/</code> directory containing
6170  * known information about the feasibility and the best known objective values for the test instances.
6171  * SCIP can use these values to verify the results. The file has to have the same basename as the
6172  * <code>.test</code>-file, i.e., in our case <code>testrun.solu</code>. One line can only contain
6173  * information about one test instance. A line has to start with the type of information given:
6174  *
6175  * - <code>=opt=</code> stating that a problem name with an optimal objective value follows
6176  * - <code>=best=</code> stating that a problem name with a best know objective value follows
6177  * - <code>=inf=</code> stating that a problem name follows which is infeasible
6178  *
6179  * With these information types you can encode for an instance named <code>instance1.lp</code> the following
6180  * information:
6181  * - The instance has a known optimal (objective) value of 10.
6182  * \code
6183  * =opt= instance1 10
6184  * \endcode
6185  * - The instance has a best known solution with objective value 15.
6186  * \code
6187  * =best= instance1 15
6188  * \endcode
6189  * - The instance is feasible (but has no objective function or we don't know a solution value)
6190  * \code
6191  * =feas= instance1
6192  * \endcode
6193  * - The instance is infeasible.
6194  * \code
6195  * =inf= instance1
6196  * \endcode
6197  *
6198  * If you don't know whether the instance is feasible or not (so the status is unknown),
6199  * you can omit the instance in the <code>solu</code>-file or write
6200  * \code
6201  * =unkn= instance1
6202  * \endcode
6203  *
6204  * <b>Note that in all lines the file extension of the file name is omitted.</b>
6205  * \n
6206  * See the files <code>scip/check/testset/short.test</code> and <code>scip/check/testset/short.solu</code>
6207  * for an example of a <code>test</code>-file and its corresponding <code>solu</code>-file.
6208  *
6209  *
6210  *
6211  * @section STARTING Starting a test run
6212  *
6213  *
6214  * \code
6215  * make TEST=testrun test
6216  * \endcode
6217  *
6218  * in the SCIP root directory. Note that <code>testrun</code> is exactly the basename of our
6219  * <code>test</code>-file (<code>testrun.test</code>). This will cause SCIP to solve our test instances
6220  * one after another and to create various output files (see \ref EVAL).
6221  *
6222  *
6223  * @section EVAL Evaluating a test run
6224  *
6225  * During computation, SCIP automatically creates the directory <code>scip/check/results/</code>
6226  * (if it does not already exist) and stores the following output files there.
6227  *
6228  * \arg <code>*.out</code> - output of <code>stdout</code>
6229  * \arg <code>*.err</code> - output of <code>stderr</code>
6230  * \arg <code>*.set</code> - copy of the used settings file
6231  *
6232  * \arg <code>*.res</code> - ASCII table containing a summary of the computational results
6233  * \arg <code>*.tex</code> - TeX table containing a summary of the computational results
6234  * \arg <code>*.pav</code> - <a href="http://www.gamsworld.org/performance/paver/">PAVER</a> output
6235  *
6236  * The last three files in the above list, i.e., the files containing a summary of the computational results,
6237  * can also be generated manually. Therefore the user has to call the <code>evalcheck.sh</code> script in the
6238  * @c check directory with the corresponding @c out file as argument. For example, this may be useful if the user stopped the
6239  * test before it was finished, in which case the last three files will not be automatically generated by SCIP.
6240  *
6241  * The last column of the ASCII summary table contains the solver status. We distinguish the following statuses: (in order of priority)
6242  *
6243  * \arg abort: solver broke before returning solution
6244  * \arg fail: solver cut off a known feasible solution (value of the <code>solu</code>-file is beyond the dual bound;
6245  * especially if problem is claimed to be solved but solution is not the optimal solution)
6246  * <b>or</b> if a final solution check revealed a violation of one of the original constraints.
6247  * \arg ok: solver solved problem with the value in solu-file
6248  * \arg solved: solver solved problem which has no (optimal) value in solu-file (since we here cannot detect the direction
6249  * of optimization, it is possible that a solver claims an optimal solution which contradicts a known feasible solution)
6250  * \arg better: solver found solution better than known best solution (or no solution was noted in the <code>solu</code>-file so far)
6251  * \arg gaplimit, sollimit: solver reached gaplimit or limit of number of solutions (at present: only in SCIP)
6252  * \arg timeout: solver reached any other limit (like time or nodes)
6253  * \arg unknown: otherwise
6254  *
6255  * Additionally the <code>evalcheck.sh</code> script can generate a <code>solu</code>-file by calling
6256  * \code
6257  * ./evalcheck.sh writesolufile=1 NEWSOLUFILE=<solu-file> <out-file>
6258  * \endcode
6259  * where <code><solu-file></code> denotes the filename of the new file where the solutions shall be
6260  * (and <code><out-file></code> denotes the output (<code>.out</code>) files to evaluate).
6261  *
6262  * Another feature can be enabled by calling:
6263  * \code
6264  * ./evalcheck.sh printsoltimes=1 ...
6265  * \endcode
6266  * The output has two additional columns containing the solving time until the first and the best solution was found.
6267  *
6268  *
6269  * @b Note: The @em basename of all these files is the same and has the following structure
6270  * which allows us to reconstruct the test run:
6271  *
6272  * \code
6273  * check.<test name>.<binary>.<machine name>.<setting name>
6274  * \endcode
6275  *
6276  * \arg <<code>test name</code>> indicates the name of the the test file, e.g., <code>testrun</code>
6277  * \arg <<code>binary</code>> defines the used binary, e.g., <code>scip-3.2.0.linux.x86_64.gnu.opt.spx</code>
6278  * \arg <<code>machine name</code>> tells the name of the machine, e.g., <code>mycomputer</code>
6279  * \arg <<code>setting name</code>> denotes the name of the used settings, e.g., <code>default</code>
6280  * means the (SCIP) default settings were used
6281  *
6282  * Using the examples out of the previous listing the six file names would have the name:
6283  *
6284  * \code
6285  * check.testrun.scip-1.1.0.linux.x86.gnu.opt.spx.mycomputer.default.<out,err,set,res,tex,pav>
6286  * \endcode
6287  *
6288  *
6289  * @section USING Using customized setting files
6290  *
6291  * It is possible to use customized settings files for the test run instead of testing SCIP with default settings.
6292  * These have to be placed in the directory <code>scip/settings/</code>.
6293  *
6294  * @b Note: Several common user parameters such as, e.g., the time limit and node limit parameters,
6295  * <b>cannot</b> be controlled by the settings file, whose specifications would be overwritten
6296  * by optional command line arguments to the <code>make test</code> command, see @ref ADVANCED
6297  * for a list of available advanced testing options that have to be specified from the command line.
6298  *
6299  * @b Note: Accessing settings files in subfolders of the @c settings directory is currently not supported.
6300  *
6301  * To run SCIP with a custom settings file, say for example <code>fast.set</code>, we call
6302  *
6303  * \code
6304  * make TEST=testrun SETTINGS=fast test
6305  * \endcode
6306  *
6307  * in the SCIP root directory. It is possible to enter a list of settings files as a double-quoted,
6308  * comma-separated list of settings names as <code>fast</code> above, i.e. <code>SETTINGS="fast,medium,slow"</code>
6309  * will invoke the solution process for every instance with the three settings <code>fast.set, medium.set, slow.set</code>
6310  * before continuing with the next instance from the <code>.test</code>-file. This may come in handy if the
6311  * whole test runs for a longer time and partial results are already available.
6312  *
6313  *
6314  * @section ADVANCED Advanced options
6315  *
6316  * We can further customize the test run by specifying the following options in the <code>make</code> call:
6317  *
6318  * \arg <code>CONTINUE</code> - continue the test run if it was previously aborted [default: "false"]
6319  * \arg <code>DISPFREQ</code> - display frequency of the output [default: 10000]
6320  * \arg <code>FEASTOL</code> - LP feasibility tolerance for constraints [default: "default"]
6321  * \arg <code>LOCK</code> - should the test run be locked to prevent other machines from performing the same test run [default: "false"]
6322  * \arg <code>MAXJOBS=n</code> - run tests on 'n' cores in parallel. Note that several instances are solved in parallel, but
6323  * only one thread is used per job (parallelization is not that easy) [default: 1]
6324  * \arg <code>MEM</code> - memory limit in MB [default: 6144]
6325  * \arg <code>NODES</code> - node limit [default: 2100000000]
6326  * \arg <code>TIME</code> - time limit for each test instance in seconds [default: 3600]
6327  * \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]
6328  * \arg <code>THREADS</code> - the number of threads used for solving LPs, if the linked LP solver supports multithreading [default: 1]
6329  * \arg <code>VALGRIND</code> - run valgrind on the SCIP binary; errors and memory leaks found by valgrind are reported as fails [default: "false"]
6330  *
6331  *
6332  * @section COMPARE Comparing test runs for different settings
6333  *
6334  * Often test runs are performed on the basis of different settings. In this case, it is useful to
6335  * have a performance comparison. For this purpose, we can use the <code>allcmpres.sh</code> script in
6336  * the @c check directory.
6337  *
6338  * Suppose, we performed our test run with two different settings, say <code>fast.set</code> and
6339  * <code>slow.set</code>. Assuming that all other parameters (including the SCIP binary), were the same,
6340  * we may have the following <code>res</code>-files in the directory <code>scip/check/results/</code>
6341  *
6342  * \code
6343  * check.testrun.scip-3.2.0.linux.x86_64.gnu.opt.spx.mycomputer.fast.res
6344  * check.testrun.scip-3.2.0.linux.x86_64.gnu.opt.spx.mycomputer.slow.res
6345  * \endcode
6346  *
6347  * For a comparison of both computations, we simply call
6348  *
6349  * \code
6350  * allcmpres.sh results/check.testrun.scip-3.2.0.linux.x86_64.gnu.opt.spx.mycomputer.fast.res \
6351  * results/check.testrun.scip-3.2.0.linux.x86_64.gnu.opt.spx.mycomputer.slow.res
6352  * \endcode
6353  *
6354  * in the @c check directory. This produces an ASCII table on the console that provide a detailed
6355  * performance comparison of both test runs. Note that the first <code>res</code>-file serves as reference
6356  * computation. The following list explains the output.
6357  * (The term "solver" can be considered as the combination of SCIP with a specific setting file.)
6358  *
6359  * \arg <code>Nodes</code> - Number of processed branch-and-bound nodes.
6360  * \arg <code>Time</code> - Computation time in seconds.
6361  * \arg <code>F</code> - If no feasible solution was found, then '#', empty otherwise.
6362  * \arg <code>NodQ</code> - Equals Nodes(i) / Nodes(0), where 'i' denotes the current solver and '0' stands for the reference solver.
6363  * \arg <code>TimQ</code> - Equals Time(i) / Time(0).
6364  * \arg <code>bounds check</code> - Status of the primal and dual bound check.
6365  *
6366  * \arg <code>proc</code> - Number of instances processed.
6367  * \arg <code>eval</code> - Number of instances evaluated (bounds check = "ok", i.e., solved to optimality
6368  * within the time and memory limit and result is correct). Only these instances are used in the calculation
6369  * of the mean values.
6370  * \arg <code>fail</code> - Number of instances with bounds check = "fail".
6371  * \arg <code>time</code> - Number of instances with timeout.
6372  * \arg <code>solv</code> - Number of instances correctly solved within the time limit.
6373  * \arg <code>wins</code> - Number of instances on which the solver won (i.e., the
6374  * solver was at most 10% slower than the fastest solver OR had the best
6375  * primal bound in case the instance was not solved by any solver within
6376  * the time limit).
6377  * \arg <code>bett</code> - Number of instances on which the solver was better than the
6378  * reference solver (i.e., more than 10% faster).
6379  * \arg <code>wors</code> - Number of instances on which the solver was worse than the
6380  * reference solver (i.e., more than 10% slower).
6381  * \arg <code>bobj</code> - Number of instances on which the solver had a better primal
6382  * bound than the reference solver (i.e., a difference larger than 10%).
6383  * \arg <code>wobj</code> - Number of instances on which the solver had a worse primal
6384  * bound than the reference solver (i.e., a difference larger than 10%).
6385  * \arg <code>feas</code> - Number of instances for which a feasible solution was found.
6386  * \arg <code>gnodes</code> - Geometric mean of the processed nodes over all evaluated instances.
6387  * \arg <code>shnodes</code> - Shifted geometric mean of the processed nodes over all evaluated instances.
6388  * \arg <code>gnodesQ</code> - Equals nodes(i) / nodes(0), where 'i' denotes the current
6389  * solver and '0' stands for the reference solver.
6390  * \arg <code>shnodesQ</code> - Equals shnodes(i) / shnodes(0).
6391  * \arg <code>gtime</code> - Geometric mean of the computation time over all evaluated instances.
6392  * \arg <code>shtime</code> - Shifted geometric mean of the computation time over all evaluated instances.
6393  * \arg <code>gtimeQ</code> - Equals time(i) / time(0).
6394  * \arg <code>shtimeQ</code> - Equals shtime(i) / shtime(0).
6395  * \arg <code>score</code> - N/A
6396  *
6397  * \arg <code>all</code> - All solvers.
6398  * \arg <code>optimal auto settings</code> - Theoretical result for a solver that performed 'best of all' for every instance.
6399  * \arg <code>diff</code> - Solvers with instances that differ from the reference solver in the number of
6400  * processed nodes or in the total number of simplex iterations.
6401  * \arg <code>equal</code> - Solvers with instances whose number of processed nodes and total number of
6402  * simplex iterations is equal to the reference solver (including a 10% tolerance) and where no timeout
6403  * occured.
6404  * \arg <code>all optimal</code> - Solvers with instances that could be solved to optimality by
6405  * <em>all</em> solvers; in particular, no timeout occurred.
6406  *
6407  * Since this large amount of information is not always needed, one can generate a narrower table by calling:
6408  * \code
6409  * allcmpres.sh short=1 ...
6410  * \endcode
6411  * where <code>NodQ</code>, <code>TimQ</code> and the additional comparison tables are omitted.
6412  *
6413  * If the <code>res</code>-files were generated with the parameter <code>printsoltimes=1</code>
6414  * we can enable the same feature here as well by calling:
6415  * \code
6416  * allcmpres.sh printsoltimes=1 ...
6417  * \endcode
6418  * As in the evaluation, the output contains the two additional columns of the solving time until the first and the best solution was found.
6419  *
6420  * @section STATISTICS Statistical tests
6421  *
6422  * The \c allcmpres script also performs two statistical tests for comparing different settings: For deciding whether
6423  * more feasible solutions have been found or more instances have been solved to optimality or not, we use a McNemar
6424  * test. For comparing the running time and number of nodes, we use a variant of the Wilcoxon signed rank test. A
6425  * detailed explanation can be found in the PhD thesis of Timo Berthold (Heuristic algorithms in global MINLP solvers).
6426  *
6427  * @subsection McNemar McNemar test
6428  *
6429  * Assume that we compare two settings \c S1 and \c S2 with respect to the number of instances solved to optimality
6430  * within the timelimit. The null hypothesis would be "Both settings lead to an equal number of instances being solved
6431  * to optimality", which we would like to disprove. Let \f$n_1\f$ be the number of instances solved by setting \c S1
6432  * 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
6433  * McNemar test statistic is
6434  * \f[
6435  * \chi^2 = \frac{(n_1 - n_2)^2}{n_1 + n_2}.
6436  * \f]
6437  * Under the null hypothesis, \f$\chi^2\f$ is chi-squared distributed with one degree of freedom. This allows to compute
6438  * a \f$p\f$-value as the probability for obtaining a similar or even more extreme result under the null hypothesis.
6439  * More explicitly, \c allcmpres uses the following evaluation:
6440  * - \f$0.05 < p\f$: The null hypothesis is accepted (marked by "X").
6441  * - \f$0.005 < p \leq 0.05\f$: The null hypothesis might be false (marked by "!").
6442  * - \f$0.0005 < p \leq 0.005\f$: The null hypothesis can be false (marked by "!!").
6443  * - \f$p \leq 0.0005\f$: The null hypothesis is very likely false (marked by "!!!").
6444  *
6445  * As an example consider the following output:
6446  * \code
6447  * McNemar (feas) x2 0.0000, 0.05 < p X
6448  * McNemar (opt) x2 6.0000, p ~ (0.005, 0.05] !
6449  * \endcode
6450  * Here, \c x2 represents \f$\chi^2\f$.
6451  *
6452  * In this case, the test with respect to the number of found feasible solutions is irrelevant, since their number is
6453  * equal. In particular, the null hypothesis gets accepted (i.e., there is no difference in the settings - this is
6454  * marked by "X").
6455  *
6456  * With respect to the number of instances solved to optimality within the timelimit, we have that \f$0.005 < p <=
6457  * 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
6458  * settings perform differently; this is marked by "!". In the concrete case, we have 230 instances, all of which are
6459  * solved by setting \c S2, but only 224 by setting \c S1.
6460  *
6461  * @subsection Wilcoxon Wilcoxon signed rank test
6462  *
6463  * Assume that we compare two settings \c S1 and \c S2 with respect to their solution times (within the time limit). We
6464  * generate a sorted list of the ratios of the run times, where ratios that are (absolutely or relatively) within 1\%
6465  * of 1.0 are discarded, and ratios between 0.0 and 0.99 are replaced with their negative inverse in order to
6466  * obtain a symmetric distribution for the ratios around the origin.
6467  * We then assign ranks 1 to \c N to the remaining \c N data points in nondecreasing
6468  * order of their absolute ratio. This yields two groups \c G1
6469  * 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
6470  * setting \c S1 is faster). Then the sums of the ranks in groups \c G1 and \c G2 are computed, yielding values \c R1
6471  * and \c R2, respectively.
6472  *
6473  * The Wilcoxon test statistic is then
6474  * \f[
6475  * z = \frac{\min(R1, R2) - \frac{N(N+1)}{4}}{\sqrt{\frac{N(N+1)(2N+1)}{24}}},
6476  * \f]
6477  * which we assume to be (approximately) normally distributed (with zero mean) and allows to compute the probability
6478  * \f$p\f$ that one setting is faster than the other. (Note that for \f$N \leq 60\f$, we apply a correction by
6479  * subtracting 0.5 from the numerator).
6480  *
6481  * As an example consider the following output:
6482  * \code
6483  * Wilcoxon (time) z -0.1285, 0.05 <= p X
6484  * Wilcoxon (nodes) z -11.9154, p < 0.0005 !!!
6485  * \endcode
6486  * While the \f$z\f$-value is close to zero for the run time, it is extremely negative regarding the solving nodes. This latter
6487  * 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
6488  * nodes than setting \c S2 is negligible (this null hypothesis is rejected - marked by "!!!").
6489  *
6490  * However, the null hypothesis is not rejected with respect to the run time. In the concrete case, setting \c S1 has a
6491  * 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
6492  * 0.88. Still - the null hypothesis is not rejected.
6493  *
6494  * @section SOLVER Testing and Evaluating for other solvers
6495  *
6496  * Analogously to the target <code>test</code> there are further targets to run automated tests with other MIP solvers.
6497  * These are:
6498  * \arg for <a href="http://www-01.ibm.com/software/integration/optimization/cplex-optimizer/">cplex</a>
6499  * \code
6500  * make testcplex
6501  * \endcode
6502  * \arg for <a href="http://www.gurobi.com/">gurobi</a>
6503  * \code
6504  * make testgurobi
6505  * \endcode
6506  * \arg for <a href="https://projects.coin-or.org/Cbc">cbc</a>
6507  * \code
6508  * make testcbc
6509  * \endcode
6510  * \arg for <a href="http://www.mosek.com/">mosek</a>
6511  * \code
6512  * make testmosek
6513  * \endcode
6514  * \arg for <a href="http://www.gnu.org/software/glpk/">glpk</a>
6515  * \code
6516  * make testglpk
6517  * \endcode
6518  * \arg for <a href="https://projects.coin-or.org/SYMPHONY">symphony</a>
6519  * \code
6520  * make testsymphony
6521  * \endcode
6522  * \arg for <a href="https://projects.coin-or.org/CHiPPS">blis</a>
6523  * \code
6524  * make testblis
6525  * \endcode
6526  * \arg for <a href="http://www.gams.com/">gams</a>
6527  * \code
6528  * make testgams GAMSSOLVER=xyz
6529  * \endcode
6530  * For this target, the option GAMSSOLVER has to be given to specify the name of a GAMS solver to run, e.g. GAMSSOLVER=SCIP.
6531  * Additional advanced options specific to this target are:
6532  * GAMS to specify the GAMS executable (default: gams),
6533  * GAP to specify a gap limit (default: 0.0),
6534  * CLIENTTMPDIR to specify a directory where GAMS should put its scratch files (default: /tmp),
6535  * 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).
6536  * The following options are NOT supported (and ignored): DISPFREQ, FEASTOL, LOCK.
6537  * 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).
6538  *
6539  * Note: This works only if the referred programs are installed globally on your machine.
6540  *
6541  * The above options like <code>TIME</code> are also available for the other solvers.
6542  *
6543  * For cbc, cplex, gams, and gurobi another advanced option is available:
6544  * \arg <code>THREADS</code> - number of threads used in the solution process
6545  *
6546  * After the testrun there should be an <code>.out</code>, an <code>.err</code> and a <code>.res</code> file
6547  * with the same basename as described above.
6548  *
6549  * Furthermore you can also use the script <code>allcmpres.sh</code> for comparing results of different solvers.
6550  *
6551  */
6552 
6553 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6554 /**@page CHG1 Interface changes between SCIP 0.9 and SCIP 1.0
6555  *
6556  * @section CHGPARAM New parameters
6557  *
6558  * - All functions SCIP<datatype>Param() got a new parameter "isadvanced".
6559  * \n
6560  * This does not influence the performance of SCIP, but the position of the parameter in the settings menu.
6561  * Hence, if you do not care about this, you can assign any value to it.
6562  * You should add the corresponding flag to the SCIP<datatype>Param() calls in your own source code.
6563  *
6564  */
6565 
6566 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6567 /**@page CHG2 Interface changes between SCIP 1.0 and SCIP 1.1
6568  *
6569  * - SCIPcreateChild() has a new last parameter giving an estimate for value of best feasible solution in the subtree to
6570  * be created. One possibility is to use SCIPgetLocalOrigEstimate() for this value.
6571  *
6572  * - The callback \ref CONSCHECK in the constraint handlers now has a new parameter <code>printreason</code> that tells
6573  * a constraint handler to output the reason for a possible infeasibility of the solution to be checked using
6574  * SCIPinfoMessage(). Have a look at one of the constraint handlers implemented in SCIP to see how it works. This
6575  * methodology makes it possible to output the reason of a violation in human readable form, for instance, for the check
6576  * at the end of a SCIP run, where the obtained best solution is checked against the original formulation.\n This change
6577  * often has little effect on C-implementations, since this parameter can be safely ignored with respect to the
6578  * correctness of the code. The corresponding C++ method scip::ObjConshdlr::scip_check(), however, has to be extended
6579  * and will not compile otherwise.
6580  *
6581  * - SCIPcheckSolOrig() is restructured. The last two parameters have changed. They are now bools indicating
6582  * whether the reason for the violation should be printed to the standard output and whether all violations should be
6583  * printed. This reflects the changes in the constraint handlers above, which allow the automation of the feasibility
6584  * test. The pointers to store the constraint handler or constraint are not needed anymore.
6585  *
6586  * - New parameters "extension" and "genericnames" in SCIPprintTransProblem(), SCIPprintOrigProblem(),
6587  * SCIPwriteOrigProblem(), and SCIPwriteTransProblem() defining the requested format or NULL for default CIP format
6588  * and using generic names for the variables and constraints. Examples are
6589  * - <code>SCIPprintTransProblem(scip, NULL, NULL, TRUE)</code> displays the transformed problem in CIP format with
6590  * generic variables and constraint names
6591  * - <code>SCIPprintOrigProblem(scip, NULL, "lp", FALSE)</code> displays the original problem in LP format with
6592  * original variables and constraint names.
6593  *
6594  * - New callback method SCIP_DECL_READERWRITE(x) in type_reader.h; this method is called to write a problem to file
6595  * stream in the format the reader stands for; useful for writing the transformed problem in LP or MPS format. Hence,
6596  * also SCIPincludeReader() has changed.
6597  *
6598  * - New parameter "conshdlrname" in SCIPincludeLinconsUpgrade().
6599  *
6600  * - Added user pointer to callback methods of hash table, see pub_misc.h.
6601  *
6602  * - New parameter "extension" in SCIPreadProb(), defining a desired file format or NULL if file extension should be used.
6603  */
6604 
6605 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6606 /**@page CHG3 Interface changes between SCIP 1.1 and SCIP 1.2
6607  *
6608  *
6609  * @section CHGCALLBACKS New and changed callbacks
6610  *
6611  * - The callback SCIP_DECL_PRICERREDCOST(x) in the \ref PRICER "pricers" has two new parameters:
6612  * - A <code>result</code> pointer determines whether the pricer guarantees that there exist no more variables. This allows for early branching.
6613  * - A pointer for providing a lower bound.
6614  *
6615  * - The \ref CONS "constraint handlers" have two new callback methods (see type_cons.h for more details).
6616  * - SCIP_DECL_CONSCOPY(x) - this method can be used to copy a constraint.
6617  * - SCIP_DECL_CONSPARSE(x) - this method can be used to parse a constraint in CIP format.
6618  *
6619  * @section CHGINTERFUNC New parameters in interface methods
6620  *
6621  * - SCIPcalcMIR() in scip.h has two new parameter "mksetcoefsvalid" and "sol". The parameter "mksetcoefsvalid" stores
6622  * whether the coefficients of the mixed knapsack set ("mksetcoefs") computed in SCIPlpCalcMIR() are valid. If the mixed knapsack constraint obtained after aggregating LP rows
6623  * 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.
6624  * The input parameter "sol" can be used to separate a solution different from the LP solution.
6625  *
6626  * - 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.
6627  *
6628  * @section MISCELLANEOUS Miscellaneous
6629  *
6630  * - A significant change for <b>C++ users</b> is that all include files of SCIP
6631  * automatically detect C++ mode, i.e., no <code>extern "C"</code> is needed anymore.
6632  *
6633  * For further release notes we refer to the \ref RELEASENOTES "Release notes".
6634  */
6635 
6636 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6637 /**@page CHG4 Interface changes between SCIP 1.2 and SCIP 2.0
6638  *
6639  *
6640  * @section CHGCALLBACKS4 New and changed callbacks
6641  *
6642  *
6643  * - <b>Copying a SCIP instance</b>:
6644  * <br>
6645  * <br>
6646  * - All plugins, like \ref BRANCH "branching rules" and \ref HEUR "primal heuristics", have a new callback method (see, e.g.,
6647  * type_branch.h and type_heur.h for more details):
6648  * - SCIP_DECL_BRANCHCOPY(x), SCIP_DECL_HEURCOPY(x) etc.
6649  * - When copying a SCIP instance, these methods are called to copy the plugins.
6650  * <br>
6651  * <br>
6652  * - Constraint handlers have two new callback methods. One for copying the constraint handler plugins
6653  * SCIP_DECL_CONSHDLRCOPY() and the other for copying a constraint itself, SCIP_DECL_CONSCOPY().
6654  * <br>
6655  * <br>
6656  * - Variables have a new callback method (see type_var.h for more details):
6657  * - SCIP_DECL_VARCOPY(x) - When copying a SCIP instance, this method is called to copy the variables' data.
6658  * <br>
6659  * <br>
6660  * - The main problem has a new callback method (see type_prob.h for more details):
6661  * - SCIP_DECL_PROBCOPY(x) - When copying a SCIP instance, this method is called to copy the problem's data.
6662  * <br>
6663  * <br>
6664  * - The argument success in SCIP_DECL_CONSCOPY has been renamed to valid.
6665  *
6666  * - <b>Branching on externally given candidates</b>:
6667  * <br>
6668  * <br>
6669  * - The \ref BRANCH "branching rules" have a second new callback method (see type_branch.h for more details):
6670  * - SCIP_DECL_BRANCHEXECEXT(x) - This method can be used to branch on external branching candidates,
6671  * which can be added by a user's "relaxation handler" or "constraint handler" plugin, calling <code>SCIPaddExternBranchCand()</code>.
6672  *
6673  * - <b>Restarts</b>:
6674  * <br>
6675  * <br>
6676  * - The callback SCIP_DECL_PROBEXITSOL(x) in the main problem has one new parameter (see type_prob.h for more details):
6677  * - The parameter <code>restart</code> is <code>TRUE</code> if the callback method was triggered by a restart.
6678  *
6679  *
6680  * <br>
6681  * @section CHGINTERFUNC4 Changed interface methods
6682  *
6683  * - <b>Copying a SCIP instance</b>:
6684  * <br>
6685  * <br>
6686  * - Every new callback method resulted in a new parameter of the include function for the corresponding plugin,
6687  * e.g., SCIPincludeBranchrule() has two new parameters <code>SCIP_DECL_BRANCHCOPY((*branchcopy))</code> and
6688  * <code>SCIP_DECL_BRANCHEXECREL((*branchexecrel))</code>. In the same fashion, the new callbacks
6689  * SCIP_DECL_VARCOPY and SCIP_DECL_PROBCOPY led to new parameters in SCIPcreateVar() and SCIPcreateProb() in
6690  * scip.c, respectively.
6691  * <br><br>
6692  * - SCIPincludeHeur() and SCIPincludeSepa() in \ref scip.h, as well as scip::ObjSepa() and scip::ObjHeur(), have a new parameter:
6693  * - <code>usessubscip</code> - It can be used to inform SCIP that the heuristic/separator to be included uses a secondary SCIP instance.
6694  * <br><br>
6695  * - SCIPapplyRens() in \ref heur_rens.h has a new parameter <code>uselprows</code>. It can be used to switch from LP rows
6696  * to constraints as basis of the sub-SCIP constructed in the RENS heuristic.
6697  * <br>
6698  * <br>
6699  * - W.r.t. to copy and the C++ wrapper classes there are two new classes. These are <code>ObjCloneable</code> and
6700  * <code>ObjProbCloneable</code>. The constraint handlers and variables pricers are derived from
6701  * <code>ObjProbCloneable</code> and all other plugin are derived from <code>ObjCloneable</code>. Both
6702  * classes implement the function <code>iscloneable()</code> which return whether a plugin is clone
6703  * able or not. Besides that
6704  * each class has a function named <code>clone()</code> which differ in their signature.
6705  * See objcloneable.h, objprobcloneable.h, and the TSP example for more details.
6706  *
6707  * - <b>Branching</b>:
6708  * <br><br>
6709  * - The method SCIPgetVarStrongbranch() has been replaced by two methods SCIPgetVarStrongbranchFrac() and
6710  * SCIPgetVarStrongbranchInt().
6711  * <br><br>
6712  * - The methods SCIPgetVarPseudocost() and SCIPgetVarPseudocostCurrentRun() in \ref scip.h now return the pseudocost value of
6713  * one branching direction, scaled to a unit interval. The former versions of SCIPgetVarPseudocost() and
6714  * SCIPgetVarPseudocostCurrentRun() are now called SCIPgetVarPseudocostVal() and SCIPgetVarPseudocostValCurrentRun(), respectively.
6715  * <br>
6716  * <br>
6717  * - The methods SCIPgetVarConflictScore() and SCIPgetVarConflictScoreCurrentRun() in \ref scip.h are now called
6718  * SCIPgetVarVSIDS() and SCIPgetVarVSIDSCurrentRun(), respectively.
6719  * <br><br>
6720  * - The methods SCIPvarGetNInferences(), SCIPvarGetNInferencesCurrentRun(), SCIPvarGetNCutoffs(), and
6721  * SCIPvarGetNCutoffsCurrentRun() are now called SCIPvarGetInferenceSum(), SCIPvarGetInferenceSumCurrentRun(),
6722  * SCIPvarGetCutoffSum(), and SCIPvarGetCutoffSumCurrentRun(), respectively. Furthermore, they now return
6723  * <code>SCIP_Real</code> instead of <code>SCIP_Longint</code> values.
6724  *
6725  * - <b>Others</b>:
6726  * <br><br>
6727  * - SCIPcutGenerationHeuristicCmir() in \ref sepa_cmir.h has three new parameters:
6728  * - <code>maxmksetcoefs</code> - If the mixed knapsack constraint obtained after aggregating LP rows contains more
6729  * than <code>maxmksetcoefs</code> nonzero coefficients the generation of the <b>c-MIR cut</b> is aborted.
6730  * - <code>delta</code> - It can be used to obtain the scaling factor which leads to the best c-MIR cut found within
6731  * the cut generation heuristic. If a <code>NULL</code> pointer is passed, the corresponding c-MIR cut will already be
6732  * added to SCIP by SCIPcutGenerationHeuristicCmir(). Otherwise, the user can generate the cut and add it to SCIP
6733  * on demand afterwards.
6734  * - <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>,
6735  * <code>deltavalid</code> will be <code>TRUE</code> if the stored scaling factor <code>delta</code> will lead to a violated c-MIR cut.
6736  * <br>
6737  * <br>
6738  * - All functions for setting <b>user parameters</b> of different types like SCIPparamSetBool(), SCIPparamSetChar(),
6739  * SCIPparamSetInt(), SCIPparamSetLongint(), and SCIPparamSetString() in pub_paramset.h have a new parameter:
6740  * - <code>quiet</code> - It prevents any output during the assign to a new value.
6741  *
6742  * <br>
6743  * @section MISCELLANEOUS4 Miscellaneous
6744  *
6745  * - The NLPI library is now a separate library that is required when linking against the SCIP library.
6746  * This requires changes to Makefiles that use SCIP, see the \ref RELEASENOTES "Release notes" for more details.
6747  *
6748  * - We do not distinguish between <b>block memory</b> for the original and the transformed problem anymore. The same
6749  * block memory is now used in both problem stages.
6750  *
6751  * - The usage of <b>strong branching</b> changed. Now, SCIPstartStrongbranch() and SCIPendStrongbranch() must be
6752  * called before and after strong branching, respectively.
6753  *
6754  * - All <b>C++</b> objects and constructors have a SCIP pointer, now.
6755  *
6756  * - The <b>predefined setting files</b> like "settings/cuts/off.set,aggressive.set,fast.set" have been replaced by
6757  * interface methods like SCIPsetHeuristics(), SCIPsetPresolving(), SCIPsetSeparating(), and SCIPsetEmphasis() in
6758  * \ref scip.h and by user dialogs in the interactive shell like
6759  * <br>
6760  * <br>
6761  * <code>SCIP&gt; set {heuristics|presolving|separating} emphasis {aggressive|fast|off}</code>
6762  * <br>
6763  * <br>
6764  * or
6765  * <br>
6766  * <br>
6767  * <code>SCIP&gt; set emphasis {counter|cpsolver|easycip|feasibility|hardlp|optimality}</code>
6768  *
6769  *
6770  * <br>
6771  * For further release notes we refer to the \ref RELEASENOTES "Release notes".
6772  */
6773 
6774 /* - SCIP now has "lazy bounds", which are useful for column generation - see @ref PRICER_REMARKS "pricer remarks" for an explanation.
6775  *
6776  * - SCIP has rudimentary support to solve quadratic nonlinear integer programs - see \ref cons_quadratic.h.
6777  *
6778  * - There are LP-interfaces to QSopt and Gurobi (rudimentary).
6779  *
6780  * - SCIP can now handle indicator constraints (reading (from LP, ZIMPL), writing, solving, ...) - see \ref cons_indicator.h.
6781  *
6782  * - One can now do "early branching" useful for column generation.
6783  *
6784  * - Can now run a black-box lexicographic dual simplex algorithm.
6785  */
6786 
6787  /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6788  /**@page CHG5 Interface changes between SCIP 2.0 and SCIP 2.1
6789  *
6790  *
6791  * @section CHGCALLBACKS5 New and changed callbacks
6792  *
6793  * - <b>Presolving</b>:
6794  * <br>
6795  * <br>
6796  * - The new parameters "nnewaddconss" and "naddconss" were added to the constraint handler callback method SCIP_DECL_CONSPRESOL()
6797  * and the presolver callback method SCIP_DECL_PRESOLEXEC(). These parameters were also added to corresponding C++ wrapper class methods.
6798  * - Propagators are now also called in during presolving, this is supported by the new callback methods SCIP_DECL_PROPINITPRE(),
6799  * SCIP_DECL_PROPEXITPRE(), and SCIP_DECL_PROPPRESOL().
6800  * - New parameters "isunbounded" and "isinfeasible" for presolving initialization (SCIP_DECL_CONSINITPRE(),
6801  * SCIP_DECL_PRESOLINITPRE(), SCIP_DECL_PROPINITPRE()) and presolving deinitialization (SCIP_DECL_CONSEXITPRE(),
6802  * SCIP_DECL_PRESOLEXITPRE(), SCIP_DECL_PROPEXITPRE()) callbacks of presolvers,
6803  * constraint handlers and propagators, telling the callback whether the problem was already declared to be
6804  * unbounded or infeasible. This allows to avoid expensive steps in these methods in case the problem is already
6805  * solved, anyway.
6806  * <br>
6807  * <br>
6808  * <DIV class="note">
6809  * Note, that the C++ methods
6810  * - scip::ObjConshdlr::scip_presol() corresponding to SCIP_DECL_CONSPRESOL()
6811  * - scip::ObjConshdlr::scip_initpre() corresponding to SCIP_DECL_CONSINITPRE()
6812  * - scip::ObjPresol::scip_initpre() corresponding to SCIP_DECL_PRESOLINITPRE()
6813  * - scip::ObjProp::scip_initpre() corresponding to SCIP_DECL_PROPINITPRE()
6814  * - scip::ObjConshdlr::scip_exitpre() corresponding to SCIP_DECL_CONSEXITPRE()
6815  * - scip::ObjPresol::scip_exitpre() corresponding to SCIP_DECL_PRESOLEXITPRE()
6816  * - scip::ObjProp::scip_exitpre() corresponding to and SCIP_DECL_PROPEXITPRE()
6817  * .
6818  * are virtual functions. That means, if you are not adding the new parameters, your code will still compile, but these methods are not executed.
6819  * </DIV>
6820  *
6821  * - <b>Constraint Handler</b>:
6822  * <br>
6823  * <br>
6824  * - The new constraint handler callback SCIP_DECL_CONSDELVARS() is called after variables were marked for deletion.
6825  * This method is optional and only of interest if you are using SCIP as a branch-and-price framework. That means,
6826  * you are generating new variables during the search. If you are not doing that just define the function pointer
6827  * to be NULL.
6828  * <br>
6829  * If this method gets implemented you should iterate over all constraints of the constraint handler and delete all
6830  * variables that were marked for deletion by SCIPdelVar().
6831  *
6832  * - <b>Problem Data</b>:
6833  * <br>
6834  * <br>
6835  * - 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.
6836  *
6837  * - <b>Conflict Analysis</b>:
6838  * <br>
6839  * <br>
6840  * - Added parameter "separate" to conflict handler callback method SCIP_DECL_CONFLICTEXEC() that defines whether the conflict constraint should be separated or not.
6841  *
6842  * - <b>NLP Solver Interface</b>:
6843  * <br>
6844  * <br>
6845  * - The callbacks SCIP_DECL_NLPIGETSOLUTION() and SCIP_DECL_NLPISETINITIALGUESS() got new parameters to get/set values of dual variables.
6846  * - The callback SCIP_DECL_NLPICOPY() now passes the block memory of the target SCIP as an additional parameter.
6847  *
6848  * <br>
6849  * @section CHGINTERFUNC5 Changed interface methods
6850  *
6851  * - <b>Writing and Parsing constraints</b>:
6852  * <br>
6853  * <br>
6854  * - The methods SCIPwriteVarName(), SCIPwriteVarsList(), and SCIPwriteVarsLinearsum() got a new boolean parameter "type"
6855  * that indicates whether the variable type should be written or not.
6856  * - The method SCIPwriteVarsList() got additionally a new parameter "delimiter" that defines the character which is used for delimitation.
6857  * - The methods SCIPparseVarName() and SCIPparseVarsList() got a new output parameter "endptr" that is filled with the position where the parsing stopped.
6858  *
6859  * - <b>Plugin management</b>:
6860  * <br>
6861  * <br>
6862  * - 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.
6863  * - SCIPincludeConshdlr() got additional parameters to set the variable deletion callback function and the timing mask for propagation.
6864  *
6865  * - <b>Constraint Handlers</b>:
6866  * <br>
6867  * <br>
6868  * - Method SCIPseparateRelaxedKnapsack() in knapsack constraint handler got new parameter "cutoff", which is a pointer to store whether a cutoff was found.
6869  * - Method SCIPincludeQuadconsUpgrade() of quadratic constraint handler got new parameter "active" to indicate whether the upgrading method is active by default.
6870  *
6871  * - <b>Nonlinear expressions, relaxation, and solver interface</b>:
6872  * <br>
6873  * <br>
6874  * - The methods SCIPexprtreeEvalSol(), SCIPexprtreeEvalIntLocalBounds(), and SCIPexprtreeEvalIntGlobalBounds() have been renamed to SCIPevalExprtreeSol(),
6875  * SCIPevalExprtreeLocalBounds(), and SCIPevalExprtreeGlobalBounds() and are now located in scip.h.
6876  * - Various types and functions dealing with polynomial expressions have been renamed to use the proper terms "monomial" and "polynomial".
6877  * - The methods SCIPnlpGetObjective(), SCIPnlpGetSolVals(), and SCIPnlpGetVarSolVal() have been removed, use SCIPgetNLPObjval(), SCIPvarGetNLPSol()
6878  * and SCIPcreateNLPSol() to retrieve NLP solution values instead.
6879  * - Removed methods SCIPmarkRequireNLP() and SCIPisNLPRequired(), because the NLP is now always constructed if nonlinearities are present.
6880  * - SCIPgetNLP() has been removed and NLP-methods from pub_nlp.h have been moved to scip.h, which resulted in some renamings, too.
6881  * - The functions SCIPnlpiGetSolution() and SCIPnlpiSetInitialGuess() got additional arguments to get/set dual values.
6882  * - The method SCIPgetNLPI() got a new parameter "nlpiproblem", which is a pointer to store the NLP solver interface problem.
6883  *
6884  * - <b>Others</b>:
6885  * <br>
6886  * <br>
6887  * - 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
6888  * the given variable is contained in the given hash map.
6889  * - Removed method SCIPreadSol(); call solution reading via SCIPreadProb() which calls the solution reader for .sol files.
6890  * - SCIPchgVarType() got an extra boolean parameter to store if infeasibility is recognized while upgrading a variable from continuous type to an integer type.
6891  * - SCIPdelVar() got a new parameter "deleted", which stores whether the variable was successfully marked to be deleted.
6892  * - SCIPcalcNodeselPriority() got a new parameter "branchdir", which defines the type of branching that was performed: upwards, downwards, or fixed.
6893  * - The parameters "timelimit" and "memorylimit" were removed from SCIPapplyRens().
6894  *
6895  * <br>
6896  * @section MISCELLANEOUS5 Miscellaneous
6897  *
6898  * - The result value SCIP_NEWROUND has been added, it allows a separator/constraint handler to start a new separation round
6899  * (without previous calls to other separators/conshdlrs).
6900  * - All timing flags are now defined type_timing.h.
6901  * - The variable deletion event is now a variable specific event and not global, anymore.
6902  * - The emphasis setting types now distinguish between plugin-type specific parameter settings (default, aggressive, fast, off), which are changed by
6903  * SCIPsetHeuristics/Presolving/Separating(), and global emphasis settings (default, cpsolver, easycip, feasibility, hardlp, optimality, counter),
6904  * which can be set using SCIPsetEmphasis().
6905  *
6906  * <br>
6907  * For further release notes we refer to the \ref RELEASENOTES "Release notes".
6908  */
6909 
6910  /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
6911  /**@page CHG6 Interface changes between SCIP 2.1 and SCIP 3.0
6912  *
6913  *
6914  * @section CHGCALLBACKS6 New and changed callbacks
6915  *
6916  * - <b>Conflict Analysis</b>:
6917  * <br>
6918  * <br>
6919  * - Added parameter "relaxedbds" to conflict handler callback method SCIP_DECL_CONFLICTEXEC(). This array contains
6920  * bounds which are sufficient to create a valid conflict
6921  *
6922  * - <b>Constraint Handler</b>:
6923  * <br>
6924  * <br>
6925  * - New optional callback methods in constraint handlers: SCIP_DECL_CONSGETVARS and SCIP_DECL_CONSGETNVARS.
6926  * These callbacks, if implemented, should return an array of all variables and the number of all variables used
6927  * by the given constraint, respectively. (This method might, e.g., be called by a presolver)
6928  * - Added a propagation timing parameter "proptiming" to SCIP_DECL_CONSPROP(), giving the current timing at which
6929  * this method is called
6930  * - Added a parameter 'restart' to the SCIP_DECL_CONSEXITSOL() callback method, indicating whether this call was
6931  * triggered by a restart.
6932  * - Added a parameter 'relaxedbd' to SCIP_DECL_CONSRESPROP() callback method. If explaining a given bound change
6933  * (index), it is sufficient to explain the reason for reaching the 'relaxedbd' value, see above
6934  * - Removed parameters "isunbounded", "isinfeasible" and "result" from SCIP_DECL_CONSINITPRE() and
6935  * SCIP_DECL_CONSEXITPRE() callback methods. It is not allowed to determine unboundedness or infeasibility in
6936  * these callbacks, anymore.
6937  *
6938  * - <b>Message Handler</b>:
6939  * <br>
6940  * <br>
6941  * - New callback method SCIP_DECL_MESSAGEHDLRFREE() which is called when the message handler is freed.
6942  * - The old callback method SCIP_DECL_MESSAGEERROR() was replaced by the callback method SCIP_DECL_ERRORPRINTING().
6943  *
6944  * - <b>Presolving</b>:
6945  * <br>
6946  * <br>
6947  * - Removed parameters "isunbounded", "isinfeasible" and "result" from SCIP_DECL_PRESOLINITPRE() and
6948  * SCIP_DECL_PRESOLSEXITPRE(). It is not allowed to determine unboundedness or infeasibility in these
6949  * callbacks, anymore.
6950  *
6951  * - <b>Propagator</b>:
6952  * <br>
6953  * <br>
6954  * - Added a propagation timing parameter "proptiming" to SCIP_DECL_PROPEXEC(), giving the
6955  * current timing at which this method is called.
6956  * - Added a parameter 'restart' to SCIP_DECL_PROPEXITSOL() callback method, indicating whether this call was
6957  * triggered by a restart.
6958  * - Added a parameter 'relaxedbd' to SCIP_DECL_PROPRESPROP() callback method. If explaining a given bound change
6959  * (index), it is sufficient to explain the reason for reaching the 'relaxedbd' value.
6960  * - Removed parameters "isunbounded", "isinfeasible" and "result" from SCIP_DECL_PROPINITPRE() and
6961  * SCIP_DECL_PROPEXITPRE() callback methods. It is not allowed to determined unboundedness or infeasibility in
6962  * these callbacks, anymore.
6963  *
6964  * - <b>NLP Solver Interface</b>:
6965  * <br>
6966  * <br>
6967  * - New NLPI callback SCIP_DECL_NLPISETMESSAGEHDLR() to set message handler in NLP solver interfaces.
6968  *
6969  * <br>
6970  * @section CHGINTERFUNC6 Changed interface methods
6971  *
6972  * - <b>Plugin management</b>:
6973  * <br>
6974  * <br>
6975  * - Added basic include methods for almost all plugin types, e.g., SCIPincludeConshdlrBasic();
6976  * these methods should make the usage easier, sparing out optional callbacks and parameters.
6977  * - To extend the basic functionalities, there are setter method to add
6978  * optional callbacks. For example SCIPsetConshdlrParse(), SCIPsetPropCopy() or SCIPsetHeurInitsol().
6979  *
6980  * - <b>Constraint Handlers</b>:
6981  * <br>
6982  * <br>
6983  * - Added basic creation methods for all constraints types, e.g., SCIPcreateConsBasicLinear(); these methods should make the usage easier,
6984  * sparing out optional callbacks and parameters.
6985  * - New methods SCIPgetConsVars() and SCIPgetConsNVars() (corresponding callbacks need to be implemented, see above)
6986  *
6987  * - <b>Problem</b>:
6988  * <br>
6989  * <br>
6990  * - Added basic creation methods SCIPcreateVarBasic() and SCIPcreateProbBasic() and setter functions
6991  * - Added method SCIPisPresolveFinished() which returns whether the presolving process would be stopped after the
6992  * current presolving round, given no further reductions will be found.
6993  * - Forbid problem modifications in SCIP_STAGE_{INIT,EXIT}PRESOLVE (see pre-conditions for corresponding methods in scip.h).
6994  *
6995  * - <b>Variable usage</b>:
6996  * <br>
6997  * <br>
6998  * - Renamed SCIPvarGetBestBound() to SCIPvarGetBestBoundLocal(), SCIPvarGetWorstBound() to
6999  * SCIPvarGetWorstBoundLocal() and added new methods SCIPvarGetBestBoundGlobal() and SCIPvarGetWorstBoundGlobal().
7000  * - Method SCIPvarGetProbvarSum() is not public anymore, use SCIPgetProbvarSum() instead.
7001  * - Replaced method SCIPvarGetRootRedcost() by SCIPvarGetBestRootRedcost().
7002  *
7003  * - <b>Message Handler</b>:
7004  * <br>
7005  * <br>
7006  * - Changed the message handler system within SCIP heavily such that it is thread-safe. SCIPcreateMessagehdlr() in
7007  * scip.{c,h} was replaced by SCIPmessagehdlrCreate() in pub_message.h/message.c with a changed parameter list.
7008  * - Error messages (SCIPerrorMessage()) are not handled via the message handler anymore; per default the error
7009  * message is written to stderr.
7010  *
7011  * - <b>Separation</b>:
7012  * <br>
7013  * <br>
7014  * - New functions SCIPcreateEmptyRowCons(), SCIPcreateEmptyRowSepa(), SCIPcreateRowCons(), and SCIPcreateRowSepa()
7015  * that allow to set the originating constraint handler or separator of a row respectively; this is, for instance,
7016  * needed for statistics on the number of applied cuts. If rows are created outside a constraint handler or separator
7017  * use SCIPcreateRowUnspec() and SCIPcreateEmptyRowUnspec(). The use of SCIPcreateEmptyRow() and SCIPcreateRow() is
7018  * deprecated.
7019  * - New functions SCIProwGetOrigintype(), SCIProwGetOriginCons(), and SCIProwGetOriginSepa() to obtain the originator
7020  * that created a row.
7021  *
7022  * - <b>LP interface</b>:
7023  * <br>
7024  * <br>
7025  * - SCIPlpiCreate() got a new parameter 'messagehdlr'.
7026  * - SoPlex LPI supports setting of SCIP_LPPAR_DUALFEASTOL when using SoPlex version 1.6.0.5 and higher.
7027  *
7028  * - <b>Nonlinear expressions, relaxation, and solver interface</b>:
7029  * <br>
7030  * <br>
7031  * - Renamed SCIPmarkNonlinearitiesPresent() to SCIPenableNLP() and SCIPhasNonlinearitiesPresent() to
7032  * SCIPisNLPEnabled().
7033  * - Method SCIPexprtreeRemoveFixedVars() is not public anymore.
7034  *
7035  * - <b>Counting</b>:
7036  * <br>
7037  * <br>
7038  * - Changed the counting system within SCIP heavily. SPARSESOLUTION was renamed to SCIP_SPARSESOL. New method for
7039  * SCIP_SPARSESOL usage, SCIPsparseSolCreate(), SCIPsparseSolFree(), SCIPsparseSolGetVars(),
7040  * SCIPsparseSolGetNVars(), SCIPsparseSolGetLbs(), SCIPsparseSolGetUbs() in (pub_)misc.{c,h}.
7041  * - Renamed SCIPgetCountedSparseSolutions() to SCIPgetCountedSparseSols() in cons_countsols.{c,h}.
7042  *
7043  * <br>
7044  * @section MISCELLANEOUS6 Miscellaneous
7045  *
7046  * - Replaced SCIPparamSet*() by SCIPchg*Param() (where * is either Bool, Int, Longint, Real, Char, or String).
7047  * - New parameter in SCIPcopy() and SCIPcopyPlugins() to indicate whether the message handler from the source SCIP
7048  * should be passed to the target SCIP (only the pointer is copied and the usage counter of the message handler is
7049  * increased).
7050  * - SCIPprintCons() does not print termination symbol ";\n" anymore; if wanted, use SCIPinfoMessage() to print
7051  * ";\n" manually
7052  * - All objscip *.h file now use the default SCIP interface macros.
7053  * - The methods SCIPsortedvecInsert*() have an additional parameter which can be used to receive the position where
7054  * the new element was inserted.
7055  * - New macro SCIPdebugPrintCons() to print constraint only if SCIP_DEBUG flag is set.
7056  *
7057  * <br>
7058  * For further information we refer to the \ref RELEASENOTES "Release notes" and the \ref CHANGELOG "Changelog".
7059  */
7060 
7061  /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
7062  /**@page CHG7 Interface changes between SCIP 3.0 and SCIP 3.1
7063  *
7064  *
7065  * @section CHGCALLBACKS7 New and changed callbacks
7066  *
7067  * - <b>Branching Rules</b>:
7068  * <br>
7069  * <br>
7070  * - new possible return value "SCIP_DIDNOTFIND" for SCIP_DECL_BRANCHEXECLP(), SCIP_DECL_BRANCHEXECPS(), and
7071  * SCIP_DECL_BRANCHEXECEXT() callbacks to state that the branching rule searched, but did not find a branching.
7072  *
7073  * - <b>Domain Propagation</b>:
7074  * <br>
7075  * <br>
7076  * - added parameter "nmarkedconss" to SCIP_DECL_CONSPROP() callback which gives the number of constraints marked
7077  * for propagation (these constraints are listed first in the conss array given as parameter).
7078  *
7079  * - <b>Message Handler</b>:
7080  * <br>
7081  * <br>
7082  * - New generic messagehandler output callback method SCIP_DECL_MESSAGEOUTPUTFUNC().
7083  * - Removed parameter "msglength" from callback method SCIP_DECL_ERRORPRINTING().
7084  *
7085  * - <b>Variable Pricers</b>:
7086  * <br>
7087  * <br>
7088  * - Added parameter "stopearly" to callback method SCIP_DECL_PRICERREDCOST(). This boolean pointer should be used
7089  * by the pricer to state whether early branching should be performed, even if new variables were added in the
7090  * current pricing round.
7091  *
7092  * - <b>Primal Heuristics</b>:
7093  * <br>
7094  * <br>
7095  * - Added parameter "nodeinfeasible" to SCIP_DECL_HEUREXEC() callback which states whether the current subproblem
7096  * was already detected to be infeasible. In this case, the current LP solution might not respect local bounds,
7097  * and the heuristic must not assume that it does.
7098  *
7099  *
7100  * <br>
7101  * @section CHGINTERFUNC7 Changed interface methods
7102  *
7103  * - <b>Branching Rules</b>:
7104  * <br>
7105  * <br>
7106  * - Added parameter "nfracimplvars" to SCIPgetLPBranchCands()
7107  *
7108  * - <b>Constraint Handlers</b>:
7109  * <br>
7110  * <br>
7111  * - New method SCIPconshdlrGetStrongBranchPropTime() which returns the time used for domain propagation methods
7112  * of the constraint handler during strong branching.
7113  * - New method SCIPconsIsMarkedPropagate() which returns whether a constraint is marked for propagation.
7114  * - New methods SCIPconsAddUpgradeLocks() and SCIPconsGetNUpgradeLocks() to increase or get the number of upgrade
7115  * locks of a constraint.
7116  *
7117  * - <b>Domain Propagation</b>:
7118  * <br>
7119  * <br>
7120  * - New method SCIPpropGetStrongBranchPropTime() which returns the time spent by a domain propagator during strong
7121  * branching.
7122  * - New methods SCIPmarkConsPropagate() and SCIPunmarkConsPropagate to (un)mark a constraint for propagation.
7123  *
7124  * - <b>LP and Cutting Planes</b>:
7125  * <br>
7126  * <br>
7127  * - New methods SCIProwChgRank() and SCIProwGetRank() to change and get the rank of a cutting plane, respectively.
7128  * - Added parameter "sidetypes" to SCIPcalcMIR() to specify the specify row side type to be used.
7129  * - Added parameter "cutrank" to SCIPcalcMIR() and SCIPcalcStrongCG() which stores the rank of the returned cut.
7130  * - New method SCIPisCutApplicable() which returns whether a cut is good enough to be applied.
7131  * - Added parameter "infeasible" to SCIPaddCut() which is a pointer to store whether the cut is infeasible for the
7132  * local bounds.
7133  * - delayed cutpool
7134  * - New methods SCIPchgRowLhsDive() and SCIPchgRowRhsDive() to change left and right hand side of a row during diving.
7135  * - Added parameter "cutoff" to SCIPsolveDiveLP(), SCIPsolveProbingLP(), and SCIPsolveProbingLPWithPricing()
7136  * which is a pointer to store whether the diving/probing LP was infeasible or the objective limit was reached.
7137  *
7138  * - <b>Message Handler</b>:
7139  * <br>
7140  * <br>
7141  * - New method SCIPmessageVPrintError() to print an error message.
7142  * - Removed method SCIPmessagePrintWarningHeader().
7143  *
7144  * - <b>Parameters</b>:
7145  * <br>
7146  * <br>
7147  * - New method SCIPparamGetCharAllowedValues() to get the allowed values for a char parameter.
7148  *
7149  * - <b>Variables</b>:
7150  * <br>
7151  * <br>
7152  * - New structure to store value-based branching and inference history (see pub_history.h).
7153  * - New method SCIPvarGetValuehistory() to get the value-based history of a variable.
7154  *
7155  * - <b>Data structures</b>:
7156  * <br>
7157  * <br>
7158  * - New method SCIPgmlWriteNodeWeight() to write a node section including weight to a .gml graph file.
7159  * - New methods SCIPsparseSolGetFirstSol() and SCIPsparseSolGetNextSol() to get the first sparse solution
7160  * or iterate over the sparse solutions, respectively.
7161  * - New methods in pub_misc.h to handle a (circular) queue, e.g., SCIPqueueCreate(), SCIPqueueFree(),
7162  * SCIPqueueInsert(), ...
7163  * - New methods for hash tables: SCIPhashtableRemoveAll(), SCIPhashtableGetNElements(), SCIPhashtableGetLoad()
7164  * - New methods in pub_misc.h to handle a resource activity, e.g., SCIPactivityCreate(), SCIPactivityFree(),
7165  * SCIPactivityGetVar(), SCIPactivityGetDemand() ...
7166  * - New methods for digraphs: SCIPdigraphResize() to resize the graph and SCIPdigraphSetNodeDatas() and
7167  * SCIPdigraphGetNodeDatas() to set and get the data attached to the nodes.
7168  *
7169  * - <b>Misc</b>:
7170  * <br>
7171  * <br>
7172  * - New method SCIPcopyOrig() to copy the original problem. Analoguosly, use SCIPcopyOrigProb(), SCIPcopyOrigVars(),
7173  * and SCIPcopyOrigConss() to copy original problem data, variables, or constraints, respectively.
7174  * - New method SCIPcopyImplicationsCliques() to copy implications and cliques to a copied SCIP instance.
7175  * - New method SCIPgetParam() to get the parameter with a given name.
7176  * - New method SCIPaddOrigObjoffset() to add an offset to the objective function.
7177  * - New method SCIPgetNCheckConss() which returns the number of checked constraints.
7178  * - Added parameter "endptr" to SCIPparseVar() which stores the final string position after parsing.
7179  * - Added parameter "enablepropagation" to SCIPstartStrongbranch(), which can be used to enable strong branching
7180  * with domain propagation.
7181  * - New method SCIPgetVarStrongbranchWithPropagation() which performs strong branching with propagation on a variable.
7182  * - New method SCIPwriteCliqueGraph() to write the clique graph.
7183  * - New method SCIPdoNotMultaggr() which returns whether multi-aggregation was disabled.
7184  * - Added parameter "lazyconss" to SCIPwriteMIP() to swith writing removable rows as lazy constraints.
7185  * - New method SCIPcreateFiniteSolCopy() to create a copy of a solution with infinite fixings removed.
7186  * - New method SCIPadjustImplicitSolVals() which sets implicit integer variables to an integer value in the given
7187  * solution without deteriorating its objective value.
7188  * - New method SCIPprintDualSol() which prints the dual solution for a pure LP (works only with preprocessing disabled).
7189  * - New method SCIPgetOpenNodesData() which returns all unprocessed nodes.
7190  * - New method SCIPgetFirstLPTime() and SCIPgetNRootFirstLPIterations() to return time and iterations for the first
7191  * LP solve and SCIPgetFirstLPDualboundRoot() and SCIPgetFirstLPLowerboundRoot() to return the first root LP dual and
7192  * lower bound.
7193  * - New method SCIPgetNLimSolsFound() returning the number of feasible primal solution respecting the objective limit.
7194  * - Added parameter "endline" to SCIPprintDisplayLine() to switch printing a newline symbol at the end of the line.
7195  *
7196  * <br>
7197  * @section MISCELLANEOUS7 Miscellaneous
7198  *
7199  * - Moved LP solver interfaces to subdirectory src/lpi.
7200  *
7201  * <br>
7202  * For further information we refer to the \ref RELEASENOTES "Release notes" and the \ref CHANGELOG "Changelog".
7203  */
7204 
7205  /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
7206  /**@page CHG8 Interface changes between SCIP 3.1 and SCIP 3.2
7207  *
7208  *
7209  * @section CHGCALLBACKS8 New and changed callbacks
7210  *
7211  * - <b>Branching Rules</b>:
7212  * - Added paramter "forcestrongbranch" to SCIPselectVarStrongBranching()
7213  * - Added paramter "executebranching" SCIPexecRelpscostBranching()
7214  * - Added paramter "presoltiming" to SCIPpropCumulativeCondition()
7215  *
7216  * <br>
7217  * - <b>Domain Propagation</b>:
7218  *
7219  * <br>
7220  * - <b>Message Handler</b>:
7221  *
7222  * <br>
7223  * - <b>Variable Pricers</b>:
7224  *
7225  * <br>
7226  * - <b>Primal Heuristics</b>:
7227  * - Added paramter "freesubscip" to SCIPapplyProximity()
7228  *
7229  * <br>
7230  * @section CHGINTERFUNC8 Changed interface methods
7231  *
7232  * <br>
7233  * - <b>Branching Rules</b>:
7234  *
7235  * <br>
7236  * - <b>Constraint Handlers</b>:
7237  * - Removed method SCIPconshdlrIsPresolvingDelayed()
7238  * - Removed method SCIPconshdlrWasPresolvingDelayed()
7239  * - Renamed method SCIPconshdlrGetPropTimingmask() to SCIPconshdlrGetPropTiming()
7240  *
7241  * <br>
7242  * - <b>Domain Propagation</b>:
7243  *
7244  * <br>
7245  * - <b>LP and Cutting Planes</b>:
7246  * - Added parameter "inds" to SCIPgetLPBInvRow()
7247  * - Added parameter "ninds" to SCIPgetLPBInvRow()
7248  * - Added parameter "inds" to SCIPgetLPBInvCol()
7249  * - Added parameter "ninds" to SCIPgetLPBInvCol()
7250  * - Added parameter "inds" to SCIPgetLPBInvARow()
7251  * - Added parameter "ninds" to SCIPgetLPBInvARow()
7252  * - Added parameter "inds" to SCIPgetLPBInvACol()
7253  * - Added parameter "ninds" to SCIPgetLPBInvACol()
7254  * - Added parameter "maxweight" to SCIPcalcMIR()
7255  * - Added parameter "weightinds" to SCIPcalcMIR()
7256  * - Added parameter "nweightinds" to SCIPcalcMIR()
7257  * - Added parameter "rowlensum" to SCIPcalcMIR()
7258  * - Added parameter "inds" to SCIPcalcStrongCG()
7259  * - Added parameter "ninds" to SCIPcalcStrongCG()
7260  *
7261  * <br>
7262  * - <b>Message Handler</b>:
7263  *
7264  * <br>
7265  * - <b>Parameters</b>:
7266  *
7267  * <br>
7268  * - <b>Variables</b>:
7269  * - Removed method SCIPvarGetNBinImpls()
7270  *
7271  * <br>
7272  * - <b>Data structures</b>:
7273  * - Renamed method SCIPdigraphGetNodeDatas() to SCIPdigraphGetNodeData()
7274  * - Renamed method SCIPdigraphSetNodeDatas() to SCIPdigraphSetNodeData()
7275  * - Renamed method SCIPdigraphGetSuccessorsDatas() to SCIPdigraphGetSuccessorsData()
7276  *
7277  * <br>
7278  * - <b>Misc</b>:
7279  * - Removed parameter "delaypos" from SCIPincludeConshdlr()
7280  * - Added parameter "presoltiming" to SCIPincludeConshdlr()
7281  * - Added parameter "consgetdivebdchgs" to SCIPincludeConshdlr()
7282  * - Removed parameter "delaypos" from SCIPsetConshdlrPresol()
7283  * - Added parameter "presoltiming" to SCIPsetConshdlrPresol()
7284  * - Removed parameter "delaypos" from SCIPincludePresol()
7285  * - Added parameter "presoltiming" to SCIPincludePresol()
7286  * - Removed parameter "delaypos" from SCIPincludePresolBasic()
7287  * - Added parameter "presoltiming" to SCIPincludePresolBasic()
7288  * - Removed paramter "presoldelay" from SCIPincludePresol()
7289  * - Removed paramter "presoltiming" from SCIPincludePresol()
7290  * - Removed paramter "presoldelay" from SCIPsetPropPresol()
7291  * - Removed paramter "presoltiming" from SCIPsetPropPresol()
7292  * - Added parameter "ndomredsdown" to SCIPgetVarStrongbranchWithPropagation()
7293  * - Added parameter "ndomredsup" to SCIPgetVarStrongbranchWithPropagation()
7294  * - Added parameter "isequation" to SCIPaddClique()
7295  * - Removed parameter "writeimplications" from SCIPwriteCliqueGraph()
7296  * - Removed method SCIPallocBufferSize()
7297  * - Removed method SCIPduplicateBufferSize()
7298  * - Removed method SCIPreallocBufferSize()
7299  * - Removed method SCIPfreeBufferSize()
7300  * - Removed method callback SCIPdialogExecConflictgraph()
7301  *
7302  * <br>
7303  * @section MISCELLANEOUS7 Miscellaneous
7304  *
7305  * <br>
7306  * For further information we refer to the \ref RELEASENOTES "Release notes" and the \ref CHANGELOG "Changelog".
7307  */
7308 
7309 /*--+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2*/
7310 /**@page COUNTER How to use SCIP to count/enumerate feasible solutions
7311  *
7312  * SCIP is capable of computing (count or enumerate) the number of feasible solutions of a given constraint integer
7313  * program. In case continuous variables are present, the number of feasible solutions for the projection to the
7314  * integral variables is counted/enumerated. This means, an assignment to the integer variables is counted if the
7315  * remaining problem (this is the one after fixing the integer variables w.r.t. to this assignment) is feasible.
7316  *
7317  * As a first step you have to load or create your problem in the usual way. In case of using the
7318  * interactive shell, you use the <code>read</code> command:
7319  *
7320  * <code>SCIP&gt; read &lt;file name&gt;</code>
7321  *
7322  * Afterwards you can count the number of feasible solution with the command <code>count</code>.
7323  *
7324  * <code>SCIP&gt; count</code>
7325  *
7326  * That means SCIP will count the number of solution but does not store (enumerate) them. If you are interested in that see
7327  * \ref COLLECTALLFEASEBLES.
7328  *
7329  * @note Since SCIP version 2.0.0 you do not have to worry about <tt>dual</tt> reductions anymore. These are
7330  * automatically turned off. The only thing you should switch off are restarts. These restarts can lead to a wrong
7331  * counting process. We recommend using the counting settings which can be set in the interactive shell as follows:
7332  *
7333  * <code>SCIP&gt; set emphasis counter</code>
7334  *
7335  * The SCIP callable library provides an interface method SCIPcount() which allows users to count the number of feasible
7336  * solutions to their problem. The method SCIPsetParamsCountsols(), which is also located in cons_countsols.h, loads the
7337  * predefined counting settings to ensure a safe count. The complete list of all methods that can be used for counting
7338  * via the callable library can be found in cons_countsols.h.
7339  *
7340  *
7341  * @section COUNTLIMIT Limit the number of solutions which should be counted
7342  *
7343  * It is possible to give a (soft) upper bound on the number solutions that should be counted. If this upper bound is
7344  * exceeded, SCIP will be stopped. The name of this parameter is <code>constraints/countsols/sollimit</code>. In
7345  * the interactive shell this parameter can be set as follows:
7346  *
7347  * <code>SCIP&gt; set constraints countsols sollimit 1000</code>
7348  *
7349  * In case you are using the callable library, this upper bound can be assigned by calling SCIPsetLongintParam() as follows:
7350  *
7351  * \code
7352  * SCIP_CALL( SCIPsetLongintParam( scip, "constraints/countsols/sollimit", 1000) );
7353  * \endcode
7354  *
7355  *
7356  * The reason why this upper bound is soft comes from the fact that, by default, SCIP uses a technique called unrestricted
7357  * subtree detection. Using this technique it is possible to detect several solutions at once. Therefore, it can happen
7358  * that the solution limit is exceeded before SCIP is stopped.
7359  *
7360  * @section COLLECTALLFEASEBLES Collect all feasible solution
7361  *
7362  * Per default SCIP only counts all feasible solutions. This means, these solutions are not stored. If you switch the
7363  * parameter <code>constraints/countsols/collect</code> to TRUE (the default value is FALSE) the detected solutions are
7364  * stored. Changing this parameter can be done in the interactive shell
7365  *
7366  * <code>SCIP&gt; set constraints countsols collect TRUE</code>
7367  *
7368  * as well as via the callable library
7369  *
7370  * \code
7371  * SCIP_CALL( SCIPsetBoolParam( scip, "constraints/countsols/collect", TRUE) );
7372  * \endcode
7373  *
7374  * @note The solution which are collected are stored w.r.t. the active variables. These are the variables which got not
7375  * removed during presolving.
7376  *
7377  * In case you are using the interactive shell you can write all collected solutions to a file as follows
7378  *
7379  * <code>SCIP&gt; write allsolutions &lt;file name&gt;</code>
7380  *
7381  * In that case the sparse solutions are unrolled and lifted back into the original variable space.
7382  *
7383  * The callable library provides a method which gives access to all collected sparse solutions. That is,
7384  * SCIPgetCountedSparseSolutions(). The sparse solutions you get are defined w.r.t. active variables. To get solutions
7385  * w.r.t. to the original variables. You have to do two things:
7386  *
7387  * -# unroll each sparse solution
7388  * -# lift each solution into original variable space by extending the solution by those variable which got removed
7389  * during presolving
7390  *
7391  * The get the variables which got removed during presolving, you can use the methods SCIPgetFixedVars() and
7392  * SCIPgetNFixedVars(). The method SCIPgetProbvarLinearSum() transforms given variables, scalars and constant to the
7393  * corresponding active variables, scalars and constant. Using this method for a single variable gives a representation
7394  * for that variable w.r.t. the active variables which can be used to compute the value for the considered solution (which
7395  * is defined w.r.t. active variables).
7396  *
7397  * For that complete procedure you can also check the source code of
7398  * \ref SCIP_DECL_DIALOGEXEC(SCIPdialogExecWriteAllsolutions) "SCIPdialogExecWriteAllsolutions()" cons_countsols.c which
7399  * does exactly that.
7400  *
7401  *
7402  * @section COUNTOPTIMAL Count number of optimal solutions
7403  *
7404  * If you are interested in counting the number of optimal solutions, this can be done with SCIP using the
7405  * <code>count</code> command by applying the following steps:
7406  *
7407  * -# Solve the original problem to optimality and let \f$c^*\f$ be the optimal value
7408  * -# Add the objective function as constraint with left and right hand side equal to \f$c^*\f$
7409  * -# load the adjusted problem into SCIP
7410  * -# use the predefined counting settings
7411  * -# start counting the number of feasible solutions
7412  *
7413  * If you do this, SCIP will collect all optimal solutions of the original problem.
7414  *
7415  */
7416 
7417 /**@page LICENSE License
7418  *
7419  * \verbinclude COPYING
7420  */
7421 
7422 /**@page FAQ Frequently Asked Questions (FAQ)
7423  * \htmlinclude faq.inc
7424  */
7425 
7426 /**@page INSTALL Installation information
7427  * \verbinclude INSTALL
7428  */
7429 
7430 /**@page RELEASENOTES Release notes
7431  *
7432  * \verbinclude SCIP-release-notes-3.2.1
7433  *
7434  * \verbinclude SCIP-release-notes-3.2
7435  *
7436  * \verbinclude SCIP-release-notes-3.1
7437  *
7438  * \verbinclude SCIP-release-notes-3.0.2
7439  *
7440  * \verbinclude SCIP-release-notes-3.0.1
7441  *
7442  * \verbinclude SCIP-release-notes-3.0
7443  *
7444  * \verbinclude SCIP-release-notes-2.1.1
7445  *
7446  * \verbinclude SCIP-release-notes-2.1
7447  *
7448  * \verbinclude SCIP-release-notes-2.0.2
7449  *
7450  * \verbinclude SCIP-release-notes-2.0.1
7451  *
7452  * \verbinclude SCIP-release-notes-2.0
7453  *
7454  * \verbinclude SCIP-release-notes-1.2
7455  *
7456  * \verbinclude SCIP-release-notes-1.1
7457  */
7458 
7459 /**@page CHANGELOG CHANGELOG
7460  *
7461  * \verbinclude CHANGELOG
7462  *
7463  */
7464 
7465 /**@defgroup PUBLICMETHODS Public Methods
7466  *
7467  * This page lists headers containing methods provided by the core of SCIP that can be used via the
7468  * callable library. If you are in the <a href="../html">User's Manual</a> you only find methods that are
7469  * public and, therefore, allowed to be used. The <a href="../html_devel">Developer's Manual</a> includes
7470  * all methods.
7471  *
7472  * All of the headers listed below include functions that are allowed to be called by external users. Besides those
7473  * functions it is also valid to call methods that are listed in one of the headers of the (default) plugins, e.g.,
7474  * cons_linear.h.
7475  *
7476  * If you are looking for information about a particular object of SCIP, such as a variable or a constraint, you should
7477  * first search the corresponding "pub_<...>.h" header. E.g., for constraints, look in pub_cons.h. If you need some
7478  * information about the overall problem, you should start searching in scip.h.
7479  *
7480  * Since there is a huge number of methods in scip.h, these methods are grouped into different categories. These
7481  * categories are:
7482  *
7483  * - Memory Management
7484  * - Miscellaneous Methods
7485  * - General SCIP Methods
7486  * - Message Output Methods
7487  * - Parameter Methods
7488  * - SCIP User Functionality Methods: Managing Plugins
7489  * - User Interactive Dialog Methods
7490  * - Global Problem Methods
7491  * - Local Subproblem Methods
7492  * - Solve Methods
7493  * - Variable Methods
7494  * - Conflict Analysis Methods
7495  * - Constraint Methods
7496  * - LP Methods
7497  * - LP Column Methods
7498  * - LP Row Methods
7499  * - Cutting Plane Methods
7500  * - LP Diving Methods
7501  * - Probing Methods
7502  * - Branching Methods
7503  * - Primal Solution Methods
7504  * - Event Methods
7505  * - Tree Methods
7506  * - Statistic Methods
7507  * - Timing Methods
7508  * - Numerical Methods
7509  * - Dynamic Arrays
7510  *
7511  */
7512 
7513 /**@defgroup TYPEDEFINITIONS Type Definitions
7514  * This page lists headers which contain type definitions of callback methods.
7515  *
7516  * All headers below include the descriptions of callback methods of
7517  * certain plugins. For more detail see the corresponding header.
7518  */
7519 
7520 /**@defgroup BRANCHINGRULES Branching Rules
7521  * @brief This page contains a list of all branching rule which are currently available.
7522  *
7523  * A detailed description what a branching rule does and how to add a branching rule to SCIP can be found
7524  * \ref BRANCH "here".
7525  */
7526 
7527 /**@defgroup CONSHDLRS Constraint Handler
7528  * @brief This page contains a list of all constraint handlers which are currently available.
7529  *
7530  * A detailed description what a constraint handler does and how to add a constraint handler to SCIP can be found
7531  * \ref CONS "here".
7532  */
7533 
7534 /**@defgroup DIALOGS Dialogs
7535  * @brief This page contains a list of all dialogs which are currently available.
7536  *
7537  * A detailed description what a dialog does and how to add a dialog to SCIP can be found
7538  * \ref DIALOG "here".
7539  */
7540 
7541 /**@defgroup DISPLAYS Displays
7542  * @brief This page contains a list of all displays (output columns) which are currently available.
7543  *
7544  * A detailed description what a display does and how to add a display to SCIP can be found
7545  * \ref DISP "here".
7546  *
7547  */
7548 
7549 /**@defgroup EXPRINTS Expression Interpreter
7550  * @brief This page contains a list of all expression interpreter which are currently available.
7551  *
7552  * A detailed description what a expression interpreter does and how to add a expression interpreter to SCIP can be found
7553  * \ref EXPRINT "here".
7554  */
7555 
7556 /**@defgroup FILEREADERS File Readers
7557  * @brief This page contains a list of all file readers which are currently available.
7558  *
7559  * @section AVAILABLEFORMATS List of readable file formats
7560  *
7561  * The \ref SHELL "interactive shell" and the callable library are capable of reading/parsing several different file
7562  * formats.
7563  *
7564  * <table>
7565  * <tr><td>\ref reader_cip.h "CIP format"</td> <td>for SCIP's constraint integer programming format</td></tr>
7566  * <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>
7567  * <tr><td>\ref reader_diff.h "DIFF format"</td> <td>for reading a new objective function for mixed-integer programs</td></tr>
7568  * <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>
7569  * <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>
7570  * <tr><td>\ref reader_lp.h "LP format"</td> <td>for mixed-integer (quadratically constrained quadratic) programs (CPLEX)</td></tr>
7571  * <tr><td>\ref reader_mps.h "MPS format"</td> <td>for mixed-integer (quadratically constrained quadratic) programs</td></tr>
7572  * <tr><td>\ref reader_opb.h "OPB format"</td> <td>for pseudo-Boolean optimization instances</td></tr>
7573  * <tr><td>\ref reader_osil.h "OSiL format"</td> <td>for mixed-integer nonlinear programs</td></tr>
7574  * <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>
7575  * <tr><td>\ref reader_sol.h "SOL format"</td> <td>for solutions; XML-format (read-only) or raw SCIP format</td></tr>
7576  * <tr><td>\ref reader_wbo.h "WBO format"</td> <td>for weighted pseudo-Boolean optimization instances</td></tr>
7577  * <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
7578  * programming problems [read only]</td></tr>
7579  * </table>
7580  *
7581  * @section ADDREADER How to add a file reader
7582  *
7583  * A detailed description what a file reader does and how to add a file reader to SCIP can be found
7584  * \ref READER "here".
7585  *
7586  */
7587 
7588 /**@defgroup LPIS LP Solver Interfaces
7589  * @brief This page contains a list of all LP solver interfaces which are currently available.
7590  */
7591 
7592 /**@defgroup NODESELECTORS Node Selectors
7593  * @brief This page contains a list of all node selectors which are currently available.
7594  *
7595  * A detailed description what a node selector does and how to add a node selector to SCIP can be found
7596  * \ref NODESEL "here".
7597  */
7598 
7599 /**@defgroup NLPIS NLP Solver Interfaces
7600  * @brief This page contains a list of all NLP solver interfaces which are currently available.
7601  *
7602  * A detailed description what a NLP solver interface does and how to add a NLP solver interface to SCIP can be found
7603  * \ref NLPI "here".
7604  */
7605 
7606 /**@defgroup PRESOLVERS Presolvers
7607  * @brief This page contains a list of all presolvers which are currently available.
7608  *
7609  * A detailed description what a presolver does and how to add a presolver to SCIP can be found
7610  * \ref PRESOL "here".
7611  */
7612 
7613 /**@defgroup PRICERS Pricers
7614  * @brief This page contains a list of all pricers which are currently available.
7615  *
7616  * Per default there exist no variable pricer. A detailed description what a variable pricer does and how to add a
7617  * variable pricer to SCIP can be found \ref PRICER "here".
7618  */
7619 
7620 /**@defgroup PRIMALHEURISTICS Primal Heuristics
7621  * @brief This page contains a list of all primal heuristics which are currently available.
7622  *
7623  * A detailed description what a primal heuristic does and how to add a primal heuristic to SCIP can be found
7624  * \ref HEUR "here".
7625  */
7626 
7627 /**@defgroup PROPAGATORS Propagators
7628  * @brief This page contains a list of all propagators which are currently available.
7629  *
7630  * A detailed description what a propagator does and how to add a propagator to SCIP can be found
7631  * \ref PROP "here".
7632  */
7633 
7634 /**@defgroup RELAXATORS Relaxation Handlers
7635  * @brief This page contains a list of all relaxation handlers which are currently available.
7636  *
7637  * Note that the linear programming relaxation is not implemented via the relaxation handler plugin. Per default there
7638  * exist no relaxation handler. A detailed description what a variable pricer does and how to add a A detailed
7639  * description what a relaxation handler does and how to add a relaxation handler to SCIP can be found \ref RELAX
7640  * "here".
7641  */
7642 
7643 /**@defgroup SEPARATORS Separators
7644  * @brief This page contains a list of all separators which are currently available.
7645  *
7646  * A detailed description what a separator does and how to add a separator to SCIP can be found
7647  * \ref SEPA "here".
7648  */
7649 
7650 /**@page PARAMETERS List of all SCIP parameters
7651  *
7652  * This page list all parameters of the current SCIP version. This list can
7653  * easily be generated by SCIP via the interactive shell using the following command:
7654  *
7655  * <code>SCIP&gt; set save &lt;file name&gt;</code>
7656  *
7657  * or via the function call:
7658  *
7659  * <code>SCIP_CALL( SCIPwriteParams(scip, &lt;file name&gt;, TRUE, FALSE) );</code>
7660  *
7661  * \verbinclude parameters.set
7662  */
7663 
7664 /**@page PYTHON_INTERFACE Python interface for the SCIP Optimization Suite
7665  *
7666  * This page shows how to install the Python interface that comes with SCIP. A short usage example is shown below.
7667  *
7668  * INSTALL:
7669  * \verbinclude interfaces/python/INSTALL
7670  *
7671  * Usage information (README):
7672  * \verbinclude interfaces/python/README
7673  */
7674 
7675 /**@page JNI_INTERFACE Java native interface for SCIP
7676  *
7677  * This page shows how to install and test the Java native interface (JNI) of SCIP.
7678  *
7679  * \verbinclude interfaces/jni/README
7680  */
7681 
7682 /**@page INTERFACES Interfaces
7683  *
7684  * There are several ways of accessing the \SCIP Optimization Suite from other software packages or programming
7685  * platforms.
7686  *
7687  *
7688  * @section FILEFORMATS File formats
7689  *
7690  * The easiest way to load a problem into \SCIP is via an input file, given in a format that \SCIP can parse directly,
7691  * see SHELL. \SCIP is capable of reading more than ten different file formats, including formats for nonlinear
7692  * problems and constraint programs. This gives researchers from different communities an easy, first access to the
7693  * \SCIP Optimization Suite. See \ref AVAILABLEFORMATS "List of readable file formats".
7694  *
7695  *
7696  * @section CPLUSPLUS C++ wrapper
7697  *
7698  * Since SCIP is written in C, its callable library can be directly accessed from C++. If a user wants to program own
7699  * plugins in C++, there are wrapper classes for all different types of plugins available in the <code>src/objscip</code>
7700  * directory of the \SCIP standard distribution. See also <a href=annotated.php>Wrapper Classes</a>.
7701  *
7702  *
7703  * @section MODELLING Modeling languages and Matlab interface
7704  *
7705  * A natural way of formulating an optimization problem is to use a modeling language. Besides ZIMPL there are several
7706  * other modeling tools with a direct interface to \SCIP. These include <a href="http://dynadec.com/">Comet</a>, a
7707  * modeling language for constraint programming, <a href="http://www.ampl.com/">AMPL</a> and <a
7708  * href="http://www.gams.com/">GAMS</a>, which are well-suited for modeling mixed-integer linear and nonlinear
7709  * optimization problems, and <a href="https://projects.coin-or.org/Cmpl">CMPL</a> for mixed-integer linear problems.
7710  * The AMPL, GAMS, and ZIMPL interfaces are included in the SCIP distribution, the GAMS interface originated <a
7711  * href="https://projects.coin-or.org/GAMSlinks">here</a>.
7712  *
7713  * With \SCIP 3.0, a first beta version of a functional MATLAB interface has been released. It supports solving MIPs
7714  * and LPs defined by Matlab's matrix and vector types. The <a href="http://www.i2c2.aut.ac.nz/Wiki/OPTI/index.php">OPTI
7715  * project</a> by Jonathan Currie provides an external MATLAB interface for the \SCIP Optimization Suite. On top of this,
7716  * <a href="http://users.isy.liu.se/johanl/yalmip/pmwiki.php?n=Main.HomePage">YALMIP</a> by Johan L&ouml;fberg provides a
7717  * free modeling language.
7718  *
7719  * @section OTHER Python and Java interfaces
7720  *
7721  * With \SCIP 3.1, beta versions of a \ref JNI_INTERFACE "Java native interface" and a \ref PYTHON_INTERFACE "Python interface" have been released.
7722  *
7723  * There are also several third-party python interfaces to the \SCIP Optimization Suite, e.g., <a
7724  * href="http://numberjack.ucc.ie/">NUMBERJACK</a> and <a
7725  * href="http://code.google.com/p/python-zibopt/">python-zibopt</a>. <a href="http://numberjack.ucc.ie/">NUMBERJACK</a>
7726  * is a constraint programming platform implemented in python. It supports a variety of different solvers, one of them
7727  * being the \SCIP Optimization Suite. <a href="http://code.google.com/p/python-zibopt/">python-zibopt</a> was developed
7728  * by Ryan J. O'Neil and is a python extension of the \SCIP Optimization Suite. <a
7729  * href="http://picos.zib.de/">PICOS</a> is a python interface for conic optimization, provided by Guillaume Sagnol.
7730  *
7731  *
7732  */