The MOSEK Python optimizer API manual Version 7.0 (Revision 141)

Optimizer API for Python - Documentation - Mosek Optimizer API for Python - Documentation - Mosek

25.11.2015 Views

68 CHAPTER 5. BASIC API TUTORIAL • Task.putmaxnumanz. Estimate for the number of non-zeros in A. • Task.putmaxnumqnz. Estimate for the number of non-zeros in the quadratic terms. None of these functions change the problem, they only give hints to the eventual dimension of the problem. If the problem ends up growing larger than this, the estimates are automatically increased. Do not mix put- and get- functions: For instance, the functions Task.putacol and Task.getacol. MOSEK will queue put- commands internally until a get- function is called. If every put- function call is followed by a getfunction call, the queue will have to be flushed often, decreasing efficiency. In general get- commands should not be called often during problem setup. Use the LIFO principle when removing constraints and variables: MOSEK can more efficiently remove constraints and variables with a high index than a small index. An alternative to removing a constraint or a variable is to fix it at 0, and set all relevant coefficients to 0. Generally this will not have any impact on the optimization speed. Add more constraints and variables than you need (now): The cost of adding one constraint or one variable is about the same as adding many of them. Therefore, it may be worthwhile to add many variables instead of one. Initially fix the unused variable at zero, and then later unfix them as needed. Similarly, you can add multiple free constraints and then use them as needed. Use one environment (env) only: If possible share the environment (env) between several tasks. For most applications you need to create only a single env. Do not remove basic variables: When doing re-optimizations, instead of removing a basic variable it may be more efficient to fix the variable at zero and then remove it when the problem is re-optimized and it has left the basis. This makes it easier for MOSEK to restart the simplex optimizer. 5.12.1 API overhead The Python interface is a thin wrapper around a native MOSEK library. The layer between the Python application and the native MOSEK library is made as thin as possible to minimize the overhead from function calls. The methods in mosek.Env and mosek.Task are all written in C and resides in the module pymosek. Each method converts the call parameter data structures (i.e. creates a complete copy of the data), calls a MOSEK function and converts the returned values back into Python structures. The follwing rules will often improve the performance of the MOSEK/Python API:

5.13. CONVENTIONS EMPLOYED IN THE API 69 Reuse Env and Task whenever possible There may be some overhead involved in creating and deleting task and environment objects, so if possible reuse these. Make sure to delete task and environment when not in use anymore Using the with-construction (available in python 2.6 and later) will allow automatic deletion of the environment and task. If this is not an option, use Env. del () and Task. del () to destroy the objects. Failing to do this may cause memory leaks in some cases. Avoid input loops Whenever possible imput data in large chunks or vectors instead of using loops. For small put- and get- methods there is a significant overhead, so for example inputting one row of the A-matrix at the time may be much slower than inputting the whole matrix. For example, a loop with Task.putarow may be replaced with one Task.putarowlist, or a loop of Task.putqobjij may be replaced with Task.putqobj. 5.13 Conventions employed in the API 5.13.1 Naming conventions for arguments In the definition of the MOSEK Python API a consistent naming convention has been used. This implies that whenever for example numcon is an argument in a function definition it indicates the number of constraints. In Table 5.2 the variable names used to specify the problem parameters are listed. The relation between the variable names and the problem parameters is as follows: • The quadratic terms in the objective: q o qosubi[t],qosubj[t] • The linear terms in the objective: = qoval[t], t = 0, . . . , numqonz − 1. (5.13) • The fixed term in the objective: c j = c[j], j = 0, . . . , numvar − 1 (5.14) • The quadratic terms in the constraints: c f = cfix. q qcsubk[t] qcsubi[t],qcsubj[t] = qcval[t], t = 0, . . . , numqcnz − 1. (5.15)

68 CHAPTER 5. BASIC <strong>API</strong> TUTORIAL<br />

• Task.putmaxnumanz. Estimate for the number of non-zeros in A.<br />

• Task.putmaxnumqnz. Estimate for the number of non-zeros in the quadratic terms.<br />

None of these functions change the problem, they only give hints to the eventual dimension of<br />

the problem. If the problem ends up growing larger than this, the estimates are automatically<br />

increased.<br />

Do not mix put- and get- functions:<br />

For instance, the functions Task.putacol and Task.getacol. <strong>MOSEK</strong> will queue put- commands<br />

internally until a get- function is called. If every put- function call is followed by a getfunction<br />

call, the queue will have to be flushed often, decreasing efficiency.<br />

In general get- commands should not be called often during problem setup.<br />

Use the LIFO principle when removing constraints and variables:<br />

<strong>MOSEK</strong> can more efficiently remove constraints and variables with a high index than a small<br />

index.<br />

An alternative to removing a constraint or a variable is to fix it at 0, and set all relevant<br />

coefficients to 0. Generally this will not have any impact on the optimization speed.<br />

Add more constraints and variables than you need (now):<br />

<strong>The</strong> cost of adding one constraint or one variable is about the same as adding many of them.<br />

<strong>The</strong>refore, it may be worthwhile to add many variables instead of one. Initially fix the unused<br />

variable at zero, and then later unfix them as needed. Similarly, you can add multiple free<br />

constraints and then use them as needed.<br />

Use one environment (env) only:<br />

If possible share the environment (env) between several tasks. For most applications you need<br />

to create only a single env.<br />

Do not remove basic variables:<br />

When doing re-optimizations, instead of removing a basic variable it may be more efficient to<br />

fix the variable at zero and then remove it when the problem is re-optimized and it has left the<br />

basis. This makes it easier for <strong>MOSEK</strong> to restart the simplex <strong>optimizer</strong>.<br />

5.12.1 <strong>API</strong> overhead<br />

<strong>The</strong> <strong>Python</strong> interface is a thin wrapper around a native <strong>MOSEK</strong> library. <strong>The</strong> layer between the <strong>Python</strong><br />

application and the native <strong>MOSEK</strong> library is made as thin as possible to minimize the overhead from<br />

function calls.<br />

<strong>The</strong> methods in mosek.Env and mosek.Task are all written in C and resides in the module pymosek.<br />

Each method converts the call parameter data structures (i.e. creates a complete copy of the data),<br />

calls a <strong>MOSEK</strong> function and converts the returned values back into <strong>Python</strong> structures.<br />

<strong>The</strong> follwing rules will often improve the performance of the <strong>MOSEK</strong>/<strong>Python</strong> <strong>API</strong>:

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!