oxfordcontrol / clarabel.cpp Goto Github PK

Clarabel.cpp: C/C++ interface to the Clarabel Interior-point solver for convex conic optimisation problems.

License: Apache License 2.0

CMake 3.79% C 22.34% C++ 49.14% Rust 24.73%

c conic-optimization conic-programs convex-optimization cpp interior-point-method linear-programming optimization optimization-algorithms quadratic-programming semidefinite-programming

clarabel.cpp's Introduction

Features • Installation • License • Documentation

Clarabel.cpp is a C/C++ wrapper of Clarabel.rs.

Installation

Note: The C++ interface is WIP and there might be breaking changes in future releases.

Clarabel.cpp uses CMake to generate the build system and requires the following dependencies:

Rust
Clarabel.rs (included as a submodule)
A compiler that supports C11 and C++11
Eigen (optional for the C++ interface)

You may install Eigen via the system package manager on Unix-like systems or vcpkg on Windows.

Follow the vcpkg instructions to compile vcpkg and add vcpkg.exe to PATH.

Ubuntu:

sudo apt install libeigen3-dev

Windows:

vcpkg install eigen3:x64-windows

For 32-bit platforms, use eigen3:x86-windows instead of eigen3:x64-windows.

Clone this repo

git clone --recurse-submodules https://github.com/oxfordcontrol/Clarabel.cpp.git
cd Clarabel.cpp

Build

mkdir build
cd build
cmake ..
cmake --build .

You may specify a particular build system using the -G flag for cmake (e.g. -G "Unix Makefiles").

Windows

If you are using vcpkg on Windows, you may find the vcpkg toolchain file using:

vcpkg integrate install

and then specify the vcpkg toolchain file path and target triplet to generate the build system using:

cmake .. -DCMAKE_TOOLCHAIN_FILE=VCPKG_TOOLCHAIN_PATH -DVCPKG_TARGET_TRIPLET=x64-windows

where VCPKG_TOOLCHAIN_PATH is the path to the vcpkg toolchain file.

For 32-bit platforms, use x86-windows instead of x64-windows.

CMake options

SDP support

To enable SDP features, set the CLARABEL_FEATURE_SDP option to one of the following values:

sdp-accelerate
sdp-netlib
sdp-openblas
sdp-mkl
sdp-r

By default, CLARABEL_FEATURE_SDP is none and SDP support is disabled.

Unit tests

By default, unit tests are disabled to reduce build time. To enable unit tests, set the CLARABEL_BUILD_TESTS option to 'true'.

Run examples

Examples for both C and C++ are available in examples/c and examples/cpp and can be run from the build directory using:

./examples/c/C_EXAMPLE
./examples/cpp/CPP_EXAMPLE

Usage

Link to the libclarabel_c_shared (shared library) or libclarabel_c_static (static library) target in CMake.
#include <Clarabel> in your C/C++ source files.

License 🔍

This project is licensed under the Apache License 2.0 - see the LICENSE.md file for details.

clarabel.cpp's People

Contributors

Stargazers

Watchers

Forkers

maxschaller ghorn jwnimmer-tri mjt123 acados mipals

clarabel.cpp's Issues

solution.obj_val is not set

At the termination, should I expect that solution.obj_val is the objective value? I ran https://github.com/oxfordcontrol/Clarabel.cpp/blob/main/examples/cpp/example_lp.cpp and also print out solution.obj_val, the log shows that the objective value is -2, but std::cout << "obj_val: " << solution.obj_val << "\n" prints 5e-5. Here is my print out

-------------------------------------------------------------
           Clarabel.rs v0.0.0  -  Clever Acronym

                   (c) Paul Goulart
                University of Oxford, 2022
-------------------------------------------------------------

problem:
  variables     = 2
  constraints   = 4
  nnz(P)        = 0
  nnz(A)        = 4
  cones (total) = 1
    : Nonnegative = 1,  numel = 4

settings:
  linear algebra: direct / qdldl, precision: 64 bit
  max iter = 200, time limit = Inf,  max step = 0.990
  tol_feas = 1.0e-8, tol_gap_abs = 1.0e-8, tol_gap_rel = 1.0e-8,
  static reg : on, ϵ1 = 1.0e-8, ϵ2 = 4.9e-32
  dynamic reg: on, ϵ = 1.0e-13, δ = 2.0e-7
  iter refine: on, reltol = 1.0e-13, abstol = 1.0e-12,
               max iter = 10, stop ratio = 5.0
  equilibrate: on, min_scale = 1.0e-4, max_scale = 1.0e4
               max iter = 50

iter    pcost        dcost       gap       pres      dres      k/t        μ       step
---------------------------------------------------------------------------------------------
  0  +0.0000e+00  -6.0000e+00  6.00e+00  0.00e+00  0.00e+00  1.00e+00  1.40e+00   ------
  1  -9.1640e-01  -2.0400e+00  1.12e+00  8.16e-17  1.02e-16  1.93e-01  2.63e-01  8.25e-01
  2  -1.9880e+00  -2.0193e+00  1.58e-02  3.00e-17  4.10e-17  6.96e-03  7.66e-03  9.90e-01
  3  -1.9999e+00  -2.0002e+00  1.57e-04  1.20e-16  0.00e+00  6.97e-05  7.67e-05  9.90e-01
  4  -2.0000e+00  -2.0000e+00  1.57e-06  1.83e-13  2.20e-13  6.97e-07  7.67e-07  9.90e-01
  5  -2.0000e+00  -2.0000e+00  1.57e-08  3.66e-15  4.39e-15  6.97e-09  7.67e-09  9.90e-01
  6  -2.0000e+00  -2.0000e+00  1.57e-10  8.47e-17  8.20e-17  6.97e-11  7.67e-11  9.90e-01
---------------------------------------------------------------------------------------------
Terminated with status = Solved
solve time = 57.906µs
Solution (x)     = [-0.9999999999, 0.9999999999]
Multipliers (z)  = [0.0000000000, 1.0000000000, 1.0000000000, 0.0000000000]
Slacks (s)       = [1.9999999999, 0.0000000001, 0.0000000001, 1.9999999999]
obj_val: 5e-05

provide different header for C vs C++ interfaces

Right now there is one public header: include/Clarabel. This header conditionally includes either the C interface or the C++ interface depending on whether __cplusplus is defined.

My application is C++ but I'm using Clarabel through cvxpygen, which code-generates a convex problem and an interface to various solvers. Cvxpygen uses the C interface to Clarabel.cpp, but when I include the cvxpygen headers it into my C++ application, include/Clarabel picks up that I'm a C++ program and includes the C++ interface. This causes a conflict.

RIght now I have a workaround where I rewrite include/Clarabel to only ever use the C interface, but I think a better solution would be to have a C header include/Clarabel.h and a C++ header include/Clarabel.

unicode μ causes problems on older compilers

Using GCC 9.4, I had a build error where the C interface would not accept the unicode μ character. GCC 9.4 is not old (June 2021) or uncommon (I came across it using an nvidia toolchain for a new product).

Is it possible to use "mu" in the C++ part and "μ" in the rust part? My workaround was a global find-replace but that doesn't help other people.

release is missing rust submodule

The V0.6.0 release has an empty Clarabel.rs/ folder. Whatever script builds the release could be missing the git clone --recurse-submodules part.

Inaccurate solution for simple QP problem

Hi @goulart-paul, I was noticing some strange results with Clarabel (using v0.7.0) and I was able to reproduce it in the form of a simple QP with 2 variables, 1 equality constraint and 2 inequality constraints. The code in C++ looks like this:

  MatrixXd P_dense(2, 2);
  P_dense << 2., 0., 0., 4.;

  SparseMatrix<double> P = P_dense.sparseView();
  P.makeCompressed();

  Vector<double, 2> q = {-2., 0.};

  MatrixXd A_dense(3, 2);
  A_dense << 1., 1.,
    -1., 0.,
    0., -1.;

  SparseMatrix<double> A = A_dense.sparseView();
  A.makeCompressed();

  Vector<double, 3> b = {1., 0., 0.};

  vector<SupportedConeT<double>> cones{
    ZeroConeT<double>(1),
    NonnegativeConeT<double>(2),
  };

  DefaultSettings<double> settings = DefaultSettings<double>::default_settings();

  DefaultSolver<double> solver(P, q, A, b, cones, settings);

  solver.solve();
  DefaultSolution<double> solution = solver.solution();

The correct solution should be (1, 0), but the solution that is provided has an error of 1e-4 even though Clarabel reports primal and dual feasibility of 1e-12.
Obtained solution from Clarabel = 0.999967 3.31364e-05

I attached the complete output as a txt file. Do you have any idea what is going wrong for this problem?
simple_qp_output.txt