The following code segfaults:

DifferentialState xx(3, 4, "xx");
Control yy(3, 1, "yy");
IntermediateState zz = xx * yy;
Function fzz;
fzz << zz;
stdout << fzz;

... instead of returning an error.

The mentioned class is kinda not maintained, nor I can't remember anyone using it. I am not using it either. People use Matlab/Simulink and python for simulations. Moreover, I have not updated the class for the new impl. of the OCP solvers that I am going to upload these days.

All in all, the idea about this class was good, but nobody is using it. I suggest I remove it in the next release.

@ferreau, @rienq ?

A useful new features, though with low-priority, would be to introduce an automatic flop count of the exported code. Adding this should be straight-forwards but a bit tedious.
Discussion

Joachim Ferreau
2012-12-15

Using the qpOASES based solvers in a more complex build system environments, it was observed that ./qpoases/solver.hpp and cpp made some problems and required some hacks. Speaking with @rienq and other users within our group, we came to the conclusion that it would be much easier to export those 2 files to the root of the export folder. Additionally, the name of those two files is kinda not descriptive, thus I would rename them to qpoases_interface.hpp and cpp.

@ferreau What do you think about this? In case there is a really good reason not to proceed this way, please enlighten us :)

Milestone: 1.0 Status: pending Owner: Rien Quirynen Labels: feature (2)
Updated: 2013-01-28 Created: 2013-01-28 Creator: Milan Vukov Private: No

The integrator API signature should be changed to:
int integrator(real_t* eta, int reset, int index)
with:
return value =0 if everything is OK, otherwise some kind of an error, i.e. if there are any numerical problems in linear solver of an implicit integrator.
eta, in/out array as before.
reset, this is mandatory for implicit integrator since recently, in case of explicit int it is not relevant (and avoid compiler warnings with reset=reset somewhere in the beginning of the integrator function).
index, important for non-equidistant grids, ignored otherwise (if not used prevent compiler warnings with index = index).

The auto-generated S function wrapper (as exported by MPCexport class, if this is still in use) features a subtle issue that might prevent the function from working correctly. Instead of

for( i=0; i < NX_N; ++i ) acadoVariables.xRef[i] = (double)(_in_xRef)[i];

it has to read

for( i=0; i < NX_N; ++i ) acadoVariables.xRef[i] = (double)(_in_xRef[i]);

and similarly for all other occurences.

Exported integrators should have a feature to return sparsity patterns for the sensitivity matrices. This can simplify some calculations and save some computation times for the export of OCP solvers.

Milestone: 1.0 Status: closed Owner: Rien Quirynen Labels: bug (4)
Updated: 2012-11-14 Created: 2012-11-14 Creator: Milan Vukov Private: No
MATLAB interface is not compiling. Typing "make" in the interfaces/matlab folder results in the following error message:
Making ACADO...
??? Error using ==> fprintf
Invalid file identifier. Use fopen to generate a valid file identifier.

Error in ==> addTemplates at 32
fprintf(fid, '%s \n', ' #ifndef ACADO_TOOLKIT_TEMPLATES_HPP');

Error in ==> makehelper at 176
addTemplates;

Error in ==> make at 81
makehelper(0, {});
Solved
Discussion

Milan Vukov
2012-11-14
Description has changed:
Diff:
--- old
+++ new
@@ -1,4 +1,4 @@
-MATLAB interface is not compiling. Typing "make" in the interfaces/matlab causes the following error message:
+MATLAB interface is not compiling. Typing "make" in the interfaces/matlab folder results in the following error message:
Making ACADO...

Reply
Link
Edit
Delete

Attach

Milan Vukov
2012-11-14
Description has changed:
Diff:
--- old
+++ new
@@ -14,3 +14,5 @@
Error in ==> make at 81
makehelper(0, {});
+
+Solved

• status: pending --> closed

I introduced automatic testing in mvukov@bb9117d. When testing is enable in CMake, additional target is made: test. When one runs make test, this guy will execute all examples (some are blacklisted for now, but that is a separate issue).

Once I polish this I will push this to the main remote. Here is an example how it looks like:

https://travis-ci.org/mvukov/acado/jobs/9757296

Scroll down, and click on "after_success".

Currently it's impossible to run OCP codegen on more than 1 OCP in one session, because at least "DifferentialState", "Control", etc have global counters.

This has more implications that I initially realized. I have a python library which generates 2 separate C++ files: MHE code export, and NMPC code export. When I compile and run both of these C++ files from a single python process, the global state is shared in the ACADO library and the second OCP I export is corrupted, even though I use two subprocess.call functions. My workaround is currently to fork 2 separate processes using multiprocessing.

I think a more modular OCP codegen interface would be something like:

ocp = Ocp();
ocp.differentialState("position");
ocp.control("thrust");
ocp.subjectTo(....)

etc

This would also facilitate proper foreign bindings, instead of generating C++, compiling and running it.

Using OS X 10.8.3
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)

Following the installation guide to make a debug version of the library
(cmake -DCMAKE_BUILD_TYPE=Debug ..)
make gives the following error (immediately)

clang: error: unsupported option '-gstabs+'

Maybe -gstabs+ is an option of GCC and not of Clang... ?
I changed to -g and it compiled successfully.

When defining an implicit DAE, this:

DifferentialEquation f;
f << c == 0;

gives this error, upon code export:

[ACADO] Error: A user-defined option has an invalid value
  Code: (RET_INVALID_OPTION) 
  File: /home/ghorn/planepower/extern/acado/src/code_generation/integrators/irk_export.cpp
  Line: 140

@rienq suggested switching the order around the ==:

DifferentialEquation f;
f << 0 == c;

which fixed the issue.

I understand why this might be the case with explicit ODEs (though I still don't like it), but for implicit ones this is confusing. I suspect ocp.subjectTo may have the same feature.

Milestone: 1.0 Status: open Owner: nobody Labels: minor bug (4)
Updated: 2013-02-28 Created: 2013-02-28 Creator: Joachim Ferreau Private: No

The auto-generated test file should include code to initialize all acadoVariables (that are not hard-coded). For example, if one does not hard-code the matrices Q and R, the test file should initiliaze them to some default values in order to run properly.

The same goes for the Simulink interface.

Milestone: 1.0 Status: open Owner: nobody Labels: feature (2)
Updated: 2013-02-12 Created: 2013-02-12 Creator: Milan Vukov Private: No

The function Addition::isOneOrZero() is a performance bottleneck for longer expressions. This was already reported on a forum thread, and I experienced the same behavior with some longer polinomial expressions. In my case, the program spent more than 1 minute (!!!) in this function.

Thus, I commented the code inside this function, and the function is now returning NE_NEITHER_ONE_NOR_ZERO.

Discussion

Milan Vukov
2013-02-12
Description has changed:
Diff:
--- old
+++ new
@@ -1,3 +1,3 @@
-The Function Addition::isOneOrZero() is a performance bottleneck for longer expressions. This was already reported on a forum thread, and I experienced the same behavior with some longer polinomial expressions. In my case, the program spent more than 1 minute (!!!) in this function.
+The function Addition::isOneOrZero() is a performance bottleneck for longer expressions. This was already reported on a forum thread, and I experienced the same behavior with some longer polinomial expressions. In my case, the program spent more than 1 minute (!!!) in this function.

Thus, I commented the code inside this function, and the function is now returning NE_NEITHER_ONE_NOR_ZERO.

Condensing could and should also largely profit from the definition of linear subsystems (linear in- and/or output) in the nonlinear model by exploiting this clear structure.

Data structure inside the ExportData/ExportArgument should be automatically converted to a vector-like struct. This is going to simplify a lot the internal indexing.

Milestone: 1.0 Status: closed Owner: nobody Labels: minor bug (4)
Updated: 2012-12-06 Created: 2012-11-22 Creator: Joachim Ferreau Private: No
Dear,
I have locally fixed the following inefficient artefacts related to the code export of pow-statements:

1. The class Power now exports
   a) sqrt(X) instead of pow(X,0.5)
   b) 1.0/sqrt(X) instead of pow(X,-0.5)
2. The class Power_Int now exports
   a) X instead of pow(X,1)
   b) X*X instead of pow(X,2) iff X is a variable (if X is a lengthy expression, using pow might still be more efficient)
   c) X instead of pow(pow(X,1/n),n)
   I will merge these changes into the trunk in the near future.
   Joachim
   Discussion

Joachim Ferreau
2012-12-06
status: open --> closed

I just found out that the integrators are reset for every shooting interval in case of single shooting, just like for multiple shooting. In my opinion, this does not make sense and is even (very) inefficient from the integration side.

I believe, previously the integrator was only reset for the first shooting interval in case of single shooting and I would prefer that actually.

While extending the QR based lin. solver I think I found a bug. @rienq please take a look at commit mvukov@d0219e4. I commented out some lines and fixed the loop limit of the outer-most loop of the factorization routine.

The basic problem was that the last element of the R matrix, i.e. R(nc, nc), was wrong.

The solver works now w/o reuse feature. I compared results (for both cases m=n, m > n) against MATLAB and everything is fine.

@rienq please fix the solver so that it works with reuse of factorization again. Thanx! :)

Milestone: 1.0 Status: closed Owner: nobody Labels: new feature (4)
Updated: 2012-12-06 Created: 2012-11-22 Creator: Joachim Ferreau Private: No
Why not support the diag command? Here the code for
Vector v = diag(Matrix M) ,
Matrix M = diag(Vector v) ,
ExportVariable Q = diag( name,dim ) ,
the latter setting up a diagonal, user-defined variable (i.e. off-diagonal elements are ignored when exporting code):
I) include/acado/symbolic_expression/acado_syntax.hpp:

include <acado/code_generation/export_variable.hpp>

REFER_NAMESPACE_ACADO Matrix diag ( const REFER_NAMESPACE_ACADO Vector& v );
REFER_NAMESPACE_ACADO Vector diag ( const REFER_NAMESPACE_ACADO Matrix& M );
REFER_NAMESPACE_ACADO ExportVariable diag( const REFER_NAMESPACE_ACADO String& _name, unsigned int _n );
II) src/symbolic_expression/acado_syntax.cpp:
Matrix diag( const Vector& v )
{
int n = v.getDim();

Matrix t = zeros( n,n );
for( int i=0; i<n; ++i )
    t(i,i) = v(i);

return t;

}

Vector diag( const Matrix& M )
{
ASSERT( M.isSquare() == BT_TRUE );

int n = M.getNumRows();

Vector t( n );
for( int i=0; i<n; ++i )
    t(i) = M(i,i);

return t;

}

ExportVariable diag( const String& _name,
unsigned int _n )
{
ExportVariable t( _name, _n,_n );
t = eye( _n );
t.resetDiagonal( );
return t;
}
Discussion

Joachim Ferreau
2012-12-06
status: open --> closed

Here is a rather serious bug which @jfrasch reported some time ago. tried out his example some weeks ago, and it still does not work.

Here is his email...

I tried to understand the problem of the error message "Hessian matrix is too ill-conditioned...", that apparently some of us seem to face in situations where we don't understand where it comes from.

I was having this problem in a slightly more involved model, but I managed to boil it down to a 1-state model with the dynamics dot(x) = -100*x (see attachment). If initialized at x = 0.0, I would expect the optimizer tracking xRef = 0.0 to not have much trouble, or am I overlooking something? However I get the Hessian error message. I know, I'm using a RK45 integrator which seems not the right choice here, but I also had the problem in my original model with the BDF integrator. Still, (a) the integrator itself does not seem fail, and (b) for x = 0.0, there should not be too many problems, should there?

The first thing I do not understand is the check that raises the error message (condensing_based_cp_solver.cpp:434). It seems to me that the matrix is checked for infinity entries (> +/-1e16). Why? Maybe the error message of ill-conditionedness is a bit misleading, but anyways.

Backtracking the problem in the debugger it seems to me like before condensing the Hessian entry looks fine, but after condensing it explodes. During the condensing some stuff happens that I do not completely understand (the matrices hT, T, ... seem to have more entries than I expected, I don't really know what like 535 in condensing_based_cp_solver does), but it looks to me like some strange values (maybe uninitialized?) are accessed. Particularly when block_matrix:482 is called (during the operation T^hT in line 535) {this->}elements[1][0] is accessed, but elements seems to have nRows = nCols = 1.

The code he sent to us is here:

#include <acado_toolkit.hpp>
#include <include/acado_gnuplot/gnuplot_window.hpp>


USING_NAMESPACE_ACADO


// BEGIN MAIN
// ----------------------------------------
int main( ){   
   // INITIALIZE THE STATES AND CONTROLS:
   // ----------------------------------------
   DifferentialEquation f;

   DifferentialState vy;   // velocity perpendicular to tractor orientation

   f << dot( vy )  == -100 * vy;


   // OCP MODEL AND PATH CONSTRAINTS
   // -----------------------------------------
   OCP ocp( 0,1, 1 );

   ocp.subjectTo( f );



   Function obj; 
   obj << vy;

   Matrix objWeights = eye(1);

   VariablesGrid ref( 1, 0, 1, 2 );
   ref.setAll( 0.0 );

   ocp.minimizeLSQ( objWeights, obj, ref );



   VariablesGrid xInit( 1, 0, 1, 2 );
   xInit.setAll( 0. );

   // SET UP OPTIMIZATION ALGORITHM (FOR VERIFICATION)
   // ----------------------------------------------
   OptimizationAlgorithm algorithm(ocp);

   algorithm.set( DISCRETIZATION_TYPE,   MULTIPLE_SHOOTING );
   algorithm.set( INTEGRATOR_TYPE,       INT_RK45 );

   algorithm.initializeDifferentialStates( xInit );
   algorithm.init();
   // RUN ALGORITHM
   algorithm.solve();

   return 0;
}

I'm not sure what the interface would look like, but it would be super awesome if I could provide all required sparsity patterns of an OCP, and generate my own C code for objective, constraints, DAE residual, etc (including their derivatives) using external symbolic tools, and have ACADO generate the solvers for me.

Milestone: 1.0 Status: closed Owner: Milan Vukov Labels: new feature (4)
Updated: 2012-10-06 Created: 2012-09-12 Creator: Joachim Ferreau Private: No
Exporting the data declaration of a given ExportVariable can be easily supported by adding the following lines of code to ExportArgument::exportDataDeclaration()
if ( getDim( ) == 1 )
acadoFPrintf( file," = %e;\n", data(0,0) );
else
{
acadoFPrintf( file," = " );
data.printToFile( file, "", "{ "," };\n", 1, 16, ", ",", \n" );
}
Discussion

Milan Vukov
2012-10-06
status: accepted --> closed
Feature is implemented

Last edit: Milan Vukov 2012-10-06

Currently, the term "parameter" is being misused in code generation. It is namely used to denote a constant parameter that the user can set later in the generated code, instead of a free parameter which is what one would expect. In the latter case, the parameters are variables in the OCP (e.g. they are estimated) and sensitivity information is needed as well.

The nice way to solve this would be to create a new class called "OnlineData" to deal with these 'constant parameters' in the generated code. This leaves the Parameter class for what it is supposed to be used.

When I initialize a UniformNoise with the "scalar" constructor (UniformNoise (uint _dim, double _lowerLimit, double _upperLimit)) I get a EXC_BAD_ACCESS when accessing lowerLimit vector.

I think after the initialization of w, these two lines are missing:

lowerLimit.init(_dim);
upperLimit.init(_dim);

Milestone: 1.0 Status: open Owner: Rien Quirynen Labels: None
Updated: 2013-01-29 Created: 2013-01-29 Creator: Rien Quirynen Private: No

This function wants to give a matrix that tells you if a certain row in the expression depends on a certain variable (the element is different from zero)
or not (the element is equal to zero).
However, it does this by differentiation and then evaluating the resulting expressions by setting all the variables to zero.
This of course does not always work, e.g. x^2 --> derivative = 2*x --> result = 0.0 after evaluation at x = 0
(solved temporarily in revision 145)

ExportVariable should support diagonal matrices. Mainly I think about storage, but also all operators should be defined. The first idea is to derive a new internal class from ExportArgument and keep the public i/f more/less the same

When code is compiled in the Debug mode, it happens that ASSERT works in some cases (I am trying some weird stuff :)). Asserts work as expected, but there are memory leaks. I noticed this working with code generation tool, and checked with valgrind.

I will provide an example later...

Milestone: 1.0 Status: closed Owner: Milan Vukov Labels: minor bug (4)
Updated: 2012-12-04 Created: 2012-09-12 Creator: Joachim Ferreau Private: No
When exporting an ExportVariable with a given value, its numerical value is explicitly type-casted to "real_t". That should be replace by whatever is passed as "realTypeString" to the exporting function.
Closed. Works now.
Discussion

Milan Vukov
2012-12-04
Description has changed:
Diff:
--- old
+++ new
@@ -1 +1,3 @@
When exporting an ExportVariable with a given value, its numerical value is explicitly type-casted to "real_t". That should be replace by whatever is passed as "realTypeString" to the exporting function.
+
+Closed. Works now.
status: open --> closed
assigned_to: Milan Vukov

When building for Cygwin, turn -fPIC compiler option off - reporter by @ferreau .

This option should be split into two separate ones: one for codegen and one for standard ACADO, given the fact that codegen integrators are not supported in standard acado and viceversa

Milestone: 1.0 Status: open Owner: nobody Labels: minor bug (4)
Updated: 2013-02-28 Created: 2013-02-28 Creator: Joachim Ferreau Private: No

In the latest revision (maybe also in earlier ones), the auto-generated auxiliary function printStates does output the state trajectory in a transposed fashion, which does not make sense. The same might hold true for the control trajectory, but I have not checked this.

As @ghorn pointed out to me today:

-this does not work:

_ocp.subjectTo( force <= 0.1 );
_ocp.subjectTo( force >= -0.1 );

This does work:

_ocp.subjectTo( -0.1 <= force <= 0.1 );

where forces is Control object.

In the first case, only the second constraint is respected.

This bug was spotted in code-generation, only.

Hi,

could you please do the following fix in 'qpdunes_interface.in':

1. Instead of (currently line 39)
   qpData.intervals[ kk ]->H.sparsityType = QPDUNES_DIAGONAL;
   please add
   if ("H is diagonal") {
   qpData.intervals[ kk ]->H.sparsityType = QPDUNES_DIAGONAL;
   }
   else {
   qpData.intervals[ kk ]->H.sparsityType = QPDUNES_DENSE;
   }
   depending on how you save the sparsity type for the Hessians.
   Line 41 (the comment) can then also be removed.

2. Please remove (formerly line 40)
   qpData.intervals[ kk ]->D.sparsityType = QPDUNES_IDENTITY;
   It is obsolete now.

3. The default printlevel (lines 21,22) should be "@PRINT_LEVEL@", not 4.

Thanks a lot!

Milestone: 1.0 Status: closed Owner: Milan Vukov Labels: bug (4)
Updated: 2012-11-11 Created: 2012-09-12 Creator: Joachim Ferreau Private: No

When exporting an arithmetic statement, it must be checked whether the left-hand side to be assigned has a given value. In that case, exporting the corresponding line of code needs to be skipped.

Discussion

Milan Vukov
2012-11-11
Description has changed:
Diff:
In case LHS is given and size of LHS is greater than 0 (meaning we have something to export), an error will be returned. The bug is fixed within commit 55.
status: open --> closed
assigned_to: Milan Vukov

Last edit: Milan Vukov 2012-11-11

Milestone: 1.0 Status: closed Owner: Milan Vukov Labels: None
Updated: 3 days ago Created: 3 days ago Creator: Greg Horn Private: No
when acado_env.sh is created, it would be very nice to also create acado.pc
Discussion

Milan Vukov
3 days ago
assigned_to: Milan Vukov

Reply
Link
Edit
Delete

Attach

Milan Vukov
3 days ago
status: open --> closed

Reply
Link
Edit
Delete

Attach

Milan Vukov
3 days ago
Done. It creates a pkg-config script that works with the local build. I still have to implement one for the "make install" case.

Last edit: Milan Vukov 3 days ago

Milestone: 1.0 Status: open Owner: nobody Labels: None
Updated: 2013-01-29 Created: 2013-01-29 Creator: Rien Quirynen Private: No

The code export examples don't seem to work on Windows 64-bit systems.

I don't think this will cause exceptional hardship in most cases

Milestone: 1.0 Status: closed Owner: Boris Labels: bug (4)
Updated: 2013-02-24 Created: 2013-02-16 Creator: Milan Vukov Private: No
Math functions erf and erfc are not defined in MS Visual Studio. Thus, ACADO code cannot be compiled. In short, those two functions must be provided in case ACADO is compiled with MS Visual Studio. Also, MSVC++ reports that constant INFINITY used in interval.ipp is not defined. This can be solved with

ifndef INFINITY

define INFINITY INFTY

endif

A separate issue is that because those two functions are defined in the new standard ACADO code might be not possible to compile with older compilers.
I can help to test with CMake whether thos two functions are available for particular OS/compiler conf, but I would need source for those two guys.
NOTE: There are no issues with Cygwin compilation.
Discussion

Milan Vukov
2013-02-16
summary: erf and erfc are are part of c++11 std. Thus, ACADO cannot be compiled --> erf and erfc are are part of c++11 std. Thus, ACADO cannot be compiled with MSVC++.
Description has changed:
Diff:
--- old
+++ new
@@ -0,0 +1,13 @@
+Math functions erf and erfc are not defined in MS Visual Studio. Thus, ACADO code cannot be compiled. In short, those two functions must be provided in case ACADO is compiled with MS Visual Studio. Also, MSVC++ reports that constant INFINITY used in interval.ipp is not defined. This can be solved with
+
+* * *

• #ifndef INFINITY
• #define INFINITY INFTY
• #endif
  +* * *

+A separate issue is that because those two functions are defined in the new standard ACADO code might be not possible to compile with older compilers.
+
+I can help to test with CMake whether thos two functions are available for particular OS/compiler conf, but I would need source for those two guys.
+
+NOTE: There are no issues with Cygwin compilation.
assigned_to: Boris

Reply
Link
Edit
Delete

Attach

Milan Vukov
2013-02-24
All bugs related to this ticket are fixed. erf and erfc are removed from the Interval class. Some constants are defined properly now, like the INFINITY constant.

Reply
Link
Edit
Delete

Attach

Milan Vukov
2013-02-24
status: accepted --> closed

Yet another cool new feature would be an automated memory access analysis. In principle, the existing data structures allow to detect whether a given component of an ExportedVariable is accessed by each exported command. Combining this information across different exported commands and different modules would allow to see, whether certain components are actually never accessed. If this analysis is performed before actually exporting the code, these components could even be neglected and the allocated size of the corresponding ExportedVariable could be decreased. If one keeps this framework general, the code export would, e.g., automatically detect whether a given matrix is actually banded or triangular and would only allocate memory for the non-zero parts.
I know this would take quite some effort to implement, but in the long run, it should be quicker than exploiting the different block-structures of different problem formulations by hand each time.
Discussion

Joachim Ferreau
2012-12-15

It would be very useful to have a nice way of changing the prefix name used for global structs, e.g. by adding some prefix to the prefix.

A possible situation would be when exporting MHE and MPC for one experiment and compiling both exported codes together. The linker will then complain about duplicate symbols..
The 'core problem' is situated in the function "ExportDataInternal::getDataStructString()".

Milestone: 1.0 Status: closed Owner: Milan Vukov Labels: bug (4)
Updated: 2013-01-22 Created: 2012-12-04 Creator: Andrew Wagner Private: No
On linux, Acado should install things only under /usr/local by default.
Currently, the libraries are getting installed in /usr/lib, although some of the other stuff gets correctly placed under /usr/local/*
By convention, the package manager is the only thing that should be installing anything in /usr/lib/*.
Related
Ticket: #7
Discussion

Milan Vukov
2012-12-04
labels: --> bug
status: open --> accepted
assigned_to: Milan Vukov

Reply
Link
Edit
Delete

Attach

Milan Vukov
2013-01-22
The "bug" has been fixed... in commit 120.

Reply
Link
Edit
Delete

Attach

Milan Vukov
2013-01-22
status: accepted --> closed

Reply
Link
Edit
Delete

Attach

Andrew Wagner
2013-01-23
Thanks Milan!
On Tue, Jan 22, 2013 at 8:12 PM, Milan Vukov [email protected] wrote:
status: accepted --> closed
[tickets:#7] Install in /usr/local/ by default on linux
Status: closed
Labels: bug
Created: Tue Dec 04, 2012 05:00 PM UTC by Andrew Wagner
Last Updated: Tue Jan 22, 2013 07:11 PM UTC
Owner: Milan Vukov
On linux, Acado should install things only under /usr/local by default.
Currently, the libraries are getting installed in /usr/lib, although some of
the other stuff gets correctly placed under /usr/local/*
By convention, the package manager is the only thing that should be
installing anything in /usr/lib/*.
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/acado/tickets/7/
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/prefs/

Related
Ticket: #7

I would like to be able to get the files as a file tree of some sort. Currently I run the code export somewhere in /tmp and then read the files and delete the tmp dir afterwords, which is annoying and not very portable.