The file needed to run CONOPT, i.e. the file with the main program and the callback routines Tut_ReadMatrix and Tut_FDEval has an almost machine independent format. The file naming conventions and the way CONOPT is called is machine dependent.

A Makefile is included in each of the example directories Fort_1thread, Fort_OpenMP, C_1thread and C_OpenMP. By default, the call to make will build and run all examples. To run a single example, such as tutorial.f90, the user can call make tutorial. The call to make will build the Fortran examples using gfortran (linux, macos) or the Intel Fortran compiler (Windows). The C examples are built using clang (macos-arm64), gcc (linux, macos-x84_64) or the Intel C compiler (Windows). Following the build, it will link with the CONOPT library, and then run the executable module. In the process, it will produce some output one the screen. The screen output will depend on the machine but will typically consist of some information from the FORTRAN (C) compiler, some information from the linker or loader, and an iteration log from CONOPT (the so-called screen file mentioned in the section on the Message callback routine in the Reference Manual). The make process will stop if the user’s routines contain serious errors or if the linker encounters unsatisfied external references. The error message will depend on the Fortran (C) compiler or the linker or loader on the particular machine, and you should consult the relevant manual.

If no errors are found, CONOPT starts to optimize. In the process it will create a status file (<stem>.sta where <stem> is the name of the Fortran (C) file) and a documentation file (<stem>.lst). The tutorial.lst from the solution of our model built with gcc under Linux is shown below.

    C O N O P T   version 4.35
    Copyright (C) GAMS Software GmbH
                  GAMS Development Corporation
 
 
 Cannot find option file tutorial.opt
 Using default options.
 
 
    The user model has 3 constraints and 4 variables
    with 9 Jacobian elements, 4 of which are nonlinear.
 
    Iter Phase   Ninf   Infeasibility   RGmax      NSB   Step  InItr MX OK
       0   0          4.8771929825E+00 (Input point)
 
    The post-triangular part of the model has 2 constraints and 1 variables.
 
    Preprocessed model has 1 constraints and 3 variables
    with 3 Jacobian elements, 2 of which are nonlinear.
                      8.7719298246E-01 (Full preprocessed model)
                      8.7719298246E-01 (After scaling)
                      0.0000000000E+00 (After adjusting individual variables)
 
    Iter Phase   Ninf   Infeasibility   RGmax      NSB   Step  InItr MX OK
 
    Feasible solution. Value of objective =   0.469652200677
 
Search for an optimal solution.
 
 
    Iter Phase   Ninf     Objective     RGmax      NSB   Step  InItr MX OK
       1   3          5.6913410976E-01 4.5E-01       2 4.2E-01     1 F  T
       2   4          5.7291889698E-01 1.1E-01       2 1.0E+00     1 F  T
       3   4          5.7294297050E-01 8.8E-03       2 1.0E+00     1 F  T
       4   4          5.7294297132E-01 5.1E-05       2 1.0E+00     1 F  T
       5   4          5.7294297132E-01 9.4E-10       2
 
    Optimal solution. Reduced gradient less than tolerance.
 
...

The first part lists a default control program. The output from the optimization is shown next. It consists of the search for a feasible solution and the optimization itself, where CONOPT goes through a sequence of feasible points. The most interesting figures to watch are the infeasibility (Ninf), the objective function (Objective), and the largest reduced gradient, Rgmax. The optimization stops when Rgmax is small, usually somewhere between 1.E-7 and 1.E-9, depending on the model and its scaling and on the accuracy of real numbers on the machine used for the optimization. The detailed meaning of each figure in the iteration log is given in the GAMS/CONOPT solvers guide at CONOPT.

Note that the optimization path may vary from machine to machine and from one version of CONOPT to another. However, if the model is convex and therefore only has one solution the final solutions should be the same within the given precision. If the model is non-convex and has multiple local optima, running CONOPT on different machines or using different versions of CONOPT can lead to different solutions, even from the same starting point.

The final part of the listing file is the listing of the solution, in this case the optimal solution. The output from CONOPT is shown below. There is some status information, produced by Std_Status, followed by one section describing the variables and one section describing the constraints, produced by Std_Solution.

...
 
CONOPT has finished Optimizing
Model status    =        2
Solver status   =        1
Iteration count =        5
Objective value =   0.572943
 
 Variable   Solution value    Reduced cost    Status
 
     0          0.295686         -0.000000     Super
     1          0.295686         -0.000000     Super
     2          0.632019         -0.000000     Basic
     3          1.683990         -0.000000     Basic
 
 Constrnt   Activity level    Marginal cost   Status
 
     0          0.472943          0.000000     Basic
     1          0.000000         -1.367981     Lower
     2          4.000000          0.316010     Upper
 
 CONOPT time Total                            0.002 seconds
   of which: Function evaluations             0.000 =  0.0%
             1st Derivative evaluations       0.000 =  0.0%
 
... 

The variable section contains one line of information for each variable, with the index, the value of the variable, its reduced gradient or marginal cost, and its status (Lower, Upper, Basic, or Super). The reduced gradients of the variables labeled "Super" (for superbasic) in the Status column are the ones CONOPT tries to reduce to zero. If you try to rerun the model with a different initial point, on a different machine, or using a different version of CONOPT you will probably get slightly different values, but the differences should be within the optimality tolerance.

The constraint section contains one line for each constraint with information on the activity level of the constraint meaning the value of \(g(x)\), the marginal value or shadow price associated with the constraint, and the status of the constraint: Lower means that \(g(x) < b\) is binding, Upper that \(g(x) > b\) is binding, and Basic means that the slack variable in the constraint is in the basic and the constraint is therefore not binding. An equality constraint will be binding as Lower or Upper, depending on which of the two equivalent inequalities is binding.

The last few lines of the output show the total (CPU) time used by the execution part of CONOPT in COI_Solve. The total amount of memory allocated and used is also printed. These last numbers can be useful if you for some reason have to change the memory allocation.

...
 
 Memory: Max used =      0.02 Mbytes
  Total Allocated =      0.02 Mbytes