Knitro offers several features to exploit parallel computations on shared memory multi-processor machines. These features are implemented using OpenMP.


The parallel features offered through Knitro are not available through all interfaces. Check with your modeling language vendor to see if these features are included. The parallel features are included in the AMPL interface, the object-oriented interfaces, and through the callable library. Parallel features are also available through the MATLAB interface, but some may be less efficient in this environment.

Knitro offers the following parallel features:

Parallel Finite-Difference Gradients

As described in Derivatives, if you are unable to provide the exact first derivatives, Knitro offers the option to approximate first derivatives using either a forward or central finite-difference approach, by setting the option gradopt. Knitro will compute these finite difference gradient values in parallel if the user specifies that Knitro should use multiple threads through the option par_numthreads (see below). This parallel feature only applies to first derivative finite-difference evaluations.


In the Knitro-MATLAB interface, the parallel finite-difference feature is controlled by the UseParallel MATLAB option, rather than the Knitro par_numthreads option. See Knitro / MATLAB reference for more information.

Parallel Multistart

The multistart procedure described in Multistart can run in parallel by setting par_numthreads to use multiple threads.

When the multistart procedure is run in parallel, Knitro will produce the same sequence of initial points and solves that you see when running multistart sequentially (though, perhaps, not in the same order).

Therefore, as long as you run multistart to completion (ms_terminate =0) and use the deterministic option (ms_deterministic =1), you should visit the same initial points encountered when running multistart sequentially, and get the same final solution. By default ms_terminate =0 and ms_deterministic =1 so that the parallel multistart produces the same solution as the sequential multistart.

However, if ms_deterministic =0, or ms_terminate >0, there is no guarantee that the final solution reported by multistart will be the same when run in parallel compared to the solution when run sequentially, and even the parallel solution may change when run at different times.

The option par_msnumthreads can be used to set the number of threads used by the multistart procedure. For instance, if par_numthreads =16 and par_msnumthreads =8, Knitro will run 8 solves in parallel and each solve will be allocated 2 threads.

Parallel Algorithms

If the user option alg is set to multi, then Knitro will run all four algorithms (see Algorithms). When par_numthreads is set to use multiple threads, the four Knitro algorithms will run in parallel. The termination of the parallel algorithms procedure is controlled by the user option ma_terminate. See Algorithms for more details on the multi algorithm procedure.

Parallel Tuning

The Knitro-Tuner can help you identify some non-default options settings that may improve performance on a particular model or set of models. When par_numthreads is set to use multiple threads, Knitro will test the Tuner options in parallel.

Parallel Basic Linear Algebra Subroutine (BLAS)

The Knitro algorithms - in particular the interior-point/barrier algorithms - rely heavily on BLAS operations (e.g. dot products of vectors, dense matrix-matrix and matrix-vector products, etc.). For large-scale problems, these operations may often take 35%-50% of the overall solution time, and sometimes more.

These operations can be computed in parallel using multiple threads by setting the user option par_blasnumthreads >1 (by default par_blasnumthreads =1). This option is currently only active when using the default Intel BLAS (blasoption =1) provided with Knitro.

Parallel Sparse Linear System Solves

The primary computational cost each iteration in the Knitro interior-point algorithms is the solution of a linear system of equations. The linsolver user option specifies the linear system, solver to use. You can use the multi-threaded Intel MKL PARDISO solver in Knitro by choosing linsolver =6. By default the Intel MKL PARDISO solver will use one thread, however, it can solve linear systems in parallel by choosing par_lsnumthreads >1 (in combination with linsolver =6). It is also possible to use par_lsnumthreads >1 with the linear solvers MA86 and MA97.


Generally you should not use BOTH parallel BLAS and a parallel linear solver as they may conflict with each other. If par_blasnumthreads >1 one should set par_lsnumthreads =1 and vise versa.

Parallel Options

Option Meaning
par_numthreads Specifies the max number of threads to use for all parallel features. You can just set this and let Knitro decide how to distribute the threads.
par_concurrent_evals Whether or not to allow concurrent evaluations
par_blasnumthreads Specifies the number of threads to use for parallel BLAS (when blasoption =1)
par_lsnumthreads Specifies the number of threads to use for parallel linear system solves (when linsolver =6)
par_msnumthreads Specifies the number of threads to use for the parallel multi-start procedure.

The user option par_numthreads is used to determine the number of threads Knitro can use for all parallel computations. Knitro will decide how to apply the threads. If par_numthreads > 0, then the number of threads is determined by the value of par_numthreads. If par_numthreads = 0, then the number of threads is determined by the value of the environment variables OMP_NUM_THREADS. If par_numthreads = 0 and OMP_NUM_THREADS is not set, then the number of threads to use will be automatically deteremined by OpenMP. If par_numthreads < 0, Knitro will run in sequential mode.

Generally, if you are unsure of how best to apply parallel threads in Knitro you should just set the general option par_numthreads to the maximum number of threads you want Knitro to use, and leave par_blasnumthreads and par_lsnumthreads at their default values. Then Knitro will try to allocate work to these different threads in the most sensible way. Typically, if you are performing a single solve, the threads will get applied to the BLAS operations. If, for example, you are using multi-start then the multi-start solves are run in parallel but BLAS is sequential (typically applying 2 layers of parallelism is not good).

The options par_blasnumthreads and par_lsnumthreads allow the expert user more fine-grained control over parallelism of these specific features.

The user option par_blasnumthreads is used to determine the number of threads Knitro can use for parallel BLAS computations. This option is only active when using the default Intel BLAS (blasoption =1). The domain specific par_blasnumthreads, will override the general thread setting specified by par_numthreads for BLAS operations.

The user option par_lsnumthreads is used to determine the number of threads Knitro can use for parallel linear system solves. This option is only active when using the Intel MKL PARDISO linear solver (linsolver =6), the HSL MA97 linear solver (linsolver =7) and the HSL MA86 linear solver (linsolver =8). The domain specific par_lsnumthreads, will override the general thread setting specified by par_numthreads for linear system solve operations.

The user option par_msnumthreads is used to determine the number of threads to use for the multi-start procedure. See Multistart for more details.

The user option par_concurrent_evals determines whether or not the user provided callback functions used for function and derivative evaluations can take place concurrently in parallel (for possibly different values of “x”). If it is not safe to have concurrent evaluations, then setting par_concurrent_evals =0, will put these evaluations in a critical region so that only one evaluation can take place at a time. If par_concurrent_evals =1 then concurrent evaluations are allowed when Knitro is run in parallel, and it is the responsibility of the user to ensure that these evaluations are stable.

Preventing concurrent evaluations will decrease the efficiency of the parallel features, particularly when the evaluations are expensive or there are many threads and these evaluations create a bottleneck.

AMPL example

Let us consider again our AMPL example from Section Getting started with AMPL and run it with the parallel multi algorithm procedure. We specify that Knitro should run in parallel with four threads (one for each algorithm):

ampl: reset;
ampl: option solver knitroampl;
ampl: option knitro_options "alg=5 ma_terminate=0 par_numthreads=4";
ampl: model testproblem.mod;
ampl: solve;

The Knitro log printed to the screen shows the results of each algorithm (one per line):

          Commercial License
         Artelys Knitro 11.0.0

Knitro presolve eliminated 0 variables and 0 constraints.

algorithm:            5
datacheck:            0
hessian_no_f:         1
ma_terminate:         0
par_concurrent_evals: 0
par_numthreads:       4

Problem Characteristics                                 (   Presolved)
Objective goal:  Minimize
Objective type:  quadratic
Number of variables:                                  3 (           3)
    bounded below only:                               3 (           3)
    bounded above only:                               0 (           0)
    bounded below and above:                          0 (           0)
    fixed:                                            0 (           0)
    free:                                             0 (           0)
Number of constraints:                                2 (           2)
    linear equalities:                                1 (           1)
    quadratic equalities:                             0 (           0)
    gen. nonlinear equalities:                        0 (           0)
    linear one-sided inequalities:                    0 (           0)
    quadratic one-sided inequalities:                 1 (           1)
    gen. nonlinear one-sided inequalities:            0 (           0)
    linear two-sided inequalities:                    0 (           0)
    quadratic two-sided inequalities:                 0 (           0)
    gen. nonlinear two-sided inequalities:            0 (           0)
Number of nonzeros in Jacobian:                       6 (           6)
Number of nonzeros in Hessian:                        5 (           5)

Knitro running multiple algorithms in parallel with 4 threads.

   Alg      Status    Objective      FeasError   OptError   Real Time
--------  --------- --------------  ----------  ---------- ----------
       2         0    9.360000e+02   0.000e+00   1.945e-07      0.002
       1         0    9.360000e+02   6.738e-08   6.614e-08      0.002
       4         0    9.360000e+02   0.000e+00   2.387e-12      0.005
       3         0    9.360000e+02   0.000e+00   0.000e+00      0.010
Multiple algorithms stopping, all solves have completed.

EXIT: Locally optimal solution found.

Final Statistics
Final objective value               =   9.35999997829394e+02
Final feasibility error (abs / rel) =   6.74e-08 / 5.18e-09
Final optimality error  (abs / rel) =   6.61e-08 / 4.13e-09
# of iterations                     =         16
# of CG iterations                  =         12
# of function evaluations           =         28
# of gradient evaluations           =         24
# of Hessian evaluations            =         16
Total program time (secs)           =       0.01169 (     0.023 CPU time)


Knitro 11.0.0: Locally optimal or satisfactory solution.
objective 935.9999978293937; feasibility error 6.74e-08
16 iterations; 28 function evaluations

As can be seen, all four Knitro algorithms solve the problem and find the same local solution. However, the two interior-point algorithms (alg=1 and 2) are the fastest.

C example

As an example, the C example can also be easily modified to enable parallel multi-algorithms by adding the following lines before the call to KN_solve():

// parallelism
if (KN_set_int_param_by_name (kc, "algorithm", KN_ALG_MULTI) != 0)
exit( -1 );
if (KN_set_int_param_by_name (kc, "ma_terminate", 0) != 0)
exit( -1 );
if (KN_set_int_param_by_name (kc, "par_numthreads", 4) != 0)
exit( -1 );

Again, running this example we get a Knitro log that looks simlar to what we observed with AMPL.