250 * There are several extensions of \SCIP for particular applications included in the release. They are contained in the "applications" directory
894 * 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
895 * solution" to show the nonzero variables of the best found solution.
1140 * \par LINCONSUPGD_PRIORITY: priority of the constraint handler for upgrading of linear constraints
1141 * This property is only needed if a certain linear constraint can be upgraded to a more specific one. In one of
1142 * the first presolving rounds SCIP tries to upgrade linear constraints to more specialized constraints, such as
1143 * knapsack constraints. The upgrading calls are processed in the order of decreasing priority.
1144 *
1145 * \par NONLINCONSUPGD_PRIORITY: priority of the constraint handler for upgrading of nonlinear constraints
1146 * This property has the same effect as the LINCONSUPGD_PRIORITY parameter, see above, and should be set whenever
1147 * an upgrade functionality from a general nonlinear constraint to the more specific one is defined.
1148 *
1149 * \par CONSHDLR_SEPAFREQ: the default frequency for separating cuts.
1150 * The separation frequency defines the depth levels at which the constraint handler's separation methods \ref CONSSEPALP
1151 * and \ref CONSSEPASOL are called.
1152 * For example, a separation frequency of 7 means, that the separation callback is executed for subproblems that are
1153 * in depth 0, 7, 14, ... of the branching tree.
1154 * A separation frequency of 0 means, that the separation method is only called at the root node.
1155 * A separation frequency of -1 disables the separation method of the constraint handler.
1156 * \n
1157 * The separation frequency can be adjusted by the user.
1158 * This property of the constraint handler only defines the default value of the frequency.
1159 * If you want to have a more flexible control of when to execute the separation algorithm, you have to assign
1160 * a separation frequency of 1 and implement a check at the beginning of your separation algorithm whether you really
1161 * want to execute the separator or not.
1162 * If you do not want to execute the method, set the result code to SCIP_DIDNOTRUN.
1163 *
1164 * \par CONSHDLR_SEPAPRIORITY: the priority of the constraint handler for separation. (optional: to be set only if the constraint handler supports separation)
1165 * In each separation round during the price-and-cut loop of the subproblem processing or during the separation loop
1166 * of the primal solution separation, the separators and separation methods of the constraint handlers are called in
1167 * a predefined order, which is given by the priorities of the separators and the separation priorities of the
1168 * constraint handlers.
1169 * First, the separators with non-negative priority are called in the order of decreasing priority.
1170 * Next, the separation methods of the different constraint handlers are called in the order of decreasing separation
1171 * priority.
1172 * Finally, the separators with negative priority are called in the order of decreasing priority.
1173 * \n
1174 * The separation priority of the constraint handler should be set according to the complexity of the cut separation
1175 * algorithm and the impact of the resulting cuts:
1176 * Constraint handlers that provide fast algorithms that usually have a high impact (i.e., cut off a large portion of
1177 * the LP relaxation) should have a high priority.
1178 * See \ref CONSSEPALP and \ref CONSSEPASOL for further details of the separation callbacks.
1179 *
1180 * \par CONSHDLR_DELAYSEPA: the default for whether the separation method should be delayed, if other separators found cuts.
1181 * If the constraint handler's separation method is marked to be delayed, it is only executed after no other separator
1182 * or constraint handler found a cut during the price-and-cut loop.
1183 * If the separation method of the constraint handler is very expensive, you may want to mark it to be delayed until all
1184 * cheap separation methods have been executed.
1185 *
1186 * \par CONSHDLR_PROPFREQ: the default frequency for propagating domains.
1187 * This default frequency has the same meaning as the CONSHDLR_SEPAFREQ with respect to the domain propagation
1188 * callback of the constraint handler.
1189 * A propagation frequency of 0 means that propagation is only applied in preprocessing and at the root node.
1190 * A propagation frequency of -1 disables the propagation method of the constraint handler.
1191 *
1192 * \par CONSHDLR_DELAYPROP: the default for whether the propagation method should be delayed, if other propagators found reductions.
1193 * This property is analogous to the DELAYSEPA flag, but deals with the propagation method of the constraint handler.
1194 *
1195 * \par CONSHDLR_PROP_TIMING: the propagation timing mask of the constraint handler.
1196 * SCIP calls the domain propagation routines at different places in the node processing loop.
1197 * This property indicates at which places the propagation routine of the constraint handler is called.
1198 * Possible values are defined in type_timing.h and can be concatenated, e.g., as in SCIP_PROPTIMING_ALWAYS.
1199 *
1200 * \par CONSHDLR_PRESOLTIMING: the timing of the constraint handler's presolving method (FAST, MEDIUM, or EXHAUSTIVE).
1201 * Every presolving round starts with the FAST presolving methods. MEDIUM presolvers are only called, if FAST presolvers did not find
1202 * enough reductions in this round so far, and EXHAUSTIVE presolving steps are only performed if all presolvers called before
1203 * in this round were unsuccessful.
1204 * Presolving methods should be assigned a timing based on how expensive they are, e.g., presolvers that provide fast algorithms that
1205 * usually have a high impact (i.e., remove lots of variables or tighten bounds of many variables) should have a timing FAST.
1206 * If a presolving method implements different algorithms of different complexity, it may also get multiple timings and check the timing
1207 * internally in the \ref CONSPRESOL callback to decide which algorithms to run.
1208 *
1209 * \par CONSHDLR_MAXPREROUNDS: the default maximal number of presolving rounds the constraint handler participates in.
1210 * The preprocessing is executed in rounds.
1211 * If enough changes have been applied to the model, an additional preprocessing round is performed.
1212 * The MAXPREROUNDS parameter of a constraint handler denotes the maximal number of preprocessing rounds the constraint
1213 * handler participates in.
1214 * A value of -1 means that there is no limit on the number of rounds.
1215 * A value of 0 means the preprocessing callback of the constraint handler is disabled.
1216 *
1217 *
1218 *
1219 * @section CONS_DATA Constraint Data and Constraint Handler Data
1220 *
1221 * Below the header "Data structures" you can find two structs called "struct SCIP_ConsData" and
1222 * "struct SCIP_ConshdlrData".
1223 * If you are using C++, you only need to define the "struct SCIP_ConsData".
1224 * The constraint handler data must be implemented as member variables of your constraint handler class.
1225 * \n
1226 * The constraint data are the information that is needed to define a single constraint of the constraint handler's
1227 * constraint class.
1228 * For example, the data of a knapsack constraint would consist of a list of variables, a list of weights, and
1229 * the capacity of the knapsack.
1230 * The data of a subtour constraint consists of the graph on which the problem is defined.
1231 * In the graph, each edge should be linked to the corresponding binary problem variable.
1232 * \n
1233 * The constraint handler data are additional variables, that belong to the constraint handler itself and which are
1234 * not specific to a single constraint.
1235 * For example, you can use these data to store parameters of the constraint handler or statistical information.
1236 * The constraint handler data are optional.
1237 * You can leave the struct empty.
1238 *
1239 *
1240 * @section CONS_INTERFACE Interface Methods
1241 *
1242 * At the bottom of "cons_subtour.c" you can find three interface methods, that also appear in "cons_subtour.h".
1243 * These are SCIPincludeConshdlrSubtour(), SCIPcreateConsSubtour(), and SCIPcreateConsSubtourBasic().
1244 * \n
1245 * The method SCIPincludeConshdlrSubtour() only has to be adjusted slightly.
1246 * It is responsible for notifying SCIP of the presence of the constraint handler by calling the method
1247 * SCIPincludeConshdlr().
1248 * It is called by the user, if (s)he wants to include the constraint handler, i.e., if (s)he wants to make
1249 * the constraint handler available to the model, and looks like this:
1250 * \dontinclude src/scip/cons_knapsack.c
1251 * -# If you are using constraint handler data, you have to <b>allocate the memory for the data</b> at this point.
1252 * You also have to initialize the fields in struct SCIP_ConshdlrData afterwards.
1580 * The CONSINITLP callback is executed before the first LP relaxation is solved.
1581 * It should add the LP relaxations of all "initial" constraints to the LP. The method should scan the constraints
1582 * array for constraints that are marked initial via calls to SCIPconsIsInitial() and put the LP relaxation
1583 * of all initial constraints to the LP with calls to SCIPaddCut().
1584 *
1585 * @subsection CONSSEPALP
1586 *
1587 * The CONSSEPALP callback is executed during the price-and-cut loop of the subproblem processing.
1588 * It should try to generate cutting planes for the constraints of the constraint handler in order to separate
1589 * the current LP solution.
1590 * The method is called in the LP solution loop, which means that a valid LP solution exists.
1591 *
1592 * Usually, a separation callback searches and produces cuts, that are added with a call to SCIPaddCut().
1593 * If the cut should be remembered in the global cut pool, it may also call SCIPaddPoolCut().
1594 * However, the callback may also produce domain reductions or add other constraints.
1595 *
1596 * The CONSSEPALP callback has the following options:
1597 * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
1598 * - adding an additional constraint (result SCIP_CONSADDED)
1599 * - reducing a variable's domain (result SCIP_REDUCEDDOM)
1600 * - adding a cutting plane to the LP (result SCIP_SEPARATED)
1601 * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
1602 * (result SCIP_DIDNOTFIND)
1603 * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
1604 * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
1605 * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
1606 *
1607 * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1608 * CONSHDLR_SEPAFREQ, CONSHDLR_SEPAPRIORITY, and CONSHDLR_DELAYSEPA, which influence the behaviour of SCIP
1609 * calling CONSSEPALP.
1610 *
1611 * @subsection CONSSEPASOL
1612 *
1613 * The CONSSEPASOL callback is executed during separation loop on arbitrary primal solutions.
1614 * It should try to generate cutting planes for the constraints of the constraint handler in order to separate
1615 * the given primal solution.
1616 * The method is not called in the LP solution loop, which means that there is no valid LP solution.
1617 *
1618 * Usually, a separation callback searches and produces cuts, that are added with a call to SCIPaddCut().
1619 * If the cut should be remembered in the global cut pool, it may also call SCIPaddPoolCut().
1620 * However, the callback may also produce domain reductions or add other constraints.
1621 *
1622 * The CONSSEPASOL callback has the following options:
1623 * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
1624 * - adding an additional constraint (result SCIP_CONSADDED)
1625 * - reducing a variable's domain (result SCIP_REDUCEDDOM)
1626 * - adding a cutting plane to the LP (result SCIP_SEPARATED)
1627 * - stating that the separator searched, but did not find domain reductions, cutting planes, or cut constraints
1628 * (result SCIP_DIDNOTFIND)
1629 * - stating that the separator was skipped (result SCIP_DIDNOTRUN)
1630 * - stating that the separator was skipped, but should be called again (result SCIP_DELAYED)
1631 * - stating that a new separation round should be started without calling the remaining separator methods (result SCIP_NEWROUND)
1632 *
1633 * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1634 * CONSHDLR_SEPAFREQ, CONSHDLR_SEPAPRIORITY, and CONSHDLR_DELAYSEPA, which influence the behaviour of SCIP
1635 * calling CONSSEPASOL.
1636 *
1637 * @subsection CONSENFORELAX
1638 *
1639 * The CONSENFORELAX callback is similar to the CONSENFOLP and CONSENFOPS callbacks, but deals with relaxation solutions.
1640 *
1641 * If the best bound computed by a relaxator that includes the whole LP is strictly better than the bound of the LP itself,
1642 * the corresponding relaxation solution will get enforced. Therefore the CONSENFORELAX callback will only be called for
1643 * solutions that satisfy all active LP-constraints.
1644 *
1645 * Like the ENFOLP and ENFOPS callbacks, the ENFORELAX callback has to check whether the solution given in sol satisfies
1646 * all the constraints of the constraint handler. Since the callback is only called for relaxators including the whole LP,
1647 * cuts may be added with a result of SCIP_SEPARATED, like in the ENFOLP callback. It is also possible to return
1648 * SCIP_SOLVELP if the relaxation solution is invalid for some reason and the LP should be solved instead.
1649 *
1650 * Note that the CONSENFORELAX callback is only relevant if relaxators are used. Since the basic distribution of the
1651 * SCIP Optimization Suite does not contain any relaxators, this callback can be ignored unless any relaxators are added
1652 * via user-plugins.
1653 *
1654 * @subsection CONSPROP
1655 *
1656 * The CONSPROP callback is called during the subproblem processing.
1657 * It should propagate the constraints, which means that it should infer reductions in the variables' local bounds
1658 * from the current local bounds.
1659 * This technique, which is the main workhorse of constraint programming, is called "node preprocessing" in the
1660 * Integer Programming community.
1661 *
1662 * The CONSPROP callback has the following options:
1663 * - detecting that the node is infeasible in the variables' bounds and can be cut off (result SCIP_CUTOFF)
1664 * - reducing a variable's domain (result SCIP_REDUCEDDOM)
1665 * - stating that the propagator searched, but did not find domain reductions, cutting planes, or cut constraints
1666 * (result SCIP_DIDNOTFIND)
1667 * - stating that the propagator was skipped (result SCIP_DIDNOTRUN)
1668 * - stating that the propagator was skipped, but should be called again (result SCIP_DELAYED)
1669 *
1670 * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1671 * CONSHDLR_PROPFREQ, CONSHDLR_DELAYPROP, and CONSHDLR_PROP_TIMING, which influence the behaviour of SCIP
1672 * calling CONSPROP.
1673 *
1674 * @subsection CONSRESPROP
1675 *
1676 * If the constraint handler should support \ref CONF "conflict analysis", it has to supply a CONSRESPROP method.
1677 * It also should call SCIPinferVarLbCons() or SCIPinferVarUbCons() in domain propagation instead of SCIPchgVarLb() or
1678 * SCIPchgVarUb() in order to deduce bound changes on variables.
1679 * In the SCIPinferVarLbCons() and SCIPinferVarUbCons() calls, the handler provides the constraint that deduced the
1680 * variable's bound change, and an integer value <code>inferinfo</code> that can be arbitrarily chosen.
1681 *
1682 * The propagation conflict resolving method CONSRESPROP must then be implemented to provide the "reasons" for the bound
1683 * changes, i.e., the bounds of variables at the time of the propagation, which forced the constraint to set the
1684 * conflict variable's bound to its current value. It can use the <code>inferinfo</code> tag to identify its own propagation rule
1685 * and thus identify the "reason" bounds. The bounds that form the reason of the assignment must then be provided by
1686 * calls to SCIPaddConflictLb() and SCIPaddConflictUb() in the propagation conflict resolving method.
1687 *
1688 * <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
1689 * need more information to efficiently infer the original propagation steps that lead to the conflict. This would,
1690 * however, require too much space. In the extreme, the original propagation steps have to be repeated.
1691 *
1692 * 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
1693 * 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
1694 * variables are 0.0). It uses <code>SCIPinferVarLbCons(scip, z, 1.0, c, 0)</code> to apply this assignment (an
1695 * inference information tag is not needed by the constraint handler and is set to 0). In the conflict analysis, the
1696 * constraint handler may be asked to resolve the lower bound change on \f$z\f$ with constraint \f$c\f$, that was
1697 * applied at a time given by a bound change index "bdchgidx". With a call to <code>SCIPvarGetLbAtIndex(z,
1698 * bdchgidx)</code>, the handler can find out, that the lower bound of variable \f$z\f$ was set to 1.0 at the given
1699 * point of time, and should call <code>SCIPaddConflictUb(scip, x, bdchgidx)</code> and <code>SCIPaddConflictUb(scip, y,
1700 * 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
1701 * the deduction of the lower bound of \f$z\f$.
1702 *
1703 * If conflict analysis should not be supported, the method has to set the result code to SCIP_DIDNOTFIND. Although
1704 * this is a viable approach to circumvent the implementation of the usually rather complex conflict resolving method, it
1705 * will make the conflict analysis less effective. We suggest to first omit the conflict resolving method and check how
1706 * effective the \ref CONSPROP "propagation method" is. If it produces a lot of propagations for your application, you definitely should
1707 * consider implementing the conflict resolving method.
1708 *
1709 * @subsection CONSPRESOL
1710 *
1711 * The CONSPRESOL callback is called during preprocessing.
1712 * It should try to tighten the domains of the variables, tighten the coefficients of the constraints of the constraint
1713 * handler, delete redundant constraints, aggregate and fix variables if possible, and upgrade constraints to more
1714 * specific types.
1715 *
1716 * If the CONSPRESOL callback applies changes to the constraint data, you also have to implement the \ref CONSTRANS callback
1717 * in order to copy the constraint data to the transformed problem space and protect the original problem from the
1718 * preprocessing changes.
1719 *
1720 * To inform SCIP that the presolving method found a reduction the result pointer has to be set in a proper way.
1721 * The following options are possible:
1722 *
1723 * - SCIP_UNBOUNDED : at least one variable is not bounded by any constraint in objective direction
1724 * - SCIP_CUTOFF : at least one constraint is infeasible in the variable's bounds
1725 * - SCIP_SUCCESS : the presolver found a reduction
1726 * - SCIP_DIDNOTFIND : the presolver searched, but did not find a presolving change
1727 * - SCIP_DIDNOTRUN : the presolver was skipped
1728 * - SCIP_DELAYED : the presolver was skipped, but should be called again
1729 *
1730 * Please see also the @ref CONS_ADDITIONALPROPERTIES section to learn about the properties
1731 * CONSHDLR_PRESOLTIMING and CONSHDLR_MAXPREROUNDS, which influence the behaviour of SCIP
1732 * calling CONSPRESOL.
1733 *
1734 * @subsection CONSACTIVE
1735 *
1736 * The CONSACTIVE callback method is called each time a constraint of the constraint handler is activated.
1737 * For example, if a constraint is added locally to a subproblem, the CONSACTIVE callback is called whenever the
1738 * search enters the subtree where the constraint exists.
1739 *
1740 * @subsection CONSDEACTIVE
1741 *
1742 * The CONSDEACTIVE callback method is called each time a constraint of the constraint handler is deactivated.
1743 * For example, if a constraint is added locally to a subproblem, the CONSDEACTIVE callback is called whenever the
1744 * search leaves the subtree where the constraint exists.
1745 *
1746 * @subsection CONSENABLE
1747 *
1748 * The CONSENABLE callback method is called each time a constraint of the constraint handler is enabled.
1749 * Constraints might be active without being enabled. In this case, only the feasibility checks are executed,
1750 * but domain propagation and separation is skipped.
1751 *
1752 * @subsection CONSDISABLE
1753 *
1754 * The CONSDISABLE callback method is called each time a constraint of the constraint handler is disabled.
1755 *
1756 * @subsection CONSPRINT
1757 *
1758 * The CONSPRINT callback method is called, when the user asks SCIP to display the problem to the screen
1759 * or save the problem into a file. This is, however, only the case if the user requested the CIP format.
1760 * For more details about reading and writing with SCIP we refer to the \ref READER "file readers". In this
1761 * callback method the constraint handler should display the data of the constraint in an appropriate form.
1762 * The output format that is defined by the CONSPRINT callbacks is called CIP format.
1763 * In later versions of SCIP, the constraint handlers should also be able to parse (i.e., read) constraints
1764 * which are given in CIP format.
1765 *
1766 * @subsection CONSCOPY
1767 *
1768 * The CONSCOPY callback method is used whenever constraints should be copied from one SCIP instance into another SCIP
1769 * instance. This method comes with the necessary parameters to do so, most importantly with a mapping of the variables of the
1770 * source SCIP instance to the corresponding variables of the target SCIP instance, and a mapping for the constraints
1771 * in the same way. For a complete list of all arguments of this callback method see type_cons.h.
1772 *
1773 * To get the corresponding target variable of a given source variable, you can use the variable map directly:
2242 * You also have to initialize the fields in struct SCIP_PresolData afterwards. For freeing the
2243 * presolver data, see \ref PRESOLFREE.
2244 *
2245 * You may also add user parameters for your presolver, see \ref PARAM for how to add user parameters and
2246 * the method SCIPincludePresolTrivial() in src/scip/presol_trivial.c for an example.
2247 *
2248 *
2249 * @section PRESOL_FUNDAMENTALCALLBACKS Fundamental Callback Methods of a Presolver
2250 *
2251 * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
2252 * an operational algorithm.
2253 * They are passed together with the presolver itself to SCIP using SCIPincludePresol() or SCIPincludePresolBasic(),
2254 * see @ref PRESOL_INTERFACE.
2255 *
2256 * Presolver plugins have only one fundamental callback method, namely the @ref PRESOLEXEC method.
2257 * This method has to be implemented for every presolver; the other callback methods are optional.
2258 * In the C++ wrapper class scip::ObjPresol, the scip_exec() method (which corresponds to the PRESOLEXEC callback) is a virtual
2259 * abstract member function.
2260 * You have to implement it in order to be able to construct an object of your presolver class.
2261 *
2262 * Additional documentation for the callback methods, in particular to their input parameters,
2263 * can be found in type_presol.h.
2264 *
2265 * @subsection PRESOLEXEC
2266 *
2267 * The PRESOLEXEC callback is called inside the presolving loop and should perform the actual presolving reductions.
2268 * It should inspect the problem instance at hand and simplify it by tightening bounds of variables, aggregating or fixing
2269 * variables, changing the type of variables, modifying the graph that represents the instance of your application, and
2270 * the like.
2271 *
2272 * Typical methods called by a presolver are, for example, SCIPchgVarType(), SCIPfixVar(), SCIPaggregateVars(), SCIPtightenVarLb(),
2273 * and SCIPtightenVarUb().
2274 *
2275 *
2276 * @section PRESOL_ADDITIONALCALLBACKS Additional Callback Methods of a Presolver
2277 *
2278 * The additional callback methods do not need to be implemented in every case. However, some of them have to be
2279 * implemented for most applications, they can be used, for example, to initialize and free private data.
2280 * Additional callbacks can either be passed directly with SCIPincludePresol() to SCIP or via specific
2281 * <b>setter functions</b> after a call of SCIPincludePresolBasic(), see also @ref PRESOL_INTERFACE.
2282 *
2283 * @subsection PRESOLFREE
2284 *
2285 * 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.
2286 * This can be done by the following procedure:
2331 * Separators are used to generate general purpose cutting planes.
2332 * Constraint based cutting planes, the second type of cutting planes in SCIP, are separated in the CONSSEPALP and
2333 * CONSSEPASOL callback methods of the constraint handlers, see \ref CONSSEPALP and \ref CONSSEPASOL. These cuts are
2334 * valid inequalities or even facets of the polyhedron described by a single constraint or a subset of the constraints of
2335 * a single constraint class. In contrast, general purpose cuts do not require or exploit any knowledge about the
2336 * underlying problem structure but use only the current LP relaxation and the integrality conditions. See also
2337 * "When should I implement a constraint handler, when should I implement a separator?" on \ref FAQ.
2338 * \n
2339 * A complete list of all separators contained in this release can be found \ref SEPARATORS "here".
2340 *
2341 * We now explain how users can add their own separators.
2342 * Take the separator for the class of Gomory mixed integer inequalities (src/scip/sepa_gomory.c) as an example.
2343 * As all other default plugins, it is written in C. C++ users can easily adapt the code by using the scip::ObjSepa wrapper
2344 * base class and implement the scip_...() virtual methods instead of the SCIP_DECL_SEPA... callback methods.
2345 *
2346 * Additional documentation for the callback methods of a separator, in particular for the input parameters,
2347 * can be found in the file type_sepa.h.
2348 *
2349 * Here is what you have to do to implement a separator:
2350 * -# Copy the template files src/scip/sepa_xyz.c and src/scip/sepa_xyz.h into files "sepa_myseparator.c"
2351 * and "sepa_myseparator.h".
2352 \n
2353 * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2354 * -# Use SCIPincludeSepaMyseparator() in order to include the separator into your SCIP instance,
2355 * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
2356 * -# Open the new files with a text editor and replace all occurrences of "xyz" by "myseparator".
2357 * -# Adjust the properties of the separator (see \ref SEPA_PROPERTIES).
2358 * -# Define the separator data (see \ref SEPA_DATA). This is optional.
2359 * -# Implement the interface methods (see \ref SEPA_INTERFACE).
2360 * -# Implement the fundamental callback methods (see \ref SEPA_FUNDAMENTALCALLBACKS).
2361 * -# Implement the additional callback methods (see \ref SEPA_ADDITIONALCALLBACKS). This is optional.
2362 *
2363 *
2364 * @section SEPA_PROPERTIES Properties of a Separator
2365 *
2366 * At the top of the new file "sepa_myseparator.c", you can find the separator properties.
2367 * These are given as compiler defines.
2368 * In the C++ wrapper class, you have to provide the separator properties by calling the constructor
2369 * of the abstract base class scip::ObjSepa from within your constructor.
2370 * The properties you have to set have the following meaning:
2371 *
2372 * \par SEPA_NAME: the name of the separator.
2373 * This name is used in the interactive shell to address the separator.
2374 * Additionally, if you are searching for a separator with SCIPfindSepa(), this name is looked up.
2375 * Names have to be unique: no two separators may have the same name.
2376 *
2377 * \par SEPA_DESC: the description of the separator.
2378 * This string is printed as a description of the separator in the interactive shell.
2379 *
2380 * \par SEPA_PRIORITY: the priority of the separator.
2381 * In each separation round during the price-and-cut loop of the subproblem processing or the separation loop
2382 * of the primal solution separation, the separators and separation methods of the constraint handlers are called in
2383 * a predefined order, which is given by the priorities of the separators and the separation priorities
2384 * of the constraint handlers (see \ref CONS_PROPERTIES).
2385 * First, the separators with non-negative priority are called in the order of decreasing priority.
2386 * Next, the separation methods of the constraint handlers are called in the order of decreasing separation
2387 * priority.
2388 * Finally, the separators with negative priority are called in the order of decreasing priority. An easy way to list the
2389 * priorities of all separators and constraint handlers is to type "display separators" and "display conshdlrs" in
2390 * the interactive shell.
2391 * \n
2392 * The priority of the separator should be set according to the complexity of the cut separation algorithm and the
2393 * impact of the resulting cuts: separators that provide fast algorithms that usually have a high impact (i.e., cut off
2394 * a large portion of the LP relaxation) should have a high priority.
2395 * See \ref SEPAEXECLP and \ref SEPAEXECSOL for further details of the separation callbacks.
2396 *
2397 * \par SEPA_FREQ: the default frequency for separating cuts.
2398 * The frequency defines the depth levels at which the separation methods \ref SEPAEXECLP and \ref SEPAEXECSOL are called.
2399 * For example, a frequency of 7 means, that the separation callback is executed for subproblems that are in depth
2400 * 0, 7, 14, ... of the branching tree. A frequency of 0 means, that the separation method is only called at the root node.
2401 * A frequency of -1 disables the separator.
2402 * \n
2403 * The frequency can be adjusted by the user. This property of the separator only defines the default value of the frequency.
2404 * If you want to have a more flexible control of when to execute the separation algorithm, you have to assign
2405 * a frequency of 1 and implement a check at the beginning of your separation methods whether you really want to execute
2406 * the separation or not. If you do not want to execute it, set the result code of
2407 * \ref SEPAEXECLP and \ref SEPAEXECSOL to SCIP_DIDNOTRUN.
2408 *
2409 * \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.
2410 * At the current branch-and-bound node, the relative distance from its dual bound (local dual bound)
2411 * to the primal bound compared to the best node's dual bound (global dual bound) is considered. The separation method
2412 * of the separator will only be applied at the current node if this relative distance does not exceed SEPA_MAXBOUNDDIST.
2413 * \n
2414 * For example, if the global dual bound is 50 and the primal bound is 60, SEPA_MAXBOUNDDIST = 0.25 means that separation
2415 * 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
2416 * than or equal to 52.5.
2417 * \n
2418 * In particular, the values 0.0 and 1.0 mean that separation is applied at the current best node only or at all
2419 * nodes, respectively. Since separation seems to be most important to apply at nodes that define to the global
2420 * dual bound, 0.0 is probably a good choice for SEPA_MAXBOUNDDIST.
2421 * Note that separators with a frequency of SEPA_FREQ = 0 are only applied at the root node.
2422 * Obviously, at the root node the local dual bound is equal to the global dual bound and thus, the separator is called
2423 * for any value of SEPA_MAXBOUNDDIST.
2424 *
2425 * \par SEPA_USESSUBSCIP: Does the separator use a secondary SCIP instance?
2426 * Some heuristics and separators solve MIPs or SAT problems and use a secondary SCIP instance. Examples are
2427 * Large Neighborhood Search heuristics such as RINS and Local Branching or the CGMIP separator. To avoid recursion,
2428 * these plugins usually deactivate all other plugins that solve MIPs. If a separator uses a secondary SCIP instance,
2429 * this parameter has to be TRUE and it is recommended to call SCIPsetSubscipsOff() for the secondary SCIP instance.
2430 *
2431 * \par SEPA_DELAY: the default for whether the separation method should be delayed, if other separators or constraint handlers found cuts.
2432 * If the separator's separation method is marked to be delayed, it is only executed after no other separator
2433 * or constraint handler found a cut during the price-and-cut loop.
2434 * If the separation method of the separator is very expensive, you may want to mark it to be delayed until all cheap
2435 * separation methods have been executed.
2436 *
2437 * @section SEPA_DATA Separator Data
2438 *
2439 * Below the header "Data structures" you can find a struct which is called "struct SCIP_SepaData".
2440 * In this data structure, you can store the data of your separator. For example, you should store the adjustable
2441 * parameters of the separator in this data structure. In a separator, user parameters for the maximal number of
2442 * separation rounds per node and for the maximal number of cuts separated per separation round might be useful.
2443 * If you are using C++, you can add separator data as usual as object variables to your class.
2444 * \n
2445 * Defining separator data is optional. You can leave the struct empty.
2446 *
2447 * @section SEPA_INTERFACE Interface Methods
2448 *
2449 * At the bottom of "sepa_myseparator.c", you can find the interface method SCIPincludeSepaMyseparator(),
2450 * which also appears in "sepa_myseparator.h"
2451 * SCIPincludeSepaMyseparator() is called by the user, if (s)he wants to include the separator,
2452 * i.e., if (s)he wants to use the separator in his/her application.
2453 *
2454 * This method only has to be adjusted slightly.
2455 * It is responsible for notifying SCIP of the presence of the separator. For this, you can either call SCIPincludeSepa(),
2456 * or SCIPincludeSepaBasic() since SCIP version 3.0. In the latter variant, \ref SEPA_ADDITIONALCALLBACKS "additional callbacks"
2457 * must be added via setter functions as, e.g., SCIPsetSepaCopy(). We recommend this latter variant because
2458 * it is more stable towards future SCIP versions which might have more callbacks, whereas source code using the first
2459 * variant must be manually adjusted with every SCIP release containing new callbacks for separators in order to compile.
2460 *
2461 * If you are using separator data, you have to allocate the memory
2462 * for the data at this point. You can do this by calling:
2590 * Propagators are used to tighten the domains of the variables. Like for cutting planes, there are two different types
2591 * of domain propagations. Constraint based (primal) domain propagation algorithms are part of the corresponding
2592 * constraint handlers, see \ref CONSPROP. In contrast, domain propagators usually provide dual propagations, i.e.,
2593 * propagations that can be applied using the objective function and the current best known primal solution. This
2594 * section deals with such propagators.
2595 *
2596 * A complete list of all propagators contained in this release can be found \ref PROPAGATORS "here".
2597 *
2598 * We now explain how users can add their own propagators. Take the pseudo objective function propagator
2599 * (src/scip/prop_pseudoobj.c) as an example. As all other default plugins, it is written in C. C++ users can easily
2600 * adapt the code by using the scip::ObjProp wrapper base class and implement the @c scip_...() virtual methods instead
2601 * of the @c SCIP_DECL_PROP... callback methods.
2602 *
2603 * Additional documentation for the callback methods of a propagator can be found in the file type_prop.h.
2604 *
2605 * Here is what you have to do to implement a propagator:
2606 * -# Copy the template files src/scip/prop_xyz.c and src/scip/prop_xyz.h into files named "prop_mypropagator.c"
2607 * and "prop_mypropagator.h".
2608 * \n
2609 * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2610 * -# Use SCIPincludePropMypropagator() in order to include the propagator into your SCIP instance,
2611 * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
2612 * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mypropagator".
2613 * -# Adjust the properties of the propagator (see \ref PROP_PROPERTIES).
2614 * -# Define the propagator data (see \ref PROP_DATA). This is optional.
2615 * -# Implement the interface methods (see \ref PROP_INTERFACE).
2616 * -# Implement the fundamental callback methods (see \ref PROP_FUNDAMENTALCALLBACKS).
2617 * -# Implement the additional callback methods (see \ref PROP_ADDITIONALCALLBACKS). This is optional.
2618 *
2619 * @section PROP_PROPERTIES Properties of a Propagator
2620 *
2621 * At the top of the new file "prop_mypropagator.c" you can find the propagator properties. These are given as compiler
2622 * defines. The presolving-related properties are optional,
2623 * they only have to be defined if the propagator supports presolving routines.
2624 * In the C++ wrapper class, you have to provide the propagator properties by calling the constructor of the
2625 * abstract base class scip::ObjProp from within your constructor. The properties you have the following meaning:
2626 *
2627 * @subsection PROP_FUNDAMENTALPROPERTIES Fundamental properties of a propagator
2628 *
2629 * \par PROP_NAME: the name of the propagator.
2630 * This name is used in the interactive shell to address the propagator. Additionally, if you are searching for a
2631 * propagator with SCIPfindProp(), this name is searched for. Names have to be unique: no two propagators may have the
2632 * same name.
2633 *
2634 * \par PROP_DESC: the description of the propagator.
2635 * This string is printed as a description of the propagator in the interactive shell.
2636 *
2637 * \par PROP_PRIORITY: the priority of the propagator.
2638 * In each propagation round, the propagators and propagation methods of the constraint handlers are called in a
2639 * predefined order, which is given by the priorities of the propagators and the check priorities of the constraint
2640 * handlers. First, the propagators with non-negative priority are called in order of decreasing priority. Next, the
2641 * propagation methods of the different constraint handlers are called in order of decreasing check priority. Finally,
2642 * the propagators with negative priority are called in order of decreasing priority. \n The priority of the
2643 * propagators should be set according to the complexity of the propagation algorithm and the impact of the domain
2644 * propagations: propagators providing fast algorithms that usually have a high impact (i.e., tighten many bounds)
2645 * should have a high priority.
2646 *
2647 * \par PROP_FREQ: the default frequency for propagating domains.
2648 * The frequency defines the depth levels at which the propagation method \ref PROPEXEC is called. For example, a
2649 * frequency of 7 means, that the propagation callback is executed for subproblems that are in depth 0, 7, 14, ... of
2650 * the branching tree. A frequency of 0 means that propagation is only applied in preprocessing and at the root node. A
2651 * frequency of -1 disables the propagator.
2652 * \n
2653 * The frequency can be adjusted by the user. This property of the propagator only defines the default value of the
2654 * frequency.\n
2655 * <b>Note:</b> If you want to have a more flexible control of when to execute the propagation algorithm, you have to
2656 * assign a frequency of 1 and implement a check at the beginning of your propagation algorithm whether you really want
2657 * to execute the domain propagation or not. If you do not want to execute it, set the result code to SCIP_DIDNOTRUN.
2658 *
2659 * \par PROP_DELAY: the default for whether the propagation method should be delayed, if other propagators or constraint handlers found domain reductions.
2660 * If the propagator's propagation method is marked to be delayed, it is only executed after no other propagator or
2661 * constraint handler found a domain reduction in the current iteration of the domain propagation loop. If the
2662 * propagation method of the propagator is very expensive, you may want to mark it to be delayed until all cheap
2663 * propagation methods have been executed.
2664 *
2665 * \par PROP_TIMING: the timing mask of the propagator.
2666 * SCIP calls the domain propagation routines at different places in the node processing loop.
2667 * This property indicates at which places the propagator is called.
2668 * Possible values are defined in type_timing.h and can be concatenated, e.g., as in SCIP_PROPTIMING_ALWAYS.
2872 * Branching rules are used to split the problem at the current node into smaller subproblems. Branching rules can be called at three
2873 * different occasions, which is why they have three different execution methods (see \ref
2874 * BRANCHRULE_ADDITIONALCALLBACKS). Branching is performed if:
2875 * - the LP solution of the current problem is fractional. In this case, the integrality constraint handler calls the
2876 * \ref BRANCHEXECLP methods of the branching rules.
2877 * - the list of external branching candidates is not empty. This will only be the case if branching candidates were added
2878 * by a user's \ref RELAX "relaxation handler" or \ref CONS "constraint handler" plugin, calling SCIPaddExternBranchCand().
2879 * These branching candidates should be processed by the \ref BRANCHEXECEXT method.
2880 * - if an integral solution violates one or more constraints and this infeasibility could not be resolved in the callback methods
2881 * \ref CONSENFOLP and \ref CONSENFOPS of the corresponding constraint handlers. In this case, the \ref BRANCHEXECPS method will be called. This is the
2882 * 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
2883 * branching on pseudo solutions works as a last resort.
2884 *
2885 * The idea of branching rules is to take a global view on the problem. In contrast, branching paradigms which are
2886 * specific to one type of constraint are best implemented within the enforcement callbacks of your constraint handler.
2887 * See, e.g., the constraint specific branching rules provided by the constraint handlers for special ordered sets
2888 * (src/scip/cons_sos{1,2}.c)).
2889 * \n
2890 * All branching rules that come with the default distribution of SCIP create two subproblems by splitting a single
2891 * variable's domain. It is, however, fully supported to implement much more general branching schemes, for example by
2892 * creating more than two subproblems, or by adding additional constraints to the subproblems instead of tightening the
2893 * domains of the variables.
2894 * \n
2895 * A complete list of all branching rules contained in this release can be found \ref BRANCHINGRULES "here".
2896 *
2897 * We now explain how users can add their own branching rules. Take the most infeasible LP branching rule
2898 * (src/scip/branch_mostinf.c) as an example. As all other default plugins, it is written in C. C++ users can easily
2899 * adapt the code by using the scip::ObjBranchrule wrapper base class and implement the scip_...() virtual methods instead of
2900 * the SCIP_DECL_BRANCH... callback methods.
2901 *
2902 * Additional documentation for the callback methods of a branching rule can be found in the file type_branch.h.
2903 *
2904 * Here is what you have to do to implement a branching rule:
2905 * -# Copy the template files src/scip/branch_xyz.c and src/scip/branch_xyz.h into files named
2906 * "branch_mybranchingrule.c" and "branch_mybranchingrule.h".
2907 * \n
2908 * Make sure to adjust your Makefile such that these files are compiled and linked to your project.
2909 * -# Use SCIPincludeBranchruleMybranchingrule() in order to include the branching rule into your SCIP instance,
2910 * e.g., in the main file of your project (see, e.g., src/cmain.c in the Binpacking example).
2911 * -# Open the new files with a text editor and replace all occurrences of "xyz" by "mybranchingrule".
2912 * -# Adjust the properties of the branching rule (see \ref BRANCHRULE_PROPERTIES).
2913 * -# Define the branching rule data (see \ref BRANCHRULE_DATA). This is optional.
2914 * -# Implement the interface methods (see \ref BRANCHRULE_INTERFACE).
2915 * -# Implement the fundamental callback methods (see \ref BRANCHRULE_FUNDAMENTALCALLBACKS).
2916 * -# Implement the additional callback methods (see \ref BRANCHRULE_ADDITIONALCALLBACKS). This is optional.
2917 *
2918 *
2919 * @section BRANCHRULE_PROPERTIES Properties of a Branching Rule
2920 *
2921 * At the top of the new file "branch_mybranchingrule.c" you can find the branching rule properties.
2922 * These are given as compiler defines.
2923 * In the C++ wrapper class, you have to provide the branching rule properties by calling the constructor
2924 * of the abstract base class scip::ObjBranchrule from within your constructor.
2925 * The properties you have to set have the following meaning:
2926 *
2927 * \par BRANCHRULE_NAME: the name of the branching rule.
2928 * This name is used in the interactive shell to address the branching rule.
2929 * Additionally, if you are searching for a branching rule with SCIPfindBranchrule(), this name is looked up.
2930 * Names have to be unique: no two branching rules may have the same name.
2931 *
2932 * \par BRANCHRULE_DESC: the description of the branching rule.
2933 * This string is printed as a description of the branching rule in the interactive shell.
2934 *
2935 * \par BRANCHRULE_PRIORITY: the default value for the priority of the branching rule.
2936 * In the subproblem processing, the branching rules are called in decreasing order of their priority until
2937 * one succeeded to branch. Since most branching rules are able to generate a branching in all situations,
2938 * only the rule of highest priority is used. In combination with the BRANCHRULE_MAXDEPTH and
2939 * BRANCHRULE_MAXBOUNDDIST settings, however, interesting strategies can be easily employed. For example,
2940 * the user can set the priority of the "full strong branching" strategy to the highest value and assign the
2941 * second highest value to the "reliable pseudo cost" rule. If (s)he also sets the maximal depth for the
2942 * "full strong branching" to 5, in the top 5 depth levels of the search tree the "full strong branching" is
2943 * applied, while in the deeper levels "reliable pseudo cost branching" is used.
2944 * \n
2945 * Note that the BRANCHRULE_PRIORITY property only specifies the default value of the priority. The user can
2946 * change this value arbitrarily.
2947 *
2948 * \par BRANCHRULE_MAXDEPTH: the default value for the maximal depth level of the branching rule.
2949 * This parameter denotes the maximal depth level in the branch-and-bound tree up to which the branching method of the
2950 * branching rule will be applied. Use -1 for no limit.
2951 * \n
2952 * Note that this property only specifies the default value. The user can change this value arbitrarily.
2953 *
2954 * \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.
2955 * At the current branch-and-bound node, the relative distance from its dual bound (local dual bound)
2956 * to the primal bound compared to the best node's dual bound (global dual bound) is considered. The branching method of
2957 * the branching rule will only be applied at the node if this relative distance does not exceed BRANCHRULE_MAXBOUNDDIST.
2958 * \n
2959 * For example, if the global dual bound is 50 and the primal bound is 60, BRANCHRULE_MAXBOUNDDIST = 0.25 means that
2960 * 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
2961 * 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
2962 * current best node only or at all nodes, respectively.
2963 * \n
2964 * Note that the BRANCHRULE_MAXBOUNDDIST property only specifies the default value of the maximal bound distance.
2965 * The user can change this value arbitrarily.
2966 *
2967 *
2968 * @section BRANCHRULE_DATA Branching Rule Data
2969 *
2970 * Below the header "Data structures" you can find a struct which is called "struct SCIP_BranchruleData".
2971 * In this data structure, you can store the data of your branching rule. For example, you should store the adjustable
2972 * parameters of the branching rule in this data structure.
2973 * If you are using C++, you can add branching rule data as usual as object variables to your class.
2974 * \n
2975 * Defining branching rule data is optional. You can leave the struct empty.
4935 * You also have to initialize the fields in struct SCIP_NlpiData afterwards. For freeing the
4936 * NLPI data, see \ref NLPIFREE.
4937 *
4938 *
4939 * @section NLPI_FUNDAMENTALCALLBACKS Fundamental Callback Methods of an NLPI
4940 *
4941 * The fundamental callback methods of the plugins are the ones that have to be implemented in order to obtain
4942 * an operational algorithm. Currently, all NLPI callbacks are fundamental.
4943 *
4944 * Additional documentation of the callback methods, in particular to their input parameters,
4945 * can be found in type_nlpi.h.
4946 *
4947 * @subsection NLPICOPY
4948 *
4949 * The NLPICOPY callback is executed if the plugin should be copied, e.g., when a SCIP instance is copied.
4950 *
4951 * @subsection NLPIFREE
4952 *
4953 * The NLPIFREE callback is executed if the NLP solver interface data structure should be freed, e.g., when a SCIP instance is freed.
4954 *
4955 * @subsection NLPIGETSOLVERPOINTER
4956 *
4957 * The NLPIGETSOLVERPOINTER callback can be used to pass a pointer to a solver specific data structure to the user.
4958 *
4959 * @subsection NLPICREATEPROBLEM
4960 *
4961 * The NLPICREATEPROBLEM callback is executed if a particular NLP problem is to be created.
4962 * The callback method should initialize a SCIP_NlpiProblem struct here that corresponds to an empty NLP.
4963 *
4964 * @subsection NLPIFREEPROBLEM
4965 *
4966 * The NLPIFREEPROBLEMPOINTER callback is executed if a particular NLP problem is to be freed.
4967 * The callback method should free a SCIP_NlpiProblem struct here.
4968 *
4969 * @subsection NLPIGETPROBLEMPOINTER
4970 *
4971 * The NLPIGETPROBLEMPOINTER callback can be used to pass a pointer to a solver specific data structure of the NLP to the user.
4972 *
4973 * @subsection NLPIADDVARS
4974 *
4975 * The NLPIADDVARS callback is executed if a set of variables with lower and upper bounds and names should be added to a particular NLP.
4976 * The callback method must add the new variables behind the previously added variables, if any.
4977 * If NULL is given for the lower bounds arguments, -infinity is assumed as lower bound for each new variable.
4978 * If NULL is given for the upper bounds arguments, +infinity is assumed as upper bound for each new variable.
4979 * It is also permitted to use NULL for the names argument.
4980 *
4981 * @subsection NLPIADDCONSTRAINTS
4982 *
4983 * The NLPIADDCONSTRAINTS callback is executed if a set of constraints should be added to a particular NLP.
4984 * Constraints are specified by providing left and right hand sides, linear and quadratic coefficients, expression trees, and constraint names.
4985 * All of these arguments are optional, giving NULL for left hand sides corresponds to -infinity, giving NULL for right hand sides corresponds to +infinity.
4986 *
4987 * @subsection NLPISETOBJECTIVE
4988 *
4989 * The NLPISETOBJECTIVE callback is executed to set the objective function of a particular NLP.
4990 *
4991 * @subsection NLPICHGVARBOUNDS
4992 *
4993 * The NLPICHGVARBOUNDS callback is executed to change the bounds on a set of variables of an NLP.
4994 *
4995 * @subsection NLPICHGCONSSIDES
4996 *
4997 * The NLPICHGCONSSIDES callback is executed to change the sides on a set of constraints of an NLP.
4998 *
4999 * @subsection NLPIDELVARSET
5000 *
5001 * The NLPIDELVARSET callback is executed to delete a set of variables from an NLP.
5002 * The caller provides an array in which for each variable it is marked whether it should be deleted.
5003 * In the same array, the method should return the new position of each variable in the NLP, or -1 if it was deleted.
5004 *
5005 * @subsection NLPIDELCONSSET
5006 *
5007 * The NLPIDELCONSSET callback is executed to delete a set of constraints from an NLP.
5008 * The caller provides an array in which for each constraint it is marked whether it should be deleted.
5009 * In the same array, the method should return the new position of each constraint in the NLP, or -1 if it was deleted.
5010 *
5011 * @subsection NLPICHGLINEARCOEFS
5012 *
5013 * The NLPICHGLINEARCOEFS callback is executed to change the coefficients in the linear part of the objective function or a constraint of an NLP.
5014 *
5015 * @subsection NLPICHGQUADCOEFS
5016 *
5017 * The NLPICHGQUADCOEFS callback is executed to change the coefficients in the quadratic part of the objective function or a constraint of an NLP.
5018 *
5019 * @subsection NLPICHGEXPRTREE
5020 *
5021 * The NLPICHGEXPRTREE callback is executed to replace the expression tree of the objective function or a constraint of an NLP.
5022 *
5023 * @subsection NLPICHGNONLINCOEF
5024 *
5025 * 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.
5026 *
5027 * @subsection NLPICHGOBJCONSTANT
5028 *
5029 * The NLPICHGOBJCONSTANT callback is executed to change the constant offset of the objective function of an NLP.
5030 *
5031 * @subsection NLPISETINITIALGUESS
5032 *
5033 * The NLPISETINITIALGUESS callback is executed to provide primal and dual initial values for the variables and constraints of an NLP.
5034 * For a local solver, these values can be used as a starting point for the search.
5035 * 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).
5036 * In this case, the solver should clear previously set starting values and setup its own starting point.
5037 *
5038 * @subsection NLPISOLVE
5039 *
5040 * The NLPISOLVE callback is executed when an NLP should be solved.
5041 * The solver may use the initial guess provided by \ref NLPISETINITIALGUESS as starting point.
5042 * The status of the solving process and solution can be requested by
5047 * The NLPIGETSOLSTAT callback can be used to request the solution status (solved, infeasible, ...) after an NLP has been solved.
5048 *
5049 * @subsection NLPIGETTERMSTAT
5050 *
5051 * The NLPIGETTERMSTAT callback can be used to request the termination reason (normal, iteration limit, ...) after an NLP has been solved.
5052 *
5053 * @subsection NLPIGETSOLUTION
5054 *
5055 * The NLPIGETSOLUTION callback can be used to request the primal and dual solution values after an NLP solve.
5056 * The method should pass pointers to arrays of variable values to the caller.
5057 * 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.
5058 *
5059 * @subsection NLPIGETSTATISTICS
5060 *
5061 * The NLPIGETSTATISTICS callback can be used to request the statistical values (number of iterations, time, ...) after an NLP solve.
5062 * The method should fill the provided NLPSTATISTICS data structure.
5063 *
5064 * <!-- NLPIGETWARMSTARTSIZE, NLPIGETWARMSTARTMEMO, NLPISETWARMSTARTMEMO are not documented,
5065 since they are currently not used, not implemented, and likely to change with a next version. -->
5066 *
5067 * @subsection NLPIGETINTPAR
5068 *
5069 * The NLPIGETINTPAR callback can be used to request the value of an integer valued NLP parameter.
5070 *
5071 * @subsection NLPISETINTPAR
5072 *
5073 * The NLPISETINTPAR callback is executed to set the value of an integer valued NLP parameter.
5074 *
5075 * @subsection NLPIGETREALPAR
5076 *
5077 * The NLPIGETREALPAR callback can be used to request the value of a real valued NLP parameter.
5078 *
5079 * @subsection NLPISETREALPAR
5080 *
5081 * The NLPISETREALPAR callback is executed to set the value of a real valued NLP parameter.
5082 *
5083 * @subsection NLPIGETSTRINGPAR
5084 *
5085 * The NLPIGETSTRINGPAR callback can be used to request the value of a string valued NLP parameter.
5086 *
5087 * @subsection NLPISETSTRINGPAR
5088 *
5089 * The NLPISETSTRINGPAR callback is executed to set the value of a string valued NLP parameter.
5129 * The expression interpreter has to implement a set of interface method.
5130 * In your "exprinterpret_myexprinterpret.c", these methods are mostly dummy methods that return error codes.
5131 *
5132 * @subsection SCIPexprintGetName
5133 *
5134 * The SCIPexprintGetName method should return the name of the expression interpreter.
5135 *
5136 * @subsection SCIPexprintGetDesc
5137 *
5138 * The SCIPexprintGetDesc method should return a short description of the expression interpreter, e.g., the name of the developer of the code.
5139 *
5140 * @subsection SCIPexprintGetCapability
5141 *
5142 * The SCIPexprintGetCapability method should return a bitmask that indicates the capabilities of the expression interpreter,
5143 * i.e., whether it can evaluate gradients, Hessians, or do interval arithmetic.
5144 *
5145 * @subsection SCIPexprintCreate
5146 *
5147 * The SCIPexprintCreate method is called to create an expression interpreter data structure.
5148 * The method should initialize a "struct SCIP_ExprInt" here.
5149 *
5150 * @subsection SCIPexprintFree
5151 *
5152 * The SCIPexprintFree method is called to free an expression interpreter data structure.
5153 * The method should free a "struct SCIP_ExprInt" here.
5154 *
5155 * @subsection SCIPexprintCompile
5156 *
5157 * The SCIPexprintCompile method is called to initialize the data structures that are required to evaluate
5158 * a particular expression tree.
5159 * The expression interpreter can store data that is particular to a given expression tree in the tree by using
5160 * SCIPexprtreeSetInterpreterData().
5161 *
5162 * @subsection SCIPexprintFreeData
5163 *
5164 * The SCIPexprintFreeData method is called when an expression tree is freed.
5165 * The expression interpreter should free the given data structure.
5166 *
5167 * @subsection SCIPexprintNewParametrization
5168 *
5169 * The SCIPexprintNewParametrization method is called when the values of the parameters in a parametrized expression tree have changed.
5170 *
5171 * @subsection SCIPexprintEval
5172 *
5173 * The SCIPexprintEval method is called when the value of an expression represented by an expression tree should be computed for a point.
5174 *
5175 * @subsection SCIPexprintEvalInt
5176 *
5177 * 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.
5178 *
5179 * @subsection SCIPexprintGrad
5180 *
5181 * The SCIPexprintGrad method is called when the gradient of an expression represented by an expression tree should be computed for a point.
5182 *
5183 * @subsection SCIPexprintGradInt
5184 *
5185 * 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.
5189 * The SCIPexprintHessianSparsityDense method is called when the sparsity structure of the Hessian matrix should be computed and returned in dense form.
5190 *
5191 * @subsection SCIPexprintHessianDense
5192 *
5193 * The SCIPexprintHessianDense method is called when the Hessian of an expression represented by an expression tree should be computed for a point.
5372/**@page CONCSCIP How to use the concurrent solving mode
5373 *
5374 * @section Overview
5375 *
5376 * In \SCIP 4.0 a new feature has been added that allows to run multiple \SCIP instances with different settings
5377 * on one problem in parallel. To use this feature \SCIP has to be compiled with an additional make option to
5378 * enable the threading functionality (e.g. TPI=tny, see \ref MAKE).
5379 * Then, a concurrent solve can be started by using the <code>concurrentopt</code> command instead of the <code>optimize</code> command
5380 * in the \SCIP shell, or by calling the interface function SCIPsolveParallel().
5381 * To configure the behavior of the concurrent solving mode there are new parameters in the category <code>concurrent/</code>
5382 * and <code>parallel/</code> which will be explained here shortly.
5383 *
5384 * @section CONTROLNTHREADS Controlling the number of threads
5385 *
5386 * The parameters <code>parallel/maxnthreads</code> and <code>parallel/minnthreads</code> can be used to configure the number of threads
5387 * that sould be used for solving. \SCIP will try to use the configured maximum number of threads. If the
5388 * problem that is currently read is too large \SCIP will automatically use fewer threads, but never
5389 * go below the configured minimum number of threads.
5390 *
5391 * @section USEEMPHSETTINGS Using emphasis settings
5392 *
5393 * The parameters <code>concurrent/scip.../prefprio</code> configure which concurrent solvers should be used.
5394 * The concurrent solver <code>scip</code> will use the same settings as the \SCIP instance configured by the user.
5395 * The other concurrent solvers, e.g. <code>scip-feas</code>, will load the corresponding emphasis setting.
5396 * The behavior of the prefprio parameter is as follows: If it is set to 1.0 for <code>scip-feas</code> and
5397 * <code>scip-opti</code>, and to 0.0 for every other concurrent solver, then the threads will be evenly
5398 * 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
5399 * 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
5400 * and the latter will use 3 threads of the 4 available threads.
5404 * To use custom settings for the concurrent solvers there is the parameter <code>concurrent/paramsetprefix</code>. If custom parameters
5405 * 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).
5406 * The parameter settings must be named after the concurrent solvers, e.g. if only the concurrent solver <code>scip</code> is used
5407 * 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
5408 * starts at one for each of them, e.g. <code>scip-1</code> and <code>scip-feas-1</code>.
5866 * \arg <code>TIME</code> - time limit for each test instance in seconds [default: 3600]
5867 * \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]
5868 * \arg <code>THREADS</code> - the number of threads used for solving LPs, if the linked LP solver supports multithreading [default: 1]
5869 * \arg <code>VALGRIND</code> - run valgrind on the SCIP binary; errors and memory leaks found by valgrind are reported as fails [default: "false"]
5870 *
5871 *
5872 * @section COMPARE Comparing test runs for different settings
5873 *
5874 * Often test runs are performed on the basis of different settings. In this case, it is useful to
5875 * have a performance comparison. For this purpose, we can use the <code>allcmpres.sh</code> script in
5876 * the @c check directory.
5877 *
5878 * Suppose, we performed our test run with two different settings, say <code>fast.set</code> and
5879 * <code>slow.set</code>. Assuming that all other parameters (including the SCIP binary), were the same,
5880 * we may have the following <code>res</code>-files in the directory <code>scip/check/results/</code>
5992 * In this case, the test with respect to the number of found feasible solutions is irrelevant, since their number is
5993 * equal. In particular, the null hypothesis gets accepted (i.e., there is no difference in the settings - this is
5994 * marked by "X").
5995 *
5996 * With respect to the number of instances solved to optimality within the timelimit, we have that \f$0.005 < p <=
5997 * 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
5998 * settings perform differently; this is marked by "!". In the concrete case, we have 230 instances, all of which are
5999 * solved by setting \c S2, but only 224 by setting \c S1.
6000 *
6001 * @subsection Wilcoxon Wilcoxon signed rank test
6002 *
6003 * Assume that we compare two settings \c S1 and \c S2 with respect to their solution times (within the time limit). We
6004 * generate a sorted list of the ratios of the run times, where ratios that are (absolutely or relatively) within 1\%
6005 * of 1.0 are discarded, and ratios between 0.0 and 0.99 are replaced with their negative inverse in order to
6006 * obtain a symmetric distribution for the ratios around the origin.
6007 * We then assign ranks 1 to \c N to the remaining \c N data points in nondecreasing
6008 * order of their absolute ratio. This yields two groups \c G1
6009 * 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
6010 * setting \c S1 is faster). Then the sums of the ranks in groups \c G1 and \c G2 are computed, yielding values \c R1
6011 * and \c R2, respectively.
6012 *
6013 * The Wilcoxon test statistic is then
6014 * \f[
6015 * z = \frac{\min(R1, R2) - \frac{N(N+1)}{4}}{\sqrt{\frac{N(N+1)(2N+1)}{24}}},
6016 * \f]
6017 * which we assume to be (approximately) normally distributed (with zero mean) and allows to compute the probability
6018 * \f$p\f$ that one setting is faster than the other. (Note that for \f$N \leq 60\f$, we apply a correction by
6019 * subtracting 0.5 from the numerator).
6020 *
6021 * As an example consider the following output:
6022 * \code
6023 * Wilcoxon (time) z -0.1285, 0.05 <= p X
6024 * Wilcoxon (nodes) z -11.9154, p < 0.0005 !!!
6025 * \endcode
6026 * While the \f$z\f$-value is close to zero for the run time, it is extremely negative regarding the solving nodes. This latter
6027 * 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
6028 * nodes than setting \c S2 is negligible (this null hypothesis is rejected - marked by "!!!").
6029 *
6030 * However, the null hypothesis is not rejected with respect to the run time. In the concrete case, setting \c S1 has a
6031 * 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
6032 * 0.88. Still - the null hypothesis is not rejected.
6033 *
6034 * @section SOLVER Testing and Evaluating using GAMS
6035 *
6036 * Analogously to the target <code>test</code> there is another target to run automated tests with <a href="http://www.gams.com/">gams</a>
6037 * \code
6038 * make testgams GAMSSOLVER=xyz
6039 * \endcode
6040 * For this target, the option GAMSSOLVER has to be given to specify the name of a GAMS solver to run, e.g. GAMSSOLVER=SCIP.
6041 * Additional advanced options specific to this target are:
6042 * GAMS to specify the GAMS executable (default: gams),
6043 * GAP to specify a gap limit (default: 0.0),
6044 * CLIENTTMPDIR to specify a directory where GAMS should put its scratch files (default: /tmp),
6045 * 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).
6046 * The following options are NOT supported (and ignored): DISPFREQ, FEASTOL, LOCK.
6047 * 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).
6048 *
6049 * Note: This works only if the referred programs are installed globally on your machine.
6050 *
6051 * The above options like <code>TIME</code> are also available for gams.
6052 *
6053 * After the testrun there should be an <code>.out</code>, an <code>.err</code> and a <code>.res</code> file
6054 * with the same basename as described above.
6055 *
6056 * Furthermore you can also use the script <code>allcmpres.sh</code> for comparing results.
6116/**@page CHG3 Interface changes between SCIP 1.1 and SCIP 1.2
6117 *
6118 *
6119 * @section CHGCALLBACKS New and changed callbacks
6120 *
6121 * - The callback SCIP_DECL_PRICERREDCOST(x) in the \ref PRICER "pricers" has two new parameters:
6122 * - A <code>result</code> pointer determines whether the pricer guarantees that there exist no more variables. This allows for early branching.
6123 * - A pointer for providing a lower bound.
6124 *
6125 * - The \ref CONS "constraint handlers" have two new callback methods (see type_cons.h for more details).
6126 * - SCIP_DECL_CONSCOPY(x) - this method can be used to copy a constraint.
6127 * - SCIP_DECL_CONSPARSE(x) - this method can be used to parse a constraint in CIP format.
6128 *
6129 * @section CHGINTERFUNC New parameters in interface methods
6130 *
6131 * - SCIPcalcMIR() in scip.h has two new parameter "mksetcoefsvalid" and "sol". The parameter "mksetcoefsvalid" stores
6132 * whether the coefficients of the mixed knapsack set ("mksetcoefs") computed in SCIPlpCalcMIR() are valid. If the mixed knapsack constraint obtained after aggregating LP rows
6133 * 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.
6134 * The input parameter "sol" can be used to separate a solution different from the LP solution.
6135 *
6136 * - 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.
6137 *
6138 * @section MISCELLANEOUS Miscellaneous
6139 *
6140 * - A significant change for <b>C++ users</b> is that all include files of SCIP
6141 * automatically detect C++ mode, i.e., no <code>extern "C"</code> is needed anymore.
6142 *
6143 * For further release notes we refer to the \ref RELEASENOTES "Release notes".
6299 /**@page CHG5 Interface changes between SCIP 2.0 and SCIP 2.1
6300 *
6301 *
6302 * @section CHGCALLBACKS5 New and changed callbacks
6303 *
6304 * - <b>Presolving</b>:
6305 * <br>
6306 * <br>
6307 * - The new parameters "nnewaddconss" and "naddconss" were added to the constraint handler callback method SCIP_DECL_CONSPRESOL()
6308 * and the presolver callback method SCIP_DECL_PRESOLEXEC(). These parameters were also added to corresponding C++ wrapper class methods.
6309 * - Propagators are now also called in during presolving, this is supported by the new callback methods SCIP_DECL_PROPINITPRE(),
6310 * SCIP_DECL_PROPEXITPRE(), and SCIP_DECL_PROPPRESOL().
6311 * - New parameters "isunbounded" and "isinfeasible" for presolving initialization (SCIP_DECL_CONSINITPRE(),
6312 * SCIP_DECL_PRESOLINITPRE(), SCIP_DECL_PROPINITPRE()) and presolving deinitialization (SCIP_DECL_CONSEXITPRE(),
6313 * SCIP_DECL_PRESOLEXITPRE(), SCIP_DECL_PROPEXITPRE()) callbacks of presolvers,
6314 * constraint handlers and propagators, telling the callback whether the problem was already declared to be
6315 * unbounded or infeasible. This allows to avoid expensive steps in these methods in case the problem is already
6316 * solved, anyway.
6317 * <br>
6318 * <br>
6319 * <DIV class="note">
6320 * Note, that the C++ methods
6321 * - scip::ObjConshdlr::scip_presol() corresponding to SCIP_DECL_CONSPRESOL()
6322 * - scip::ObjConshdlr::scip_initpre() corresponding to SCIP_DECL_CONSINITPRE()
6323 * - scip::ObjPresol::scip_initpre() corresponding to SCIP_DECL_PRESOLINITPRE()
6324 * - scip::ObjProp::scip_initpre() corresponding to SCIP_DECL_PROPINITPRE()
6325 * - scip::ObjConshdlr::scip_exitpre() corresponding to SCIP_DECL_CONSEXITPRE()
6326 * - scip::ObjPresol::scip_exitpre() corresponding to SCIP_DECL_PRESOLEXITPRE()
6327 * - scip::ObjProp::scip_exitpre() corresponding to and SCIP_DECL_PROPEXITPRE()
6328 * .
6329 * are virtual functions. That means, if you are not adding the new parameters, your code will still compile, but these methods are not executed.
6330 * </DIV>
6331 *
6332 * - <b>Constraint Handler</b>:
6333 * <br>
6334 * <br>
6335 * - The new constraint handler callback SCIP_DECL_CONSDELVARS() is called after variables were marked for deletion.
6336 * This method is optional and only of interest if you are using SCIP as a branch-and-price framework. That means,
6337 * you are generating new variables during the search. If you are not doing that just define the function pointer
6338 * to be NULL.
6339 * <br>
6340 * If this method gets implemented you should iterate over all constraints of the constraint handler and delete all
6341 * variables that were marked for deletion by SCIPdelVar().
6342 *
6343 * - <b>Problem Data</b>:
6344 * <br>
6345 * <br>
6346 * - 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.
6347 *
6348 * - <b>Conflict Analysis</b>:
6349 * <br>
6350 * <br>
6351 * - Added parameter "separate" to conflict handler callback method SCIP_DECL_CONFLICTEXEC() that defines whether the conflict constraint should be separated or not.
6352 *
6353 * - <b>NLP Solver Interface</b>:
6354 * <br>
6355 * <br>
6356 * - The callbacks SCIP_DECL_NLPIGETSOLUTION() and SCIP_DECL_NLPISETINITIALGUESS() got new parameters to get/set values of dual variables.
6357 * - The callback SCIP_DECL_NLPICOPY() now passes the block memory of the target SCIP as an additional parameter.
6365 * - The methods SCIPwriteVarName(), SCIPwriteVarsList(), and SCIPwriteVarsLinearsum() got a new boolean parameter "type"
6366 * that indicates whether the variable type should be written or not.
6367 * - The method SCIPwriteVarsList() got additionally a new parameter "delimiter" that defines the character which is used for delimitation.
6368 * - The methods SCIPparseVarName() and SCIPparseVarsList() got a new output parameter "endptr" that is filled with the position where the parsing stopped.
6369 *
6370 * - <b>Plugin management</b>:
6371 * <br>
6372 * <br>
6373 * - 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.
6374 * - SCIPincludeConshdlr() got additional parameters to set the variable deletion callback function and the timing mask for propagation.
6375 *
6376 * - <b>Constraint Handlers</b>:
6377 * <br>
6378 * <br>
6379 * - Method SCIPseparateRelaxedKnapsack() in knapsack constraint handler got new parameter "cutoff", which is a pointer to store whether a cutoff was found.
6380 * - Method SCIPincludeQuadconsUpgrade() of quadratic constraint handler got new parameter "active" to indicate whether the upgrading method is active by default.
6381 *
6382 * - <b>Nonlinear expressions, relaxation, and solver interface</b>:
6383 * <br>
6384 * <br>
6385 * - The methods SCIPexprtreeEvalSol(), SCIPexprtreeEvalIntLocalBounds(), and SCIPexprtreeEvalIntGlobalBounds() have been renamed to SCIPevalExprtreeSol(),
6386 * SCIPevalExprtreeLocalBounds(), and SCIPevalExprtreeGlobalBounds() and are now located in scip.h.
6387 * - Various types and functions dealing with polynomial expressions have been renamed to use the proper terms "monomial" and "polynomial".
6388 * - The methods SCIPnlpGetObjective(), SCIPnlpGetSolVals(), and SCIPnlpGetVarSolVal() have been removed, use SCIPgetNLPObjval(), SCIPvarGetNLPSol()
6389 * and SCIPcreateNLPSol() to retrieve NLP solution values instead.
6390 * - Removed methods SCIPmarkRequireNLP() and SCIPisNLPRequired(), because the NLP is now always constructed if nonlinearities are present.
6391 * - SCIPgetNLP() has been removed and NLP-methods from pub_nlp.h have been moved to scip.h, which resulted in some renamings, too.
6392 * - The functions SCIPnlpiGetSolution() and SCIPnlpiSetInitialGuess() got additional arguments to get/set dual values.
6393 * - The method SCIPgetNLPI() got a new parameter "nlpiproblem", which is a pointer to store the NLP solver interface problem.
6394 *
6395 * - <b>Others</b>:
6396 * <br>
6397 * <br>
6398 * - 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
6399 * the given variable is contained in the given hash map.
6400 * - Removed method SCIPreadSol(); call solution reading via SCIPreadProb() which calls the solution reader for .sol files.
6401 * - SCIPchgVarType() got an extra boolean parameter to store if infeasibility is recognized while upgrading a variable from continuous type to an integer type.
6402 * - SCIPdelVar() got a new parameter "deleted", which stores whether the variable was successfully marked to be deleted.
6403 * - SCIPcalcNodeselPriority() got a new parameter "branchdir", which defines the type of branching that was performed: upwards, downwards, or fixed.
6404 * - The parameters "timelimit" and "memorylimit" were removed from SCIPapplyRens().
6405 *
6406 * <br>
6407 * @section MISCELLANEOUS5 Miscellaneous
6408 *
6409 * - The result value SCIP_NEWROUND has been added, it allows a separator/constraint handler to start a new separation round
6410 * (without previous calls to other separators/conshdlrs).
6411 * - All timing flags are now defined type_timing.h.
6412 * - The variable deletion event is now a variable specific event and not global, anymore.
6413 * - The emphasis setting types now distinguish between plugin-type specific parameter settings (default, aggressive, fast, off), which are changed by
6414 * SCIPsetHeuristics/Presolving/Separating(), and global emphasis settings (default, cpsolver, easycip, feasibility, hardlp, optimality, counter),
6415 * which can be set using SCIPsetEmphasis().
6416 *
6417 * <br>
6418 * For further release notes we refer to the \ref RELEASENOTES "Release notes".
6967 * In that case the sparse solutions are unrolled and lifted back into the original variable space.
6968 *
6969 * The callable library provides a method which gives access to all collected sparse solutions. That is,
6970 * SCIPgetCountedSparseSolutions(). The sparse solutions you get are defined w.r.t. active variables. To get solutions
6971 * w.r.t. to the original variables. You have to do two things:
6972 *
6973 * -# unroll each sparse solution
6974 * -# lift each solution into original variable space by extending the solution by those variable which got removed
6975 * during presolving
6976 *
6977 * The get the variables which got removed during presolving, you can use the methods SCIPgetFixedVars() and
6978 * SCIPgetNFixedVars(). The method SCIPgetProbvarLinearSum() transforms given variables, scalars and constant to the
6979 * corresponding active variables, scalars and constant. Using this method for a single variable gives a representation
6980 * for that variable w.r.t. the active variables which can be used to compute the value for the considered solution (which
6981 * is defined w.r.t. active variables).
6982 *
6983 * For that complete procedure you can also check the source code of
6984 * \ref SCIP_DECL_DIALOGEXEC(SCIPdialogExecWriteAllsolutions) "SCIPdialogExecWriteAllsolutions()" cons_countsols.c which
6985 * does exactly that.
6986 *
6987 *
6988 * @section COUNTOPTIMAL Count number of optimal solutions
6989 *
6990 * If you are interested in counting the number of optimal solutions, this can be done with SCIP using the
6991 * <code>count</code> command by applying the following steps:
6992 *
6993 * -# Solve the original problem to optimality and let \f$c^*\f$ be the optimal value
6994 * -# Add the objective function as constraint with left and right hand side equal to \f$c^*\f$
6995 * -# load the adjusted problem into SCIP
6996 * -# use the predefined counting settings
6997 * -# start counting the number of feasible solutions
6998 *
6999 * If you do this, SCIP will collect all optimal solutions of the original problem.
7000 *
7001 */
7002
7003/**@page LICENSE License
7004 *
7005 * \verbinclude COPYING
7006 */
7007
7008/**@page FAQ Frequently Asked Questions (FAQ)
7009 * \htmlinclude faq.inc
7010 */
7011
7012/**@page INSTALL Installation information
7013 * \verbinclude INSTALL
7014 */
7015
7016/**@page RELEASENOTES Release notes
7017 *
7018 * A release report with an in-depth description of many of the new features is available on <a href="http://www.optimization-online.org">Optimization Online</a>.
7019 * \verbinclude SCIP-release-notes-4.0
7020 *
7021 * Please consult the <a href="http://nbn-resolving.de/urn:nbn:de:0297-zib-57675">release report</a> that explains many of the new features in detail.
7022 *
7023 * \verbinclude SCIP-release-notes-3.2.1
7024 *
7025 * \verbinclude SCIP-release-notes-3.2
7026 *
7027 * \verbinclude SCIP-release-notes-3.1
7028 *
7029 * \verbinclude SCIP-release-notes-3.0.2
7030 *
7031 * \verbinclude SCIP-release-notes-3.0.1
7032 *
7033 * \verbinclude SCIP-release-notes-3.0
7034 *
7035 * \verbinclude SCIP-release-notes-2.1.1
7036 *
7037 * \verbinclude SCIP-release-notes-2.1
7038 *
7039 * \verbinclude SCIP-release-notes-2.0.2
7040 *
7041 * \verbinclude SCIP-release-notes-2.0.1
7042 *
7043 * \verbinclude SCIP-release-notes-2.0
7044 *
7045 * \verbinclude SCIP-release-notes-1.2
7046 *
7047 * \verbinclude SCIP-release-notes-1.1
7048 */
7049
7050/**@page CHANGELOG CHANGELOG
7051 *
7052 * \verbinclude CHANGELOG
7053 *
7054 */
7055
7056
7057
7058/**@page PARAMETERS List of all SCIP parameters
7059 *
7060 * This page list all parameters of the current SCIP version. This list can
7061 * easily be generated by SCIP via the interactive shell using the following command:
7062 *
7063 * <code>SCIP> set save <file name></code>
7577 * <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>
7578 * <tr><td>\ref reader_diff.h "DIFF format"</td> <td>for reading a new objective function for mixed-integer programs</td></tr>
7579 * <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>
7580 * <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>
