251 * There are several extensions of \SCIP for particular applications included in the release. They are contained in the "applications" directory
1060 * Okay, let's solve the example instance... use "read check/instances/MIP/stein27.fzn" to parse the instance file, "optimize" to solve it and "display
1061 * solution" to show the nonzero variables of the best found solution.
1306 * \par LINCONSUPGD_PRIORITY: priority of the constraint handler for upgrading of linear constraints
1307 * This property is only needed if a certain linear constraint can be upgraded to a more specific one. In one of
1308 * the first presolving rounds SCIP tries to upgrade linear constraints to more specialized constraints, such as
1309 * knapsack constraints. The upgrading calls are processed in the order of decreasing priority.
1310 *
1311 * \par NONLINCONSUPGD_PRIORITY: priority of the constraint handler for upgrading of nonlinear constraints
1312 * This property has the same effect as the LINCONSUPGD_PRIORITY parameter, see above, and should be set whenever
1313 * an upgrade functionality from a general nonlinear constraint to the more specific one is defined.
1314 *
1315 * \par CONSHDLR_SEPAFREQ: the default frequency for separating cuts.
1316 * The separation frequency defines the depth levels at which the constraint handler's separation methods \ref CONSSEPALP
1317 * and \ref CONSSEPASOL are called.
1318 * For example, a separation frequency of 7 means, that the separation callback is executed for subproblems that are
1319 * in depth 0, 7, 14, ... of the branching tree.
1320 * A separation frequency of 0 means, that the separation method is only called at the root node.
1321 * A separation frequency of -1 disables the separation method of the constraint handler.
1322 * \n
1323 * The separation frequency can be adjusted by the user.
1324 * This property of the constraint handler only defines the default value of the frequency.
1325 * If you want to have a more flexible control of when to execute the separation algorithm, you have to assign
1326 * a separation frequency of 1 and implement a check at the beginning of your separation algorithm whether you really
1327 * want to execute the separator or not.
1328 * If you do not want to execute the method, set the result code to SCIP_DIDNOTRUN.
1329 *
1330 * \par CONSHDLR_SEPAPRIORITY: the priority of the constraint handler for separation. (optional: to be set only if the constraint handler supports separation)
1331 * In each separation round during the price-and-cut loop of the subproblem processing or during the separation loop
1332 * of the primal solution separation, the separators and separation methods of the constraint handlers are called in
1333 * a predefined order, which is given by the priorities of the separators and the separation priorities of the
1334 * constraint handlers.
1335 * First, the separators with non-negative priority are called in the order of decreasing priority.
1336 * Next, the separation methods of the different constraint handlers are called in the order of decreasing separation
1337 * priority.
1338 * Finally, the separators with negative priority are called in the order of decreasing priority.
1339 * \n
1340 * The separation priority of the constraint handler should be set according to the complexity of the cut separation
1341 * algorithm and the impact of the resulting cuts:
1342 * Constraint handlers that provide fast algorithms that usually have a high impact (i.e., cut off a large portion of
1343 * the LP relaxation) should have a high priority.
1344 * See \ref CONSSEPALP and \ref CONSSEPASOL for further details of the separation callbacks.
1345 *
1346 * \par CONSHDLR_DELAYSEPA: the default for whether the separation method should be delayed, if other separators found cuts.
1347 * If the constraint handler's separation method is marked to be delayed, it is only executed after no other separator
1348 * or constraint handler found a cut during the price-and-cut loop.
1349 * If the separation method of the constraint handler is very expensive, you may want to mark it to be delayed until all
1350 * cheap separation methods have been executed.
1351 *
1352 * \par CONSHDLR_PROPFREQ: the default frequency for propagating domains.
1353 * This default frequency has the same meaning as the CONSHDLR_SEPAFREQ with respect to the domain propagation
1354 * callback of the constraint handler.
1355 * A propagation frequency of 0 means that propagation is only applied in preprocessing and at the root node.
1356 * A propagation frequency of -1 disables the propagation method of the constraint handler.
1357 *
1358 * \par CONSHDLR_DELAYPROP: the default for whether the propagation method should be delayed, if other propagators found reductions.
1359 * This property is analogous to the DELAYSEPA flag, but deals with the propagation method of the constraint handler.
1360 *
1361 * \par CONSHDLR_PROP_TIMING: the propagation timing mask of the constraint handler.
1362 * SCIP calls the domain propagation routines at different places in the node processing loop.
1363 * This property indicates at which places the propagation routine of the constraint handler is called.
1364 * Possible values are defined in type_timing.h and can be concatenated, e.g., as in SCIP_PROPTIMING_ALWAYS.
1365 *
1366 * \par CONSHDLR_PRESOLTIMING: the timing of the constraint handler's presolving method (FAST, MEDIUM, or EXHAUSTIVE).
1367 * Every presolving round starts with the FAST presolving methods. MEDIUM presolvers are only called, if FAST presolvers did not find
1368 * enough reductions in this round so far, and EXHAUSTIVE presolving steps are only performed if all presolvers called before
1369 * in this round were unsuccessful.
1370 * Presolving methods should be assigned a timing based on how expensive they are, e.g., presolvers that provide fast algorithms that
1371 * usually have a high impact (i.e., remove lots of variables or tighten bounds of many variables) should have a timing FAST.
1372 * If a presolving method implements different algorithms of different complexity, it may also get multiple timings and check the timing
1373 * internally in the \ref CONSPRESOL callback to decide which algorithms to run.
1374 *
1375 * \par CONSHDLR_MAXPREROUNDS: the default maximal number of presolving rounds the constraint handler participates in.
1376 * The preprocessing is executed in rounds.
1377 * If enough changes have been applied to the model, an additional preprocessing round is performed.
1378 * The MAXPREROUNDS parameter of a constraint handler denotes the maximal number of preprocessing rounds the constraint
1379 * handler participates in.
1380 * A value of -1 means that there is no limit on the number of rounds.
1381 * A value of 0 means the preprocessing callback of the constraint handler is disabled.
1382 *
1383 *
1384 *
1385 * @section CONS_DATA Constraint Data and Constraint Handler Data
1386 *
1387 * Below the header "Data structures" you can find two structs called "struct SCIP_ConsData" and
1388 * "struct SCIP_ConshdlrData".
1389 * If you are using C++, you only need to define the "struct SCIP_ConsData".
1390 * The constraint handler data must be implemented as member variables of your constraint handler class.
1391 * \n
1392 * The constraint data are the information that is needed to define a single constraint of the constraint handler's
1393 * constraint class.
1394 * For example, the data of a knapsack constraint would consist of a list of variables, a list of weights, and
1395 * the capacity of the knapsack.
1396 * The data of a subtour constraint consists of the graph on which the problem is defined.
1397 * In the graph, each edge should be linked to the corresponding binary problem variable.
1398 * \n
1399 * The constraint handler data are additional variables, that belong to the constraint handler itself and which are
1400 * not specific to a single constraint.
1401 * For example, you can use these data to store parameters of the constraint handler or statistical information.
1402 * The constraint handler data are optional.
1403 * You can leave the struct empty.
1404 *
1405 *
1406 * @section CONS_INTERFACE Interface Methods
1407 *
1408 * At the bottom of "cons_subtour.c" you can find three interface methods, that also appear in "cons_subtour.h".
1409 * These are SCIPincludeConshdlrSubtour(), SCIPcreateConsSubtour(), and SCIPcreateConsSubtourBasic().
1410 * \n
1411 * The method SCIPincludeConshdlrSubtour() only has to be adjusted slightly.
1412 * It is responsible for notifying SCIP of the presence of the constraint handler by calling the method
1413 * SCIPincludeConshdlr().
1414 * It is called by the user, if (s)he wants to include the constraint handler, i.e., if (s)he wants to make
1415 * the constraint handler available to the model, and looks like this:
1416 * \dontinclude src/scip/cons_knapsack.c
1417 * -# If you are using constraint handler data, you have to <b>allocate the memory for the data</b> at this point.
1418 * You also have to initialize the fields in struct SCIP_ConshdlrData afterwards.
1746 * The CONSINITLP callback is executed before the first LP relaxation is solved.
1747 * It should add the LP relaxations of all "initial" constraints to the LP. The method should scan the constraints
1748 * array for constraints that are marked initial via calls to SCIPconsIsInitial() and put the LP relaxation
1749 * of all initial constraints to the LP with calls to SCIPaddCut().
1750 *
1751 * @subsection CONSSEPALP
1752 *
1753 * The CONSSEPALP callback is executed during the price-and-cut loop of the subproblem processing.
1754 * It should try to generate cutting planes for the constraints of the constraint handler in order to separate
1755 * the current LP solution.
1756 * The method is called in the LP solution loop, which means that a valid LP solution exists.
1757 *
1758 * Usually, a separation callback searches and produces cuts, that are added with a call to SCIPaddCut().
1759 * If the cut should be remembered in the global cut pool, it may also call SCIPaddPoolCut().
1760 * However, the callback may also produce domain reductions or add other constraints.
1761 *
1762 * The CONSSEPALP callback has the following options:
1763 * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
1764 * - adding an additional constraint (result SCIP_CONSADDED)
1765 * - reducing a variable's domain (result SCIP_REDUCEDDOM)
1766 * - adding a cutting plane to the LP (result SCIP_SEPARATED)
1767 * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
1768 * (result SCIP_DIDNOTFIND)
1769 * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
1770 * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
1771 * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
1772 *
1773 * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1774 * CONSHDLR_SEPAFREQ, CONSHDLR_SEPAPRIORITY, and CONSHDLR_DELAYSEPA, which influence the behaviour of SCIP
1775 * calling CONSSEPALP.
1776 *
1777 * @subsection CONSSEPASOL
1778 *
1779 * The CONSSEPASOL callback is executed during separation loop on arbitrary primal solutions.
1780 * It should try to generate cutting planes for the constraints of the constraint handler in order to separate
1781 * the given primal solution.
1782 * The method is not called in the LP solution loop, which means that there is no valid LP solution.
1783 *
1784 * Usually, a separation callback searches and produces cuts, that are added with a call to SCIPaddCut().
1785 * If the cut should be remembered in the global cut pool, it may also call SCIPaddPoolCut().
1786 * However, the callback may also produce domain reductions or add other constraints.
1787 *
1788 * The CONSSEPASOL callback has the following options:
1789 * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
1790 * - adding an additional constraint (result SCIP_CONSADDED)
1791 * - reducing a variable's domain (result SCIP_REDUCEDDOM)
1792 * - adding a cutting plane to the LP (result SCIP_SEPARATED)
1793 * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
1794 * (result SCIP_DIDNOTFIND)
1795 * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
1796 * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
1797 * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
1798 *
1799 * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1800 * CONSHDLR_SEPAFREQ, CONSHDLR_SEPAPRIORITY, and CONSHDLR_DELAYSEPA, which influence the behaviour of SCIP
1801 * calling CONSSEPASOL.
1802 *
1803 * @subsection CONSENFORELAX
1804 *
1805 * The CONSENFORELAX callback is similar to the CONSENFOLP and CONSENFOPS callbacks, but deals with relaxation solutions.
1806 *
1807 * If the best bound computed by a relaxator that includes the whole LP is strictly better than the bound of the LP itself,
1808 * the corresponding relaxation solution will get enforced. Therefore the CONSENFORELAX callback will only be called for
1809 * solutions that satisfy all active LP-constraints.
1810 *
1811 * Like the ENFOLP and ENFOPS callbacks, the ENFORELAX callback has to check whether the solution given in sol satisfies
1812 * all the constraints of the constraint handler. Since the callback is only called for relaxators including the whole LP,
1813 * cuts may be added with a result of SCIP_SEPARATED, like in the ENFOLP callback. It is also possible to return
1814 * SCIP_SOLVELP if the relaxation solution is invalid for some reason and the LP should be solved instead.
1815 *
1816 * Note that the CONSENFORELAX callback is only relevant if relaxators are used. Since the basic distribution of the
1817 * SCIP Optimization Suite does not contain any relaxators, this callback can be ignored unless any relaxators are added
1818 * via user-plugins.
1819 *
1820 * @subsection CONSPROP
1821 *
1822 * The CONSPROP callback is called during the subproblem processing.
1823 * It should propagate the constraints, which means that it should infer reductions in the variables' local bounds
1824 * from the current local bounds.
1825 * This technique, which is the main workhorse of constraint programming, is called "node preprocessing" in the
1826 * Integer Programming community.
1827 *
1828 * The CONSPROP callback has the following options:
1829 * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
1830 * - reducing a variable's domain (result SCIP_REDUCEDDOM)
1831 * - stating that the propagator searched, but did not find domain reductions, cutting planes, or cut constraints
1832 * (result SCIP_DIDNOTFIND)
1833 * - stating that the propagator was skipped (result SCIP_DIDNOTRUN)
1834 * - stating that the propagator was skipped, but should be called again (result SCIP_DELAYED)
1835 *
1836 * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1837 * CONSHDLR_PROPFREQ, CONSHDLR_DELAYPROP, and CONSHDLR_PROP_TIMING, which influence the behaviour of SCIP
1838 * calling CONSPROP.
1839 *
1840 * @subsection CONSRESPROP
1841 *
1842 * If the constraint handler should support \ref CONF "conflict analysis", it has to supply a CONSRESPROP method.
1843 * It also should call SCIPinferVarLbCons() or SCIPinferVarUbCons() in domain propagation instead of SCIPchgVarLb() or
1844 * SCIPchgVarUb() in order to deduce bound changes on variables.
1845 * In the SCIPinferVarLbCons() and SCIPinferVarUbCons() calls, the handler provides the constraint that deduced the
1846 * variable's bound change, and an integer value <code>inferinfo</code> that can be arbitrarily chosen.
1847 *
1848 * The propagation conflict resolving method CONSRESPROP must then be implemented to provide the "reasons" for the bound
1849 * changes, i.e., the bounds of variables at the time of the propagation, which forced the constraint to set the
1850 * conflict variable's bound to its current value. It can use the <code>inferinfo</code> tag to identify its own propagation rule
1851 * and thus identify the "reason" bounds. The bounds that form the reason of the assignment must then be provided by
1852 * calls to SCIPaddConflictLb() and SCIPaddConflictUb() in the propagation conflict resolving method.
1853 *
1854 * <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
1855 * need more information to efficiently infer the original propagation steps that lead to the conflict. This would,
1856 * however, require too much space. In the extreme, the original propagation steps have to be repeated.
1857 *
1858 * 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
1859 * 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
1860 * variables are 0.0). It uses <code>SCIPinferVarLbCons(scip, z, 1.0, c, 0)</code> to apply this assignment (an
1861 * inference information tag is not needed by the constraint handler and is set to 0). In the conflict analysis, the
1862 * constraint handler may be asked to resolve the lower bound change on \f$z\f$ with constraint \f$c\f$, that was
1863 * applied at a time given by a bound change index "bdchgidx". With a call to <code>SCIPvarGetLbAtIndex(z,
1864 * bdchgidx)</code>, the handler can find out, that the lower bound of variable \f$z\f$ was set to 1.0 at the given
1865 * point of time, and should call <code>SCIPaddConflictUb(scip, x, bdchgidx)</code> and <code>SCIPaddConflictUb(scip, y,
1866 * 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
1867 * the deduction of the lower bound of \f$z\f$.
1868 *
1869 * If conflict analysis should not be supported, the method has to set the result code to SCIP_DIDNOTFIND. Although
1870 * this is a viable approach to circumvent the implementation of the usually rather complex conflict resolving method, it
1871 * will make the conflict analysis less effective. We suggest to first omit the conflict resolving method and check how
1872 * effective the \ref CONSPROP "propagation method" is. If it produces a lot of propagations for your application, you definitely should
1873 * consider implementing the conflict resolving method.
1874 *
1875 * @subsection CONSPRESOL
1876 *
1877 * The CONSPRESOL callback is called during preprocessing.
1878 * It should try to tighten the domains of the variables, tighten the coefficients of the constraints of the constraint
1879 * handler, delete redundant constraints, aggregate and fix variables if possible, and upgrade constraints to more
1880 * specific types.
1881 *
1882 * If the CONSPRESOL callback applies changes to the constraint data, you also have to implement the \ref CONSTRANS callback
1883 * in order to copy the constraint data to the transformed problem space and protect the original problem from the
1884 * preprocessing changes.
1885 *
1886 * To inform SCIP that the presolving method found a reduction the result pointer has to be set in a proper way.
1887 * The following options are possible:
1888 *
1889 * - SCIP_UNBOUNDED : at least one variable is not bounded by any constraint in objective direction
1890 * - SCIP_CUTOFF : at least one constraint is infeasible in the variable's bounds
1891 * - SCIP_SUCCESS : the presolver found a reduction
1892 * - SCIP_DIDNOTFIND : the presolver searched, but did not find a presolving change
1893 * - SCIP_DIDNOTRUN : the presolver was skipped
1894 * - SCIP_DELAYED : the presolver was skipped, but should be called again
1895 *
1896 * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1897 * CONSHDLR_PRESOLTIMING and CONSHDLR_MAXPREROUNDS, which influence the behaviour of SCIP
1898 * calling CONSPRESOL.
1899 *
1900 * @subsection CONSACTIVE
1901 *
1902 * The CONSACTIVE callback method is called each time a constraint of the constraint handler is activated.
1903 * For example, if a constraint is added locally to a subproblem, the CONSACTIVE callback is called whenever the
1904 * search enters the subtree where the constraint exists.
1905 *
1906 * @subsection CONSDEACTIVE
1907 *
1908 * The CONSDEACTIVE callback method is called each time a constraint of the constraint handler is deactivated.
1909 * For example, if a constraint is added locally to a subproblem, the CONSDEACTIVE callback is called whenever the
1910 * search leaves the subtree where the constraint exists.
1911 *
1912 * @subsection CONSENABLE
1913 *
1914 * The CONSENABLE callback method is called each time a constraint of the constraint handler is enabled.
1915 * Constraints might be active without being enabled. In this case, only the feasibility checks are executed,
1916 * but domain propagation and separation is skipped.
1917 *
1918 * @subsection CONSDISABLE
1919 *
1920 * The CONSDISABLE callback method is called each time a constraint of the constraint handler is disabled.
1921 *
1922 * @subsection CONSPRINT
1923 *
1924 * The CONSPRINT callback method is called, when the user asks SCIP to display the problem to the screen
1925 * or save the problem into a file. This is, however, only the case if the user requested the CIP format.
1926 * For more details about reading and writing with SCIP we refer to the \ref READER "file readers". In this
1927 * callback method the constraint handler should display the data of the constraint in an appropriate form.
1928 * The output format that is defined by the CONSPRINT callbacks is called CIP format.
1929 * In later versions of SCIP, the constraint handlers should also be able to parse (i.e., read) constraints
1930 * which are given in CIP format.
1931 *
1932 * @subsection CONSCOPY
1933 *
1934 * The CONSCOPY callback method is used whenever constraints should be copied from one SCIP instance into another SCIP
1935 * instance. This method comes with the necessary parameters to do so, most importantly with a mapping of the variables of the
1936 * source SCIP instance to the corresponding variables of the target SCIP instance, and a mapping for the constraints
1937 * in the same way. For a complete list of all arguments of this callback method see type_cons.h.
1938 *
1939 * To get the corresponding target variable of a given source variable, you can use the variable map directly:
2408 * You also have to initialize the fields in struct SCIP_PresolData afterwards. For freeing the
2409 * presolver data, see \ref PRESOLFREE.
2410 *
2411 * You may also add user parameters for your presolver, see \ref PARAM for how to add user parameters and
2412 * the method SCIPincludePresolTrivial() in src/scip/presol_trivial.c for an example.
2413 *
2414 *
2415 * @section PRESOL_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Presolver
2416 *
2417 * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
2418 * an operational algorithm.
2419 * They are passed together with the presolver itself to SCIP using SCIPincludePresol() or SCIPincludePresolBasic(),
2420 * see @ref PRESOL_INTERFACE.
2421 *
2422 * Presolver plugins have only one fundamental callback method, namely the @ref PRESOLEXEC method.
2423 * This method has to be implemented for every presolver; the other callback methods are optional.
2424 * In the C++ wrapper class scip::ObjPresol, the scip_exec() method (which corresponds to the PRESOLEXEC callback) is a virtual
2425 * abstract member function.
2426 * You have to implement it in order to be able to construct an object of your presolver class.
2427 *
2428 * Additional documentation for the callback methods, in particular to their input parameters,
2429 * can be found in type_presol.h.
2430 *
2431 * @subsection PRESOLEXEC
2432 *
2433 * The PRESOLEXEC callback is called inside the presolving loop and should perform the actual presolving reductions.
2434 * It should inspect the problem instance at hand and simplify it by tightening bounds of variables, aggregating or fixing
2435 * variables, changing the type of variables, modifying the graph that represents the instance of your application, and
2436 * the like.
2437 *
2438 * Typical methods called by a presolver are, for example, SCIPchgVarType(), SCIPfixVar(), SCIPaggregateVars(), SCIPtightenVarLb(),
2439 * and SCIPtightenVarUb().
2440 *
2441 *
2442 * @section PRESOL_ADDITIONALCALLBACKS Additional Callback Methods of a Presolver
2443 *
2444 * The additional callback methods do not need to be implemented in every case. However, some of them have to be
2445 * implemented for most applications, they can be used, for example, to initialize and free private data.
2446 * Additional callbacks can either be passed directly with SCIPincludePresol() to SCIP or via specific
2447 * <b>setter functions</b> after a call of SCIPincludePresolBasic(), see also @ref PRESOL_INTERFACE.
2448 *
2449 * @subsection PRESOLFREE
2450 *
2451 * 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.
2452 * This can be done by the following procedure:
2497 * Separators are used to generate general purpose cutting planes.
2498 * Constraint based cutting planes, the second type of cutting planes in SCIP, are separated in the CONSSEPALP and
2499 * CONSSEPASOL callback methods of the constraint handlers, see \ref CONSSEPALP and \ref CONSSEPASOL. These cuts are
2500 * valid inequalities or even facets of the polyhedron described by a single constraint or a subset of the constraints of
2501 * a single constraint class. In contrast, general purpose cuts do not require or exploit any knowledge about the
2502 * underlying problem structure but use only the current LP relaxation and the integrality conditions. See also
2503 * "When should I implement a constraint handler, when should I implement a separator?" on \ref FAQ.
2504 * \n
2505 * A complete list of all separators contained in this release can be found \ref SEPARATORS "here".
2506 *
2507 * We now explain how users can add their own separators.
2508 * Take the separator for the class of Gomory mixed integer inequalities (src/scip/sepa_gomory.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::ObjSepa wrapper
2510 * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_SEPA... callback methods.
2511 *
2512 * Additional documentation for the callback methods of a separator, in particular for the input parameters,
2513 * can be found in the file type_sepa.h.
2514 *
2515 * Here is what you have to do to implement a separator:
2516 * -# Copy the template files src/scip/sepa_xyz.c and src/scip/sepa_xyz.h into files "sepa_myseparator.c"
2517 * and "sepa_myseparator.h".
2518 \n
2519 * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2520 * -# Use SCIPincludeSepaMyseparator() in order to include the separator 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 "myseparator".
2523 * -# Adjust the properties of the separator (see \ref SEPA_PROPERTIES).
2524 * -# Define the separator data (see \ref SEPA_DATA). This is optional.
2525 * -# Implement the interface methods (see \ref SEPA_INTERFACE).
2526 * -# Implement the fundamental callback methods (see \ref SEPA_FUNDAMENTALCALLBACKS).
2527 * -# Implement the additional callback methods (see \ref SEPA_ADDITIONALCALLBACKS). This is optional.
2528 *
2529 *
2530 * @section SEPA_PROPERTIES Properties of a Separator
2531 *
2532 * At the top of the new file "sepa_myseparator.c", you can find the separator properties.
2533 * These are given as compiler defines.
2534 * In the C++ wrapper class, you have to provide the separator properties by calling the constructor
2535 * of the abstract base class scip::ObjSepa from within your constructor.
2536 * The properties you have to set have the following meaning:
2537 *
2538 * \par SEPA_NAME: the name of the separator.
2539 * This name is used in the interactive shell to address the separator.
2540 * Additionally, if you are searching for a separator with SCIPfindSepa(), this name is looked up.
2541 * Names have to be unique: no two separators may have the same name.
2542 *
2543 * \par SEPA_DESC: the description of the separator.
2544 * This string is printed as a description of the separator in the interactive shell.
2545 *
2546 * \par SEPA_PRIORITY: the priority of the separator.
2547 * In each separation round during the price-and-cut loop of the subproblem processing or the separation loop
2548 * of the primal solution separation, the separators and separation methods of the constraint handlers are called in
2549 * a predefined order, which is given by the priorities of the separators and the separation priorities
2550 * of the constraint handlers (see \ref CONS_PROPERTIES).
2551 * First, the separators with non-negative priority are called in the order of decreasing priority.
2552 * Next, the separation methods of the constraint handlers are called in the order of decreasing separation
2553 * priority.
2554 * Finally, the separators with negative priority are called in the order of decreasing priority. An easy way to list the
2555 * priorities of all separators and constraint handlers is to type "display separators" and "display conshdlrs" in
2556 * the interactive shell.
2557 * \n
2558 * The priority of the separator should be set according to the complexity of the cut separation algorithm and the
2559 * impact of the resulting cuts: separators that provide fast algorithms that usually have a high impact (i.e., cut off
2560 * a large portion of the LP relaxation) should have a high priority.
2561 * See \ref SEPAEXECLP and \ref SEPAEXECSOL for further details of the separation callbacks.
2562 *
2563 * \par SEPA_FREQ: the default frequency for separating cuts.
2564 * The frequency defines the depth levels at which the separation methods \ref SEPAEXECLP and \ref SEPAEXECSOL are called.
2565 * For example, a frequency of 7 means, that the separation callback is executed for subproblems that are in depth
2566 * 0, 7, 14, ... of the branching tree. A frequency of 0 means, that the separation method is only called at the root node.
2567 * A frequency of -1 disables the separator.
2568 * \n
2569 * The frequency can be adjusted by the user. This property of the separator only defines the default value of the frequency.
2570 * If you want to have a more flexible control of when to execute the separation algorithm, you have to assign
2571 * a frequency of 1 and implement a check at the beginning of your separation methods whether you really want to execute
2572 * the separation or not. If you do not want to execute it, set the result code of
2573 * \ref SEPAEXECLP and \ref SEPAEXECSOL to SCIP_DIDNOTRUN.
2574 *
2575 * \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.
2576 * At the current branch-and-bound node, the relative distance from its dual bound (local dual bound)
2577 * to the primal bound compared to the best node's dual bound (global dual bound) is considered. The separation method
2578 * of the separator will only be applied at the current node if this relative distance does not exceed SEPA_MAXBOUNDDIST.
2579 * \n
2580 * For example, if the global dual bound is 50 and the primal bound is 60, SEPA_MAXBOUNDDIST = 0.25 means that separation
2581 * 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
2582 * than or equal to 52.5.
2583 * \n
2584 * In particular, the values 0.0 and 1.0 mean that separation is applied at the current best node only or at all
2585 * nodes, respectively. Since separation seems to be most important to apply at nodes that define to the global
2586 * dual bound, 0.0 is probably a good choice for SEPA_MAXBOUNDDIST.
2587 * Note that separators with a frequency of SEPA_FREQ = 0 are only applied at the root node.
2588 * Obviously, at the root node the local dual bound is equal to the global dual bound and thus, the separator is called
2589 * for any value of SEPA_MAXBOUNDDIST.
2590 *
2591 * \par SEPA_USESSUBSCIP: Does the separator use a secondary SCIP instance?
2592 * Some heuristics and separators solve MIPs or SAT problems and use a secondary SCIP instance. Examples are
2593 * Large Neighborhood Search heuristics such as RINS and Local Branching or the CGMIP separator. To avoid recursion,
2594 * these plugins usually deactivate all other plugins that solve MIPs. If a separator uses a secondary SCIP instance,
2595 * this parameter has to be TRUE and it is recommended to call SCIPsetSubscipsOff() for the secondary SCIP instance.
2596 *
2597 * \par SEPA_DELAY: the default for whether the separation method should be delayed, if other separators or constraint handlers found cuts.
2598 * If the separator's separation method is marked to be delayed, it is only executed after no other separator
2599 * or constraint handler found a cut during the price-and-cut loop.
2600 * If the separation method of the separator is very expensive, you may want to mark it to be delayed until all cheap
2601 * separation methods have been executed.
2602 *
2603 * @section SEPA_DATA Separator Data
2604 *
2605 * Below the header "Data structures" you can find a struct which is called "struct SCIP_SepaData".
2606 * In this data structure, you can store the data of your separator. For example, you should store the adjustable
2607 * parameters of the separator in this data structure. In a separator, user parameters for the maximal number of
2608 * separation rounds per node and for the maximal number of cuts separated per separation round might be useful.
2609 * If you are using C++, you can add separator data as usual as object variables to your class.
2610 * \n
2611 * Defining separator data is optional. You can leave the struct empty.
2612 *
2613 * @section SEPA_INTERFACE Interface Methods
2614 *
2615 * At the bottom of "sepa_myseparator.c", you can find the interface method SCIPincludeSepaMyseparator(),
2616 * which also appears in "sepa_myseparator.h"
2617 * SCIPincludeSepaMyseparator() is called by the user, if (s)he wants to include the separator,
2618 * i.e., if (s)he wants to use the separator in his/her application.
2619 *
2620 * This method only has to be adjusted slightly.
2621 * It is responsible for notifying SCIP of the presence of the separator. For this, you can either call SCIPincludeSepa(),
2622 * or SCIPincludeSepaBasic() since SCIP version 3.0. In the latter variant, \ref SEPA_ADDITIONALCALLBACKS "additional callbacks"
2623 * must be added via setter functions as, e.g., SCIPsetSepaCopy(). We recommend this latter variant because
2624 * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
2625 * variant must be manually adjusted with every SCIP release containing new callbacks for separators in order to compile.
2626 *
2627 * If you are using separator data, you have to allocate the memory
2628 * for the data at this point. You can do this by calling:
2756 * Propagators are used to tighten the domains of the variables. Like for cutting planes, there are two different types
2757 * of domain propagations. Constraint based (primal) domain propagation algorithms are part of the corresponding
2758 * constraint handlers, see \ref CONSPROP. In contrast, domain propagators usually provide dual propagations, i.e.,
2759 * propagations that can be applied using the objective function and the current best known primal solution. This
2760 * section deals with such propagators.
2761 *
2762 * A complete list of all propagators contained in this release can be found \ref PROPAGATORS "here".
2763 *
2764 * We now explain how users can add their own propagators. Take the pseudo objective function propagator
2765 * (src/scip/prop_pseudoobj.c) as an example. As all other default plugins, it is written in C. C++ users can easily
2766 * adapt the code by using the scip::ObjProp wrapper base class and implement the @c scip_...() virtual methods instead
2767 * of the @c SCIP_DECL_PROP... callback methods.
2768 *
2769 * Additional documentation for the callback methods of a propagator can be found in the file type_prop.h.
2770 *
2771 * Here is what you have to do to implement a propagator:
2772 * -# Copy the template files src/scip/prop_xyz.c and src/scip/prop_xyz.h into files named "prop_mypropagator.c"
2773 * and "prop_mypropagator.h".
2774 * \n
2775 * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2776 * -# Use SCIPincludePropMypropagator() in order to include the propagator into your SCIP instance,
2777 * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
2778 * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mypropagator".
2779 * -# Adjust the properties of the propagator (see \ref PROP_PROPERTIES).
2780 * -# Define the propagator data (see \ref PROP_DATA). This is optional.
2781 * -# Implement the interface methods (see \ref PROP_INTERFACE).
2782 * -# Implement the fundamental callback methods (see \ref PROP_FUNDAMENTALCALLBACKS).
2783 * -# Implement the additional callback methods (see \ref PROP_ADDITIONALCALLBACKS). This is optional.
2784 *
2785 * @section PROP_PROPERTIES Properties of a Propagator
2786 *
2787 * At the top of the new file "prop_mypropagator.c" you can find the propagator properties. These are given as compiler
2788 * defines. The presolving-related properties are optional,
2789 * they only have to be defined if the propagator supports presolving routines.
2790 * In the C++ wrapper class, you have to provide the propagator properties by calling the constructor of the
2791 * abstract base class scip::ObjProp from within your constructor. The properties you have the following meaning:
2792 *
2793 * @subsection PROP_FUNDAMENTALPROPERTIES Fundamental properties of a propagator
2794 *
2795 * \par PROP_NAME: the name of the propagator.
2796 * This name is used in the interactive shell to address the propagator. Additionally, if you are searching for a
2797 * propagator with SCIPfindProp(), this name is searched for. Names have to be unique: no two propagators may have the
2798 * same name.
2799 *
2800 * \par PROP_DESC: the description of the propagator.
2801 * This string is printed as a description of the propagator in the interactive shell.
2802 *
2803 * \par PROP_PRIORITY: the priority of the propagator.
2804 * In each propagation round, the propagators and propagation methods of the constraint handlers are called in a
2805 * predefined order, which is given by the priorities of the propagators and the check priorities of the constraint
2806 * handlers. First, the propagators with non-negative priority are called in order of decreasing priority. Next, the
2807 * propagation methods of the different constraint handlers are called in order of decreasing check priority. Finally,
2808 * the propagators with negative priority are called in order of decreasing priority. \n The priority of the
2809 * propagators should be set according to the complexity of the propagation algorithm and the impact of the domain
2810 * propagations: propagators providing fast algorithms that usually have a high impact (i.e., tighten many bounds)
2811 * should have a high priority.
2812 *
2813 * \par PROP_FREQ: the default frequency for propagating domains.
2814 * The frequency defines the depth levels at which the propagation method \ref PROPEXEC is called. For example, a
2815 * frequency of 7 means, that the propagation callback is executed for subproblems that are in depth 0, 7, 14, ... of
2816 * the branching tree. A frequency of 0 means that propagation is only applied in preprocessing and at the root node. A
2817 * frequency of -1 disables the propagator.
2818 * \n
2819 * The frequency can be adjusted by the user. This property of the propagator only defines the default value of the
2820 * frequency.\n
2821 * <b>Note:</b> If you want to have a more flexible control of when to execute the propagation algorithm, you have to
2822 * assign a frequency of 1 and implement a check at the beginning of your propagation algorithm whether you really want
2823 * to execute the domain propagation or not. If you do not want to execute it, set the result code to SCIP_DIDNOTRUN.
2824 *
2825 * \par PROP_DELAY: the default for whether the propagation method should be delayed, if other propagators or constraint handlers found domain reductions.
2826 * If the propagator's propagation method is marked to be delayed, it is only executed after no other propagator or
2827 * constraint handler found a domain reduction in the current iteration of the domain propagation loop. If the
2828 * propagation method of the propagator is very expensive, you may want to mark it to be delayed until all cheap
2829 * propagation methods have been executed.
2830 *
2831 * \par PROP_TIMING: the timing mask of the propagator.
2832 * SCIP calls the domain propagation routines at different places in the node processing loop.
2833 * This property indicates at which places the propagator is called.
2834 * Possible values are defined in type_timing.h and can be concatenated, e.g., as in SCIP_PROPTIMING_ALWAYS.
3038 * Branching rules are used to split the problem at the current node into smaller subproblems. Branching rules can be called at three
3039 * different occasions, which is why they have three different execution methods (see \ref
3040 * BRANCHRULE_ADDITIONALCALLBACKS). Branching is performed if:
3041 * - the LP solution of the current problem is fractional. In this case, the integrality constraint handler calls the
3042 * \ref BRANCHEXECLP methods of the branching rules.
3043 * - the list of external branching candidates is not empty. This will only be the case if branching candidates were added
3044 * by a user's \ref RELAX "relaxation handler" or \ref CONS "constraint handler" plugin, calling SCIPaddExternBranchCand().
3045 * These branching candidates should be processed by the \ref BRANCHEXECEXT method.
3046 * - if an integral solution violates one or more constraints and this infeasibility could not be resolved in the callback methods
3047 * \ref CONSENFOLP and \ref CONSENFOPS of the corresponding constraint handlers. In this case, the \ref BRANCHEXECPS method will be called. This is the
3048 * 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
3049 * branching on pseudo solutions works as a last resort.
3050 *
3051 * The idea of branching rules is to take a global view on the problem. In contrast, branching paradigms which are
3052 * specific to one type of constraint are best implemented within the enforcement callbacks of your constraint handler.
3053 * See, e.g., the constraint specific branching rules provided by the constraint handlers for special ordered sets
3054 * (src/scip/cons_sos{1,2}.c)).
3055 * \n
3056 * All branching rules that come with the default distribution of SCIP create two subproblems by splitting a single
3057 * variable's domain. It is, however, fully supported to implement much more general branching schemes, for example by
3058 * creating more than two subproblems, or by adding additional constraints to the subproblems instead of tightening the
3059 * domains of the variables.
3060 * \n
3061 * A complete list of all branching rules contained in this release can be found \ref BRANCHINGRULES "here".
3062 *
3063 * We now explain how users can add their own branching rules. Take the most infeasible LP branching rule
3064 * (src/scip/branch_mostinf.c) as an example. As all other default plugins, it is written in C. C++ users can easily
3065 * adapt the code by using the scip::ObjBranchrule wrapper base class and implement the scip_...() virtual methods instead of
3066 * the SCIP_DECL_BRANCH... callback methods.
3067 *
3068 * Additional documentation for the callback methods of a branching rule can be found in the file type_branch.h.
3069 *
3070 * Here is what you have to do to implement a branching rule:
3071 * -# Copy the template files src/scip/branch_xyz.c and src/scip/branch_xyz.h into files named
3072 * "branch_mybranchingrule.c" and "branch_mybranchingrule.h".
3073 * \n
3074 * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
3075 * -# Use SCIPincludeBranchruleMybranchingrule() in order to include the branching rule into your SCIP instance,
3076 * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
3077 * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mybranchingrule".
3078 * -# Adjust the properties of the branching rule (see \ref BRANCHRULE_PROPERTIES).
3079 * -# Define the branching rule data (see \ref BRANCHRULE_DATA). This is optional.
3080 * -# Implement the interface methods (see \ref BRANCHRULE_INTERFACE).
3081 * -# Implement the fundamental callback methods (see \ref BRANCHRULE_FUNDAMENTALCALLBACKS).
3082 * -# Implement the additional callback methods (see \ref BRANCHRULE_ADDITIONALCALLBACKS). This is optional.
3083 *
3084 *
3085 * @section BRANCHRULE_PROPERTIES Properties of a Branching Rule
3086 *
3087 * At the top of the new file "branch_mybranchingrule.c" you can find the branching rule properties.
3088 * These are given as compiler defines.
3089 * In the C++ wrapper class, you have to provide the branching rule properties by calling the constructor
3090 * of the abstract base class scip::ObjBranchrule from within your constructor.
3091 * The properties you have to set have the following meaning:
3092 *
3093 * \par BRANCHRULE_NAME: the name of the branching rule.
3094 * This name is used in the interactive shell to address the branching rule.
3095 * Additionally, if you are searching for a branching rule with SCIPfindBranchrule(), this name is looked up.
3096 * Names have to be unique: no two branching rules may have the same name.
3097 *
3098 * \par BRANCHRULE_DESC: the description of the branching rule.
3099 * This string is printed as a description of the branching rule in the interactive shell.
3100 *
3101 * \par BRANCHRULE_PRIORITY: the default value for the priority of the branching rule.
3102 * In the subproblem processing, the branching rules are called in decreasing order of their priority until
3103 * one succeeded to branch. Since most branching rules are able to generate a branching in all situations,
3104 * only the rule of highest priority is used. In combination with the BRANCHRULE_MAXDEPTH and
3105 * BRANCHRULE_MAXBOUNDDIST settings, however, interesting strategies can be easily employed. For example,
3106 * the user can set the priority of the "full strong branching" strategy to the highest value and assign the
3107 * second highest value to the "reliable pseudo cost" rule. If (s)he also sets the maximal depth for the
3108 * "full strong branching" to 5, in the top 5 depth levels of the search tree the "full strong branching" is
3109 * applied, while in the deeper levels "reliable pseudo cost branching" is used.
3110 * \n
3111 * Note that the BRANCHRULE_PRIORITY property only specifies the default value of the priority. The user can
3112 * change this value arbitrarily.
3113 *
3114 * \par BRANCHRULE_MAXDEPTH: the default value for the maximal depth level of the branching rule.
3115 * This parameter denotes the maximal depth level in the branch-and-bound tree up to which the branching method of the
3116 * branching rule will be applied. Use -1 for no limit.
3117 * \n
3118 * Note that this property only specifies the default value. The user can change this value arbitrarily.
3119 *
3120 * \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.
3121 * At the current branch-and-bound node, the relative distance from its dual bound (local dual bound)
3122 * to the primal bound compared to the best node's dual bound (global dual bound) is considered. The branching method of
3123 * the branching rule will only be applied at the node if this relative distance does not exceed BRANCHRULE_MAXBOUNDDIST.
3124 * \n
3125 * For example, if the global dual bound is 50 and the primal bound is 60, BRANCHRULE_MAXBOUNDDIST = 0.25 means that
3126 * 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
3127 * 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
3128 * current best node only or at all nodes, respectively.
3129 * \n
3130 * Note that the BRANCHRULE_MAXBOUNDDIST property only specifies the default value of the maximal bound distance.
3131 * The user can change this value arbitrarily.
3132 *
3133 *
3134 * @section BRANCHRULE_DATA Branching Rule Data
3135 *
3136 * Below the header "Data structures" you can find a struct which is called "struct SCIP_BranchruleData".
3137 * In this data structure, you can store the data of your branching rule. For example, you should store the adjustable
3138 * parameters of the branching rule in this data structure.
3139 * If you are using C++, you can add branching rule data as usual as object variables to your class.
3140 * \n
3141 * Defining branching rule data is optional. You can leave the struct empty.
5101 * You also have to initialize the fields in struct SCIP_NlpiData afterwards. For freeing the
5102 * NLPI data, see \ref NLPIFREE.
5103 *
5104 *
5105 * @section NLPI_FUNDAMENTALCALLBACKS Fundamental Callback Methods of an NLPI
5106 *
5107 * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
5108 * an operational algorithm. Currently, all NLPI callbacks are fundamental.
5109 *
5110 * Additional documentation of the callback methods, in particular to their input parameters,
5111 * can be found in type_nlpi.h.
5112 *
5113 * @subsection NLPICOPY
5114 *
5115 * The NLPICOPY callback is executed if the plugin should be copied, e.g., when a SCIP instance is copied.
5116 *
5117 * @subsection NLPIFREE
5118 *
5119 * The NLPIFREE callback is executed if the NLP solver interface data structure should be freed, e.g., when a SCIP instance is freed.
5120 *
5121 * @subsection NLPIGETSOLVERPOINTER
5122 *
5123 * The NLPIGETSOLVERPOINTER callback can be used to pass a pointer to a solver specific data structure to the user.
5124 *
5125 * @subsection NLPICREATEPROBLEM
5126 *
5127 * The NLPICREATEPROBLEM callback is executed if a particular NLP problem is to be created.
5128 * The callback method should initialize a SCIP_NlpiProblem struct here that corresponds to an empty NLP.
5129 *
5130 * @subsection NLPIFREEPROBLEM
5131 *
5132 * The NLPIFREEPROBLEMPOINTER callback is executed if a particular NLP problem is to be freed.
5133 * The callback method should free a SCIP_NlpiProblem struct here.
5134 *
5135 * @subsection NLPIGETPROBLEMPOINTER
5136 *
5137 * The NLPIGETPROBLEMPOINTER callback can be used to pass a pointer to a solver specific data structure of the NLP to the user.
5138 *
5139 * @subsection NLPIADDVARS
5140 *
5141 * The NLPIADDVARS callback is executed if a set of variables with lower and upper bounds and names should be added to a particular NLP.
5142 * The callback method must add the new variables behind the previously added variables, if any.
5143 * If NULL is given for the lower bounds arguments, -infinity is assumed as lower bound for each new variable.
5144 * If NULL is given for the upper bounds arguments, +infinity is assumed as upper bound for each new variable.
5145 * It is also permitted to use NULL for the names argument.
5146 *
5147 * @subsection NLPIADDCONSTRAINTS
5148 *
5149 * The NLPIADDCONSTRAINTS callback is executed if a set of constraints should be added to a particular NLP.
5150 * Constraints are specified by providing left and right hand sides, linear and quadratic coefficients, expression trees, and constraint names.
5151 * All of these arguments are optional, giving NULL for left hand sides corresponds to -infinity, giving NULL for right hand sides corresponds to +infinity.
5152 *
5153 * @subsection NLPISETOBJECTIVE
5154 *
5155 * The NLPISETOBJECTIVE callback is executed to set the objective function of a particular NLP.
5156 *
5157 * @subsection NLPICHGVARBOUNDS
5158 *
5159 * The NLPICHGVARBOUNDS callback is executed to change the bounds on a set of variables of an NLP.
5160 *
5161 * @subsection NLPICHGCONSSIDES
5162 *
5163 * The NLPICHGCONSSIDES callback is executed to change the sides on a set of constraints of an NLP.
5164 *
5165 * @subsection NLPIDELVARSET
5166 *
5167 * The NLPIDELVARSET callback is executed to delete a set of variables from an NLP.
5168 * The caller provides an array in which for each variable it is marked whether it should be deleted.
5169 * In the same array, the method should return the new position of each variable in the NLP, or -1 if it was deleted.
5170 *
5171 * @subsection NLPIDELCONSSET
5172 *
5173 * The NLPIDELCONSSET callback is executed to delete a set of constraints from an NLP.
5174 * The caller provides an array in which for each constraint it is marked whether it should be deleted.
5175 * In the same array, the method should return the new position of each constraint in the NLP, or -1 if it was deleted.
5176 *
5177 * @subsection NLPICHGLINEARCOEFS
5178 *
5179 * The NLPICHGLINEARCOEFS callback is executed to change the coefficients in the linear part of the objective function or a constraint of an NLP.
5180 *
5181 * @subsection NLPICHGQUADCOEFS
5182 *
5183 * The NLPICHGQUADCOEFS callback is executed to change the coefficients in the quadratic part of the objective function or a constraint of an NLP.
5184 *
5185 * @subsection NLPICHGEXPRTREE
5186 *
5187 * The NLPICHGEXPRTREE callback is executed to replace the expression tree of the objective function or a constraint of an NLP.
5188 *
5189 * @subsection NLPICHGNONLINCOEF
5190 *
5191 * 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.
5192 *
5193 * @subsection NLPICHGOBJCONSTANT
5194 *
5195 * The NLPICHGOBJCONSTANT callback is executed to change the constant offset of the objective function of an NLP.
5196 *
5197 * @subsection NLPISETINITIALGUESS
5198 *
5199 * The NLPISETINITIALGUESS callback is executed to provide primal and dual initial values for the variables and constraints of an NLP.
5200 * For a local solver, these values can be used as a starting point for the search.
5201 * 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).
5202 * In this case, the solver should clear previously set starting values and setup its own starting point.
5203 *
5204 * @subsection NLPISOLVE
5205 *
5206 * The NLPISOLVE callback is executed when an NLP should be solved.
5207 * The solver may use the initial guess provided by \ref NLPISETINITIALGUESS as starting point.
5208 * The status of the solving process and solution can be requested by
5213 * The NLPIGETSOLSTAT callback can be used to request the solution status (solved, infeasible, ...) after an NLP has been solved.
5214 *
5215 * @subsection NLPIGETTERMSTAT
5216 *
5217 * The NLPIGETTERMSTAT callback can be used to request the termination reason (normal, iteration limit, ...) after an NLP has been solved.
5218 *
5219 * @subsection NLPIGETSOLUTION
5220 *
5221 * The NLPIGETSOLUTION callback can be used to request the primal and dual solution values after an NLP solve.
5222 * The method should pass pointers to arrays of variable values to the caller.
5223 * 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.
5224 *
5225 * @subsection NLPIGETSTATISTICS
5226 *
5227 * The NLPIGETSTATISTICS callback can be used to request the statistical values (number of iterations, time, ...) after an NLP solve.
5228 * The method should fill the provided NLPSTATISTICS data structure.
5229 *
5230 * <!-- NLPIGETWARMSTARTSIZE, NLPIGETWARMSTARTMEMO, NLPISETWARMSTARTMEMO are not documented,
5231 since they are currently not used, not implemented, and likely to change with a next version. -->
5232 *
5233 * @subsection NLPIGETINTPAR
5234 *
5235 * The NLPIGETINTPAR callback can be used to request the value of an integer valued NLP parameter.
5236 *
5237 * @subsection NLPISETINTPAR
5238 *
5239 * The NLPISETINTPAR callback is executed to set the value of an integer valued NLP parameter.
5240 *
5241 * @subsection NLPIGETREALPAR
5242 *
5243 * The NLPIGETREALPAR callback can be used to request the value of a real valued NLP parameter.
5244 *
5245 * @subsection NLPISETREALPAR
5246 *
5247 * The NLPISETREALPAR callback is executed to set the value of a real valued NLP parameter.
5248 *
5249 * @subsection NLPIGETSTRINGPAR
5250 *
5251 * The NLPIGETSTRINGPAR callback can be used to request the value of a string valued NLP parameter.
5252 *
5253 * @subsection NLPISETSTRINGPAR
5254 *
5255 * The NLPISETSTRINGPAR callback is executed to set the value of a string valued NLP parameter.
5295 * The expression interpreter has to implement a set of interface method.
5296 * In your "exprinterpret_myexprinterpret.c", these methods are mostly dummy methods that return error codes.
5297 *
5298 * @subsection SCIPexprintGetName
5299 *
5300 * The SCIPexprintGetName method should return the name of the expression interpreter.
5301 *
5302 * @subsection SCIPexprintGetDesc
5303 *
5304 * The SCIPexprintGetDesc method should return a short description of the expression interpreter, e.g., the name of the developer of the code.
5305 *
5306 * @subsection SCIPexprintGetCapability
5307 *
5308 * The SCIPexprintGetCapability method should return a bitmask that indicates the capabilities of the expression interpreter,
5309 * i.e., whether it can evaluate gradients, Hessians, or do interval arithmetic.
5310 *
5311 * @subsection SCIPexprintCreate
5312 *
5313 * The SCIPexprintCreate method is called to create an expression interpreter data structure.
5314 * The method should initialize a "struct SCIP_ExprInt" here.
5315 *
5316 * @subsection SCIPexprintFree
5317 *
5318 * The SCIPexprintFree method is called to free an expression interpreter data structure.
5319 * The method should free a "struct SCIP_ExprInt" here.
5320 *
5321 * @subsection SCIPexprintCompile
5322 *
5323 * The SCIPexprintCompile method is called to initialize the data structures that are required to evaluate
5324 * a particular expression tree.
5325 * The expression interpreter can store data that is particular to a given expression tree in the tree by using
5326 * SCIPexprtreeSetInterpreterData().
5327 *
5328 * @subsection SCIPexprintFreeData
5329 *
5330 * The SCIPexprintFreeData method is called when an expression tree is freed.
5331 * The expression interpreter should free the given data structure.
5332 *
5333 * @subsection SCIPexprintNewParametrization
5334 *
5335 * The SCIPexprintNewParametrization method is called when the values of the parameters in a parametrized expression tree have changed.
5336 *
5337 * @subsection SCIPexprintEval
5338 *
5339 * The SCIPexprintEval method is called when the value of an expression represented by an expression tree should be computed for a point.
5340 *
5341 * @subsection SCIPexprintEvalInt
5342 *
5343 * 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.
5344 *
5345 * @subsection SCIPexprintGrad
5346 *
5347 * The SCIPexprintGrad method is called when the gradient of an expression represented by an expression tree should be computed for a point.
5348 *
5349 * @subsection SCIPexprintGradInt
5350 *
5351 * 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.
5355 * The SCIPexprintHessianSparsityDense method is called when the sparsity structure of the Hessian matrix should be computed and returned in dense form.
5356 *
5357 * @subsection SCIPexprintHessianDense
5358 *
5359 * The SCIPexprintHessianDense method is called when the Hessian of an expression represented by an expression tree should be computed for a point.
5538/**@page CONCSCIP How to use the concurrent solving mode
5539 *
5540 * @section Overview
5541 *
5542 * In \SCIP 4.0 a new feature has been added that allows to run multiple \SCIP instances with different settings
5543 * on one problem in parallel. To use this feature \SCIP has to be compiled with an additional make option to
5544 * enable the threading functionality (e.g. TPI=tny, see \ref MAKE).
5545 * Then, a concurrent solve can be started by using the <code>concurrentopt</code> command instead of the <code>optimize</code> command
5546 * in the \SCIP shell, or by calling the interface function SCIPsolveParallel().
5547 * To configure the behavior of the concurrent solving mode there are new parameters in the category <code>concurrent/</code>
5548 * and <code>parallel/</code> which will be explained here shortly.
5549 *
5550 * @section CONTROLNTHREADS Controlling the number of threads
5551 *
5552 * The parameters <code>parallel/maxnthreads</code> and <code>parallel/minnthreads</code> can be used to configure the number of threads
5553 * that sould be used for solving. \SCIP will try to use the configured maximum number of threads. If the
5554 * problem that is currently read is too large \SCIP will automatically use fewer threads, but never
5555 * go below the configured minimum number of threads.
5556 *
5557 * @section USEEMPHSETTINGS Using emphasis settings
5558 *
5559 * The parameters <code>concurrent/scip.../prefprio</code> configure which concurrent solvers should be used.
5560 * The concurrent solver <code>scip</code> will use the same settings as the \SCIP instance configured by the user.
5561 * The other concurrent solvers, e.g. <code>scip-feas</code>, will load the corresponding emphasis setting.
5562 * The behavior of the prefprio parameter is as follows: If it is set to 1.0 for <code>scip-feas</code> and
5563 * <code>scip-opti</code>, and to 0.0 for every other concurrent solver, then the threads will be evenly
5564 * distributed between the two types <code>scip-feas</code> and <code>scip-opti</code>. An example: if 4 threads are used each of these concurrent
5565 * solvers will use 2 threads. If the <code>prefprio</code> for one solver is set to 0.33 and the other is set to 1.0, then the former will use 1 thread
5566 * and the latter will use 3 threads of the 4 available threads.
5570 * To use custom settings for the concurrent solvers there is the parameter <code>concurrent/paramsetprefix</code>. If custom parameters
5571 * should be loaded by the concurrent solvers, then it must point to the folder where they are located (including a path separator at the end).
5572 * The parameter settings must be named after the concurrent solvers, e.g. if only the concurrent solver <code>scip</code> is used
5573 * they should be named <code>scip-1</code>, <code>scip-2</code>, <code>scip-3</code>. When different types of concurrent solvers are used the counter
5574 * starts at one for each of them, e.g. <code>scip-1</code> and <code>scip-feas-1</code>.
6032 * \arg <code>TIME</code> - time limit for each test instance in seconds [default: 3600]
6033 * \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]
6034 * \arg <code>THREADS</code> - the number of threads used for solving LPs, if the linked LP solver supports multithreading [default: 1]
6035 * \arg <code>VALGRIND</code> - run valgrind on the SCIP binary; errors and memory leaks found by valgrind are reported as fails [default: "false"]
6036 *
6037 *
6038 * @section COMPARE Comparing test runs for different settings
6039 *
6040 * Often test runs are performed on the basis of different settings. In this case, it is useful to
6041 * have a performance comparison. For this purpose, we can use the <code>allcmpres.sh</code> script in
6042 * the @c check directory.
6043 *
6044 * Suppose, we performed our test run with two different settings, say <code>fast.set</code> and
6045 * <code>slow.set</code>. Assuming that all other parameters (including the SCIP binary), were the same,
6046 * we may have the following <code>res</code>-files in the directory <code>scip/check/results/</code>
6158 * In this case, the test with respect to the number of found feasible solutions is irrelevant, since their number is
6159 * equal. In particular, the null hypothesis gets accepted (i.e., there is no difference in the settings - this is
6160 * marked by "X").
6161 *
6162 * With respect to the number of instances solved to optimality within the timelimit, we have that \f$0.005 < p <=
6163 * 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
6164 * settings perform differently; this is marked by "!". In the concrete case, we have 230 instances, all of which are
6165 * solved by setting \c S2, but only 224 by setting \c S1.
6166 *
6167 * @subsection Wilcoxon Wilcoxon signed rank test
6168 *
6169 * Assume that we compare two settings \c S1 and \c S2 with respect to their solution times (within the time limit). We
6170 * generate a sorted list of the ratios of the run times, where ratios that are (absolutely or relatively) within 1\%
6171 * of 1.0 are discarded, and ratios between 0.0 and 0.99 are replaced with their negative inverse in order to
6172 * obtain a symmetric distribution for the ratios around the origin.
6173 * We then assign ranks 1 to \c N to the remaining \c N data points in nondecreasing
6174 * order of their absolute ratio. This yields two groups \c G1
6175 * 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
6176 * setting \c S1 is faster). Then the sums of the ranks in groups \c G1 and \c G2 are computed, yielding values \c R1
6177 * and \c R2, respectively.
6178 *
6179 * The Wilcoxon test statistic is then
6180 * \f[
6181 * z = \frac{\min(R1, R2) - \frac{N(N+1)}{4}}{\sqrt{\frac{N(N+1)(2N+1)}{24}}},
6182 * \f]
6183 * which we assume to be (approximately) normally distributed (with zero mean) and allows to compute the probability
6184 * \f$p\f$ that one setting is faster than the other. (Note that for \f$N \leq 60\f$, we apply a correction by
6185 * subtracting 0.5 from the numerator).
6186 *
6187 * As an example consider the following output:
6188 * \code
6189 * Wilcoxon (time) z -0.1285, 0.05 <= p X
6190 * Wilcoxon (nodes) z -11.9154, p < 0.0005 !!!
6191 * \endcode
6192 * While the \f$z\f$-value is close to zero for the run time, it is extremely negative regarding the solving nodes. This latter
6193 * 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
6194 * nodes than setting \c S2 is negligible (this null hypothesis is rejected - marked by "!!!").
6195 *
6196 * However, the null hypothesis is not rejected with respect to the run time. In the concrete case, setting \c S1 has a
6197 * 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
6198 * 0.88. Still - the null hypothesis is not rejected.
6199 *
6200 * @section SOLVER Testing and Evaluating using GAMS
6201 *
6202 * Analogously to the target <code>test</code> there is another target to run automated tests with <a href="http://www.gams.com/">gams</a>
6203 * \code
6204 * make testgams GAMSSOLVER=xyz
6205 * \endcode
6206 * For this target, the option GAMSSOLVER has to be given to specify the name of a GAMS solver to run, e.g. GAMSSOLVER=SCIP.
6207 * Additional advanced options specific to this target are:
6208 * GAMS to specify the GAMS executable (default: gams),
6209 * GAP to specify a gap limit (default: 0.0),
6210 * CLIENTTMPDIR to specify a directory where GAMS should put its scratch files (default: /tmp),
6211 * 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).
6212 * The following options are NOT supported (and ignored): DISPFREQ, FEASTOL, LOCK.
6213 * 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).
6214 *
6215 * Note: This works only if the referred programs are installed globally on your machine.
6216 *
6217 * The above options like <code>TIME</code> are also available for gams.
6218 *
6219 * After the testrun there should be an <code>.out</code>, an <code>.err</code> and a <code>.res</code> file
6220 * with the same basename as described above.
6221 *
6222 * Furthermore you can also use the script <code>allcmpres.sh</code> for comparing results.
6282/**@page CHG3 Interface changes between SCIP 1.1 and SCIP 1.2
6283 *
6284 *
6285 * @section CHGCALLBACKS New and changed callbacks
6286 *
6287 * - The callback SCIP_DECL_PRICERREDCOST(x) in the \ref PRICER "pricers" has two new parameters:
6288 * - A <code>result</code> pointer determines whether the pricer guarantees that there exist no more variables. This allows for early branching.
6289 * - A pointer for providing a lower bound.
6290 *
6291 * - The \ref CONS "constraint handlers" have two new callback methods (see type_cons.h for more details).
6292 * - SCIP_DECL_CONSCOPY(x) - this method can be used to copy a constraint.
6293 * - SCIP_DECL_CONSPARSE(x) - this method can be used to parse a constraint in CIP format.
6294 *
6295 * @section CHGINTERFUNC New parameters in interface methods
6296 *
6297 * - SCIPcalcMIR() in scip.h has two new parameter "mksetcoefsvalid" and "sol". The parameter "mksetcoefsvalid" stores
6298 * whether the coefficients of the mixed knapsack set ("mksetcoefs") computed in SCIPlpCalcMIR() are valid. If the mixed knapsack constraint obtained after aggregating LP rows
6299 * 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.
6300 * The input parameter "sol" can be used to separate a solution different from the LP solution.
6301 *
6302 * - 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.
6303 *
6304 * @section MISCELLANEOUS Miscellaneous
6305 *
6306 * - A significant change for <b>C++ users</b> is that all include files of SCIP
6307 * automatically detect C++ mode, i.e., no <code>extern "C"</code> is needed anymore.
6308 *
6309 * For further release notes we refer to the \ref RELEASENOTES "Release notes".
6465 /**@page CHG5 Interface changes between SCIP 2.0 and SCIP 2.1
6466 *
6467 *
6468 * @section CHGCALLBACKS5 New and changed callbacks
6469 *
6470 * - <b>Presolving</b>:
6471 * <br>
6472 * <br>
6473 * - The new parameters "nnewaddconss" and "naddconss" were added to the constraint handler callback method SCIP_DECL_CONSPRESOL()
6474 * and the presolver callback method SCIP_DECL_PRESOLEXEC(). These parameters were also added to corresponding C++ wrapper class methods.
6475 * - Propagators are now also called in during presolving, this is supported by the new callback methods SCIP_DECL_PROPINITPRE(),
6476 * SCIP_DECL_PROPEXITPRE(), and SCIP_DECL_PROPPRESOL().
6477 * - New parameters "isunbounded" and "isinfeasible" for presolving initialization (SCIP_DECL_CONSINITPRE(),
6478 * SCIP_DECL_PRESOLINITPRE(), SCIP_DECL_PROPINITPRE()) and presolving deinitialization (SCIP_DECL_CONSEXITPRE(),
6479 * SCIP_DECL_PRESOLEXITPRE(), SCIP_DECL_PROPEXITPRE()) callbacks of presolvers,
6480 * constraint handlers and propagators, telling the callback whether the problem was already declared to be
6481 * unbounded or infeasible. This allows to avoid expensive steps in these methods in case the problem is already
6482 * solved, anyway.
6483 * <br>
6484 * <br>
6485 * <DIV class="note">
6486 * Note, that the C++ methods
6487 * - scip::ObjConshdlr::scip_presol() corresponding to SCIP_DECL_CONSPRESOL()
6488 * - scip::ObjConshdlr::scip_initpre() corresponding to SCIP_DECL_CONSINITPRE()
6489 * - scip::ObjPresol::scip_initpre() corresponding to SCIP_DECL_PRESOLINITPRE()
6490 * - scip::ObjProp::scip_initpre() corresponding to SCIP_DECL_PROPINITPRE()
6491 * - scip::ObjConshdlr::scip_exitpre() corresponding to SCIP_DECL_CONSEXITPRE()
6492 * - scip::ObjPresol::scip_exitpre() corresponding to SCIP_DECL_PRESOLEXITPRE()
6493 * - scip::ObjProp::scip_exitpre() corresponding to and SCIP_DECL_PROPEXITPRE()
6494 * .
6495 * are virtual functions. That means, if you are not adding the new parameters, your code will still compile, but these methods are not executed.
6496 * </DIV>
6497 *
6498 * - <b>Constraint Handler</b>:
6499 * <br>
6500 * <br>
6501 * - The new constraint handler callback SCIP_DECL_CONSDELVARS() is called after variables were marked for deletion.
6502 * This method is optional and only of interest if you are using SCIP as a branch-and-price framework. That means,
6503 * you are generating new variables during the search. If you are not doing that just define the function pointer
6504 * to be NULL.
6505 * <br>
6506 * If this method gets implemented you should iterate over all constraints of the constraint handler and delete all
6507 * variables that were marked for deletion by SCIPdelVar().
6508 *
6509 * - <b>Problem Data</b>:
6510 * <br>
6511 * <br>
6512 * - 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.
6513 *
6514 * - <b>Conflict Analysis</b>:
6515 * <br>
6516 * <br>
6517 * - Added parameter "separate" to conflict handler callback method SCIP_DECL_CONFLICTEXEC() that defines whether the conflict constraint should be separated or not.
6518 *
6519 * - <b>NLP Solver Interface</b>:
6520 * <br>
6521 * <br>
6522 * - The callbacks SCIP_DECL_NLPIGETSOLUTION() and SCIP_DECL_NLPISETINITIALGUESS() got new parameters to get/set values of dual variables.
6523 * - The callback SCIP_DECL_NLPICOPY() now passes the block memory of the target SCIP as an additional parameter.
6531 * - The methods SCIPwriteVarName(), SCIPwriteVarsList(), and SCIPwriteVarsLinearsum() got a new boolean parameter "type"
6532 * that indicates whether the variable type should be written or not.
6533 * - The method SCIPwriteVarsList() got additionally a new parameter "delimiter" that defines the character which is used for delimitation.
6534 * - The methods SCIPparseVarName() and SCIPparseVarsList() got a new output parameter "endptr" that is filled with the position where the parsing stopped.
6535 *
6536 * - <b>Plugin management</b>:
6537 * <br>
6538 * <br>
6539 * - 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.
6540 * - SCIPincludeConshdlr() got additional parameters to set the variable deletion callback function and the timing mask for propagation.
6541 *
6542 * - <b>Constraint Handlers</b>:
6543 * <br>
6544 * <br>
6545 * - Method SCIPseparateRelaxedKnapsack() in knapsack constraint handler got new parameter "cutoff", which is a pointer to store whether a cutoff was found.
6546 * - Method SCIPincludeQuadconsUpgrade() of quadratic constraint handler got new parameter "active" to indicate whether the upgrading method is active by default.
6547 *
6548 * - <b>Nonlinear expressions, relaxation, and solver interface</b>:
6549 * <br>
6550 * <br>
6551 * - The methods SCIPexprtreeEvalSol(), SCIPexprtreeEvalIntLocalBounds(), and SCIPexprtreeEvalIntGlobalBounds() have been renamed to SCIPevalExprtreeSol(),
6552 * SCIPevalExprtreeLocalBounds(), and SCIPevalExprtreeGlobalBounds() and are now located in scip.h.
6553 * - Various types and functions dealing with polynomial expressions have been renamed to use the proper terms "monomial" and "polynomial".
6554 * - The methods SCIPnlpGetObjective(), SCIPnlpGetSolVals(), and SCIPnlpGetVarSolVal() have been removed, use SCIPgetNLPObjval(), SCIPvarGetNLPSol()
6555 * and SCIPcreateNLPSol() to retrieve NLP solution values instead.
6556 * - Removed methods SCIPmarkRequireNLP() and SCIPisNLPRequired(), because the NLP is now always constructed if nonlinearities are present.
6557 * - SCIPgetNLP() has been removed and NLP-methods from pub_nlp.h have been moved to scip.h, which resulted in some renamings, too.
6558 * - The functions SCIPnlpiGetSolution() and SCIPnlpiSetInitialGuess() got additional arguments to get/set dual values.
6559 * - The method SCIPgetNLPI() got a new parameter "nlpiproblem", which is a pointer to store the NLP solver interface problem.
6560 *
6561 * - <b>Others</b>:
6562 * <br>
6563 * <br>
6564 * - 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
6565 * the given variable is contained in the given hash map.
6566 * - Removed method SCIPreadSol(); call solution reading via SCIPreadProb() which calls the solution reader for .sol files.
6567 * - SCIPchgVarType() got an extra boolean parameter to store if infeasibility is recognized while upgrading a variable from continuous type to an integer type.
6568 * - SCIPdelVar() got a new parameter "deleted", which stores whether the variable was successfully marked to be deleted.
6569 * - SCIPcalcNodeselPriority() got a new parameter "branchdir", which defines the type of branching that was performed: upwards, downwards, or fixed.
6570 * - The parameters "timelimit" and "memorylimit" were removed from SCIPapplyRens().
6571 *
6572 * <br>
6573 * @section MISCELLANEOUS5 Miscellaneous
6574 *
6575 * - The result value SCIP_NEWROUND has been added, it allows a separator/constraint handler to start a new separation round
6576 * (without previous calls to other separators/conshdlrs).
6577 * - All timing flags are now defined type_timing.h.
6578 * - The variable deletion event is now a variable specific event and not global, anymore.
6579 * - The emphasis setting types now distinguish between plugin-type specific parameter settings (default, aggressive, fast, off), which are changed by
6580 * SCIPsetHeuristics/Presolving/Separating(), and global emphasis settings (default, cpsolver, easycip, feasibility, hardlp, optimality, counter),
6581 * which can be set using SCIPsetEmphasis().
6582 *
6583 * <br>
6584 * For further release notes we refer to the \ref RELEASENOTES "Release notes".
7011 * - added arguments "fixedvars", "fixedvals", "nfixedvars" to SCIPcopyVars()
7012 * - added arguments "fixedvars", "fixedvals", "nfixedvars" to SCIPcopyOrigVars()
7013 * - renamed argument "success" to valid in SCIPgetConsCopy()
7014 *
7015 * <br>
7016 * - <b>Parameters</b>:
7017 * - renamed method SCIPcheckBoolParam() to SCIPisBoolParamValid()
7018 * - renamed method SCIPcheckLongintParam() to SCIPisLongintParamValid()
7019 * - renamed method SCIPcheckRealParam() to SCIPisRealParamValid()
7020 * - renamed method SCIPcheckCharParam() to SCIPisCharParamValid()
7021 * - renamed method SCIPcheckStringParam() to SCIPisStringParamValid()
7022 *
7023 * <br>
7024 * - <b>Relaxators</b>:
7025 * - added argument "includeslp" to SCIPincludeRelax() and SCIPincludeRelaxBasic()
7026 *
7027 * <br>
7028 * - <b>Primal Heuristics</b>:
7029 * - introduced new type SCIP_HEURTIMING for primal heuristic timing masks
7030 * - changed type of argument "timingmask" from unsigned int to SCIP_HEURTIMING in SCIPincludeHeur(), SCIPincludeHeurBasic()
7031 * - added argument "initialseed" to SCIPcreateDiveset()
7032 * <br>
7033 * - <b>Reoptimization</b>:
7034 * - renamed function SCIPgetReopSolsRun() to SCIPgetReoptSolsRun()
7035 *
7036 * <br>
7037 * - <b>Variables</b>:
7038 * - Removed method SCIPvarGetNBinImpls()
7039 *
7040 * <br>
7041 * - <b>Conflict Analysis</b>:
7042 * - added arguments "conftype" and "iscutoffinvolved" to SCIPinitConflictAnalysis()
7043 *
7044 * <br>
7045 * - <b>Constraint Handlers</b>:
7046 * - added argument "infeasible" to SCIPinitlpCons()
7047 *
7048 * <br>
7049 * - <b>Nonlinear Relaxation</b>:
7050 * - added argument "curvature" to SCIPcreateNlRow()
7051 *
7052 * <br>
7053 * - <b>Solutions</b>:
7054 * - added argument "completely" to SCIPtrySol(), SCIPtrySolFree(), SCIPcheckSol()
7055 *
7056 * - <b>Hashmap and Hashtable</b>:
7057 * - removed function SCIPcalcHashtableSize() since not required anymore for SCIP_HASHTABLE and SCIP_HASHMAP
7058 * - based on the initial size SCIP_HASHTABLE and SCIP_HASHMAP choose an appropriate size internally to allow insertion of that many elements without resizing
7059 * - SCIP_MULTIHASH behaves like the old SCIP_HASHTABLE and SCIPcalcMultihashSize() should be used as replacement for SCIPcalcHashtableSize()
7060 *
7061 * <br>
7062 * For further information we refer to the \ref RELEASENOTES "Release notes" and the \ref CHANGELOG "Changelog".
7138 * In that case the sparse solutions are unrolled and lifted back into the original variable space.
7139 *
7140 * The callable library provides a method which gives access to all collected sparse solutions. That is,
7141 * SCIPgetCountedSparseSolutions(). The sparse solutions you get are defined w.r.t. active variables. To get solutions
7142 * w.r.t. to the original variables. You have to do two things:
7143 *
7144 * -# unroll each sparse solution
7145 * -# lift each solution into original variable space by extending the solution by those variable which got removed
7146 * during presolving
7147 *
7148 * The get the variables which got removed during presolving, you can use the methods SCIPgetFixedVars() and
7149 * SCIPgetNFixedVars(). The method SCIPgetProbvarLinearSum() transforms given variables, scalars and constant to the
7150 * corresponding active variables, scalars and constant. Using this method for a single variable gives a representation
7151 * for that variable w.r.t. the active variables which can be used to compute the value for the considered solution (which
7152 * is defined w.r.t. active variables).
7153 *
7154 * For that complete procedure you can also check the source code of
7155 * \ref SCIP_DECL_DIALOGEXEC(SCIPdialogExecWriteAllsolutions) "SCIPdialogExecWriteAllsolutions()" cons_countsols.c which
7156 * does exactly that.
7157 *
7158 *
7159 * @section COUNTOPTIMAL Count number of optimal solutions
7160 *
7161 * If you are interested in counting the number of optimal solutions, this can be done with SCIP using the
7162 * <code>count</code> command by applying the following steps:
7163 *
7164 * -# Solve the original problem to optimality and let \f$c^*\f$ be the optimal value
7165 * -# Add the objective function as constraint with left and right hand side equal to \f$c^*\f$
7166 * -# load the adjusted problem into SCIP
7167 * -# use the predefined counting settings
7168 * -# start counting the number of feasible solutions
7169 *
7170 * If you do this, SCIP will collect all optimal solutions of the original problem.
7171 *
7172 */
7173
7174/**@page LICENSE License
7175 *
7176 * \verbinclude COPYING
7177 */
7178
7179/**@page FAQ Frequently Asked Questions (FAQ)
7180 * \htmlinclude faq.inc
7181 */
7182
7183/**@page INSTALL Installation information
7184 * \verbinclude INSTALL
7185 */
7186
7187/**@page INSTALL_CMAKE Installation information (CMake)
7188 * \verbinclude INSTALL_CMAKE
7189 */
7190
7191
7192/**@page RELEASENOTES Release notes
7193 *
7194 * A release report with an in-depth description of many of the new features in version 4.0 is available on <a href="http://www.optimization-online.org/DB_HTML/2017/03/5895.html">Optimization Online</a>.
7195 *
7196 * \verbinclude SCIP-release-notes-4.0.1
7197 *
7198 * \verbinclude SCIP-release-notes-4.0
7199 *
7200 * Please consult the <a href="http://nbn-resolving.de/urn:nbn:de:0297-zib-57675">release report</a> for version 3.2 that explains many of the new features in detail.
7201 *
7202 * \verbinclude SCIP-release-notes-3.2.1
7203 *
7204 * \verbinclude SCIP-release-notes-3.2
7205 *
7206 * \verbinclude SCIP-release-notes-3.1
7207 *
7208 * \verbinclude SCIP-release-notes-3.0.2
7209 *
7210 * \verbinclude SCIP-release-notes-3.0.1
7211 *
7212 * \verbinclude SCIP-release-notes-3.0
7213 *
7214 * \verbinclude SCIP-release-notes-2.1.1
7215 *
7216 * \verbinclude SCIP-release-notes-2.1
7217 *
7218 * \verbinclude SCIP-release-notes-2.0.2
7219 *
7220 * \verbinclude SCIP-release-notes-2.0.1
7221 *
7222 * \verbinclude SCIP-release-notes-2.0
7223 *
7224 * \verbinclude SCIP-release-notes-1.2
7225 *
7226 * \verbinclude SCIP-release-notes-1.1
7227 */
7228
7229/**@page CHANGELOG CHANGELOG
7230 *
7231 * \verbinclude CHANGELOG
7232 *
7233 */
7234
7235
7236
7237/**@page PARAMETERS List of all SCIP parameters
7238 *
7239 * This page list all parameters of the current SCIP version. This list can
7240 * easily be generated by SCIP via the interactive shell using the following command:
7241 *
7242 * <code>SCIP> set save <file name></code>
7756 * <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>
7757 * <tr><td>\ref reader_diff.h "DIFF format"</td> <td>for reading a new objective function for mixed-integer programs</td></tr>
7758 * <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>
7759 * <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>
