Logging

Logging related parameters and functions are essential for users to control the display of solving logs of COPT. This chapter provides an interpretation of loggings for different algorithms, including the following sections:

Parameters and Functions for Logging

Users can control whether to show logs and how detailed they are by setting logging-related arguments.

  • Logging

    Integer argument.

    Whether to print optimization logs.

    Default: 1

    Possible values:

    0: Do not print optimization logs.

    1: Print optimization logs.

  • LogLevel

    Integer argument.

    Controls the level of detail in the optimization logs.

    Default: 2

    Possible values:

    2: Print basic optimization logs.

    3: In addition to the basic logs, print memory usage information (for MIP problems).

  • LogToConsole

    Integer argument.

    Whether to print optimization logs to the console.

    Default: 1

    Possible values:

    0: Do not print logs to the console.

    1: Print logs to the console.

COPT provides operations related to logs, such as setting the logging file. COPT provides functions to set the logging file, write the optimization logs into the specified file (with the file name suffix .log ), allowing users to save and review the logs. The functions for different programming interfaces are shown in Table 51:

Table 51 Functions for setting logging files in different programming interfaces

Programming Interface

Functions for setting logging files

C

COPT_SetLogFile

C++

Model::SetLogFile()

C#

Model.SetLogFile()

Java

Model.setLogFile()

Python

Model.setLogFile()

Note: When calling these functions, users should specify the file name for saving logs using the logfile parameter.

Basic Information Section

COPT outputs basic information before starting the solving process, depending on the problem types. The following information is typically displayed:

This section prints the overview information of the model and optimization task, such as model size and presolve results, and the numerical characteristics, helping users quickly understand the problem structure and numerical status.

Solver Environment and Model Overview

At the beginning of the log, COPT prints an overview of the solver environment and the model, including the model fingerprint (fingerprint), COPT version, platform, and problem type.

Example:

Using Cardinal Optimizer v8.0.1 on Windows
Model fingerprint: 2c27ab28
Hardware has 64 cores and 128 threads. Using instruction set X86_AVX512_E1 (14)
Minimizing a MIP problem

Here, Model fingerprint is a unique identifier of the current model. Hardware information includes CPU cores (cores) and threads (threads). COPT automatically detects the problem type and optimization sense, and then selects appropriate algorithms to solve it, for example:

Minimizing an LP problem, Minimizing a MIP problem, Minimizing an SDP problem, etc.

Model Size and Presolve

First, COPT prints the size of the original model, for example:

The original problem has:
    404 rows, 1200 columns and 2598 non-zero elements
    200 binaries and 1000 integers

For LP problems, the size includes:

  • Constraints (rows)

  • Variables (columns)

  • Nonzeros in the constraint matrix (non-zero elements)

For MIP problems, it additionally includes integer-variable statistics:

  • Binary variables (binaries)

  • General integer variables (integers)

Note

  • For MIP problems, the variable count (columns) includes all variables in the model: continuous, integer, and binary.

  • In theory, binaries are a special case of integer variables, but here they are reported separately.

For nonlinear problems, the log also reports corresponding nonlinear structures, for example:

  • Semidefinite variables (PSD columns)

  • Quadratic terms in the objective (quadratic objective elements)

  • Quadratic constraints (quadratic constraints)

  • Second-Order cones (SOC rows)

  • Exponential cones (exponential cones)

With default settings, before the optimization starts, COPT presolves to transform or reduce the original model to improve quality; the algorithm then works on the presolved model. The presolve part prints the model sizes. Example:

Presolving the problem
The presolved problem has:
    373 rows, 1169 columns and 2505 non-zero elements
    369 binaries and 800 integers

Problem Numerical Characteristics

This part prints key numerical characteristics of the model to help assess numerical issue (e.g., whether coefficient ranges span too many orders of magnitude). The items are:

  • Range of matrix coefficients: Range of the constraint matrix coefficients

  • Range of rhs coefficients: Range of right-hand-side coefficients

  • Range of bound coefficients: Range of variable bounds

  • Range of cost coefficients: Range of objective function coefficients

  • Density of cost: Density of the objective coefficients (ratio of nonzeros)

Example:

Problem info:
    Range of matrix coefficients:    [5e-01,4e+00]
    Range of rhs coefficients:       [7e+02,2e+04]
    Range of bound coefficients:     [8e+02,3e+03]
    Range of cost coefficients:      [6e-02,3e-01]

Simplex Logging

Based on different stages of the optimization process, the logs for Simplex Method can be divided into two parts:

  1. Simplex iteration process

  2. Summary of optimization results

This section uses the logs for example problem afiro.mps to interpret the information in the Simplex Method logging.

Simplex Iteration Process

This part of the logs provides relevant information about the iteration process using the Simplex method.

Starting the simplex solver using up to 8 threads

Method   Iteration           Objective  Primal.NInf   Dual.NInf        Time
Dual             0   -4.8553789460e+02            3           0       0.00s
Dual             3   -4.6476735494e+02            0           0       0.00s
Postsolving
Dual             3   -4.6475314286e+02            0           0       0.00s

Here, the first line indicates that the current optimization algorithm is the Simplex method, and it uses 8 threads (threads) for computation.

The subsequent lines represent the simplex iteration process with 6 columns:

  • Method: The optimization algorithm used, where "Dual" represents the dual simplex method.

  • Iteration: The number of iterations.

  • Objective: The objective function value.

  • Primal.NInf: The number of primal infeasibilities in the primal problem.

  • Dual.NInf: The number of dual infeasibilities in the dual problem.

  • Time: The time taken for solving (in seconds).

Solution Summary

This part of the logs summarizes the results and the iteration process of the Simplex method after completing the solving process.

Solving finished
Status: Optimal  Objective: -4.6475314286e+02  Iterations: 3  Time: 0.00s

The included information consists of:

  • Solving status (Status): If the model has an optimal solution, it is Optimal.

  • Objective function value (Objective): If the model has an optimal solution, Objective displays the optimal objective function value.

  • Total number of iterations (Iterations).

  • Total solving time (Time).

If the model is infeasible, the corresponding log output is as follows:

Solving finished
Status: Infeasible  Objective: -  Iterations: 2  Time: 0.00s

Barrier Logging

By solution phase, the Barrier log consists of two parts:

  1. Barrier solution Process

  2. Solution summary

Note: By setting the optimization parameter "LpMethod = 2", you can choose the Barrier method as the algorithm for solving linear programming problems.

Again, we take afiro.mps as an example to explain the Barrier log for LP.

Barrier Iteration Process

First, the log prints numerical information related to Barrier:

Starting barrier solver using 64 threads

Problem info:
Dualized in presolve:            No
Range of matrix coefficients:    [4e-01,4e+00]
Range of rhs coefficients:       [8e+01,3e+02]
Range of bound coefficients:     [4e+01,1e+02]
Range of cost coefficients:      [2e-01,2e+00]

Factor info:
Number of free columns:          0
Number of dense columns:         0
Number of matrix entries:        2.800e+01
Number of factor entries:        2.800e+01
Number of factor flops:          1.140e+02

The first line shows the algorithm (Barrier) and thread count (threads). Then:

  • Problem info includes whether the model is dualized in presolve, and the ranges of matrix, RHS, bounds, and costs.

  • Factor info includes the number of free columns, dense columns, and factorization-related statistics.

Next comes the Barrier iteration table, which reports iteration (Iter), objectives, and time:

  • Iter: Iteration number

  • Primal.Obj: Primal objective

  • Dual.Obj: Dual objective

  • Compl: Complementarity violation

  • Primal.Inf: Primal infeasibility

  • Dual.Inf: Dual infeasibility

  • Time: Elapsed time (s)

Iter       Primal.Obj         Dual.Obj      Compl  Primal.Inf  Dual.Inf    Time
   0  +2.07010046e+01  -4.97632246e+02   5.89e+03    4.50e+02  2.65e+00   0.02s
   1  -1.18912241e+02  -5.91808560e+02   7.58e+02    3.36e+01  1.61e-01   0.02s
   2  -3.98096520e+02  -4.77597371e+02   2.28e+02    9.32e+00  7.45e-02   0.02s
   3  -4.55223227e+02  -4.68222895e+02   1.86e+01    3.60e-01  2.63e-03   0.02s
   4  -4.64587726e+02  -4.64803786e+02   2.52e-01    7.80e-03  7.93e-06   0.02s
   5  -4.64753143e+02  -4.64753143e+02   3.11e-07    7.80e-09  1.56e-11   0.02s

Barrier Summary

Key items include solution status, primal/dual optimal objectives, etc.

Barrier status:                  OPTIMAL
Primal objective:                -4.64753143e+02
Dual objective:                  -4.64753143e+02
Duality gap (abs/rel):           2.61e-07 / 5.63e-10
Primal infeasibility (abs/rel):  7.80e-09 / 2.60e-11
Dual infeasibility (abs/rel):    1.56e-11 / 6.99e-12

Crossover

Starting crossover using up to 8 threads

    1 primal pushes remaining      0.03s
    0 primal pushes remaining      0.03s
    1 dual pushes remaining        0.03s
    0 dual pushes remaining        0.03s

Method   Iteration           Objective  Primal.NInf   Dual.NInf        Time
Dual             1   -4.6475314286e+02            0           0       0.03s
Postsolving
Dual             1   -4.6475314286e+02            0           0       0.03s

Solution Summary

Printed after solving finishes; it summarizes the model solution and the (final) crossover cleanup.

Solving finished
Status: Optimal  Objective: -4.6475314286e+02  Iterations: 1  Time: 0.03s

Same as the Simplex log, it includes:

  • Status: If the model is solved to optimality, the status will be Optimal

  • Objective: If solved to optimality, the optimal objective value

  • Iterations: Total iterations

  • Time: Total solving time

Branch-and-Cut Logging

By solution phase, the Branch-and-Cut log consists of two parts:

  1. Search Process

  2. Solution Summary

We use the cutstock.mps.gz example (available under /examples/data in the COPT installation) to explain the MIP log.

Branch-and-Cut Search Process

This section of the log provides information about the Branch-and-Cut search process.

Starting the MIP solver with 8 threads and 32 tasks

    Nodes    Active  LPit/n  IntInf     BestBound  BestSolution    Gap   Time
        0         1      --       0  3.100000e+01            --    Inf  0.05s
H       0         1      --       0  3.100000e+01  6.800000e+01  54.4%  0.70s
H       0         1      --       0  3.100000e+01  6.600000e+01  53.0%  0.70s
H       0         1      --       0  3.100000e+01  6.500000e+01  52.3%  0.71s
        0         1      --      86  5.591304e+01  6.500000e+01  14.0%  0.72s
H       0         1      --      86  5.591304e+01  6.200000e+01  9.82%  0.74s
        1         2     0.0      86  5.591304e+01  6.200000e+01  9.82%  0.76s
H       1         1    2129       6  6.000000e+01  6.000000e+01  0.00%  0.87s
        2         0    1064       6  6.000000e+01  6.000000e+01  0.00%  0.87s
        2         0    1064       6  6.000000e+01  6.000000e+01  0.00%  0.87s

Note: For brevity, only a portion of the log is shown for explanation.

By meaning, the columns can be grouped as follows; we explain each group below:

  • Node search information (columns 1-4)

  • Feasible solution interval information (columns 5-7)

  • Solving time information (column 8)

Node search information (columns 1-4):

  • Nodes: Number of nodes searched

  • Active: Number of leaf nodes yet to be searched

  • LPit/n: Average simplex iterations per node

  • IntInf: Number of integer variables that are fractional in the current LP relaxation

Feasible solution interval information (columns 5-7):

  • BestBound: Current best bound on the objective

  • BestSolution: Current incumbent objective value

  • Gap: Relative gap between bound and incumbent. If it drops below the RelGap threshold, solving process stops

Solving time information (column 8):

  • Time: Total solving time

Notes

  • The prefix before the first column (H/*) indicates a new incumbent solution:

    • H: Found by a heuristic

    • *: Found by branching (subproblem) search

  • Sometimes Nodes remains 0 for a while, which means COPT is still processing the root node—typically generating cuts or running heuristics to obtain a good incumbent, in order to reduce subsequent search.

Solution Summary

Printed after solving finishes, it summarizes the final MIP status and the search effort, including the model solution and search workload.

Best solution   : 60.000000000
Best bound      : 60.000000000
Best gap        : 0.0000%
Solve time      : 0.87
Solve node      : 2
MIP status      : solved
Solution status : integer optimal (relative gap limit 0.0001)

Violations    :     absolute     relative
bounds        :            0            0
rows          :            0            0
integrality   :            0

Solution summary includes:

  • Best objective (Best solution)

  • Best bound (Best bound)

  • Best gap (Best gap)

  • Solution status (Solution status)

Search workload includes:

  • Solve time (Solve time)

  • Number of explored nodes (Solve node)

The Violations block reports the satisfaction of bounds and constraints at the solution, including:

  • Violations in variable bounds (bounds) and constraints (rows)

  • Integrality violations (integrality)

First-order Method (PDLP) Logging for GPU Solver

For Linear Programming Problems, if the PDLP method is selected (setting the parameter LpMethod=6 ), GPU solver can be enabled. (The machine needs the compatible GPU and the necessary CUDA library needs to be configured).

The logging for GPU solver can be divided into the following sections, which are slightly different from the CPU solver, with the main distinction in the second section:

  1. GPU hardware information of the machine

  2. First-order method PDLP iteration process

  3. Crossover section

  4. Summary of optimization results

Taking the "thk_63" instance from public LP benchmark as an example, the following is the solving log for the GPU solver.

GPU Hardware Information

This section outputs information about the current machine’s GPU information and CUDA version.

Hardware has 1 supported GPU device with CUDA 12.3
  GPU 0: NVIDIA GeForce RTX 4090 (CUDA capability 8.9)

Notes

  1. The "CUDA 12.3" mentioned in the log refers to the highest version of the CUDA Toolkit supported by the currently installed CUDA driver.

  2. COPT’s GPU solver requires a minimum CUDA Toolkit version of 12.0.1.

First-order Method(PDLP) Iteration Process

This section outputs the solving iteration process of the PDLP method, and the summary after the completion, including the iteration count of PDLP, and the optimal objective values, dual gaps for primal and dual problems.

Starting PDLP solver on GPU 0

Iterations      Primal.Obj        Dual.Obj         Gap  Primal.Inf  Dual.Inf    Time
        0  +6.00000000e+00  +6.00000000e+00  +0.00e+00    7.87e+00  0.00e+00  21.63s
     4000  +1.95436674e+03  -1.77166004e+03  +3.73e+03    2.09e-02  0.00e+00  33.37s
     8000  +1.90433201e+03  +1.55817851e+03  +3.46e+02    1.51e-02  0.00e+00  44.75s
    12000  +1.87801607e+03  +1.85689627e+03  +2.11e+01    1.74e-02  0.00e+00  56.27s
    16000  +1.86810632e+03  +1.86897715e+03  +8.71e-01    4.92e-03  0.00e+00  67.72s
    20000  +1.87022842e+03  +1.86994685e+03  +2.82e-01    3.42e-03  0.00e+00  79.18s
    23640  +1.87099459e+03  +1.87099144e+03  +3.15e-03    4.69e-05  0.00e+00  89.68s

PDLP status:                     OPTIMAL
PDLP iterations:                 23640
Primal objective:                1.87099459e+03
Dual objective:                  1.87099144e+03
Primal infeasibility (abs/rel):  4.69e-05 / 6.20e-07
Dual infeasibility (abs/rel):    0.00e+00 / 0.00e+00
Duality gap (abs/rel):           3.15e-03 / 8.43e-07

Experimental: using crossover to find a basic solution after PDLP
Please set parameter Crossover to 0 if the basic solution is not required
Please set parameter PDLPTol to a smaller value if the crossover cleanup takes too long

Starting crossover using up to 8 threads

50320 primal pushes remaining     92.09s
12495 primal pushes remaining     97.71s
 4124 primal pushes remaining       102s
  202 primal pushes remaining       104s
    0 primal pushes remaining       104s
1480858 dual pushes remaining       104s
 589582 dual pushes remaining       106s
      0 dual pushes remaining       107s

Method   Iteration           Objective  Primal.NInf   Dual.NInf        Time
Dual        986011    1.8710000000e+03            0           0     107.97s
Postsolving
Dual        986011    1.8710000000e+03            0           0     110.56s
Unfolding
Dual       1036742    1.8710000000e+03            0           0     157.25s

Solving finished
Status: Optimal  Objective: 1.8710000000e+03  Iterations: 1036742  Time: 157.69s

Note: After solving with a First-order method (PDLP), if the solution reaches optimality (Status: Optimal), the default behavior is to perform the Crossover process to the basic solution. This process can also be disabled by setting the parameter Crossover to 0.