255 * There are several extensions of \SCIP for particular applications included in the release. They are contained in the "applications" directory
1138 * 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
1139 * solution" to show the nonzero variables of the best found solution.
1384 * \par LINCONSUPGD_PRIORITY: priority of the constraint handler for upgrading of linear constraints
1385 * This property is only needed if a certain linear constraint can be upgraded to a more specific one. In one of
1386 * the first presolving rounds SCIP tries to upgrade linear constraints to more specialized constraints, such as
1387 * knapsack constraints. The upgrading calls are processed in the order of decreasing priority.
1388 *
1389 * \par NONLINCONSUPGD_PRIORITY: priority of the constraint handler for upgrading of nonlinear constraints
1390 * This property has the same effect as the LINCONSUPGD_PRIORITY parameter, see above, and should be set whenever
1391 * an upgrade functionality from a general nonlinear constraint to the more specific one is defined.
1392 *
1393 * \par CONSHDLR_SEPAFREQ: the default frequency for separating cuts.
1394 * The separation frequency defines the depth levels at which the constraint handler's separation methods \ref CONSSEPALP
1395 * and \ref CONSSEPASOL are called.
1396 * For example, a separation frequency of 7 means, that the separation callback is executed for subproblems that are
1397 * in depth 0, 7, 14, ... of the branching tree.
1398 * A separation frequency of 0 means, that the separation method is only called at the root node.
1399 * A separation frequency of -1 disables the separation method of the constraint handler.
1400 * \n
1401 * The separation frequency can be adjusted by the user.
1402 * This property of the constraint handler only defines the default value of the frequency.
1403 * If you want to have a more flexible control of when to execute the separation algorithm, you have to assign
1404 * a separation frequency of 1 and implement a check at the beginning of your separation algorithm whether you really
1405 * want to execute the separator or not.
1406 * If you do not want to execute the method, set the result code to SCIP_DIDNOTRUN.
1407 *
1408 * \par CONSHDLR_SEPAPRIORITY: the priority of the constraint handler for separation. (optional: to be set only if the constraint handler supports separation)
1409 * In each separation round during the price-and-cut loop of the subproblem processing or during the separation loop
1410 * of the primal solution separation, the separators and separation methods of the constraint handlers are called in
1411 * a predefined order, which is given by the priorities of the separators and the separation priorities of the
1412 * constraint handlers.
1413 * First, the separators with non-negative priority are called in the order of decreasing priority.
1414 * Next, the separation methods of the different constraint handlers are called in the order of decreasing separation
1415 * priority.
1416 * Finally, the separators with negative priority are called in the order of decreasing priority.
1417 * \n
1418 * The separation priority of the constraint handler should be set according to the complexity of the cut separation
1419 * algorithm and the impact of the resulting cuts:
1420 * Constraint handlers that provide fast algorithms that usually have a high impact (i.e., cut off a large portion of
1421 * the LP relaxation) should have a high priority.
1422 * See \ref CONSSEPALP and \ref CONSSEPASOL for further details of the separation callbacks.
1423 *
1424 * \par CONSHDLR_DELAYSEPA: the default for whether the separation method should be delayed, if other separators found cuts.
1425 * If the constraint handler's separation method is marked to be delayed, it is only executed after no other separator
1426 * or constraint handler found a cut during the price-and-cut loop.
1427 * If the separation method of the constraint handler is very expensive, you may want to mark it to be delayed until all
1428 * cheap separation methods have been executed.
1429 *
1430 * \par CONSHDLR_PROPFREQ: the default frequency for propagating domains.
1431 * This default frequency has the same meaning as the CONSHDLR_SEPAFREQ with respect to the domain propagation
1432 * callback of the constraint handler.
1433 * A propagation frequency of 0 means that propagation is only applied in preprocessing and at the root node.
1434 * A propagation frequency of -1 disables the propagation method of the constraint handler.
1435 *
1436 * \par CONSHDLR_DELAYPROP: the default for whether the propagation method should be delayed, if other propagators found reductions.
1437 * This property is analogous to the DELAYSEPA flag, but deals with the propagation method of the constraint handler.
1438 *
1439 * \par CONSHDLR_PROP_TIMING: the propagation timing mask of the constraint handler.
1440 * SCIP calls the domain propagation routines at different places in the node processing loop.
1441 * This property indicates at which places the propagation routine of the constraint handler is called.
1442 * Possible values are defined in type_timing.h and can be concatenated, e.g., as in SCIP_PROPTIMING_ALWAYS.
1443 *
1444 * \par CONSHDLR_PRESOLTIMING: the timing of the constraint handler's presolving method (FAST, MEDIUM, or EXHAUSTIVE).
1445 * Every presolving round starts with the FAST presolving methods. MEDIUM presolvers are only called, if FAST presolvers did not find
1446 * enough reductions in this round so far, and EXHAUSTIVE presolving steps are only performed if all presolvers called before
1447 * in this round were unsuccessful.
1448 * Presolving methods should be assigned a timing based on how expensive they are, e.g., presolvers that provide fast algorithms that
1449 * usually have a high impact (i.e., remove lots of variables or tighten bounds of many variables) should have a timing FAST.
1450 * If a presolving method implements different algorithms of different complexity, it may also get multiple timings and check the timing
1451 * internally in the \ref CONSPRESOL callback to decide which algorithms to run.
1452 *
1453 * \par CONSHDLR_MAXPREROUNDS: the default maximal number of presolving rounds the constraint handler participates in.
1454 * The preprocessing is executed in rounds.
1455 * If enough changes have been applied to the model, an additional preprocessing round is performed.
1456 * The MAXPREROUNDS parameter of a constraint handler denotes the maximal number of preprocessing rounds the constraint
1457 * handler participates in.
1458 * A value of -1 means that there is no limit on the number of rounds.
1459 * A value of 0 means the preprocessing callback of the constraint handler is disabled.
1460 *
1461 *
1462 *
1463 * @section CONS_DATA Constraint Data and Constraint Handler Data
1464 *
1465 * Below the header "Data structures" you can find two structs called "struct SCIP_ConsData" and
1466 * "struct SCIP_ConshdlrData".
1467 * If you are using C++, you only need to define the "struct SCIP_ConsData".
1468 * The constraint handler data must be implemented as member variables of your constraint handler class.
1469 * \n
1470 * The constraint data are the information that is needed to define a single constraint of the constraint handler's
1471 * constraint class.
1472 * For example, the data of a knapsack constraint would consist of a list of variables, a list of weights, and
1473 * the capacity of the knapsack.
1474 * The data of a subtour constraint consists of the graph on which the problem is defined.
1475 * In the graph, each edge should be linked to the corresponding binary problem variable.
1476 * \n
1477 * The constraint handler data are additional variables, that belong to the constraint handler itself and which are
1478 * not specific to a single constraint.
1479 * For example, you can use these data to store parameters of the constraint handler or statistical information.
1480 * The constraint handler data are optional.
1481 * You can leave the struct empty.
1482 *
1483 *
1484 * @section CONS_INTERFACE Interface Methods
1485 *
1486 * At the bottom of "cons_subtour.c" you can find three interface methods, that also appear in "cons_subtour.h".
1487 * These are SCIPincludeConshdlrSubtour(), SCIPcreateConsSubtour(), and SCIPcreateConsSubtourBasic().
1488 * \n
1489 * The method SCIPincludeConshdlrSubtour() only has to be adjusted slightly.
1490 * It is responsible for notifying SCIP of the presence of the constraint handler by calling the method
1491 * SCIPincludeConshdlr().
1492 * It is called by the user, if (s)he wants to include the constraint handler, i.e., if (s)he wants to make
1493 * the constraint handler available to the model, and looks like this:
1494 * \dontinclude src/scip/cons_knapsack.c
1495 * -# If you are using constraint handler data, you have to <b>allocate the memory for the data</b> at this point.
1496 * You also have to initialize the fields in struct SCIP_ConshdlrData afterwards.
1832 * The CONSINITLP callback is executed before the first LP relaxation is solved.
1833 * It should add the LP relaxations of all "initial" constraints to the LP. The method should scan the constraints
1834 * array for constraints that are marked initial via calls to SCIPconsIsInitial() and put the LP relaxation
1835 * of all initial constraints to the LP with calls to SCIPaddCut().
1836 *
1837 * @subsection CONSSEPALP
1838 *
1839 * The CONSSEPALP callback is executed during the price-and-cut loop of the subproblem processing.
1840 * It should try to generate cutting planes for the constraints of the constraint handler in order to separate
1841 * the current LP solution.
1842 * The method is called in the LP solution loop, which means that a valid LP solution exists.
1843 *
1844 * Usually, a separation callback searches and produces cuts, that are added with a call to SCIPaddCut().
1845 * If the cut should be remembered in the global cut pool, it may also call SCIPaddPoolCut().
1846 * However, the callback may also produce domain reductions or add other constraints.
1847 *
1848 * The CONSSEPALP callback has the following options:
1849 * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
1850 * - adding an additional constraint (result SCIP_CONSADDED)
1851 * - reducing a variable's domain (result SCIP_REDUCEDDOM)
1852 * - adding a cutting plane to the LP (result SCIP_SEPARATED)
1853 * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
1854 * (result SCIP_DIDNOTFIND)
1855 * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
1856 * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
1857 * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
1858 *
1859 * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1860 * CONSHDLR_SEPAFREQ, CONSHDLR_SEPAPRIORITY, and CONSHDLR_DELAYSEPA, which influence the behaviour of SCIP
1861 * calling CONSSEPALP.
1862 *
1863 * @subsection CONSSEPASOL
1864 *
1865 * The CONSSEPASOL callback is executed during separation loop on arbitrary primal solutions.
1866 * It should try to generate cutting planes for the constraints of the constraint handler in order to separate
1867 * the given primal solution.
1868 * The method is not called in the LP solution loop, which means that there is no valid LP solution.
1869 *
1870 * Usually, a separation callback searches and produces cuts, that are added with a call to SCIPaddCut().
1871 * If the cut should be remembered in the global cut pool, it may also call SCIPaddPoolCut().
1872 * However, the callback may also produce domain reductions or add other constraints.
1873 *
1874 * The CONSSEPASOL callback has the following options:
1875 * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
1876 * - adding an additional constraint (result SCIP_CONSADDED)
1877 * - reducing a variable's domain (result SCIP_REDUCEDDOM)
1878 * - adding a cutting plane to the LP (result SCIP_SEPARATED)
1879 * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
1880 * (result SCIP_DIDNOTFIND)
1881 * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
1882 * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
1883 * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
1884 *
1885 * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1886 * CONSHDLR_SEPAFREQ, CONSHDLR_SEPAPRIORITY, and CONSHDLR_DELAYSEPA, which influence the behaviour of SCIP
1887 * calling CONSSEPASOL.
1888 *
1889 * @subsection CONSENFORELAX
1890 *
1891 * The CONSENFORELAX callback is similar to the CONSENFOLP and CONSENFOPS callbacks, but deals with relaxation solutions.
1892 *
1893 * If the best bound computed by a relaxator that includes the whole LP is strictly better than the bound of the LP itself,
1894 * the corresponding relaxation solution will get enforced. Therefore the CONSENFORELAX callback will only be called for
1895 * solutions that satisfy all active LP-constraints.
1896 *
1897 * Like the ENFOLP and ENFOPS callbacks, the ENFORELAX callback has to check whether the solution given in sol satisfies
1898 * all the constraints of the constraint handler. Since the callback is only called for relaxators including the whole LP,
1899 * cuts may be added with a result of SCIP_SEPARATED, like in the ENFOLP callback. It is also possible to return
1900 * SCIP_SOLVELP if the relaxation solution is invalid for some reason and the LP should be solved instead.
1901 *
1902 * Note that the CONSENFORELAX callback is only relevant if relaxators are used. Since the basic distribution of the
1903 * SCIP Optimization Suite does not contain any relaxators, this callback can be ignored unless any relaxators are added
1904 * via user-plugins.
1905 *
1906 * @subsection CONSPROP
1907 *
1908 * The CONSPROP callback is called during the subproblem processing.
1909 * It should propagate the constraints, which means that it should infer reductions in the variables' local bounds
1910 * from the current local bounds.
1911 * This technique, which is the main workhorse of constraint programming, is called "node preprocessing" in the
1912 * Integer Programming community.
1913 *
1914 * The CONSPROP callback has the following options:
1915 * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
1916 * - reducing a variable's domain (result SCIP_REDUCEDDOM)
1917 * - stating that the propagator searched, but did not find domain reductions, cutting planes, or cut constraints
1918 * (result SCIP_DIDNOTFIND)
1919 * - stating that the propagator was skipped (result SCIP_DIDNOTRUN)
1920 * - stating that the propagator was skipped, but should be called again (result SCIP_DELAYED)
1921 *
1922 * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1923 * CONSHDLR_PROPFREQ, CONSHDLR_DELAYPROP, and CONSHDLR_PROP_TIMING, which influence the behaviour of SCIP
1924 * calling CONSPROP.
1925 *
1926 * @subsection CONSRESPROP
1927 *
1928 * If the constraint handler should support \ref CONF "conflict analysis", it has to supply a CONSRESPROP method.
1929 * It also should call SCIPinferVarLbCons() or SCIPinferVarUbCons() in domain propagation instead of SCIPchgVarLb() or
1930 * SCIPchgVarUb() in order to deduce bound changes on variables.
1931 * In the SCIPinferVarLbCons() and SCIPinferVarUbCons() calls, the handler provides the constraint that deduced the
1932 * variable's bound change, and an integer value <code>inferinfo</code> that can be arbitrarily chosen.
1933 *
1934 * The propagation conflict resolving method CONSRESPROP must then be implemented to provide the "reasons" for the bound
1935 * changes, i.e., the bounds of variables at the time of the propagation, which forced the constraint to set the
1936 * conflict variable's bound to its current value. It can use the <code>inferinfo</code> tag to identify its own propagation rule
1937 * and thus identify the "reason" bounds. The bounds that form the reason of the assignment must then be provided by
1938 * calls to SCIPaddConflictLb() and SCIPaddConflictUb() in the propagation conflict resolving method.
1939 *
1940 * <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
1941 * need more information to efficiently infer the original propagation steps that lead to the conflict. This would,
1942 * however, require too much space. In the extreme, the original propagation steps have to be repeated.
1943 *
1944 * 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
1945 * 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
1946 * variables are 0.0). It uses <code>SCIPinferVarLbCons(scip, z, 1.0, c, 0)</code> to apply this assignment (an
1947 * inference information tag is not needed by the constraint handler and is set to 0). In the conflict analysis, the
1948 * constraint handler may be asked to resolve the lower bound change on \f$z\f$ with constraint \f$c\f$, that was
1949 * applied at a time given by a bound change index "bdchgidx". With a call to <code>SCIPvarGetLbAtIndex(z,
1950 * bdchgidx)</code>, the handler can find out, that the lower bound of variable \f$z\f$ was set to 1.0 at the given
1951 * point of time, and should call <code>SCIPaddConflictUb(scip, x, bdchgidx)</code> and <code>SCIPaddConflictUb(scip, y,
1952 * 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
1953 * the deduction of the lower bound of \f$z\f$.
1954 *
1955 * If conflict analysis should not be supported, the method has to set the result code to SCIP_DIDNOTFIND. Although
1956 * this is a viable approach to circumvent the implementation of the usually rather complex conflict resolving method, it
1957 * will make the conflict analysis less effective. We suggest to first omit the conflict resolving method and check how
1958 * effective the \ref CONSPROP "propagation method" is. If it produces a lot of propagations for your application, you definitely should
1959 * consider implementing the conflict resolving method.
1960 *
1961 * @subsection CONSPRESOL
1962 *
1963 * The CONSPRESOL callback is called during preprocessing.
1964 * It should try to tighten the domains of the variables, tighten the coefficients of the constraints of the constraint
1965 * handler, delete redundant constraints, aggregate and fix variables if possible, and upgrade constraints to more
1966 * specific types.
1967 *
1968 * If the CONSPRESOL callback applies changes to the constraint data, you also have to implement the \ref CONSTRANS callback
1969 * in order to copy the constraint data to the transformed problem space and protect the original problem from the
1970 * preprocessing changes.
1971 *
1972 * To inform SCIP that the presolving method found a reduction the result pointer has to be set in a proper way.
1973 * The following options are possible:
1974 *
1975 * - SCIP_UNBOUNDED : at least one variable is not bounded by any constraint in objective direction
1976 * - SCIP_CUTOFF : at least one constraint is infeasible in the variable's bounds
1977 * - SCIP_SUCCESS : the presolver found a reduction
1978 * - SCIP_DIDNOTFIND : the presolver searched, but did not find a presolving change
1979 * - SCIP_DIDNOTRUN : the presolver was skipped
1980 * - SCIP_DELAYED : the presolver was skipped, but should be called again
1981 *
1982 * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1983 * CONSHDLR_PRESOLTIMING and CONSHDLR_MAXPREROUNDS, which influence the behaviour of SCIP
1984 * calling CONSPRESOL.
1985 *
1986 * @subsection CONSACTIVE
1987 *
1988 * The CONSACTIVE callback method is called each time a constraint of the constraint handler is activated.
1989 * For example, if a constraint is added locally to a subproblem, the CONSACTIVE callback is called whenever the
1990 * search enters the subtree where the constraint exists.
1991 *
1992 * @subsection CONSDEACTIVE
1993 *
1994 * The CONSDEACTIVE callback method is called each time a constraint of the constraint handler is deactivated.
1995 * For example, if a constraint is added locally to a subproblem, the CONSDEACTIVE callback is called whenever the
1996 * search leaves the subtree where the constraint exists.
1997 *
1998 * @subsection CONSENABLE
1999 *
2000 * The CONSENABLE callback method is called each time a constraint of the constraint handler is enabled.
2001 * Constraints might be active without being enabled. In this case, only the feasibility checks are executed,
2002 * but domain propagation and separation is skipped.
2003 *
2004 * @subsection CONSDISABLE
2005 *
2006 * The CONSDISABLE callback method is called each time a constraint of the constraint handler is disabled.
2007 *
2008 * @subsection CONSPRINT
2009 *
2010 * The CONSPRINT callback method is called, when the user asks SCIP to display the problem to the screen
2011 * or save the problem into a file. This is, however, only the case if the user requested the CIP format.
2012 * For more details about reading and writing with SCIP we refer to the \ref READER "file readers". In this
2013 * callback method the constraint handler should display the data of the constraint in an appropriate form.
2014 * The output format that is defined by the CONSPRINT callbacks is called CIP format.
2015 * In later versions of SCIP, the constraint handlers should also be able to parse (i.e., read) constraints
2016 * which are given in CIP format.
2017 *
2018 * @subsection CONSCOPY
2019 *
2020 * The CONSCOPY callback method is used whenever constraints should be copied from one SCIP instance into another SCIP
2021 * instance. This method comes with the necessary parameters to do so, most importantly with a mapping of the variables of the
2022 * source SCIP instance to the corresponding variables of the target SCIP instance, and a mapping for the constraints
2023 * in the same way. For a complete list of all arguments of this callback method see type_cons.h.
2024 *
2025 * To get the corresponding target variable of a given source variable, you can use the variable map directly:
2494 * You also have to initialize the fields in struct SCIP_PresolData afterwards. For freeing the
2495 * presolver data, see \ref PRESOLFREE.
2496 *
2497 * You may also add user parameters for your presolver, see \ref PARAM for how to add user parameters and
2498 * the method SCIPincludePresolTrivial() in src/scip/presol_trivial.c for an example.
2499 *
2500 *
2501 * @section PRESOL_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Presolver
2502 *
2503 * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
2504 * an operational algorithm.
2505 * They are passed together with the presolver itself to SCIP using SCIPincludePresol() or SCIPincludePresolBasic(),
2506 * see @ref PRESOL_INTERFACE.
2507 *
2508 * Presolver plugins have only one fundamental callback method, namely the @ref PRESOLEXEC method.
2509 * This method has to be implemented for every presolver; the other callback methods are optional.
2510 * In the C++ wrapper class scip::ObjPresol, the scip_exec() method (which corresponds to the PRESOLEXEC callback) is a virtual
2511 * abstract member function.
2512 * You have to implement it in order to be able to construct an object of your presolver class.
2513 *
2514 * Additional documentation for the callback methods, in particular to their input parameters,
2515 * can be found in type_presol.h.
2516 *
2517 * @subsection PRESOLEXEC
2518 *
2519 * The PRESOLEXEC callback is called inside the presolving loop and should perform the actual presolving reductions.
2520 * It should inspect the problem instance at hand and simplify it by tightening bounds of variables, aggregating or fixing
2521 * variables, changing the type of variables, modifying the graph that represents the instance of your application, and
2522 * the like.
2523 *
2524 * Typical methods called by a presolver are, for example, SCIPchgVarType(), SCIPfixVar(), SCIPaggregateVars(), SCIPtightenVarLb(),
2525 * and SCIPtightenVarUb().
2526 *
2527 *
2528 * @section PRESOL_ADDITIONALCALLBACKS Additional Callback Methods of a Presolver
2529 *
2530 * The additional callback methods do not need to be implemented in every case. However, some of them have to be
2531 * implemented for most applications, they can be used, for example, to initialize and free private data.
2532 * Additional callbacks can either be passed directly with SCIPincludePresol() to SCIP or via specific
2533 * <b>setter functions</b> after a call of SCIPincludePresolBasic(), see also @ref PRESOL_INTERFACE.
2534 *
2535 * @subsection PRESOLFREE
2536 *
2537 * 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.
2538 * This can be done by the following procedure:
2583 * Separators are used to generate general purpose cutting planes.
2584 * Constraint based cutting planes, the second type of cutting planes in SCIP, are separated in the CONSSEPALP and
2585 * CONSSEPASOL callback methods of the constraint handlers, see \ref CONSSEPALP and \ref CONSSEPASOL. These cuts are
2586 * valid inequalities or even facets of the polyhedron described by a single constraint or a subset of the constraints of
2587 * a single constraint class. In contrast, general purpose cuts do not require or exploit any knowledge about the
2588 * underlying problem structure but use only the current LP relaxation and the integrality conditions. See also
2589 * "When should I implement a constraint handler, when should I implement a separator?" on \ref FAQ.
2590 * \n
2591 * A complete list of all separators contained in this release can be found \ref SEPARATORS "here".
2592 *
2593 * We now explain how users can add their own separators.
2594 * Take the separator for the class of Gomory mixed integer inequalities (src/scip/sepa_gomory.c) as an example.
2595 * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjSepa wrapper
2596 * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_SEPA... callback methods.
2597 *
2598 * Additional documentation for the callback methods of a separator, in particular for the input parameters,
2599 * can be found in the file type_sepa.h.
2600 *
2601 * Here is what you have to do to implement a separator:
2602 * -# Copy the template files src/scip/sepa_xyz.c and src/scip/sepa_xyz.h into files "sepa_myseparator.c"
2603 * and "sepa_myseparator.h".
2604 \n
2605 * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2606 * -# Use SCIPincludeSepaMyseparator() in order to include the separator into your SCIP instance,
2607 * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
2608 * -# Open the new files with a text editor and replace all occurrences of "xyz" by "myseparator".
2609 * -# Adjust the properties of the separator (see \ref SEPA_PROPERTIES).
2610 * -# Define the separator data (see \ref SEPA_DATA). This is optional.
2611 * -# Implement the interface methods (see \ref SEPA_INTERFACE).
2612 * -# Implement the fundamental callback methods (see \ref SEPA_FUNDAMENTALCALLBACKS).
2613 * -# Implement the additional callback methods (see \ref SEPA_ADDITIONALCALLBACKS). This is optional.
2614 *
2615 *
2616 * @section SEPA_PROPERTIES Properties of a Separator
2617 *
2618 * At the top of the new file "sepa_myseparator.c", you can find the separator properties.
2619 * These are given as compiler defines.
2620 * In the C++ wrapper class, you have to provide the separator properties by calling the constructor
2621 * of the abstract base class scip::ObjSepa from within your constructor.
2622 * The properties you have to set have the following meaning:
2623 *
2624 * \par SEPA_NAME: the name of the separator.
2625 * This name is used in the interactive shell to address the separator.
2626 * Additionally, if you are searching for a separator with SCIPfindSepa(), this name is looked up.
2627 * Names have to be unique: no two separators may have the same name.
2628 *
2629 * \par SEPA_DESC: the description of the separator.
2630 * This string is printed as a description of the separator in the interactive shell.
2631 *
2632 * \par SEPA_PRIORITY: the priority of the separator.
2633 * In each separation round during the price-and-cut loop of the subproblem processing or the separation loop
2634 * of the primal solution separation, the separators and separation methods of the constraint handlers are called in
2635 * a predefined order, which is given by the priorities of the separators and the separation priorities
2636 * of the constraint handlers (see \ref CONS_PROPERTIES).
2637 * First, the separators with non-negative priority are called in the order of decreasing priority.
2638 * Next, the separation methods of the constraint handlers are called in the order of decreasing separation
2639 * priority.
2640 * Finally, the separators with negative priority are called in the order of decreasing priority. An easy way to list the
2641 * priorities of all separators and constraint handlers is to type "display separators" and "display conshdlrs" in
2642 * the interactive shell.
2643 * \n
2644 * The priority of the separator should be set according to the complexity of the cut separation algorithm and the
2645 * impact of the resulting cuts: separators that provide fast algorithms that usually have a high impact (i.e., cut off
2646 * a large portion of the LP relaxation) should have a high priority.
2647 * See \ref SEPAEXECLP and \ref SEPAEXECSOL for further details of the separation callbacks.
2648 *
2649 * \par SEPA_FREQ: the default frequency for separating cuts.
2650 * The frequency defines the depth levels at which the separation methods \ref SEPAEXECLP and \ref SEPAEXECSOL are called.
2651 * For example, a frequency of 7 means, that the separation callback is executed for subproblems that are in depth
2652 * 0, 7, 14, ... of the branching tree. A frequency of 0 means, that the separation method is only called at the root node.
2653 * A frequency of -1 disables the separator.
2654 * \n
2655 * The frequency can be adjusted by the user. This property of the separator only defines the default value of the frequency.
2656 * If you want to have a more flexible control of when to execute the separation algorithm, you have to assign
2657 * a frequency of 1 and implement a check at the beginning of your separation methods whether you really want to execute
2658 * the separation or not. If you do not want to execute it, set the result code of
2659 * \ref SEPAEXECLP and \ref SEPAEXECSOL to SCIP_DIDNOTRUN.
2660 *
2661 * \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.
2662 * At the current branch-and-bound node, the relative distance from its dual bound (local dual bound)
2663 * to the primal bound compared to the best node's dual bound (global dual bound) is considered. The separation method
2664 * of the separator will only be applied at the current node if this relative distance does not exceed SEPA_MAXBOUNDDIST.
2665 * \n
2666 * For example, if the global dual bound is 50 and the primal bound is 60, SEPA_MAXBOUNDDIST = 0.25 means that separation
2667 * 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
2668 * than or equal to 52.5.
2669 * \n
2670 * In particular, the values 0.0 and 1.0 mean that separation is applied at the current best node only or at all
2671 * nodes, respectively. Since separation seems to be most important to apply at nodes that define to the global
2672 * dual bound, 0.0 is probably a good choice for SEPA_MAXBOUNDDIST.
2673 * Note that separators with a frequency of SEPA_FREQ = 0 are only applied at the root node.
2674 * Obviously, at the root node the local dual bound is equal to the global dual bound and thus, the separator is called
2675 * for any value of SEPA_MAXBOUNDDIST.
2676 *
2677 * \par SEPA_USESSUBSCIP: Does the separator use a secondary SCIP instance?
2678 * Some heuristics and separators solve MIPs or SAT problems and use a secondary SCIP instance. Examples are
2679 * Large Neighborhood Search heuristics such as RINS and Local Branching or the CGMIP separator. To avoid recursion,
2680 * these plugins usually deactivate all other plugins that solve MIPs. If a separator uses a secondary SCIP instance,
2681 * this parameter has to be TRUE and it is recommended to call SCIPsetSubscipsOff() for the secondary SCIP instance.
2682 *
2683 * \par SEPA_DELAY: the default for whether the separation method should be delayed, if other separators or constraint handlers found cuts.
2684 * If the separator's separation method is marked to be delayed, it is only executed after no other separator
2685 * or constraint handler found a cut during the price-and-cut loop.
2686 * If the separation method of the separator is very expensive, you may want to mark it to be delayed until all cheap
2687 * separation methods have been executed.
2688 *
2689 * @section SEPA_DATA Separator Data
2690 *
2691 * Below the header "Data structures" you can find a struct which is called "struct SCIP_SepaData".
2692 * In this data structure, you can store the data of your separator. For example, you should store the adjustable
2693 * parameters of the separator in this data structure. In a separator, user parameters for the maximal number of
2694 * separation rounds per node and for the maximal number of cuts separated per separation round might be useful.
2695 * If you are using C++, you can add separator data as usual as object variables to your class.
2696 * \n
2697 * Defining separator data is optional. You can leave the struct empty.
2698 *
2699 * @section SEPA_INTERFACE Interface Methods
2700 *
2701 * At the bottom of "sepa_myseparator.c", you can find the interface method SCIPincludeSepaMyseparator(),
2702 * which also appears in "sepa_myseparator.h"
2703 * SCIPincludeSepaMyseparator() is called by the user, if (s)he wants to include the separator,
2704 * i.e., if (s)he wants to use the separator in his/her application.
2705 *
2706 * This method only has to be adjusted slightly.
2707 * It is responsible for notifying SCIP of the presence of the separator. For this, you can either call SCIPincludeSepa(),
2708 * or SCIPincludeSepaBasic() since SCIP version 3.0. In the latter variant, \ref SEPA_ADDITIONALCALLBACKS "additional callbacks"
2709 * must be added via setter functions as, e.g., SCIPsetSepaCopy(). We recommend this latter variant because
2710 * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
2711 * variant must be manually adjusted with every SCIP release containing new callbacks for separators in order to compile.
2712 *
2713 * If you are using separator data, you have to allocate the memory
2714 * for the data at this point. You can do this by calling:
2842 * Propagators are used to tighten the domains of the variables. Like for cutting planes, there are two different types
2843 * of domain propagations. Constraint based (primal) domain propagation algorithms are part of the corresponding
2844 * constraint handlers, see \ref CONSPROP. In contrast, domain propagators usually provide dual propagations, i.e.,
2845 * propagations that can be applied using the objective function and the current best known primal solution. This
2846 * section deals with such propagators.
2847 *
2848 * A complete list of all propagators contained in this release can be found \ref PROPAGATORS "here".
2849 *
2850 * We now explain how users can add their own propagators. Take the pseudo objective function propagator
2851 * (src/scip/prop_pseudoobj.c) as an example. As all other default plugins, it is written in C. C++ users can easily
2852 * adapt the code by using the scip::ObjProp wrapper base class and implement the @c scip_...() virtual methods instead
2853 * of the @c SCIP_DECL_PROP... callback methods.
2854 *
2855 * Additional documentation for the callback methods of a propagator can be found in the file type_prop.h.
2856 *
2857 * Here is what you have to do to implement a propagator:
2858 * -# Copy the template files src/scip/prop_xyz.c and src/scip/prop_xyz.h into files named "prop_mypropagator.c"
2859 * and "prop_mypropagator.h".
2860 * \n
2861 * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2862 * -# Use SCIPincludePropMypropagator() in order to include the propagator into your SCIP instance,
2863 * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
2864 * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mypropagator".
2865 * -# Adjust the properties of the propagator (see \ref PROP_PROPERTIES).
2866 * -# Define the propagator data (see \ref PROP_DATA). This is optional.
2867 * -# Implement the interface methods (see \ref PROP_INTERFACE).
2868 * -# Implement the fundamental callback methods (see \ref PROP_FUNDAMENTALCALLBACKS).
2869 * -# Implement the additional callback methods (see \ref PROP_ADDITIONALCALLBACKS). This is optional.
2870 *
2871 * @section PROP_PROPERTIES Properties of a Propagator
2872 *
2873 * At the top of the new file "prop_mypropagator.c" you can find the propagator properties. These are given as compiler
2874 * defines. The presolving-related properties are optional,
2875 * they only have to be defined if the propagator supports presolving routines.
2876 * In the C++ wrapper class, you have to provide the propagator properties by calling the constructor of the
2877 * abstract base class scip::ObjProp from within your constructor. The properties you have the following meaning:
2878 *
2879 * @subsection PROP_FUNDAMENTALPROPERTIES Fundamental properties of a propagator
2880 *
2881 * \par PROP_NAME: the name of the propagator.
2882 * This name is used in the interactive shell to address the propagator. Additionally, if you are searching for a
2883 * propagator with SCIPfindProp(), this name is searched for. Names have to be unique: no two propagators may have the
2884 * same name.
2885 *
2886 * \par PROP_DESC: the description of the propagator.
2887 * This string is printed as a description of the propagator in the interactive shell.
2888 *
2889 * \par PROP_PRIORITY: the priority of the propagator.
2890 * In each propagation round, the propagators and propagation methods of the constraint handlers are called in a
2891 * predefined order, which is given by the priorities of the propagators and the check priorities of the constraint
2892 * handlers. First, the propagators with non-negative priority are called in order of decreasing priority. Next, the
2893 * propagation methods of the different constraint handlers are called in order of decreasing check priority. Finally,
2894 * the propagators with negative priority are called in order of decreasing priority. \n The priority of the
2895 * propagators should be set according to the complexity of the propagation algorithm and the impact of the domain
2896 * propagations: propagators providing fast algorithms that usually have a high impact (i.e., tighten many bounds)
2897 * should have a high priority.
2898 *
2899 * \par PROP_FREQ: the default frequency for propagating domains.
2900 * The frequency defines the depth levels at which the propagation method \ref PROPEXEC is called. For example, a
2901 * frequency of 7 means, that the propagation callback is executed for subproblems that are in depth 0, 7, 14, ... of
2902 * the branching tree. A frequency of 0 means that propagation is only applied in preprocessing and at the root node. A
2903 * frequency of -1 disables the propagator.
2904 * \n
2905 * The frequency can be adjusted by the user. This property of the propagator only defines the default value of the
2906 * frequency.\n
2907 * <b>Note:</b> If you want to have a more flexible control of when to execute the propagation algorithm, you have to
2908 * assign a frequency of 1 and implement a check at the beginning of your propagation algorithm whether you really want
2909 * to execute the domain propagation or not. If you do not want to execute it, set the result code to SCIP_DIDNOTRUN.
2910 *
2911 * \par PROP_DELAY: the default for whether the propagation method should be delayed, if other propagators or constraint handlers found domain reductions.
2912 * If the propagator's propagation method is marked to be delayed, it is only executed after no other propagator or
2913 * constraint handler found a domain reduction in the current iteration of the domain propagation loop. If the
2914 * propagation method of the propagator is very expensive, you may want to mark it to be delayed until all cheap
2915 * propagation methods have been executed.
2916 *
2917 * \par PROP_TIMING: the timing mask of the propagator.
2918 * SCIP calls the domain propagation routines at different places in the node processing loop.
2919 * This property indicates at which places the propagator is called.
2920 * Possible values are defined in type_timing.h and can be concatenated, e.g., as in SCIP_PROPTIMING_ALWAYS.
3124 * Branching rules are used to split the problem at the current node into smaller subproblems. Branching rules can be called at three
3125 * different occasions, which is why they have three different execution methods (see \ref
3126 * BRANCHRULE_ADDITIONALCALLBACKS). Branching is performed if:
3127 * - the LP solution of the current problem is fractional. In this case, the integrality constraint handler calls the
3128 * \ref BRANCHEXECLP methods of the branching rules.
3129 * - the list of external branching candidates is not empty. This will only be the case if branching candidates were added
3130 * by a user's \ref RELAX "relaxation handler" or \ref CONS "constraint handler" plugin, calling SCIPaddExternBranchCand().
3131 * These branching candidates should be processed by the \ref BRANCHEXECEXT method.
3132 * - if an integral solution violates one or more constraints and this infeasibility could not be resolved in the callback methods
3133 * \ref CONSENFOLP and \ref CONSENFOPS of the corresponding constraint handlers. In this case, the \ref BRANCHEXECPS method will be called. This is the
3134 * 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
3135 * branching on pseudo solutions works as a last resort.
3136 *
3137 * The idea of branching rules is to take a global view on the problem. In contrast, branching paradigms which are
3138 * specific to one type of constraint are best implemented within the enforcement callbacks of your constraint handler.
3139 * See, e.g., the constraint specific branching rules provided by the constraint handlers for special ordered sets
3140 * (src/scip/cons_sos{1,2}.c)).
3141 * \n
3142 * All branching rules that come with the default distribution of SCIP create two subproblems by splitting a single
3143 * variable's domain. It is, however, fully supported to implement much more general branching schemes, for example by
3144 * creating more than two subproblems, or by adding additional constraints to the subproblems instead of tightening the
3145 * domains of the variables.
3146 * \n
3147 * A complete list of all branching rules contained in this release can be found \ref BRANCHINGRULES "here".
3148 *
3149 * We now explain how users can add their own branching rules. Take the most infeasible LP branching rule
3150 * (src/scip/branch_mostinf.c) as an example. As all other default plugins, it is written in C. C++ users can easily
3151 * adapt the code by using the scip::ObjBranchrule wrapper base class and implement the scip_...() virtual methods instead of
3152 * the SCIP_DECL_BRANCH... callback methods.
3153 *
3154 * Additional documentation for the callback methods of a branching rule can be found in the file type_branch.h.
3155 *
3156 * Here is what you have to do to implement a branching rule:
3157 * -# Copy the template files src/scip/branch_xyz.c and src/scip/branch_xyz.h into files named
3158 * "branch_mybranchingrule.c" and "branch_mybranchingrule.h".
3159 * \n
3160 * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
3161 * -# Use SCIPincludeBranchruleMybranchingrule() in order to include the branching rule into your SCIP instance,
3162 * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
3163 * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mybranchingrule".
3164 * -# Adjust the properties of the branching rule (see \ref BRANCHRULE_PROPERTIES).
3165 * -# Define the branching rule data (see \ref BRANCHRULE_DATA). This is optional.
3166 * -# Implement the interface methods (see \ref BRANCHRULE_INTERFACE).
3167 * -# Implement the fundamental callback methods (see \ref BRANCHRULE_FUNDAMENTALCALLBACKS).
3168 * -# Implement the additional callback methods (see \ref BRANCHRULE_ADDITIONALCALLBACKS). This is optional.
3169 *
3170 *
3171 * @section BRANCHRULE_PROPERTIES Properties of a Branching Rule
3172 *
3173 * At the top of the new file "branch_mybranchingrule.c" you can find the branching rule properties.
3174 * These are given as compiler defines.
3175 * In the C++ wrapper class, you have to provide the branching rule properties by calling the constructor
3176 * of the abstract base class scip::ObjBranchrule from within your constructor.
3177 * The properties you have to set have the following meaning:
3178 *
3179 * \par BRANCHRULE_NAME: the name of the branching rule.
3180 * This name is used in the interactive shell to address the branching rule.
3181 * Additionally, if you are searching for a branching rule with SCIPfindBranchrule(), this name is looked up.
3182 * Names have to be unique: no two branching rules may have the same name.
3183 *
3184 * \par BRANCHRULE_DESC: the description of the branching rule.
3185 * This string is printed as a description of the branching rule in the interactive shell.
3186 *
3187 * \par BRANCHRULE_PRIORITY: the default value for the priority of the branching rule.
3188 * In the subproblem processing, the branching rules are called in decreasing order of their priority until
3189 * one succeeded to branch. Since most branching rules are able to generate a branching in all situations,
3190 * only the rule of highest priority is used. In combination with the BRANCHRULE_MAXDEPTH and
3191 * BRANCHRULE_MAXBOUNDDIST settings, however, interesting strategies can be easily employed. For example,
3192 * the user can set the priority of the "full strong branching" strategy to the highest value and assign the
3193 * second highest value to the "reliable pseudo cost" rule. If (s)he also sets the maximal depth for the
3194 * "full strong branching" to 5, in the top 5 depth levels of the search tree the "full strong branching" is
3195 * applied, while in the deeper levels "reliable pseudo cost branching" is used.
3196 * \n
3197 * Note that the BRANCHRULE_PRIORITY property only specifies the default value of the priority. The user can
3198 * change this value arbitrarily.
3199 *
3200 * \par BRANCHRULE_MAXDEPTH: the default value for the maximal depth level of the branching rule.
3201 * This parameter denotes the maximal depth level in the branch-and-bound tree up to which the branching method of the
3202 * branching rule will be applied. Use -1 for no limit.
3203 * \n
3204 * Note that this property only specifies the default value. The user can change this value arbitrarily.
3205 *
3206 * \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.
3207 * At the current branch-and-bound node, the relative distance from its dual bound (local dual bound)
3208 * to the primal bound compared to the best node's dual bound (global dual bound) is considered. The branching method of
3209 * the branching rule will only be applied at the node if this relative distance does not exceed BRANCHRULE_MAXBOUNDDIST.
3210 * \n
3211 * For example, if the global dual bound is 50 and the primal bound is 60, BRANCHRULE_MAXBOUNDDIST = 0.25 means that
3212 * 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
3213 * 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
3214 * current best node only or at all nodes, respectively.
3215 * \n
3216 * Note that the BRANCHRULE_MAXBOUNDDIST property only specifies the default value of the maximal bound distance.
3217 * The user can change this value arbitrarily.
3218 *
3219 *
3220 * @section BRANCHRULE_DATA Branching Rule Data
3221 *
3222 * Below the header "Data structures" you can find a struct which is called "struct SCIP_BranchruleData".
3223 * In this data structure, you can store the data of your branching rule. For example, you should store the adjustable
3224 * parameters of the branching rule in this data structure.
3225 * If you are using C++, you can add branching rule data as usual as object variables to your class.
3226 * \n
3227 * Defining branching rule data is optional. You can leave the struct empty.
4155 * You also have to initialize the fields in struct SCIP_RelaxData afterwards.
4156 *
4157 * You may also add user parameters for your relaxation handler, see the method SCIPincludeConshdlrKnapsack() in
4158 * the \ref cons_knapsack.h "knapsack constraint handler" for an example of how to add user parameters.
4159 *
4160 *
4161 * @section RELAX_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Relaxation Handler
4162 *
4163 * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
4164 * an operational algorithm.
4165 * They are passed together with the relaxation handler itself to SCIP using SCIPincludeRelax() or SCIPincludeRelaxBasic(),
4166 * see @ref RELAX_INTERFACE.
4167 *
4168 *
4169 * Relaxation handler plugins have only one fundamental callback method, namely the \ref RELAXEXEC method.
4170 * This method has to be implemented for every relaxation handler; the other callback methods are optional.
4171 * In the C++ wrapper class scip::ObjRelax, the scip_exec() method (which corresponds to the \ref RELAXEXEC callback) is a virtual
4172 * abstract member function.
4173 * You have to implement it in order to be able to construct an object of your relaxation handler class.
4174 *
4175 * Additional documentation for the callback methods can be found in type_relax.h.
4176 *
4177 * @subsection RELAXEXEC
4178 * The RELAXEXEC is called in each relaxation solving round. It should solve the current
4179 * subproblem's relaxation.
4180 *
4181 * Note that, like the LP relaxation, the relaxation handler should only operate on variables for which the corresponding
4182 * column exists in the transformed problem. Typical methods called by a relaxation handler are SCIPconstructLP() and SCIPflushLP() to
4183 * make sure that the LP of the current node is constructed and its data can be accessed via calls to SCIPgetLPRowsData()
4184 * and SCIPgetLPColsData(), and SCIPseparateSol() to call the cutting plane separators for a given primal solution.
4185 *
4186 * The lowerbound computed by the relaxation should be returned in the lowerbound pointer. If the relaxation improves on the best
4187 * relaxation already computed (either <code>SCIPisRelaxSolValid()</code> returns FALSE, meaning that no relaxation solution
4188 * is available so far, or the lowerbound is larger than the value returned by <code>SCIPgetRelaxSolObj()</code>), then the primal
4189 * solution of the relaxation should be stored inside the data structures of SCIP with <code>SCIPsetRelaxSolVal()</code>,
4190 * <code>SCIPsetRelaxSolVals()</code> or <code>SCIPsetRelaxSolValsSol()</code>. If you set the values one by one, you will need to call
4191 * <code>SCIPmarkRelaxSolValid()</code> to inform SCIP that the solution is complete and valid. With the "includeslp" argument of
4192 * <code>SCIPsetRelaxSolVals()</code>, <code>SCIPsetRelaxSolValsSol()</code> and <code>SCIPmarkRelaxSolValid()</code> you need to tell SCIP
4193 * whether the relaxation included all lp rows. In this case, the solution will be enforced and, if feasible, added to the solution storage if the
4194 * lowerbound of this relaxator is larger than the LP's. You may also call SCIPtrySolFree() directly from the
4195 * relaxation handler to make sure that a solution is added to the solution storage if it is feasible, even if the relaxator does not
4196 * include the LP or another relaxator produced a stronger bound. Also note that when setting the values of the relaxation solution one by one,
4197 * the objective value of the relaxation solution will be updated incrementally. If the whole solution should be updated, using SCIPsetRelaxSolVals()
4198 * instead or calling SCIPclearRelaxSolVals() before setting the first value to reset the solution and the objective value to 0 may help the numerics.
4199 * Furthermore, there is a list of external branching candidates, that can be filled by relaxation handlers and constraint handlers,
4200 * allowing branching rules to take these candidates as a guide on how to split the problem into subproblems. If the relaxation
4201 * solution is enforced, the integrality constraint handler will add external branching candidates for the relaxation solution
4202 * automatically, but the relaxation handler can also directly call <code>SCIPaddExternBranchCand()</code>.
4203 *
4204 * Usually, the RELAXEXEC callback only solves the relaxation and provides a lower (dual) bound through the corresponding pointer and
4205 * possibly a solution through <code>SCIPsetRelaxSolVal()</code> calls.
4206 * However, it may also produce domain reductions, add additional constraints or generate cutting planes. It has the
4207 * following options:
4208 * - detecting that the node is infeasible in the variable's bounds and can be cut off (result SCIP_CUTOFF)
4209 * - adding an additional constraint and stating that the relaxation handler should not be called again on the same
4210 * relaxation (result SCIP_CONSADDED)
4211 * - reducing a variable's domain and stating that the relaxation handler should not be called again on the same
4212 * relaxation (result SCIP_REDUCEDDOM)
4213 * - adding a cutting plane to the LP and stating that the relaxation handler should not be called again on the same
4214 * relaxation (result SCIP_SEPARATED)
4215 * - stating that the relaxation handler solved the relaxation and should not be called again on the same relaxation
4216 * (result SCIP_SUCCESS)
4217 * - interrupting the solving process to wait for additional input, e.g., cutting planes (result SCIP_SUSPENDED)
4218 * - stating that the separator was skipped (result SCIP_DIDNOTRUN).
4219 *
4220 * In the above criteria, "the same relaxation" means that the LP relaxation stayed unmodified. This means in particular
4221 * that no row has been added and no bounds have been modified. For example, changing the bounds of a variable will, as
4222 * long as it was a COLUMN variable, lead to a modification in the LP such that the relaxation handler is called again
4223 * after it returned with the result code SCIP_REDUCEDDOM. If the relaxation solution should be enforced, the relaxation
4224 * handler has to produce a new solution in this case which satisfies the updated LP. If a relaxation handler should only run
4225 * once per node to compute a lower bound, it should store the node of the last relaxation call itself and return
4226 * SCIP_DIDNOTRUN for subsequent calls in the same node.
4227 *
4228 *
4229 * @section RELAX_ADDITIONALCALLBACKS Additional Callback Methods of a Relaxation Handler
4230 *
4231 * The additional callback methods do not need to be implemented in every case. However, some of them have to be
4232 * implemented for most applications, they can be used, for example, to initialize and free private data.
4233 * Additional callbacks can either be passed directly with SCIPincludeRelax() to SCIP or via specific
4234 * <b>setter functions</b> after a call of SCIPincludeRelaxBasic(), see also @ref RELAX_INTERFACE.
4235 *
4236 * @subsection RELAXFREE
4237 *
4238 * If you are using relaxation handler data, you have to implement this method in order to free the relaxation handler
4239 * data. This can be done by the following procedure:
5187 * You also have to initialize the fields in struct SCIP_NlpiData afterwards. For freeing the
5188 * NLPI data, see \ref NLPIFREE.
5189 *
5190 *
5191 * @section NLPI_FUNDAMENTALCALLBACKS Fundamental Callback Methods of an NLPI
5192 *
5193 * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
5194 * an operational algorithm. Currently, all NLPI callbacks are fundamental.
5195 *
5196 * Additional documentation of the callback methods, in particular to their input parameters,
5197 * can be found in type_nlpi.h.
5198 *
5199 * @subsection NLPICOPY
5200 *
5201 * The NLPICOPY callback is executed if the plugin should be copied, e.g., when a SCIP instance is copied.
5202 *
5203 * @subsection NLPIFREE
5204 *
5205 * The NLPIFREE callback is executed if the NLP solver interface data structure should be freed, e.g., when a SCIP instance is freed.
5206 *
5207 * @subsection NLPIGETSOLVERPOINTER
5208 *
5209 * The NLPIGETSOLVERPOINTER callback can be used to pass a pointer to a solver specific data structure to the user.
5210 *
5211 * @subsection NLPICREATEPROBLEM
5212 *
5213 * The NLPICREATEPROBLEM callback is executed if a particular NLP problem is to be created.
5214 * The callback method should initialize a SCIP_NlpiProblem struct here that corresponds to an empty NLP.
5215 *
5216 * @subsection NLPIFREEPROBLEM
5217 *
5218 * The NLPIFREEPROBLEMPOINTER callback is executed if a particular NLP problem is to be freed.
5219 * The callback method should free a SCIP_NlpiProblem struct here.
5220 *
5221 * @subsection NLPIGETPROBLEMPOINTER
5222 *
5223 * The NLPIGETPROBLEMPOINTER callback can be used to pass a pointer to a solver specific data structure of the NLP to the user.
5224 *
5225 * @subsection NLPIADDVARS
5226 *
5227 * The NLPIADDVARS callback is executed if a set of variables with lower and upper bounds and names should be added to a particular NLP.
5228 * The callback method must add the new variables behind the previously added variables, if any.
5229 * If NULL is given for the lower bounds arguments, -infinity is assumed as lower bound for each new variable.
5230 * If NULL is given for the upper bounds arguments, +infinity is assumed as upper bound for each new variable.
5231 * It is also permitted to use NULL for the names argument.
5232 *
5233 * @subsection NLPIADDCONSTRAINTS
5234 *
5235 * The NLPIADDCONSTRAINTS callback is executed if a set of constraints should be added to a particular NLP.
5236 * Constraints are specified by providing left and right hand sides, linear and quadratic coefficients, expression trees, and constraint names.
5237 * All of these arguments are optional, giving NULL for left hand sides corresponds to -infinity, giving NULL for right hand sides corresponds to +infinity.
5238 *
5239 * @subsection NLPISETOBJECTIVE
5240 *
5241 * The NLPISETOBJECTIVE callback is executed to set the objective function of a particular NLP.
5242 *
5243 * @subsection NLPICHGVARBOUNDS
5244 *
5245 * The NLPICHGVARBOUNDS callback is executed to change the bounds on a set of variables of an NLP.
5246 *
5247 * @subsection NLPICHGCONSSIDES
5248 *
5249 * The NLPICHGCONSSIDES callback is executed to change the sides on a set of constraints of an NLP.
5250 *
5251 * @subsection NLPIDELVARSET
5252 *
5253 * The NLPIDELVARSET callback is executed to delete a set of variables from an NLP.
5254 * The caller provides an array in which for each variable it is marked whether it should be deleted.
5255 * In the same array, the method should return the new position of each variable in the NLP, or -1 if it was deleted.
5256 *
5257 * @subsection NLPIDELCONSSET
5258 *
5259 * The NLPIDELCONSSET callback is executed to delete a set of constraints from an NLP.
5260 * The caller provides an array in which for each constraint it is marked whether it should be deleted.
5261 * In the same array, the method should return the new position of each constraint in the NLP, or -1 if it was deleted.
5262 *
5263 * @subsection NLPICHGLINEARCOEFS
5264 *
5265 * The NLPICHGLINEARCOEFS callback is executed to change the coefficients in the linear part of the objective function or a constraint of an NLP.
5266 *
5267 * @subsection NLPICHGQUADCOEFS
5268 *
5269 * The NLPICHGQUADCOEFS callback is executed to change the coefficients in the quadratic part of the objective function or a constraint of an NLP.
5270 *
5271 * @subsection NLPICHGEXPRTREE
5272 *
5273 * The NLPICHGEXPRTREE callback is executed to replace the expression tree of the objective function or a constraint of an NLP.
5274 *
5275 * @subsection NLPICHGNONLINCOEF
5276 *
5277 * 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.
5278 *
5279 * @subsection NLPICHGOBJCONSTANT
5280 *
5281 * The NLPICHGOBJCONSTANT callback is executed to change the constant offset of the objective function of an NLP.
5282 *
5283 * @subsection NLPISETINITIALGUESS
5284 *
5285 * The NLPISETINITIALGUESS callback is executed to provide primal and dual initial values for the variables and constraints of an NLP.
5286 * For a local solver, these values can be used as a starting point for the search.
5287 * 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).
5288 * In this case, the solver should clear previously set starting values and setup its own starting point.
5289 *
5290 * @subsection NLPISOLVE
5291 *
5292 * The NLPISOLVE callback is executed when an NLP should be solved.
5293 * The solver may use the initial guess provided by \ref NLPISETINITIALGUESS as starting point.
5294 * The status of the solving process and solution can be requested by
5299 * The NLPIGETSOLSTAT callback can be used to request the solution status (solved, infeasible, ...) after an NLP has been solved.
5300 *
5301 * @subsection NLPIGETTERMSTAT
5302 *
5303 * The NLPIGETTERMSTAT callback can be used to request the termination reason (normal, iteration limit, ...) after an NLP has been solved.
5304 *
5305 * @subsection NLPIGETSOLUTION
5306 *
5307 * The NLPIGETSOLUTION callback can be used to request the primal and dual solution values after an NLP solve.
5308 * The method should pass pointers to arrays of variable values to the caller.
5309 * 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.
5310 *
5311 * @subsection NLPIGETSTATISTICS
5312 *
5313 * The NLPIGETSTATISTICS callback can be used to request the statistical values (number of iterations, time, ...) after an NLP solve.
5314 * The method should fill the provided NLPSTATISTICS data structure.
5315 *
5316 * <!-- NLPIGETWARMSTARTSIZE, NLPIGETWARMSTARTMEMO, NLPISETWARMSTARTMEMO are not documented,
5317 since they are currently not used, not implemented, and likely to change with a next version. -->
5318 *
5319 * @subsection NLPIGETINTPAR
5320 *
5321 * The NLPIGETINTPAR callback can be used to request the value of an integer valued NLP parameter.
5322 *
5323 * @subsection NLPISETINTPAR
5324 *
5325 * The NLPISETINTPAR callback is executed to set the value of an integer valued NLP parameter.
5326 *
5327 * @subsection NLPIGETREALPAR
5328 *
5329 * The NLPIGETREALPAR callback can be used to request the value of a real valued NLP parameter.
5330 *
5331 * @subsection NLPISETREALPAR
5332 *
5333 * The NLPISETREALPAR callback is executed to set the value of a real valued NLP parameter.
5334 *
5335 * @subsection NLPIGETSTRINGPAR
5336 *
5337 * The NLPIGETSTRINGPAR callback can be used to request the value of a string valued NLP parameter.
5338 *
5339 * @subsection NLPISETSTRINGPAR
5340 *
5341 * The NLPISETSTRINGPAR callback is executed to set the value of a string valued NLP parameter.
5381 * The expression interpreter has to implement a set of interface method.
5382 * In your "exprinterpret_myexprinterpret.c", these methods are mostly dummy methods that return error codes.
5383 *
5384 * @subsection SCIPexprintGetName
5385 *
5386 * The SCIPexprintGetName method should return the name of the expression interpreter.
5387 *
5388 * @subsection SCIPexprintGetDesc
5389 *
5390 * The SCIPexprintGetDesc method should return a short description of the expression interpreter, e.g., the name of the developer of the code.
5391 *
5392 * @subsection SCIPexprintGetCapability
5393 *
5394 * The SCIPexprintGetCapability method should return a bitmask that indicates the capabilities of the expression interpreter,
5395 * i.e., whether it can evaluate gradients, Hessians, or do interval arithmetic.
5396 *
5397 * @subsection SCIPexprintCreate
5398 *
5399 * The SCIPexprintCreate method is called to create an expression interpreter data structure.
5400 * The method should initialize a "struct SCIP_ExprInt" here.
5401 *
5402 * @subsection SCIPexprintFree
5403 *
5404 * The SCIPexprintFree method is called to free an expression interpreter data structure.
5405 * The method should free a "struct SCIP_ExprInt" here.
5406 *
5407 * @subsection SCIPexprintCompile
5408 *
5409 * The SCIPexprintCompile method is called to initialize the data structures that are required to evaluate
5410 * a particular expression tree.
5411 * The expression interpreter can store data that is particular to a given expression tree in the tree by using
5412 * SCIPexprtreeSetInterpreterData().
5413 *
5414 * @subsection SCIPexprintFreeData
5415 *
5416 * The SCIPexprintFreeData method is called when an expression tree is freed.
5417 * The expression interpreter should free the given data structure.
5418 *
5419 * @subsection SCIPexprintNewParametrization
5420 *
5421 * The SCIPexprintNewParametrization method is called when the values of the parameters in a parametrized expression tree have changed.
5422 *
5423 * @subsection SCIPexprintEval
5424 *
5425 * The SCIPexprintEval method is called when the value of an expression represented by an expression tree should be computed for a point.
5426 *
5427 * @subsection SCIPexprintEvalInt
5428 *
5429 * 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.
5430 *
5431 * @subsection SCIPexprintGrad
5432 *
5433 * The SCIPexprintGrad method is called when the gradient of an expression represented by an expression tree should be computed for a point.
5434 *
5435 * @subsection SCIPexprintGradInt
5436 *
5437 * 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.
5441 * The SCIPexprintHessianSparsityDense method is called when the sparsity structure of the Hessian matrix should be computed and returned in dense form.
5442 *
5443 * @subsection SCIPexprintHessianDense
5444 *
5445 * The SCIPexprintHessianDense method is called when the Hessian of an expression represented by an expression tree should be computed for a point.
5452 * After solving a constraint integer program, SCIP can display statistics tables with information about, e.g., the solving time,
5453 * number of nodes, LP iterations or the number of calls and successes of different plugins via "display statistics" in the shell
5454 * or via SCIPprintStatistics() in the C-interface. There already exists a wide variety of statistics tables which can be activated
5455 * or deactivated on demand, see src/scip/table_default.c. Additionally, the user can implement his/her own statistics tables
5456 * in order to display problem or algorithm specific values.
5457 * \n
5458 * A complete list of all statistics tables contained in this release can be found \ref TABLES "here".
5459 *
5460 * We now explain how users can add their own statistics tables.
5461 * We give the explanation for creating your own source file for each additional statistics table. Of course, you can collect
5462 * different additional statistics tables in one source file.
5463 * Take src/scip/table_default.c, where all default statistics tables are collected, as an example.
5464 * As all other default plugins, the default statistics table plugins and the statistics table template are written in C.
5465 * C++ users can easily adapt the code by using the scip::ObjTable wrapper base class and implement the scip_...() virtual methods
5466 * instead of the SCIP_DECL_TABLE... callback methods.
5467 *
5468 *
5469 * Additional documentation for the callback methods of a statistics table can be found in the file type_table.h.
5470 *
5471 * Here is what you have to do to implement a statistics table (assuming your statistics table is named "mystatisticstable"):
5472 * -# Copy the template files src/scip/table_xyz.c and src/scip/table_xyz.h into files named "table_mystatisticstable.c"
5473 * and "table_mystatisticstable.h".
5474 * \n
5475 * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
5476 * -# Use SCIPincludeTableMystatisticstable() in order to include the statistics table into your SCIP instance,
5477 * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
5478 * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mystatisticstable".
5479 * -# Adjust the \ref TABLE_PROPERTIES "properties of the statistics table".
5480 * -# Define the \ref TABLE_DATA "statistics table data". This is optional.
5481 * -# Implement the \ref TABLE_INTERFACE "interface methods".
5482 * -# Implement the \ref TABLE_FUNDAMENTALCALLBACKS "fundamental callback methods".
5483 * -# Implement the \ref TABLE_ADDITIONALCALLBACKS "additional callback methods". This is optional.
5484 *
5485 *
5486 * @section TABLE_PROPERTIES Properties of a Statistics Table
5487 *
5488 * At the top of the new file "table_mystatisticstable.c" you can find the statistics table properties.
5489 * These are given as compiler defines.
5490 * In the C++ wrapper class, you have to provide the statistics table properties by calling the constructor
5491 * of the abstract base class scip::ObjTable from within your constructor.
5492 * The properties you have to set have the following meaning:
5493 *
5494 * \par TABLE_NAME: the name of the statistics table.
5495 * This name is used in the interactive shell to address the statistics table.
5496 * Additionally, if you are searching for a statistics table with SCIPfindTable(), this name is looked up.
5497 * Names have to be unique: no two statistic tables may have the same name.
5498 *
5499 * \par TABLE_DESC: the description of the statistics table.
5500 * This string is printed as a description of the statistics table in the interactive shell.
5501 *
5502 * \par TABLE_POSITION: the position of the statistics table.
5503 * In the statistics output, the statistics tables will be ordered by increasing position. Compare with the
5504 * default statistics tables in "table_default.c" to find a value which will give you the desired position
5505 * between the default statistics tables. If you give your table a negative position value, it will appear
5506 * before all SCIP statistcs, with a value larger than 20000 it will appear after all default statistics.
5507 *
5508 * \par TABLE_EARLIEST_STAGE: output of the statistics table is only printed from this stage onwards
5509 * The output routine of your statistics table will only be called if SCIP has reached this stage. For
5510 * example, the default table "tree" will only output information starting from SCIP_STAGE_SOLVING, because
5511 * there is no meaningful information available before, while the "presolver" table can already be called
5512 * in SCIP_STAGE_TRANSFORMED.
5513 *
5514 * @section TABLE_DATA Statistics Table Data
5515 *
5516 * Below the header "Data structures" you can find a struct which is called "struct SCIP_TableData".
5517 * In this data structure, you can store the data of your statistics table. For example, you should store the adjustable
5518 * parameters of the statistics table in this data structure.
5519 * If you are using C++, you can add statistics table data as usual as object variables to your class.
5520 * \n
5521 * Defining statistics table data is optional. You can leave the struct empty.
5522 *
5523 *
5524 * @section TABLE_INTERFACE Interface Methods
5525 *
5526 * At the bottom of "table_mystatisticstable.c" you can find the interface method SCIPincludeTableMystatisticstable(), which also
5527 * appears in "table_mystatisticstable.h".
5528 * \n
5529 * This method only has to be adjusted slightly.
5530 * It is responsible for notifying SCIP of the presence of the statistics table by calling the method
5531 * SCIPincludeTable().
5532 *
5533 * The interface method is called by the user, if (s)he wants to include the statistics table, i.e., if (s)he wants to use the statistics table in an
5534 * application.
5535 *
5536 * If you are using statistics table data, you have to allocate the memory for the data at this point.
5803/**@page CONCSCIP How to use the concurrent solving mode
5804 *
5805 * @section Overview
5806 *
5807 * In \SCIP 4.0 a new feature has been added that allows to run multiple \SCIP instances with different settings
5808 * on one problem in parallel. To use this feature \SCIP has to be compiled with an additional make option to
5809 * enable the threading functionality (e.g. TPI=tny, see \ref MAKE).
5810 * Then, a concurrent solve can be started by using the <code>concurrentopt</code> command instead of the <code>optimize</code> command
5811 * in the \SCIP shell, or by calling the interface function SCIPsolveParallel().
5812 * To configure the behavior of the concurrent solving mode there are new parameters in the category <code>concurrent/</code>
5813 * and <code>parallel/</code> which will be explained here shortly.
5814 *
5815 * @section CONTROLNTHREADS Controlling the number of threads
5816 *
5817 * The parameters <code>parallel/maxnthreads</code> and <code>parallel/minnthreads</code> can be used to configure the number of threads
5818 * that sould be used for solving. \SCIP will try to use the configured maximum number of threads. If the
5819 * problem that is currently read is too large \SCIP will automatically use fewer threads, but never
5820 * go below the configured minimum number of threads.
5821 *
5822 * @section USEEMPHSETTINGS Using emphasis settings
5823 *
5824 * The parameters <code>concurrent/scip.../prefprio</code> configure which concurrent solvers should be used.
5825 * The concurrent solver <code>scip</code> will use the same settings as the \SCIP instance configured by the user.
5826 * The other concurrent solvers, e.g. <code>scip-feas</code>, will load the corresponding emphasis setting.
5827 * The behavior of the prefprio parameter is as follows: If it is set to 1.0 for <code>scip-feas</code> and
5828 * <code>scip-opti</code>, and to 0.0 for every other concurrent solver, then the threads will be evenly
5829 * 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
5830 * 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
5831 * and the latter will use 3 threads of the 4 available threads.
5835 * To use custom settings for the concurrent solvers there is the parameter <code>concurrent/paramsetprefix</code>. If custom parameters
5836 * 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).
5837 * The parameter settings must be named after the concurrent solvers, e.g. if only the concurrent solver <code>scip</code> is used
5838 * 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
5839 * starts at one for each of them, e.g. <code>scip-1</code> and <code>scip-feas-1</code>.
6294 * \arg <code>TIME</code> - time limit for each test instance in seconds [default: 3600]
6295 * \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]
6296 * \arg <code>THREADS</code> - the number of threads used for solving LPs, if the linked LP solver supports multithreading [default: 1]
6297 * \arg <code>VALGRIND</code> - run valgrind on the SCIP binary; errors and memory leaks found by valgrind are reported as fails [default: "false"]
6298 *
6299 *
6300 * @section COMPARE Comparing test runs for different settings
6301 *
6302 * Often test runs are performed on the basis of different settings. In this case, it is useful to
6303 * have a performance comparison. For this purpose, we can use the <code>allcmpres.sh</code> script in
6304 * the @c check directory.
6305 *
6306 * Suppose, we performed our test run with two different settings, say <code>fast.set</code> and
6307 * <code>slow.set</code>. Assuming that all other parameters (including the SCIP binary), were the same,
6308 * we may have the following <code>res</code>-files in the directory <code>scip/check/results/</code>
6420 * In this case, the test with respect to the number of found feasible solutions is irrelevant, since their number is
6421 * equal. In particular, the null hypothesis gets accepted (i.e., there is no difference in the settings - this is
6422 * marked by "X").
6423 *
6424 * With respect to the number of instances solved to optimality within the timelimit, we have that \f$0.005 < p <=
6425 * 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
6426 * settings perform differently; this is marked by "!". In the concrete case, we have 230 instances, all of which are
6427 * solved by setting \c S2, but only 224 by setting \c S1.
6428 *
6429 * @subsection Wilcoxon Wilcoxon signed rank test
6430 *
6431 * Assume that we compare two settings \c S1 and \c S2 with respect to their solution times (within the time limit). We
6432 * generate a sorted list of the ratios of the run times, where ratios that are (absolutely or relatively) within 1\%
6433 * of 1.0 are discarded, and ratios between 0.0 and 0.99 are replaced with their negative inverse in order to
6434 * obtain a symmetric distribution for the ratios around the origin.
6435 * We then assign ranks 1 to \c N to the remaining \c N data points in nondecreasing
6436 * order of their absolute ratio. This yields two groups \c G1
6437 * 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
6438 * setting \c S1 is faster). Then the sums of the ranks in groups \c G1 and \c G2 are computed, yielding values \c R1
6439 * and \c R2, respectively.
6440 *
6441 * The Wilcoxon test statistic is then
6442 * \f[
6443 * z = \frac{\min(R1, R2) - \frac{N(N+1)}{4}}{\sqrt{\frac{N(N+1)(2N+1)}{24}}},
6444 * \f]
6445 * which we assume to be (approximately) normally distributed (with zero mean) and allows to compute the probability
6446 * \f$p\f$ that one setting is faster than the other. (Note that for \f$N \leq 60\f$, we apply a correction by
6447 * subtracting 0.5 from the numerator).
6448 *
6449 * As an example consider the following output:
6450 * \code
6451 * Wilcoxon (time) z -0.1285, 0.05 <= p X
6452 * Wilcoxon (nodes) z -11.9154, p < 0.0005 !!!
6453 * \endcode
6454 * While the \f$z\f$-value is close to zero for the run time, it is extremely negative regarding the solving nodes. This latter
6455 * 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
6456 * nodes than setting \c S2 is negligible (this null hypothesis is rejected - marked by "!!!").
6457 *
6458 * However, the null hypothesis is not rejected with respect to the run time. In the concrete case, setting \c S1 has a
6459 * 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
6460 * 0.88. Still - the null hypothesis is not rejected.
6461 *
6462 * @section SOLVER Testing and Evaluating using GAMS
6463 *
6464 * Analogously to the target <code>test</code> there is another target to run automated tests with <a href="http://www.gams.com/">gams</a>
6465 * \code
6466 * make testgams GAMSSOLVER=xyz
6467 * \endcode
6468 * For this target, the option GAMSSOLVER has to be given to specify the name of a GAMS solver to run, e.g. GAMSSOLVER=SCIP.
6469 * Additional advanced options specific to this target are:
6470 * GAMS to specify the GAMS executable (default: gams),
6471 * GAP to specify a gap limit (default: 0.0),
6472 * CLIENTTMPDIR to specify a directory where GAMS should put its scratch files (default: /tmp),
6473 * 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).
6474 * The following options are NOT supported (and ignored): DISPFREQ, FEASTOL, LOCK.
6475 * 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).
6476 *
6477 * Note: This works only if the referred programs are installed globally on your machine.
6478 *
6479 * The above options like <code>TIME</code> are also available for gams.
6480 *
6481 * After the testrun there should be an <code>.out</code>, an <code>.err</code> and a <code>.res</code> file
6482 * with the same basename as described above.
6483 *
6484 * Furthermore you can also use the script <code>allcmpres.sh</code> for comparing results.
6544/**@page CHG3 Interface changes between SCIP 1.1 and SCIP 1.2
6545 *
6546 *
6547 * @section CHGCALLBACKS New and changed callbacks
6548 *
6549 * - The callback SCIP_DECL_PRICERREDCOST(x) in the \ref PRICER "pricers" has two new parameters:
6550 * - A <code>result</code> pointer determines whether the pricer guarantees that there exist no more variables. This allows for early branching.
6551 * - A pointer for providing a lower bound.
6552 *
6553 * - The \ref CONS "constraint handlers" have two new callback methods (see type_cons.h for more details).
6554 * - SCIP_DECL_CONSCOPY(x) - this method can be used to copy a constraint.
6555 * - SCIP_DECL_CONSPARSE(x) - this method can be used to parse a constraint in CIP format.
6556 *
6557 * @section CHGINTERFUNC New parameters in interface methods
6558 *
6559 * - SCIPcalcMIR() in scip.h has two new parameter "mksetcoefsvalid" and "sol". The parameter "mksetcoefsvalid" stores
6560 * whether the coefficients of the mixed knapsack set ("mksetcoefs") computed in SCIPlpCalcMIR() are valid. If the mixed knapsack constraint obtained after aggregating LP rows
6561 * 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.
6562 * The input parameter "sol" can be used to separate a solution different from the LP solution.
6563 *
6564 * - 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.
6565 *
6566 * @section MISCELLANEOUS Miscellaneous
6567 *
6568 * - A significant change for <b>C++ users</b> is that all include files of SCIP
6569 * automatically detect C++ mode, i.e., no <code>extern "C"</code> is needed anymore.
6570 *
6571 * For further release notes we refer to the \ref RELEASENOTES "Release notes".
6727 /**@page CHG5 Interface changes between SCIP 2.0 and SCIP 2.1
6728 *
6729 *
6730 * @section CHGCALLBACKS5 New and changed callbacks
6731 *
6732 * - <b>Presolving</b>:
6733 * <br>
6734 * <br>
6735 * - The new parameters "nnewaddconss" and "naddconss" were added to the constraint handler callback method SCIP_DECL_CONSPRESOL()
6736 * and the presolver callback method SCIP_DECL_PRESOLEXEC(). These parameters were also added to corresponding C++ wrapper class methods.
6737 * - Propagators are now also called in during presolving, this is supported by the new callback methods SCIP_DECL_PROPINITPRE(),
6738 * SCIP_DECL_PROPEXITPRE(), and SCIP_DECL_PROPPRESOL().
6739 * - New parameters "isunbounded" and "isinfeasible" for presolving initialization (SCIP_DECL_CONSINITPRE(),
6740 * SCIP_DECL_PRESOLINITPRE(), SCIP_DECL_PROPINITPRE()) and presolving deinitialization (SCIP_DECL_CONSEXITPRE(),
6741 * SCIP_DECL_PRESOLEXITPRE(), SCIP_DECL_PROPEXITPRE()) callbacks of presolvers,
6742 * constraint handlers and propagators, telling the callback whether the problem was already declared to be
6743 * unbounded or infeasible. This allows to avoid expensive steps in these methods in case the problem is already
6744 * solved, anyway.
6745 * <br>
6746 * <br>
6747 * <DIV class="note">
6748 * Note, that the C++ methods
6749 * - scip::ObjConshdlr::scip_presol() corresponding to SCIP_DECL_CONSPRESOL()
6750 * - scip::ObjConshdlr::scip_initpre() corresponding to SCIP_DECL_CONSINITPRE()
6751 * - scip::ObjPresol::scip_initpre() corresponding to SCIP_DECL_PRESOLINITPRE()
6752 * - scip::ObjProp::scip_initpre() corresponding to SCIP_DECL_PROPINITPRE()
6753 * - scip::ObjConshdlr::scip_exitpre() corresponding to SCIP_DECL_CONSEXITPRE()
6754 * - scip::ObjPresol::scip_exitpre() corresponding to SCIP_DECL_PRESOLEXITPRE()
6755 * - scip::ObjProp::scip_exitpre() corresponding to and SCIP_DECL_PROPEXITPRE()
6756 * .
6757 * are virtual functions. That means, if you are not adding the new parameters, your code will still compile, but these methods are not executed.
6758 * </DIV>
6759 *
6760 * - <b>Constraint Handler</b>:
6761 * <br>
6762 * <br>
6763 * - The new constraint handler callback SCIP_DECL_CONSDELVARS() is called after variables were marked for deletion.
6764 * This method is optional and only of interest if you are using SCIP as a branch-and-price framework. That means,
6765 * you are generating new variables during the search. If you are not doing that just define the function pointer
6766 * to be NULL.
6767 * <br>
6768 * If this method gets implemented you should iterate over all constraints of the constraint handler and delete all
6769 * variables that were marked for deletion by SCIPdelVar().
6770 *
6771 * - <b>Problem Data</b>:
6772 * <br>
6773 * <br>
6774 * - 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.
6775 *
6776 * - <b>Conflict Analysis</b>:
6777 * <br>
6778 * <br>
6779 * - Added parameter "separate" to conflict handler callback method SCIP_DECL_CONFLICTEXEC() that defines whether the conflict constraint should be separated or not.
6780 *
6781 * - <b>NLP Solver Interface</b>:
6782 * <br>
6783 * <br>
6784 * - The callbacks SCIP_DECL_NLPIGETSOLUTION() and SCIP_DECL_NLPISETINITIALGUESS() got new parameters to get/set values of dual variables.
6785 * - The callback SCIP_DECL_NLPICOPY() now passes the block memory of the target SCIP as an additional parameter.
6793 * - The methods SCIPwriteVarName(), SCIPwriteVarsList(), and SCIPwriteVarsLinearsum() got a new boolean parameter "type"
6794 * that indicates whether the variable type should be written or not.
6795 * - The method SCIPwriteVarsList() got additionally a new parameter "delimiter" that defines the character which is used for delimitation.
6796 * - The methods SCIPparseVarName() and SCIPparseVarsList() got a new output parameter "endptr" that is filled with the position where the parsing stopped.
6797 *
6798 * - <b>Plugin management</b>:
6799 * <br>
6800 * <br>
6801 * - 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.
6802 * - SCIPincludeConshdlr() got additional parameters to set the variable deletion callback function and the timing mask for propagation.
6803 *
6804 * - <b>Constraint Handlers</b>:
6805 * <br>
6806 * <br>
6807 * - Method SCIPseparateRelaxedKnapsack() in knapsack constraint handler got new parameter "cutoff", which is a pointer to store whether a cutoff was found.
6808 * - Method SCIPincludeQuadconsUpgrade() of quadratic constraint handler got new parameter "active" to indicate whether the upgrading method is active by default.
6809 *
6810 * - <b>Nonlinear expressions, relaxation, and solver interface</b>:
6811 * <br>
6812 * <br>
6813 * - The methods SCIPexprtreeEvalSol(), SCIPexprtreeEvalIntLocalBounds(), and SCIPexprtreeEvalIntGlobalBounds() have been renamed to SCIPevalExprtreeSol(),
6814 * SCIPevalExprtreeLocalBounds(), and SCIPevalExprtreeGlobalBounds() and are now located in scip.h.
6815 * - Various types and functions dealing with polynomial expressions have been renamed to use the proper terms "monomial" and "polynomial".
6816 * - The methods SCIPnlpGetObjective(), SCIPnlpGetSolVals(), and SCIPnlpGetVarSolVal() have been removed, use SCIPgetNLPObjval(), SCIPvarGetNLPSol()
6817 * and SCIPcreateNLPSol() to retrieve NLP solution values instead.
6818 * - Removed methods SCIPmarkRequireNLP() and SCIPisNLPRequired(), because the NLP is now always constructed if nonlinearities are present.
6819 * - SCIPgetNLP() has been removed and NLP-methods from pub_nlp.h have been moved to scip.h, which resulted in some renamings, too.
6820 * - The functions SCIPnlpiGetSolution() and SCIPnlpiSetInitialGuess() got additional arguments to get/set dual values.
6821 * - The method SCIPgetNLPI() got a new parameter "nlpiproblem", which is a pointer to store the NLP solver interface problem.
6822 *
6823 * - <b>Others</b>:
6824 * <br>
6825 * <br>
6826 * - 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
6827 * the given variable is contained in the given hash map.
6828 * - Removed method SCIPreadSol(); call solution reading via SCIPreadProb() which calls the solution reader for .sol files.
6829 * - SCIPchgVarType() got an extra boolean parameter to store if infeasibility is recognized while upgrading a variable from continuous type to an integer type.
6830 * - SCIPdelVar() got a new parameter "deleted", which stores whether the variable was successfully marked to be deleted.
6831 * - SCIPcalcNodeselPriority() got a new parameter "branchdir", which defines the type of branching that was performed: upwards, downwards, or fixed.
6832 * - The parameters "timelimit" and "memorylimit" were removed from SCIPapplyRens().
6833 *
6834 * <br>
6835 * @section MISCELLANEOUS5 Miscellaneous
6836 *
6837 * - The result value SCIP_NEWROUND has been added, it allows a separator/constraint handler to start a new separation round
6838 * (without previous calls to other separators/conshdlrs).
6839 * - All timing flags are now defined type_timing.h.
6840 * - The variable deletion event is now a variable specific event and not global, anymore.
6841 * - The emphasis setting types now distinguish between plugin-type specific parameter settings (default, aggressive, fast, off), which are changed by
6842 * SCIPsetHeuristics/Presolving/Separating(), and global emphasis settings (default, cpsolver, easycip, feasibility, hardlp, optimality, counter),
6843 * which can be set using SCIPsetEmphasis().
6844 *
6845 * <br>
6846 * For further release notes we refer to the \ref RELEASENOTES "Release notes".
7274 * - added arguments "fixedvars", "fixedvals", "nfixedvars" to SCIPcopyVars()
7275 * - added arguments "fixedvars", "fixedvals", "nfixedvars" to SCIPcopyOrigVars()
7276 * - renamed argument "success" to valid in SCIPgetConsCopy()
7277 *
7278 * <br>
7279 * - <b>Parameters</b>:
7280 * - renamed method SCIPcheckBoolParam() to SCIPisBoolParamValid()
7281 * - renamed method SCIPcheckLongintParam() to SCIPisLongintParamValid()
7282 * - renamed method SCIPcheckRealParam() to SCIPisRealParamValid()
7283 * - renamed method SCIPcheckCharParam() to SCIPisCharParamValid()
7284 * - renamed method SCIPcheckStringParam() to SCIPisStringParamValid()
7285 *
7286 * <br>
7287 * - <b>Relaxators</b>:
7288 * - added argument "includeslp" to SCIPincludeRelax() and SCIPincludeRelaxBasic()
7289 *
7290 * <br>
7291 * - <b>Primal Heuristics</b>:
7292 * - introduced new type SCIP_HEURTIMING for primal heuristic timing masks
7293 * - changed type of argument "timingmask" from unsigned int to SCIP_HEURTIMING in SCIPincludeHeur(), SCIPincludeHeurBasic()
7294 * - added argument "initialseed" to SCIPcreateDiveset()
7295 * <br>
7296 * - <b>Reoptimization</b>:
7297 * - renamed function SCIPgetReopSolsRun() to SCIPgetReoptSolsRun()
7298 *
7299 * <br>
7300 * - <b>Variables</b>:
7301 * - Removed method SCIPvarGetNBinImpls()
7302 *
7303 * <br>
7304 * - <b>Conflict Analysis</b>:
7305 * - added arguments "conftype" and "iscutoffinvolved" to SCIPinitConflictAnalysis()
7306 *
7307 * <br>
7308 * - <b>Constraint Handlers</b>:
7309 * - added argument "infeasible" to SCIPinitlpCons()
7310 *
7311 * <br>
7312 * - <b>Nonlinear Relaxation</b>:
7313 * - added argument "curvature" to SCIPcreateNlRow()
7314 *
7315 * <br>
7316 * - <b>Solutions</b>:
7317 * - added argument "completely" to SCIPtrySol(), SCIPtrySolFree(), SCIPcheckSol()
7318 *
7319 * - <b>Hashmap and Hashtable</b>:
7320 * - removed function SCIPcalcHashtableSize() since not required anymore for SCIP_HASHTABLE and SCIP_HASHMAP
7321 * - based on the initial size SCIP_HASHTABLE and SCIP_HASHMAP choose an appropriate size internally to allow insertion of that many elements without resizing
7322 * - SCIP_MULTIHASH behaves like the old SCIP_HASHTABLE and SCIPcalcMultihashSize() should be used as replacement for SCIPcalcHashtableSize()
7323 *
7324 * <br>
7325 * For further information we refer to the \ref RELEASENOTES "Release notes" and the \ref CHANGELOG "Changelog".
7510 * In that case the sparse solutions are unrolled and lifted back into the original variable space.
7511 *
7512 * The callable library provides a method which gives access to all collected sparse solutions. That is,
7513 * SCIPgetCountedSparseSolutions(). The sparse solutions you get are defined w.r.t. active variables. To get solutions
7514 * w.r.t. to the original variables. You have to do two things:
7515 *
7516 * -# unroll each sparse solution
7517 * -# lift each solution into original variable space by extending the solution by those variable which got removed
7518 * during presolving
7519 *
7520 * The get the variables which got removed during presolving, you can use the methods SCIPgetFixedVars() and
7521 * SCIPgetNFixedVars(). The method SCIPgetProbvarLinearSum() transforms given variables, scalars and constant to the
7522 * corresponding active variables, scalars and constant. Using this method for a single variable gives a representation
7523 * for that variable w.r.t. the active variables which can be used to compute the value for the considered solution (which
7524 * is defined w.r.t. active variables).
7525 *
7526 * For that complete procedure you can also check the source code of
7527 * \ref SCIP_DECL_DIALOGEXEC(SCIPdialogExecWriteAllsolutions) "SCIPdialogExecWriteAllsolutions()" cons_countsols.c which
7528 * does exactly that.
7529 *
7530 *
7531 * @section COUNTOPTIMAL Count number of optimal solutions
7532 *
7533 * If you are interested in counting the number of optimal solutions, this can be done with SCIP using the
7534 * <code>count</code> command by applying the following steps:
7535 *
7536 * -# Solve the original problem to optimality and let \f$c^*\f$ be the optimal value
7537 * -# Added the objective function as constraint with left and right hand side equal to \f$c^*\f$
7538 * -# load the adjusted problem into SCIP
7539 * -# use the predefined counting settings
7540 * -# start counting the number of feasible solutions
7541 *
7542 * If you do this, SCIP will collect all optimal solutions of the original problem.
7543 *
7544 */
7545
7546/**@page LICENSE License
7547 *
7548 * \verbinclude COPYING
7549 */
7550
7551/**@page FAQ Frequently Asked Questions (FAQ)
7552 * \htmlinclude faq.inc
7553 */
7554
7555/**@page INSTALL Installation information
7556 * \verbinclude INSTALL
7557 */
7558
7559/**@page INSTALL_CMAKE Installation information (CMake)
7560 * \verbinclude INSTALL_CMAKE
7561 */
7562
7563
7564/**@page RELEASENOTES Release notes
7565 *
7566 * Please consult the <a href="https://opus4.kobv.de/opus4-zib/frontdoor/index/index/docId/6629">release report</a> for version 5.0 that explains many of the new features in detail.
7567 *
7568 * \verbinclude SCIP-release-notes-5.0
7569 *
7570 * 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>.
7571 *
7572 * \verbinclude SCIP-release-notes-4.0.1
7573 *
7574 * \verbinclude SCIP-release-notes-4.0
7575 *
7576 * 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.
7577 *
7578 * \verbinclude SCIP-release-notes-3.2.1
7579 *
7580 * \verbinclude SCIP-release-notes-3.2
7581 *
7582 * \verbinclude SCIP-release-notes-3.1
7583 *
7584 * \verbinclude SCIP-release-notes-3.0.2
7585 *
7586 * \verbinclude SCIP-release-notes-3.0.1
7587 *
7588 * \verbinclude SCIP-release-notes-3.0
7589 *
7590 * \verbinclude SCIP-release-notes-2.1.1
7591 *
7592 * \verbinclude SCIP-release-notes-2.1
7593 *
7594 * \verbinclude SCIP-release-notes-2.0.2
7595 *
7596 * \verbinclude SCIP-release-notes-2.0.1
7597 *
7598 * \verbinclude SCIP-release-notes-2.0
7599 *
7600 * \verbinclude SCIP-release-notes-1.2
7601 *
7602 * \verbinclude SCIP-release-notes-1.1
7603 */
7604
7605/**@page CHANGELOG CHANGELOG
7606 *
7607 * \verbinclude CHANGELOG
7608 *
7609 */
7610
7611
7612
7613/**@page PARAMETERS List of all SCIP parameters
7614 *
7615 * This page list all parameters of the current SCIP version. This list can
7616 * easily be generated by SCIP via the interactive shell using the following command:
7617 *
7618 * <code>SCIP> set save <file name></code>
8157 * <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>
8158 * <tr><td>\ref reader_diff.h "DIFF format"</td> <td>for reading a new objective function for mixed-integer programs</td></tr>
8159 * <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>
8160 * <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>
