acados / acados Goto Github PK

Generate also problem instances with varying nx/nu to make sure that all interfaced solvers work correctly in this case too (after implementing condensing with variable dimensions though).

We should update the current script to also save the optimal solution of the generated QP (primal/dual solution for unconstrained, bounds-only, affine-only and constrained cases) to use it in the unit tests. IMPORTANT: do not forget to set quadprog accuracy to the maximum.

Some c examples are currently giving segfaults (e.g. pendulum examples). We should (a) fix them and perhaps (b) run the examples in travis to check every time that they are running properly.

@giaf suggested to introduce N+1 controls (where the last control has always dimension 0) such that we avoid treating the last state separately at the end of the loop in many cases. Parts of the code that are already written with N controls in mind will anyway remain unaffected by this change. I wanted to point this out to everyone such that you don't think that this for instance is a typo and to make sure that everyone agrees. We should also update the documentation in this case.

Two questions regarding the dual multiplier fields of ocp_qp_out:

1. are we sure we don't want to distinguish between bounds and polyhedral constraints and go for all of them concatenated (and in an order that we should always look back to)?
   2)why don't we merge the multipliers of upper and lower bounds to have nb[k]+nc[k] (btw, there's a typo in the reference.pdf, it says ng[k] instead of nc[k]) instead of 2nb[k]+2nc[k]?

The current implementation of the condensing+qpOASES solver does not yet work with variable state and control dimensions on the different stages (even though you could define different dimensions in the current version of the interface).

I would like to open this issue to start a discussion about the use of BLASFEO in ACADOS.

At the moment, BLASFEO is in early stage, but it looks promising.

A key feature is the use of a C struct to define a matrix and therefore completely hide all details about the matrix format and the like.
The idea is to have at least two implementations: one based on custom LA routines optimized for embedded optimization (see HPMPC LA), one as a wrapper on top of BLAS.

This feature can be the key for an early adoption of BLASFEO. It is easy and relatively quick and bug-free to write the wrappers on top of BLAS, and therefore it would be possible to get started with BLASFEO very soon. As soon as the custom LA routines are ready, it would be possible to switch to them by just changing a compilation flag in BLASFEO itself.

It would also be possible to add the reference (Netlib) BLAS and LAPACK implementations to BLASFEO itself, in order to make it pretty much self-contained. Then if better implementations are available (e.g. OpenBLAS or MKL), they could be used instead.

The main drawback of the fact that the matrix struct can have different implementations is that it is not possible to operate on it directly, but proper functions have to be used also e.g. to access the single matrix elements or extract a row/column from a matrix.

Today I installed acados on a new pc, and I got this compilation error
CMake Error: Directory does not exist for chdir command: /home/gianluca/acados/external/casadi/build
Once created the missing folder, I get
make: *** No targets specified and no makefile found. Stop.
since there is no makefile there.
The solution is to run cmake .. manually from the casadi/build directory.

I'm not very expert with cmake, but is there a way to automate this process, i.e. be able to compile casadi directly form the acados cmake?

It would be nice if building with the test flag and without casadi-octave in external software would generate an error in cmake similarly to eigen.

We just had a short discussion about memory and workspace usage in QP solvers together with @giaf and @dkouzoup. In particular, @giaf pointed out that, by storing stuff like cost and dynamics matrices in the workspace, the overall memory footprint could be reduced (given that the memory associated with the QP workspace could be reused for other modules (including other QP solvers), while memory allocated for the QP memory could not). On the other side, this complicates things from a user perspective and could cause inefficiency in some cases when cost and dynamics matrices should be fixed (e.g. in linear MPC or inexact methods where part of the sensitivities are fixed). We eventually agreed on storing this kind of things in the memory to simplify things, but we also thought some other people might have a different opinion and that it could be fruitful to discuss this now as we start unifying memory and workspace usage. Any comment/advice is more than welcome!

Hi,

when I tried to install acados on a freshly setup Ubuntu 17.04 with cmake installed I got the following error:

$ cmake ..
-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done

-- No build type chosen. Valid build types are:
   Release (default), Debug, Test, NoExternalLibs


 --- Configuring acados with build type: Release ---


-- acados will be installed in /home/tobi/local
CMake Error at /usr/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:138 (message):
  Could NOT find SWIG (missing: SWIG_EXECUTABLE SWIG_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.7/Modules/FindSWIG.cmake:63 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  swig/CMakeLists.txt:22 (find_package)

-- Configuring incomplete, errors occurred!
See also "/home/tobi/Documents/acados/build/CMakeFiles/CMakeOutput.log".

Up to there everything seemed to have gone smoothly.

I tried installing swig which did not resolve the issue (so far). Now I get:

$ cmake ..             

-- No build type chosen. Valid build types are:
   Release (default), Debug, Test, NoExternalLibs


 --- Configuring acados with build type: Release ---


-- acados will be installed in /home/tobi/local
-- Found SWIG: /usr/bin/swig3.0 (found version "3.0.10") 
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.3", minimum required is "3") 
CMake Error at /usr/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:138 (message):
  Could NOT find PythonLibs (missing: PYTHON_LIBRARIES PYTHON_INCLUDE_DIRS)
  (Required is at least version "3")
Call Stack (most recent call first):
  /usr/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.7/Modules/FindPythonLibs.cmake:255 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  swig/CMakeLists.txt:35 (find_package)


-- Configuring incomplete, errors occurred!
See also "/home/tobi/Documents/acados/build/CMakeFiles/CMakeOutput.log".

What am I missing? - Please let me know if you need further details.

Cheers,

Tobi

Unit testing is certainly going to be an important part for acados, as we want to be flexible in adding modules. For the moment, I see the following alternatives to be able to start unit testing ASAP.

1. Write unit tests in pure C (e.g. check)
2. Write unit tests in Python, and call the C functions with ctypes
3. Write a small SWIG wrapper and do unit tests from either Python or Matlab (eventually, we can call the C functions through casadi, see #1 , but it's probably too long of a process to wait for)

Whatever way we choose, we should start with writing tests for the following:

1. Condensing
2. QP solution (although this is actually the burden of the respective solvers)
3. Integrators @rienq what's the best way to approach this?

Implementation of the new version of the Multi-Level RTI with efficient feasibility and optimality improvement steps.

On linux, the following error is generated when compiling test_nmpc.c:

/usr/bin/cc  -DDEBUG -I/home/kotlyar/software/acados -I/home/kotlyar/software/acados/external -I/home/kotlyar/software/acados/external/qpOASES/include  -std=c99 -Wall -Wextra -g   -o CMakeFiles/test_nmpc.dir/test/test_nmpc.c.o   -c /home/kotlyar/software/acados/test/test_nmpc.c
/home/kotlyar/software/acados/test/test_nmpc.c:3:28: fatal error: mach/mach_time.h: No such file or directory

• We already had a meeting about it, but there still needs to be a first implementation of an OCP_NLP interface which could be an extension of the current OCP_QP interface to easily define, e.g., simple bounds etc explicitly..
• There would additionally be the need for a struct interface of a 'differentiable function' which could then come from a CasADi expression which gets code generated or from any other AD tool.
• For the continuity constraints in optimal control, we would define a separate 'integrator interface' which should be general enough to include both the numerical simulation of continuous time differential equations as well as black box models such as NARX, etc.
• Just like for the OCP_QP interface, there should be the flexibility to have different dynamics and therefore different integrator calls for the different stages as well as different additional inequality constraints on the different stages

Development of an interface to hpmpc that enables the use of partial tightening. A line-search has to be implemented in acados to avoid dual-infeasible problems.

Right now ExternalProjects (or some of them at least, like hpmpc and blasfeo) have INSTALL_COMMAND " " in order to avoid cmake runnig install whenever a build is called. However this causes ExternalProjects not being installed properly when make install is called. I bring this up because proper installation might be rather important for integration in more complex build systems and for portability to embedded platforms. I am looking into something like this: http://www.stackoverflow.com/questions/37838786/how-to-not-make-install-step-when-building-external-project-with-cmake at the moment. If you happen to have better ideas, please let me know, I actually need right now.

EDIT: github breaks the link, dunno why. Copy paste will do.

Currently, running cmake with the unit tests flag calls both octave (to generate condensing data) and a bunch of ipopt simulations (which requires quite some time). To my opinion, Cmake should only create the necessary makefiles. Then running the makefile should generate the data and compile the tests and finally, running the compiled code should run all tests.

When building on Linux with cc 5.4.0, multiple errors similar to the following are generated on qpOASES code:

/home/kotlyar/software/acados/acados/ocp_qp_condensing_qpoases.c:8:0: error: ignoring #pragma clang diagnostic [-Werror=unknown-pragmas]
 #pragma clang diagnostic push

/home/kotlyar/software/acados/external/qpOASES/include/qpOASES_e/QProblemB.h: In function ‘QProblemB_applyGivens’:
/home/kotlyar/software/acados/external/qpOASES/include/qpOASES_e/QProblemB.h:1541:70: error: unused parameter ‘nu’ [-Werror=unused-parameter]
 static inline void QProblemB_applyGivens( real_t c, real_t s, real_t nu, real_t xold, real_t yold,
                                                                      ^

/home/kotlyar/software/acados/external/qpOASES/include/qpOASES_e/MessageHandling.h:448:32: error: ‘MessageHandling_getErrorVisibilityStatus’ defined but not used [-Werror=unused-function]
 static inline VisibilityStatus MessageHandling_getErrorVisibilityStatus( MessageHandling* _THIS )
                                ^

Compiler version:

cc (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609

I would encourage using issues to make clear who is working on what in order to avoid overlapping. Now that quite some people are actively developing, it might happen that two or more work on the same thing...@giaf :) Assigned issues can be reassigned and modified over time, but we should not waste our time duplicating stuff. You can check which tasks are still open and already assigned with the following query:
is:open is:issue assignee:*
same thing with closed issues:
is:closed is:issue assignee:*
It is also very useful to keep track of what is currently being developed ;)

Wrapping up the development of an interface that uses BLASFEO directly. @giaf has a similar implementation based on an upper level of the software stack in hpmpc that also supports partial condensing. As partial condensing might be moved to a separate routine, the interface in ocp_qp_hpmpc.c might be a good starting point for the final version.

Installation seems to be broken with gcc-4 mainly due to warnings in compiling qpOASES being treated as errors. Installs fine with gcc-6.

Currently all files in acados, including auto generated files from CasADi for the test problems, are compiled with all warnings raising errors. This creates a lot of errors like this:

error: unused parameter ‘w’
error: unused parameter ‘iw’
error: unused parameter ‘mem’
...

There should be a convenient way to add and remove these compiler flags for specific source files.

HPMPC fails to solve the QPs in the test_nmpc example. Reducing the horizon the same solution is obtained, but it would be good to understand what breaks down there.

use the same functions to measurement timings in acados. At the moment we have gettimeofday, acado_tic/acado_tic, tic/toc and maybe more..

I think it's worthwhile to adopt a convention for .travis.yml:

after the before_install and install sections, the working directory of Travis should be the root folder of acados.

@dkouzoup Could you please fix the encrypted script? It seems the problem lies there.

We want to use casadi codegen and JIT compilation. The strategy at the moment is to write mostly low-level C code, and then write a casadi::FunctionInternal wrapper around it.

I found a memory leakage problem today in the script file ocp_qp_condensing_qpoases.c, then Robin fixed:

• Move the creator inside initialise_qpoases() to ocp_qp_condensing_qpoases(), so that the memory allocation can be freed.
  Lines: 334-338, file ocp_qp_condensing_qpoases.c.
  To be move to the beginning of ocp_qp_condensing_qpoases()
• And then free the memory for primal_solution and dual_solution at the end of ocp_qp_condensing_qpoases().
  Uncomment lines 310-311.

Since we added a second condition in the if statement (repo=acados/acados) there is an error syntax and the code never reaches the decryption step. Which means that we never compile ooql and ma27 any more. I tried a few times but travis beat me :P

I found something interesting while profiling chen_nmpc_qpoases_example on my Macbook Pro: almost 20% of the time is spent in zeroing an array (_platform_bzero).

I tracked it down to the following lines in QProblemB.c:1335 (computeCholesky) in qpOASES:

/* 1) Initialises R with all zeros. */
for( i=0; i<NVMAX*NVMAX; ++i )
	_THIS->R[i] = 0.0;

Furthermore, these lines seem unnecessary. I can comment those lines out and all of the unit tests still work. Meanwhile, chen_nmpc_qpoases_example gets a speedup of roughly 20%.

Could someone with a Linux machine confirm that they get the same speedup by commenting out those lines, e.g. @giaf @zanellia ? Make sure to pull the latest master and put the build type to Release.

I mixed up my remotes and ended up braking blessed/master (I reverted everything and pushed to a separate branch. As soon as Travis says it is OK I will push again to master)...Shouldn't we force people to go through a merge such that changes run through Travis before ending up in the master branch? I guess this simply boils down to denying push rights to everybody. I had to revert 15 commits with 2 merges in between... :)

We identified 4 different types of arguments into a function:

• input: this may not be overwritten by the called function
• output: this will (normally) be overwritten by the called function
• memory: the caller should not overwrite this between calls (warm/hot-starting)
• workspace: this is scrap, the caller may overwrite this between calls to the function

make clean seems not to be cleaning all the binaries

Function "fillWithBoundsData" should not overwrite the x0 constraint with state bounds. I also noticed that the function changes the pointers inside qp_in. Mapping pointers to structure fields before calling it is therefore useless as the qp_in after calling the function points to new data..

I'm trying to compile acados, but I got this:

/home/gianluca/acados/test/all_tests.cpp:2:35: fatal error: catch/include/catch.hpp: No such file or directory #include "catch/include/catch.hpp"

what is catch used for?

We should use const pointers to const values for inputs, and const pointers for outputs.

This way, we will have a more 'functional' interface.

ACADO code generation had the feature that the dimensions of states (NX) and controls (NU) were hardcoded. In acados, we pass arrays nx[] with possibly variable dimensions. We should investigate if this incurs a performance loss.

A possible way to have both, is defining a macro

#ifdef CODE_GENERATION
#define NX 10
#define nx(i) (NX)
#else 
#define nx(i) (nx[i])
#endif

@dkouzoup found out about the following interesting github repository, which we should keep in mind:
https://github.com/embotech/Y2F

They worked on a tool to automatically detect the multi-stage structure from a general (convex) optimization problem, which apparently is not only a very easy-to-use thing but also overall provides considerable speedups in the resulting FORCES solver! (the latter was also confirmed by Dimitris who used it for his tree-structured QP problem)

Maybe this could be an interesting approach to detect the multi-stage structure in the convex/non-convex optimization problems that one might formulate in CasADi, when passing them to acados (through the plugins we plan to develop, see #1)..

We should gradually update all modules to the standards we discussed on #3, regarding type and ordering of arguments. Integrators that are the most mature module together with the qpsolvers is probably the next "todo"

It's a bit weird, but very sporadically I get this in CMake on Travis, even if the other builds with other compilers all succeed:

The command "cmake -E chdir build cmake -D CMAKE_BUILD_TYPE=Debug .." exited with 0.
0.34s$ cmake --build build --clean-first
Scanning dependencies of target blasfeo_project
[  1%] Creating directories for 'blasfeo_project'
[  2%] No download step for 'blasfeo_project'
[  3%] No patch step for 'blasfeo_project'
[  4%] No update step for 'blasfeo_project'
[  6%] No configure step for 'blasfeo_project'
[  7%] Performing build step for 'blasfeo_project'
make[4]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.

ar: ./auxiliary/d_aux_lib4.o: No such file or directory

make[3]: *** [static_library] Error 1
make[3]: *** Waiting for unfinished jobs....
make[4]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
make[4]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
make[4]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
make[4]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
make[2]: *** [external/blasfeo_project-prefix/src/blasfeo_project-stamp/blasfeo_project-build] Error 2
make[1]: *** [external/CMakeFiles/blasfeo_project.dir/all] Error 2
make: *** [all] Error 2

I had some troubles managing ExternalProjects based on Makefiles so I made a minimal port of hpmpc's build system to CMake. Not sure this is better than a Makefile-based build system, but at least all our core code is going to be built with CMake (good? dunno). Anyways, if you guys like it we could give it a shot. The code is here:

https://github.com/zanellia/hpmpc/tree/crosscompiling

and it is based on a single CMakeLists.txt file (unlike the previous hpmpc's CMake build system).

I noticed that if I run the test_qpsolvers.cpp before test_chain.cpp, then the latter crashes (qpoases returns infeasible first QP). I valgrinded the test_qpsolvers.cpp code and I see no memory leaks so maybe the problem is in test_chain?

Currently, I get a segfault when running nmpc_example.

Adding plotting with gnuplot directly from C code using pipes.

We changed the interface such that the box constraints on x,u come in the order
[x,u]
rather than
[u,x].
@giaf The ocp_qp_hpmpc function needs to be fixed.

I have a few comments on the condensing interface.

First of all, I would suggest to substitute condensing with partial (block) condensing. This is because partial condensing is more flexible, as condensing is a special case with N=1. And partial condensing could be coupled also with sparse solvers, instead of only qpOASES.

In this framework, it would make sense to consider both the condensing_in and condensing_out as OCP QPs.

Furthermore, there can be several condensing algorithms (actually there are at least 3 with different complexity), so I would suggest to keep the condensing workspace more generic, as just a pointer to void. This would allow for the use of different condensing / partial condensing algorithms (something similar to the QP solvers).

Development of a nonlinear interior point method based on hpmpc.

We mainly use d_zeros from blasfeo/hpmpc to initialize memory. As the blasfeo headers cannot compile with g++, zeros.cpp is temporarily used for the unit_tests. We should remove this once @giaf adds the necessary code snippet in the blasfeo headers (mainly in the aux ones).

Can we change the default target of BLASFEO, at least for the unit tests in acados? Or maybe we should even test multiple (or all) of the targets? @giaf
I just spent a very long time debugging my ocp_nlp test, while it apparently runs perfectly with TARGET set to GENERIC so there must be a bug in the current version of blasfeo that acados is currently using..

I have valgrinded test_hpmpc, while debugging some other stuff and the output contains quite a few errors:

==17290== Memcheck, a memory error detector
==17290== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==17290== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==17290== Command: ./test_hpmpc
==17290== Parent PID: 5679
==17290==
==17290== Conditional jump or move depends on uninitialised value(s)
==17290== at 0x4E5C314: fmax (s_fmax.S:25)
==17290== by 0x459EA1: d_init_var_mpc_hard_tv (d_aux_ip_hard_lib4.c:149)
==17290== by 0x44934B: d_ip2_res_mpc_hard_tv (d_ip2_res_hard.c:460)
==17290== by 0x4122AC: fortran_order_d_ip_ocp_hard_tv (fortran_order_interface.c:576)
==17290== by 0x4092AB: ocp_qp_hpmpc (ocp_qp_hpmpc.c:131)
==17290== by 0x4086F8: main (test_ocp_qp_hpmpc.c:521)
==17290==
==17290== Conditional jump or move depends on uninitialised value(s)
==17290== at 0x4E5C314: fmax (s_fmax.S:25)
==17290== by 0x459EFC: d_init_var_mpc_hard_tv (d_aux_ip_hard_lib4.c:150)
==17290== by 0x44934B: d_ip2_res_mpc_hard_tv (d_ip2_res_hard.c:460)
==17290== by 0x4122AC: fortran_order_d_ip_ocp_hard_tv (fortran_order_interface.c:576)
==17290== by 0x4092AB: ocp_qp_hpmpc (ocp_qp_hpmpc.c:131)
==17290== by 0x4086F8: main (test_ocp_qp_hpmpc.c:521)
==17290==
==17290== Conditional jump or move depends on uninitialised value(s)
==17290== at 0x51C856: inner_edge_dpotrf_8x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290== by 0x51E335: kernel_dsyrk_dpotrf_nt_l_8x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290==
==17290== Conditional jump or move depends on uninitialised value(s)
==17290== at 0x51C8B1: inner_edge_dpotrf_8x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290== by 0x51E335: kernel_dsyrk_dpotrf_nt_l_8x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290==
==17290== Conditional jump or move depends on uninitialised value(s)
==17290== at 0x51C92B: inner_edge_dpotrf_8x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290== by 0x51E335: kernel_dsyrk_dpotrf_nt_l_8x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290==
==17290== Conditional jump or move depends on uninitialised value(s)
==17290== at 0x51C9C9: inner_edge_dpotrf_8x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290== by 0x51E335: kernel_dsyrk_dpotrf_nt_l_8x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290==
==17290== Conditional jump or move depends on uninitialised value(s)
==17290== at 0x518BE6: inner_edge_dpotrf_4x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290== by 0x51A30B: kernel_dsyrk_dpotrf_nt_l_4x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290== by 0x5528FBF: ???
==17290==
==17290== Conditional jump or move depends on uninitialised value(s)
==17290== at 0x518C34: inner_edge_dpotrf_4x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290== by 0x51A30B: kernel_dsyrk_dpotrf_nt_l_4x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290== by 0x5528FBF: ???
==17290==
==17290== Conditional jump or move depends on uninitialised value(s)
==17290== at 0x518C98: inner_edge_dpotrf_4x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290== by 0x51A30B: kernel_dsyrk_dpotrf_nt_l_4x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290== by 0x5528FBF: ???
==17290==
==17290== Conditional jump or move depends on uninitialised value(s)
==17290== at 0x518D17: inner_edge_dpotrf_4x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290== by 0x51A30B: kernel_dsyrk_dpotrf_nt_l_4x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290== by 0x5528FBF: ???
==17290==
==17290== Conditional jump or move depends on uninitialised value(s)
==17290== at 0x518BE6: inner_edge_dpotrf_4x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290== by 0x51A30B: kernel_dsyrk_dpotrf_nt_l_4x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290== by 0x5528B3F: ???
==17290==
==17290== Conditional jump or move depends on uninitialised value(s)
==17290== at 0x518C34: inner_edge_dpotrf_4x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290== by 0x51A30B: kernel_dsyrk_dpotrf_nt_l_4x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)
==17290== by 0x5528B3F: ???
==17290==
==17290== Conditional jump or move depends on uninitialised value(s)
==17290== at 0x518C98: inner_edge_dpotrf_4x4_vs_lib4 (in /home/andrea/acados/build/test_hpmpc)

maybe @giaf knows better?