oxfordcontrol / clarabel.cpp Goto Github PK

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.

Hi there,

In rust you can simply override the settings, but using this interface the same does not seem possible. At least I can not figure out how.

My problem initially came since I wanted to try out the faer-solver, but my json model came from Julia which do not support that (Turns out that you can actually export to the faer solver from Julia by setting direct_solve_method=:faer, since it does not check if the field is an actual available solver). However, I would like to avoid having a json file for each solver.

Best,
Mikkel

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

Hello,

I'm running Clarabel with c++. I found that I cannot update P and A matrices with different sparsity structures using the functions that claim to do a full rewrite. Any suggestions on this?

inline void DefaultSolver<double>::update_P(const Eigen::SparseMatrix<double, Eigen::ColMajor> &P){
    ConvertedCscMatrix matrix_P = DefaultSolver<double>::eigen_sparse_to_clarabel(P);
    CscMatrix<double> mat(matrix_P.m, matrix_P.n, matrix_P.colptr.data(), matrix_P.rowval.data(), matrix_P.nzval);
     clarabel_DefaultSolver_f64_update_P_csc(this->handle,&mat);
}

// DefaultSolver::update_P (full rewrite of sparse matrix data using CSC formatted source)
ClarabelDefaultInfo_f64 clarabel_DefaultSolver_f64_update_P_csc(ClarabelDefaultSolver_f64 *solver, const ClarabelCscMatrix_f64 *P);

Also, I have to disable presolve to avoid the following error when updating without changing the sparsity structure. It seems like this might be standard as data_updating.cpp used the same setting, but it felt concerning.

thread '<unnamed>' panicked at src/solver/implementations/default/data_updating.rs:35:54:
called `Result::unwrap()` on an `Err` value: PresolveEnabled
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5

A common pattern is to have C++ dependencies provisioned via git submodule. These dependencies can then be included via add_subdirectory, however this fails with Clarabel.cpp because Clarabel.cpp expects to be the top-level project:

if(CMAKE_BUILD_TYPE MATCHES Release)
   set(clarabel_c_build_flags "--release")
   set(clarabel_c_output_directory "${CMAKE_SOURCE_DIR}/rust_wrapper/target/release")
else()
    set(clarabel_c_build_flags "")
    set(clarabel_c_output_directory "${CMAKE_SOURCE_DIR}/rust_wrapper/target/debug")
endif()

If Clarabel.cpp is not the top-level project, it will fail to build, because directories like rust_wrapper won't be found.

If you download the repository fresh, and attempt to build with Ninja, the build fails with the following error:

ninja: error: '/Users/alecto/3rd/Clarabel.cpp/rust_wrapper/target/debug/libclarabel_c.dylib', needed by 'examples/c/example_expcone', missing and no known rule to make it

This is because Ninja can't find libclarabel_c.a/libclarabel_c.dylib, and the libclarabel_c custom target doesn't inform Ninja that it produces these libraries.

This can be handled by adding LIBCLARABEL_C_SHARED_PATH and LIBCLARABEL_C_STATIC_PATH as byproducts of the call to add_custom_target

Hi there,

I wanted to try out the Chordal decomposition added in 0.8 using the C++ wrapper. Turned out I needed to do a few modifications to the wrapper due to the API additions. At the same time I noticed that a few tests were missing, so I added them. The changes can be seen on my fork

If you want I can make a PR. That being said, I am not very experienced in C++ and Rust, so my code is probably substandard.

Cheers,
Mikkel

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.

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.

When attempting to build the library with Apple Clang, the build fails with the following error:

/Users/alecto/3rd/eigen/Eigen/src/Core/util/Macros.h:709:2: error: Eigen requires at least c++14 support.
#error Eigen requires at least c++14 support.
 ^

Current versions of gcc and llvm clang use C++17 by default, so CMake doesn't bother to pass the -std=c++11 flag, which is likely why this wasn't caught previously.

CMake should ensure that Eigen is at least version 3.4.0, since the library appears not to build will earlier versions.

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