Cplex Gpu

[Blossom Stemmer]

Iam solving cplex models using julia, while writing (in julia) the model (to .lp file) and solve the .lp file directly by cplex can be done in secs and mins, but when I want to solve the model directly in julia by using optimize! it takes hours or days, can anyone knows why and how to solve or avoid it?

I have never seen something as drastic, but I can vouch that the non-direct_model models sometimes will be much slower because the model itself is not hard to solve, but it is big and/or the JuMP wrapper somehow build it in a very inefficient way.

Just to confirm, the Julia code never starts solving the model, right? Or the extra times happens during model solving? If it is the second case then either the problem is very dependent on variable ordering or there is a bug in the wrapper (not the same model is being written).

Basically, if you do not use direct_model, then your model is wrapped within an extra layer of indirection. This layer saves everything you do to the model and, besides other things, allows you to switch solver on the fly, because it knows everything that needs to be done again to the new solver object to replicate your model (I think it allows other things like copying and exporting your model to file formats, but I am not entirely sure).

My experience with this layer is not good. It seems like it has serious performance issues with anything besides the most straightforward model building, i.e., if you just build your model in a single go, without changing it after, the problems often do not appear, but if you stray from this path you have bad surprises.

GAMS/Cplex is a GAMS solver that allows users to combine the high level modeling capabilities of GAMS with the power of Cplex optimizers. Cplex optimizers are designed to solve large, difficult problems quickly and with minimal user intervention. Access is provided (subject to proper licensing) to Cplex solution algorithms for linear, quadratically constrained and mixed integer programming problems. While numerous solving options are available, GAMS/Cplex automatically calculates and sets most options at the best values for specific problems.

Cplex solves LP problems using several alternative algorithms. The majority of LP problems solve best using Cplex's state of the art dual simplex algorithm. 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.

Solving linear programming problems is memory intensive. 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.

Cplex is designed to solve the majority of LP problems using default option settings. 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.

Some problems solve faster with the primal simplex algorithm rather than the default dual simplex algorithm. 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.

The barrier algorithm is an alternative to the simplex method for solving linear programs. It employs a primal-dual logarithmic barrier algorithm which generates a sequence of strictly positive primal and dual solutions. Specifying the barrier algorithm may be advantageous for large, sparse problems.

Cplex provides a sifting algorithm which can be effective on problems with many more variables than equations. 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.

GAMS/Cplex also provides access to the Cplex Conflict Refiner previously known as IIS (Irreducibly Inconsistent Set). 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. GAMS/Cplex reports the conflict in terms of GAMS equation and variable names and includes the conflict report as part of the normal solution listing.

QP models are a special case that can be reformulated to have a quadratic objective function and only linear constraints. 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. 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.

The methods used to solve pure integer and mixed integer programming problems require dramatically more mathematical computation than those for similarly sized pure linear programs. Many relatively small integer programming models take enormous amounts of time to solve.

For problems with integer variables, Cplex uses a branch and cut algorithm which solves a series of LP, subproblems. Because a single mixed integer problem generates many subproblems,even small mixed integer problems can be very compute intensive and require significant amounts of physical memory.

Cplex can also solve problems of GAMS model type MIQCP. 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.

The Conflict Refiner identifies the causes of infeasibility by means of inconsistent set of constraints. 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. An automated approach offered in GAMS/Cplex is known as FeasOpt (for Feasible Optimization) and turned on by parameter FeasOpt in a CPLEX option file. More details can be found in the section entitled Using the Feasibility Relaxation.

This section introduces the solution pool for storing multiple solutions to a mixed integer programming problem (MIP and MIQCP). The chapter also explains techniques for generating and managing those solutions.

The solution pool stores multiple solutions to a mixed integer programming (MIP and MIQCP) model. 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,

There are two ways to fill the solution pool associated with a model: You can accumulate successive incumbents or generate alternative solutions by populating the solution pool. The method is selected with the parameter SolnPoolPop:

The option SolnPoolReplace designates the strategy for replacing a solution in the solution pool when the solution pool has reached its capacity. 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.

The replacement strategy applies only to the subset of solutions created in the current call of populate. 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. The file is automatically deleted by the GAMS/Cplex link after processing.

There may be an infinite number of possible values for a continuous variable, and it is not practical to enumerate all of them on a finite-precision computer. 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.

Cplex uses numerical methods of finite-precision arithmetic. 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:

A solution may be considered feasible for one pair of values for these two parameters, and infeasible for a different pair. This phenomenon is especially noticeable in models with numeric difficulties, for example, in models with BigM coefficients.

3a8082e126