cplex user manual pdf

cplex user manual pdf

In particular, a simple 3 variable linear programming problem could be described to CPLEX by the following input text, which is completely understandable by anyone familiar with these kinds of problems: IBM also offers free access to a full version of CPLEX for faculty and researchers at accredited universities. For more information on this opportunity, see. It also shows their default settings with explanations of the effect of other settings. Normally, the default settings of ILOG CPLEX solve a wide range of mathematical programming problems without intervention on your part, but these parameters are available for fine tuning in special cases.It is available online as HTML and as Microsoft compiled HTML help (.chm).Before you can use ILOG CPLEX, you need to set up ILM. Its online documentation explains how to do so step-by-step, for different platforms. It is in HTML form, included with your distribution. Cplex optimizers are designed to solve large, difficult problems quickly and with minimal user intervention.If Cplex was specified as the default solver during GAMS installation, the above statement is not necessary. The CplexD solver link lack some functionality available in the Cplex link (e.g. sensitivity analysis for linear programs, support for SOS variables), but CplexD offers a few facility of interest to a small community: Some SOCP models are reformulated in the production link so that Cplex rejects these models while CplexD solves them nicely. Moreover, CplexD provides duals for this problem type. In the near future the two links will be merged. It comes free of charge with any GAMS system. Certain types of problems benefit from using the primal simplex algorithm, the network optimizer, the barrier algorithm, or the sifting algorithm. The concurrent option will allow solving with different algorithms in parallel. The solution is returned by the first to finish.http://yencangio.vn/uploads/userfiles/canon-bjc-85-repair-manual.xml

• cplex user manual pdf, cplex user manual pdf, cplex user manual pdf download, cplex user manual pdf free, cplex user manual pdf file, cplex user manual pdf software, cplex user manual pdf.

Even though Cplex manages memory very efficiently, insufficient physical memory is one of the most common problems when running large LPs. When memory is limited, Cplex will automatically make adjustments which may negatively impact performance. If you are working with large models, study the section entitled Physical Memory Limitations carefully. These settings usually provide the best overall problem optimization speed and reliability. However, there are occasionally reasons for changing option settings to improve performance, avoid numerical difficulties, control optimization run duration, or control output options. Very few problems exhibit poor numerical performance in both the primal and the dual. Therefore, consider trying primal simplex if numerical problems occur while using dual simplex. Network constraints have the following property: Specifying the barrier algorithm may be advantageous for large, sparse problems. Sifting solves a sequence of LP subproblems where the results from one subproblem are used to select columns from the original model for inclusion in the next subproblem. The conflict refinder takes an infeasible program and produces an set of conflicting constraints. Such a set consists of constraints and variable bounds which is infeasible but becomes feasible if any one member of the set is dropped.These are formulated in GAMS as models of type QCP. QCP models are solved with the Cplex Barrier method. Those are automatically reformulated from GAMS QCP models. When such problems are convex, Cplex normally solves them efficiently in polynomial time. Nonconvex QPs, however, are known to be quite hard. Cplex applies various approaches to those problems, such approaches as barrier algorithms or branch and bound algorithms. Notably, in the branch and bound approach, there is no theoretical guarantee about the complexity of such a problem.http://oecschool.com/userfiles/canon-bluetooth-unit-bu-30-manual.xml

Consequently, solution of such a problem (that is, a nonconvex QP) can take many orders of magnitude longer than the solution of a convex QP of comparable dimensions. Therefore, the default is to reject such model. The parameter OptimalityTarget allows to change this behavior. As in the continuous case, if the base model is a QP the Simplex methods can be used and duals will be available at the solution. If the base model is a QCP, only the Barrier method can be used for the nodes and only primal values will be available at the solution. However, you may want to go beyond diagnosis to perform automatic correction of your model and then proceed with delivering a solution. One approach for doing so is to build your model with explicit slack variables and other modeling constructs, so that an infeasible outcome is never a possibility. More details can be found in the section entitled Using the Feasibility Relaxation. The chapter also explains techniques for generating and managing those solutions. With this feature, you can direct the algorithm to generate multiple solutions in addition to the optimal solution. For example, some constraints may be difficult to formulate efficiently as linear expressions, or the objective may be difficult to quantify exactly. In such cases, obtaining multiple solutions will help you choose one which best fits all your criteria,including the criteria that could not be expressed easily in a conventional MIP or MIQCP model. For example, To do so, apply the solution pool gap parameters SolnPoolAGap and SolnPoolGap. To do so, use the solution pool replacement parameter SolnPoolReplace to set the solution pool replacement strategy to 2. In order to control the diversity of solutions even more finely, apply a diversity filter. To do so, see the use of the incumbent filter. To do so, set the solution pool intensity parameter SolnPoolIntensity to its highest value.

The method is selected with the parameter SolnPoolPop: In particular, you may invoke this procedure multiple times to find additional solutions, especially if the first solutions found are not satisfactory. This is done by specifying a GAMS program (option SolnPoolPopRepeat ) that inspects the solutions. In case this GAMS program terminates normally, i.e. no execution or compilation error, the exploration for alternative solutions proceeds. The value 0 replaces solutions according to a first-in, first-out policy. The value 1 keeps the solutions with the best objective values. The value 2 replaces solutions in order to build a set of diverse solutions. Solutions already in the pool are not affected by the replacement strategy. They will not be replaced, even if they satisfy the criterion of the replacement strategy. So with every repeated call of the populate procedure the solution pool will be extended by the newly found solution. After the GAMS program specified in SolnPoolPopRepeat determined to continue the search for alternative solutions, the file specified by option SolnPoolPopDel option is read in. The solution numbers present in this file will be delete from the solution pool before the populate routine is called again.For example, if you want to enumerate all alternative optimal solutions, do the following: Consequently, enumerating all of them will take time and consume a large quantity of memory. Therefore, populate gives only one solution for each set of binary and integer variables, even though there may exist several solutions that have the same values for all binary and integer variables but different values for continuous variables. As soon as the proof of unboundedness is obtained, the populate procedure stops. Consequently, the feasibility of a solution depends on the value given to tolerances.

Two parameters define the tolerances that assess the feasibility of a solution: This phenomenon is especially noticeable in models with numeric difficulties, for example, in models with BigM coefficients. In most models, this tolerance issue is not problematic. But, in the presence of numeric difficulties, Cplex may create solutions that are slightly infeasible or integer infeasible, and therefore create more solutions than expected. Cplex provides two predefined ways to filter solutions. This filter is practical for most purposes. However, if you require finer control of which solutions to keep and which to eliminate, use the incumbent filter. In particular, you can use a diversity filter to generate more solutions that are similar to an existing solution or to an existing partial solution. If you need more than one diversity filter, for example, to generate solutions that share the characteristics of several different solutions, additional filters can be specified through a Cplex Filter File using parameter ReadFLT. Details can be found in the example model solnpool in the GAMS model library. The incumbent checking routine is part of the GAMS BCH Facility. It will accept or reject incumbents independent of a solution pool. During the populate or regular optimize procedure, the incumbent checking routine specified by the parameter UserIncbCall is called each time a new solution is found, even if the new solution does not improve the objective value of the incumbent. The incumbent filter allows your application to accept or reject the new solution based on your own criteria. If the GAMS program specified by UserIncbCall terminates normally, the solution is rejected. If this program returns with a compilation or execution error, the incumbent is accepted. Details can be found in the model solnpool in the GAMS model library and in. If you instruct Cplex to generate thousands of solution this becomes inefficient.

The option SolnPoolMerge triggers the creation of a single GDX file containing all solutions. The associated text of these elements contain the file names of the individual GDX solution file. The name is constructed using the prefix soln (which can be specified differently by option SolnPoolPrefix ), the name of the model and a sequence number. The set Index allows us to conveniently walk through the different solutions in the solution pool. A complete model can be found in the model solnpool in the GAMS model library. The option SolnPoolMerge triggers the creation of a single GDX file containing all solutions. Details on usage of this option can be found in the model solmpool in the GAMS model library. You can specify the server with the ComputeServer option. The feature is know as Distributed MIP and builds on top of the Cplex Remote Object Server. This section describes the setup steps necessary to enable this feature. First there is some background information about CPLEX Distributed MIP. This feature, known as distributed parallel MIP optimization, is a mode of running CPLEX that harnesses the power of multiple computers or of multiple nodes inside a single computer to achieve better performance on some MIP problems. Each worker communicates what it finds to the (unique) master node, which acts as the conductor or coordinator for the whole process. In contrast to conventional branch and bound implemented on platforms with shared memory, distributed parallel MIP implements a branch and bound algorithm in an environment of distributed memory, possibly across multiple machines. The implementation can use more than a single machine to solve a given MIP, thus making it possible to solve more difficult problems than a shared memory on a single machine could solve. The master and the workers can be physical or virtual machines. Indeed, in this context, a virtual machine may simply be a process in the operating system of a machine.

Throughout the runtime of this algorithm, the master coordinates the workers, and the workers perform the heavy lifting (that is, the actual solving of the MIP). After presolving, the algorithm sends the reduced model to each of the workers. Each worker has its own parameter settings, possibly different from the parameter settings of other workers. Each worker solves the reduced model with its own parameter settings for a limited period of time. This phase is known as ramp up. During ramp up, each worker conducts its own search, according to its own parameter settings. Ramp up stops when the master concludes that at least one of the workers has created a sufficiently large search tree. In other words, the master selects a winner. The parameter settings used by the winning worker during ramp up are the basis for the master to determine which parameter settings to use in the ensuing distributed branch and bound search. The search tree of the winning worker is distributed over all workers, so that authentic distributed parallel branch and bound starts from this point. In other words, all workers now work on the same search tree, with the master coordinating the search in the distributed tree. They differ greatly, however, in their management of the search tree. In a conventional, shared-memory branch and bound, the search tree resides on a single machine, on disk or in shared memory. In contrast, distributed parallel branch and bound literally distributes the search tree across a cluster of machines. If a worker becomes idle, the master sends some of those nodes to that worker. The worker then starts branch and bound on those nodes. However, the worker does not simply solve a node, create some new nodes in doing so, and send them all back to the master. Instead, the worker considers the search tree node received from the master as a new MIP. The worker presolves that MIP and finds an optimal solution for that node using branch and bound.

In other words, a worker not only solves a single node; in fact, the worker solves an entire subtree rooted at that node. The master can then use these nodes to assign work to idle workers. To satisfy such a request from the master, a worker picks a few open nodes from its current tree. Because the current tree in a worker is a subtree of the global tree (indeed, it is the subtree rooted at the node sent to the worker), every node in that subtree is also a node in the global tree. Such limits include a time limit, a limit on the number of nodes processed, a limit on the number of solutions found, or other similar criteria. On each work machine create a directory and unzip the ZIP file in this directory: mkdir c:\tmp\gamscplexdistmipThe server does not terminate itself, however. You must explicitly terminate it; for example, by pressing CTRL-C when your optimization completes. Please note, that when you specify a single machine, one gets the Cplex Remote Object solving sequentially on a remote machine instead of a distributed MIP run. The following parameters (only applicable in CplexD) enable you to customize this ramp-up phase for your model. This approach can be applied to mixed-integer linear programs (MILP). For certain types of problems, this approach can offer significant performance improvements. By default, if you did not annotate your model to specify a decomposition, CPLEX executes conventional branch and bound. If you annotated your model, CPLEX attempts to refine your decomposition and applies Benders algorithm. With this parameter, you can direct CPLEX to decompose your model and to apply its implementation of Benders algorithm in one of these alternative ways: CPLEX initially decomposes your model according to your annotation and then attempts to refine that decomposition by further decomposing the specified subproblems.

This approach can be useful if you annotate certain variables to go into master, and all others to go into a single subproblem, which CPLEX can then decompose further for you. CPLEX puts all integer variables into the master, puts all continuous variables into a subproblem and decomposes that subproblem, if possible. These Benders partition can be conveniently specified with the dot option BendersPartition or through the.stage variable suffix. If you annotate a given variable with the value 0 (zero), CPLEX assigns that variable to the master. If you annotate a given variable with the value i, where i is greater than or equal to 1 (one), CPLEX assigns that variable to subproblem i. If a variable is not specified, the default will be to go into the master problem. Note that with variable.BendersPartition 1 you can assign all variables to the subproblem and then selectively assign the master variables with varname.BendersPartition 0. So the master variables have stage 1, and the subproblems start with stage 2. If you want to leave a variable unassigned you can either make the stage 0 or fractional (e.g. 1.5). Discrete variables are automatically put into the master problem and don't need to be set (actually the.stage suffix is even not available for discrete variables). In addition to specifying the Benders partition values via the.stage variable suffix the link option BendersPartitionInStage needs to be set to 1. Consequently, the subproblems where these variables appear according to your annotations are not disjoint with respect to the partition. For example, in a production planning model, you may want to both maximize profits and minimize late orders, or in a workforce scheduling application, you may want to both minimize the number of shifts that are short-staffed while also respecting worker's shift preferences.

Cplex provides tools that simplify the task: Cplex allows you to blend multiple objectives, to treat them hierarchically, or to combine the two approaches. In a blended approach, you optimize a weighted combination of the individual objectives. In a hierarchical or lexicographic approach, you set a priority for each objective, and optimize in priority order. When optimizing for one objective, you only consider solutions that would not degrade the objective values of higher-priority objectives. Cplex allows you to enter and manage your objectives, to provide weights for a blended approach, or to set priorities for a hierarchical approach. Cplex will only solve multi-objective models with strictly linear objectives. Moreover, for continous models, Cplex will report a primal only solution (not dual information). Using the parameter MultObj Cplex will use a hierarchical approach. A hierarchical or lexicographic approach assigns a priority to each objective, and optimizes for the objectives in decreasing priority order. At each step, it finds the best solution for the current objective, but only from among those that would not degrade the solution quality for higher-priority objectives. The priority is specified by the absolute value of the objective coefficient in the blended objective function ( defObj ). The sign of the objective coefficient determines the direction of the particular objective function. So here numShifts will be minimized (same direction as on the solve statement) while sumPreferences will be maximized. GAMS needs to identify the various objective functions, therefore the objective variables can only appear in the blended objective functions and in the particular objective defining equation. This behavior can be relaxed through a pair of attributes: ObjNRelTol and ObjNAbsTol.

By setting one of these for a particular objective, you can indicate that later objectives are allowed to degrade this objective by the specified relative or absolute amount, respectively. In our earlier example, if the optimal value for numShifts is 100, and if we set ObjNAbsTol for this objective to 20, then the second optimization step maximizing sumPreferences would find the best solution for the second objective from among all solutions with objective 120 or better for numShifts. Note that if you modify both tolerances, later optimizations would use the looser of the two values (i.e., the one that allows the larger degradation). A value of 1.0 causes GAMS to instruct Cplex not to use an advanced basis. A value of 0.0 causes GAMS to construct a basis from whatever information is available. The default value of 0.25 will nearly always cause GAMS to pass along an advanced basis if a solve statement has previously been executed. Simplex algorithms will terminate and pass on the current solution to GAMS. The iteration limit is applied per node instead of as a total over all nodes. For MIP problems, controlling the length of the solution run by limiting the execution time (ResLim) is preferable. The number of sifting iterations (LPs) can be limited by setting Cplex parameter SiftItLim. It is the number of sifting iterations that is reported back to GAMS as iterations used. The algorithm will terminate and pass on the current solution to GAMS. This option may be useful in case of a solver failure. Can speed up the search, but you may miss the optimal solution. The cheat parameter is specified in absolute terms (like the OptCA option). The Cplex option ObjDif overrides the GAMS cheat parameter. This can sometimes speed up the initial phase of the branch and bound algorithm. The OptCA option asks Cplex to stop when Notice that Cplex uses a different definition than GAMS normally uses.

The OptCR option asks Cplex to stop when The GAMS definition is: The name of the option file is cplex.opt. The preferred branching direction will only be effective when priorities are used.The length of a deterministic time tick may vary by platform. Nevertheless, ticks are normally consistent measures for a given platform (combination of hardware and software) carrying the same load. In other words, the correspondence of ticks to clock time depends on the hardware, software, and the current load of the machine. For the same platform and same load, the ratio of ticks per second stays roughly constant, independent of the model solved. However, for very short optimization runs, the variation of this ratio is typically high. Normally ETAlg is reporting the seconds. The options are listed again, in alphabetical order and with detailed descriptions, in the last section of this document. The iteration log will have an entry for each iteration instead of an entry for each refactorization. When Cplex recognizes that a limited amount of memory is available it automatically makes algorithmic adjustments to compensate. These adjustments almost always reduce optimization speed. Learning to recognize when these automatic adjustments occur can help to determine when additional memory should be added to the computer. Increasing available memory will speed the solution process dramatically. Also consider option MemoryEmphasis to conserve memory where possible. The longer Cplex works between refactorizations, the greater the amount of memory required to complete each iteration. Therefore, one means for conserving memory is to increase the refactorization frequency. Since refactorization is an expensive operation, increasing the refactorization frequency by reducing the ReInv option setting generally will slow performance. Cplex will automatically increase the refactorization frequency if it encounters low memory availability. This can be seen by watching the iteration log.

The default log reports problem status at every refactorization. If the number of iterations between iteration log entries is decreasing, Cplex is increasing the refactorization frequency. Since Cplex might increase the frequency to once per iteration, the impact on performance can be dramatic. Providing additional memory should be beneficial. This only works when the GAMS parameter SolveLink is set 0 which should be always done when memory is tight because GAMS completely vacates memory. The concurrent solvers keep multiple copies of the problem in memory which double or even triples the amount of memory consumed. If memory tight, set the Threads parameter to 1. GAMS allows you to declare SOS1 and SOS2 variables (Special Ordered Sets of type 1 and 2). If two variables are non-zero, they must be adjacent in the set. For example: This problem arises when the branch and bound tree becomes so large that insufficient memory is available to solve an LP subproblem. As memory gets tight, you may observe frequent warning messages while Cplex attempts to navigate through various operations within limited memory. If a solution is not found shortly the solution process will be terminated with an unrecoverable integer failure message. Cplex saves a basis for every unexplored node. When utilizing the best bound method of node selection, the list of such nodes can become very long for large or difficult problems. How large the unexplored node list can become is entirely dependent on the actual amount of physical memory available and the actual size of the problem. Certainly increasing the amount of memory available extends the problem solving capability. Unfortunately, once a problem has failed because of insufficient memory, you can neither project how much further the process needed to go nor how much memory would be required to ultimately solve it.

Setting NodeFileInd to 2 or 3 will cause Cplex to store portions of the branch and bound tree on disk whenever it grows to larger than the size specified by option WorkMem. That size should be set to something less than the amount of physical memory available. Depth first search rarely generates a large unexplored node list since Cplex will be diving deep into the branch and bound tree rather than jumping around within it. Strong branching spends extra computation time at each node to choose a better branching variable. As a result it generates a smaller tree. It is often faster overall, as well. Cut generation can be turned off using option Cuts. A problem containing only 30 binary variables could produce a tree having over one billion nodes. If no other stopping criteria have been set, the process might continue ad infinitum until the search is complete or your computer's memory is exhausted. Setting limits ensures that an exhaustive tree search will terminate in reasonable time. Once terminated, you can rerun the problem using some different option settings. When you provide such a starting solution, you may invoke relaxation induced neighborhood search (RINS heuristic) or solution polishing to improve the given solution. This first integer solution may include continuous and discrete variables of various types, such as semi-continuous variables or special ordered sets. If this process succeeds, the solution will be treated as an integer solution of the current problem. In essence, the feasible relaxation tries to suggest the least change that would achieve feasibility. It returns an infeasible solution to GAMS and marks the relaxations of bounds and constraints with the INFES marker in the solution section of the listing file. This default behavior can be modified by assigning relaxation preferences to variable bounds and constraints. These preferences can be conveniently specified with the dot option FeasPref.

A negative or zero preference means that the associated bound or constraint is not to be modified. The weighted penalty function is constructed from these preferences. The larger the preference, the more likely it will be that a given bound or constraint will be relaxed. However, it is not necessary to specify a unique preference for each bound or range. In fact, it is conventional to use only the values 0 (zero) and 1 (one) except when your knowledge of the problem suggests assigning explicit preferences. The syntax is: Furthermore, we specify that all variables v(i,j) have preference of 1, except variables over set element i1, which have a preference of 2. The variable over set element i1 and j2 has preference 0. Note that preferences are assigned in a procedural fashion so that preferences assigned later overwrite previous preferences. The same syntax applies for assigning preferences to equations as demonstrated above. If you want to assign a preference to all variables or equations in a model, use the keywords variables or equations instead of the individual variable and equations names (e.g. variables.feaspref 1 ). In its first phase, it attempts to minimize its relaxation of the infeasible model. That is, it attempts to find a feasible solution that requires minimal change. In its second phase, it finds an optimal solution (using the original objective) among those that require only as much relaxation as it found necessary in the first phase. Values of the parameter FeasOptMode indicate two aspects: (1) whether to stop in phase one or continue to phase two and (2) how to measure the relaxation (as a sum of required relaxations; as the number of constraints and bounds required to be relaxed; as a sum of the squares of required relaxations). Please check description of parameters FeasOpt and FeasOptMode for details.