casadi/casadi

CasADi is a symbolic framework for numeric optimization implementing automatic differentiation in forward and reverse modes on sparse matrix-valued computational graphs. It supports self-contained C-code generation and interfaces state-of-the-art codes such as SUNDIALS, IPOPT etc. It can be used from C++, Python or Matlab/Octave.

Learn all about CasADi at the homepage or jump to install instructions...

casadi's Issues

Remove the algebraic states from Idas' state vector

Currently, algebraic states are included into state vector in IDAS. This is not necessarily a good idea, since they contain no real information - they are implicitly defined by the DAE residual function.

Created by jaeandersson at: 2010-12-20T22:16:38
Last updated at: 2011-01-12T14:56:52

---

Comment 1 by jaeandersson at 2011-01-12T14:56:52

It is now possible to hide all or some of the algebraic states. The vector DAE_X contains states visible to the outside, DAE_Z internal algebraic states, always appended to the end of the IDAS vectors.

Change the arguments of evaluate(*,*)

Since the idea of higher order numerical derivatives has been scrapped (ticket #3), the arguments of evaluate(,) in the FX classes can change meaning from ad_order to number of derivative directions. This will facilitate when a derivative function is used multiple times with different number of derivative directions.

Created by jaeandersson at: 2010-11-26T16:34:35
Last updated at: 2011-03-20T22:02:28

---

Comment 1 by jaeandersson at 2011-03-20T22:02:28

This has been fixed (ac01e4b). Note that the new signature of the function is not backwards compatible when there are more than one forward and/or adjoint derivative direction. The old evaluate function is available under the name evaluate_old for backward compatibility.

MXFunction fails with modified input MX

Consider this python script:

from casadi import *
from numpy import *

x = MX("x",2,3)

f = MXFunction([trans(x)],[x]) # fails
#f = MXFunction([x],[trans(x)]) # works

f.init()
f.setInput([1,2,3,4,5,6],0)
f.evaluate()

It fails with an unhelpful 'RuntimeError: vector::_M_range_check'

Created by jgillis at: 2010-12-28T21:49:17
Last updated at: 2010-12-28T23:56:56

---

Comment 1 by jgillis at 2010-12-28T22:47:04

Traced back to MXFunctionNode::evaluate(int fsens_order, int asens_order):

for(int ind=0; ind<input_.size(); ++ind)
inputv[ind]->setOutput(input(ind).data());

---

Comment 2 by jgillis at 2010-12-28T23:32:55

Traced back to 'MXNode::init()' not being called on the Transpose node.
'MXFunctionNode::init()' seems only to initialize output nodes.
Is this intended behaviour?

---

Comment 3 by jgillis at 2010-12-28T23:56:56

Primary cause is 'MXFunctionNode::makeAlgorithm' failing to list trans(x) as a dependency.
Actually, this omitting isn't unreasonable.

Probably intended behaviour. Closing.

Reason for bringing up the issue was to allow jacobians when x is a matrix in the following snippet:

f = MXFunction([flatten(x)],[flatten(x)]) # fails

Correct handling of parameters in XML

Right now all parameters are replaced by the expressions from their binding expressions. Instead they should be kept in their original form, allowing the user to substitute them himself.

Created by jaeandersson at: 2010-11-26T14:08:12
Last updated at: 2011-05-24T17:32:51

---

Comment 1 by jaeandersson at 2011-05-24T17:32:51

This issue is solved as of f18e0cb.

Identify components appearing linearly in the objective function and constraints

This is needed to get BFGS to work well.

Created by jaeandersson at: 2010-11-08T10:10:38
Last updated at: 2011-06-04T22:10:33

---

Comment 1 by jaeandersson at 2011-02-16T23:46:08

If an exact Hessian is provided but the user still prefers to work with limited memory, the information is passed. This is of little practical value however, since there is little reason to use BFGS if one has the exact Hessian readily available. Could be helpful however to compare the methods however, BFGS vs exact Hessian.

---

Comment 2 by jaeandersson at 2011-02-18T01:35:14

The only way I know how to get this to work is to apply finite differences to the jacobian and the gradient of the objective and check the value. Is there some better way? If the function has it's syntax tree given, it is not really an interesting question, since you are then able to generate the hessian and check the sparsity (which doesn't mean that you have to use it -- you can still use BFGS).

---

Comment 3 by jaeandersson at 2011-06-04T22:10:33

This was actually given a simple fix long time ago, which unfortunately wasn't checked in.

It can probably be improved further, but I'll anyway close the ticket.

Remove, restructure the SXMatrix class

Created by jaeandersson at: 2010-10-22T18:51:43
Last updated at: 2010-11-09T00:52:12

---

Comment 1 by jaeandersson at 2010-11-01T11:51:07

There are three alternatives here:

1. Have FX not containing sparsity information
   advantages: easy to implement
   problems: how to represent e.g. jacobians and hessians?
   conclusion: not a good option
2. Replace SXMatrix it with a standard implementation
   A good choice would be ublas compressed matrix
   advantages: standard, efficient implementation, well documented
   disadvantages: more complex design, possible side effects that are hard to debug, possibly less efficient, how to recognize that an element is non-zero?, not suitable to interface with Python
3. Restructure SXMatrix
   All non-essential parts of SXMatrix can be moved away from the class definition. Only a core is kept, which consists of a row compressed storage. The class should be made a template class which works on any class that has a function "iszero" defined for it (need to define a function bool iszero(double x)).

There are two possible implementations:
3.1: inherit std::vector: old functions are kept, get iterators for free etc
Problem: less efficient to copy

3.2: inherit from shared object: more efficient to copy, similarities with the MX class. Sparsity can also be made a reference counted object.

The advantage of this approach is that you get access to an "everything is a matrix"-class in Python, which can have matlab syntax. Disadvantage is that it could be quite some work to make it run smoothly everywhere.

Specify Python installation

It is common to have multiple Python installations at the same machine - the possibility to select which one to use when building casadi and the swig interface would be handy. I tried

cmake .. -DEXTRA_LIBRARIES=gfortran -DPYTHON_LIBRARIES=/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ -DPYTHON_INCLUDE_DIRS=/opt/local/Library/Frameworks/Python.framework/Versions/2.6/Headers

This does not work, however:

make python VERBOSE=1
...
[100%] Building CXX object swig_interface/CMakeFiles/_casadi.dir/casadiPYTHON_wrap.o
cd /Users/jakesson/projects/OPTICON-SOFTWARE/build/swig_interface && /usr/bin/c++   -D_casadi_EXPORTS -O3 -fPIC -I/Users/jakesson/projects/OPTICON-SOFTWARE/. -I/Library/Frameworks/Python.framework/Headers -I/Users/jakesson/projects/OPTICON-SOFTWARE/swig_interface/..   -o CMakeFiles/_casadi.dir/casadiPYTHON_wrap.o -c /Users/jakesson/projects/OPTICON-SOFTWARE/build/swig_interface/casadiPYTHON_wrap.cxx

Obviously, another Python installation than the one specified is used.

Any clues?

Created by None at: 2010-11-15T20:23:31
Last updated at: 2011-02-17T00:44:19

---

Comment 1 by jaeandersson at 2010-11-24T15:06:43

Please refer to the email conversation with Carlo. Since none of us has multiple python installation, we cannot test it ourselves easily.

---

Comment 2 by jaeandersson at 2011-02-09T19:57:17

It should be possible to edit the CMakeCache file and to correct the Python path there. Can someone confirm that this works?

---

Comment 3 by jaeandersson at 2011-02-16T23:58:44

Closing the ticket. Editing CMakeCache.txt should work fine.

---

Comment 4 by jgillis at 2011-02-17T00:44:19

On response to the first comment, Oracle's virtualbox could provide a neat way to test this without disrupting your system.

Two ways of calculating directional derivatives

There are two ways of calculating directional derivatives:

1. Forward/Adjoint AD in multiple directions (numerically)
2. Generating the entire Jacobian and multiplying from the right or left

These two ways are related, for example the entire Jacobian can be calculated using multiple direction AD and Curtis Powel Reed seeding. But the entire Jacobian can also be calculated using AD by source code transformation, right now for the SXFunction class but later also for MXFunction, CFunction and possibly others.

A good idea could be to implement a switch: if there are more than "n" directions (user is able to set "n"), use directional derivatives, otherwise generate Jacobian and then multiply.

Created by jaeandersson at: 2010-11-23T12:25:43
Last updated at: 2011-02-18T01:20:00

---

Comment 1 by jaeandersson at 2011-02-18T01:20:00

This decision can be left to the user.

Allow building of Python code without all packages

Current version of the Python interface only works if all interfaces are installed.

Created by jaeandersson at: 2010-10-28T22:00:19
Last updated at: 2010-10-29T21:34:22

---

Comment 1 by None at 2010-10-29T21:34:22

Done.

Jacobian of matrixr functions

Calculating a Jacobian of an MXFunction requires the input and output to be vector (ncol=1).

This is a bit restrictive. While resorting to tensors may be a bit over-the-top, why not flatten the input and output before evaluation?

I believe this used to be the behaviour in earlier versions, but now there's just the error message "JacobianNode::JacobianNode: input not a vector".

Created by jgillis at: 2010-12-29T00:22:43
Last updated at: 2011-02-21T17:18:21

---

Comment 1 by jgillis at 2011-02-16T17:26:02

One harmless option is to at least allow for 'row vectors' in addition to 'column vectors'.

MX::vec() is a viable candidate to process the function that gets passed on to !JacobianInternal constructor. However, this would require the use of MXFunction::call() which is only possible after initialization. And initialization is not done in this constructor now, probably for good reason.

---

Comment 2 by jaeandersson at 2011-02-16T22:38:19

Hello! Right, it is not defined for the moment. I think that the desired behavior for the jacobian of a matrix valued function with respect to a matrix valued input is simply to to vectorize both, meaning:
A.jacobian(i) == vec(A).jacobian(i) and so on.

I don't know what makes the most sense mathematically, without resorting to tensors.

---

Comment 3 by jgillis at 2011-02-16T23:29:41

So we're on the same line of thought here...

---

Comment 4 by jgillis at 2011-02-21T17:18:21

Fixed in bcd010b: flattening input/output. There is no performance penalty whatsoever.

Jacobian function for the integrator classes

Write a Jacobian function for the integrator class(es). This function should create a new integrator for the forward sensitivity equations. Easy thing to do and not really urgent, as it is possible to do the same today with a bit of work.

Needed when AD by SCT works for the MX classes.

Spin-off of ticket #3.

Created by jaeandersson at: 2010-11-26T16:30:55
Last updated at: 2011-01-12T14:52:30

Interface KINSOL?

Interface Kinsol from the sundials suite. Do we really need this? Personally I think it would be nice if/when there is a "kinsols" newton-krylov method appearing, with sensitivitity capabilities.

Created by jaeandersson at: 2010-11-09T14:44:32
Last updated at: 2011-02-16T23:22:14

---

Comment 1 by jaeandersson at 2011-02-16T23:22:14

KINSOL has been interfaced, also with sensitivity capabilities by augmenting the system. The cstr.py example shows how to use it.

Interface all IPOPT options

Currently, only the options related to termination and derivative checking has been interfaced.

The options are described in:
http://www.coin-or.org/Ipopt/documentation/node59.html

Since there are quite a lot of possible options, an automatic procedure could be a good idea.

Created by jaeandersson at: 2010-11-08T10:20:19
Last updated at: 2010-11-09T01:17:12

---

Comment 1 by jaeandersson at 2010-11-09T01:17:12

This has now been fixed. Note that "abstol" is now called "tol" for consistency.

Wrong display of index for MX objects in SWIG

Towards a Computer Algebra System with Automatic
Differentiation for use with Object-Oriented modelling languages
x = MX("x",2,2)

print x[0] # prints x[0]
print x[1] # prints x[1]
print x[2] # BAD: prints x[0]
print x[3] # BAD: prints x[1]

Created by jgillis at: 2010-11-07T10:53:12
Last updated at: 2010-11-10T13:20:45

---

Comment 1 by jaeandersson at 2010-11-10T13:20:45

Thanks for reporting! This has been fixed in bcca91f0586e23f705d97ff8d12960f6b2dc8314. Remember that the MX class is still experimental. Joel

Add a licence header to all files

This can be done automatically. Which wording?

Created by jaeandersson at: 2010-10-28T22:07:29
Last updated at: 2010-12-01T15:19:32

---

Comment 1 by jaeandersson at 2010-10-28T22:09:48

ACADO Toolkit has the header:

/*
*    This file is part of ACADO Toolkit.
*
*    ACADO Toolkit -- A Toolkit for Automatic Control and Dynamic Optimization.
*    Copyright (C) 2008-2009 by Boris Houska and Hans Joachim Ferreau, K.U.Leuven.
*    Developed within the Optimization in Engineering Center (OPTEC) under
*    supervision of Moritz Diehl. All rights reserved.
*
*    ACADO Toolkit is free software; you can redistribute it and/or
*    modify it under the terms of the GNU Lesser General Public
*    License as published by the Free Software Foundation; either
*    version 3 of the License, or (at your option) any later version.
*
*    ACADO Toolkit is distributed in the hope that it will be useful,
*    but WITHOUT ANY WARRANTY; without even the implied warranty of
*    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
*    Lesser General Public License for more details.
*
*    You should have received a copy of the GNU Lesser General Public
*    License along with ACADO Toolkit; if not, write to the Free Software
*    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
*
*/


/**
*    \file src/utils/acado_utils.cpp
*    \author Hans Joachim Ferreau, Boris Houska
*    \date 31.05.2008
*/

Is this suitable, after changing the names?

---

Comment 2 by jaeandersson at 2010-12-01T15:19:32

This has been done in 548c799. There is also a python script for quickly updating existing or adding missing license headers automatically for all files in the future.

Make SWIG a separate target in the build system

Created by jaeandersson at: 2010-10-22T19:06:06
Last updated at: 2010-10-30T13:39:08

---

Comment 1 by None at 2010-10-28T16:45:04

I'll take care of this

---

Comment 2 by None at 2010-10-29T21:32:56

The python interface can be now compiled separately.
Use "make python" to compile the interface created through swig.

---

Comment 3 by jaeandersson at 2010-10-30T13:39:08

Hello! Great to see that you're starting to fix tickets! We should discuss whether to mark the tickets as closed as we fix them, or leave it for a group meeting, say once every two weeks. As to keep track of the things we actually do.

I updated the wiki installation entry.

Add iterators to SXMatrix

The SXMatrix class now has the iterators inherited from std::vector, which allow iterating over non-zero entries. They should be kept, but a new set of iterators should be added, allowing iterating over all entries, as if the matrix was dense.

the iterator class can be called "SXMatrix::dense_iterator" and the following corresponding functions should be added:
SXMatrix::dbegin() // dense begin
SXMatrix::dend() // dense end

Created by jaeandersson at: 2010-11-02T16:02:54
Last updated at: 2011-01-12T14:37:32

---

Comment 1 by jaeandersson at 2011-01-12T14:37:32

No longer needed: See #57

Separate differential and algebraic states in Idas' DAE residual and quadrature functions

IDAS does not distinguish between differential and algebraic states by default, only if setID is provided. Since it is often important to distinguish between the two (e.g. in a shooting method), it might be a good idea to always separate them. The main problem with this is that it might screw up a sparsity pattern such as bandedness.

Created by jaeandersson at: 2010-12-20T22:22:45
Last updated at: 2011-01-12T14:55:19

---

Comment 1 by jaeandersson at 2011-01-12T14:55:19

Has been implemented.

Correct handling of alias variables

The XML model format support alias variables, which are typically generated by a Modelica tool in the compilation process. For example, the model

model M
Real x,y;
equation
x=y;
x=1;
end M;

is usually translated into the equivalent model:

model M
Real x;
equation
x=1;
end M;

Alias variables do not appear in the model equations, and should therefore not be included in the variable vectors xdot, x, xa, etc. They do, however, appear in the list of ScalarVariables in the XML file and they are then marked as aliases.

Created by None at: 2010-11-18T18:52:43
Last updated at: 2010-11-23T11:58:05

---

Comment 1 by jaeandersson at 2010-11-19T01:29:25

Hello!

I've committed a quick-fix in revision 548: if a variable is has the "alias" attribute set to "alias", it is simply disregarded.

I guess, the information about an alternative name for the variable, should somehow be stored in the object, but I'll leave this for later.

If this is ok, I'll close the ticket.

Recompiling SWIG

The Python interface doesn't recompile automatically after changes has been made to the interface. When building with "make python", any old installation should be automatically removed, if its not possible to spot changes. Right now, it's necessary to to "make clean" and then "make python" to rebuild the interface, causing the entire casadi to rebuild.

Created by jaeandersson at: 2010-11-02T14:58:51
Last updated at: 2010-11-24T15:02:55

---

Comment 1 by jaeandersson at 2010-11-24T15:02:55

Since it appears to work for me now, I will close the ticket. Thanks to whoever fixed it!

IpoptSolver without constraints fails

The default arguments for IpoptSolver generate an error.

x=SX("x")
f = SXFunction(x, tan(x)-1)
solver = IpoptSolver(f)

Throws: RuntimeError: SharedObject::operator->(): Node is null

Created by jgillis at: 2010-11-07T13:00:40
Last updated at: 2010-11-09T01:15:12

---

Comment 1 by jaeandersson at 2010-11-09T01:15:12

This should be fixed now. Thanks for reporting! Note that there is still an issue with the exact Hessian in ipopt. Please let me know if there are more bugs.

P.S: Note that all options in IPOPT are now interfaced to CasADi. Check IPOPT for a list of possible settings. "abstol" is now called just "tol" for consistency.

Implement AD by SCT for the MX class

Implement AD by SCT for the MX class, couple this to the "jacobian"-function in the MXFunction class. This is an involved and error prone task! Only AD forward at a first stage.

This is a spin-off of ticket #3.

Created by jaeandersson at: 2010-11-26T16:28:40
Last updated at: 2011-06-18T17:42:44

---

Comment 1 by jaeandersson at 2011-06-18T17:42:44

This has been dealt with in other tickets. An AD by SCT approach for MX is now present.

Add derivative information to c-functions

There should be an efficient way of passing derivative information to c-functions. Right now, only directional derivatives are possible. There should be a way also to pass a Jacobian function (with sparsity structure). This is particularly useful when evaluating multiple directional derivatives.

Created by jaeandersson at: 2010-11-23T12:18:45
Last updated at: 2011-01-12T14:59:06

Have the python interface installed in the right place in the file system

When typing make python, the python interface should be installed in the correct place in the file system, e.g. /usr/share/python2.6/dist-packages/

Created by jaeandersson at: 2010-11-15T14:27:37
Last updated at: 2010-11-17T10:22:14

---

Comment 1 by None at 2010-11-17T10:22:14

Python can now be installed with

make install_python

The install path is found with distutils
The rest of the build systems can be used as before

Tensor jac, jacobian, hess and hessian functions

Right now, the functions jac, jacobian, hess and hessian give the jacobian/hessian of one output with respect to one input. There it should also be possible to get the full jacobians/hessians.

It can be created as a new function, with a different name, or overload the current functions, in which case the default input/output indices (now 0) of these functions must be removed.

This is important mainly for efficiency.

Created by jaeandersson at: 2010-11-23T12:08:53
Last updated at: 2011-06-06T11:54:04

---

Comment 1 by jaeandersson at 2010-12-20T22:11:28

This might not be necessary after all. If we assume that we have a function f(x,z) where x and z have a large dimension, the cost of evaluating df_fx and df_fz together or separately should be comparable, due to the fact that the (only?) calculations they have is the evaluation of f and the calculation of partial derivatives. If x and z have a high dimension, this cost should be neglible.

---

Comment 2 by jaeandersson at 2011-06-06T11:54:04

This issue has been solved (though not for hessian or hess) thanks to the new jacobian design. See issue #127.

Simple C++ tests

Need to add some simple tests for demonstrating how to use CasADi from C++ - translate Python examples? Easy thing to do, but they must also be well documented.

Created by jaeandersson at: 2010-12-10T15:42:28
Last updated at: 2012-05-06T21:49:01

---

Comment 1 by jaeandersson at 2011-02-18T01:37:55

I like the Python test suite. Does it also make sense to make a simple C++ test suite? I think yes. If so, what is a good environment for doing this? Something in Boost?

---

Comment 2 by jaeandersson at 2011-06-26T22:39:02

This important since you might not be willing, able or interested in generating the python interface on every system.

---

Comment 3 by jgillis at 2011-07-11T00:07:02

Replying to [comment:1 joelandersson]:

I like the Python test suite. Does it also make sense to make a simple C++ test suite? I think yes. If so, what is a good environment for doing this? Something in Boost?

If you create a C++ test suite, do it under /test/cpp and extend /test/Makefile a bit so the tests get included in the trunktesterbot.

Are you suggesting to do the bulk of testing in C++ and use python only for the swig-specific tests? Because I find scripting languages better suited for writing test suites...

---

Comment 4 by jaeandersson at 2012-05-06T21:49:01

I'll close this ticket. As Joris mentioned, it is already possible to add a c++ test to the test suite.

Implement support for second order numerical derivatives (forward over adjoint)

Created by jaeandersson at: 2010-10-22T18:55:07
Last updated at: 2010-11-26T16:26:23

---

Comment 1 by jaeandersson at 2010-11-26T16:26:23

This is not really necessary. Instead the same can be achieved by a combination of symbolic AD (to generate an analytic function for the first order derivatives) followed by a numerical AD (if a directional derivative is enough) or symbolic AD (if the whole hessian, with sparsity, is necessary).

Most things already exist for this and it works already today, (see CSTR example).

To make this work more smoothly, and generally:

1. Implement AD by SCT for the MX class, couple this to the "jacobian"-function in the MXFunction class (involved!) Only AD forward at a first stage.
2. Write a Jacobian function for the integrator class(es). This function should create a new integrator for the forward sensitivity equations (easy)

Clean implementation for getting setting inputs, outputs, seeds and derivatives

The current implementation is a quick fix based on macros. There is an implementation based on template member functions, but this is not working due to two reasons:

• It fails to pass references of doubles, instead appearently passing by value, causing the value to get lost
• SWIG doesn't support multiple templates

Created by jaeandersson at: 2010-10-22T18:49:25
Last updated at: 2011-01-12T14:47:59

---

Comment 1 by jaeandersson at 2011-01-12T14:47:59

The current design is good, for more flexibility it is always possible to access the storage, a Matrix directly.

Fix bug in Hessian by source code transformation

The Hessian generated by SXFunction and passed to Ipopt is incorrect. Some components are missing and others are wrong with a constant factor 2. This needs to be investigated and fixed.

Currently, all the sparse Hessian is passed, not just the upper triangular part. This might be a clue.

Created by jaeandersson at: 2010-11-08T10:15:16
Last updated at: 2010-11-09T14:39:12

---

Comment 1 by jaeandersson at 2010-11-09T14:39:12

The problem had to do, not with the Hessian but with ad by source code transformation in forward mode. The forward mode is now turned off, which should work fine at least for small problems. A new ticket has been created to fix forward mode AD.

Add a unittest suite

Created by jaeandersson at: 2010-10-22T19:04:56
Last updated at: 2010-12-29T21:25:01

---

Comment 1 by jaeandersson at 2010-10-28T22:05:43

The test suite should preferably be implemented in Python. A good candidate is "Nose":
http://somethingaboutorange.com/mrl/projects/nose/0.11.2/

---

Comment 2 by jgillis at 2010-12-28T21:39:09

There is now a mian directory /test that contains unittests.
So far, there is only a python test suite in /test/python.

Running /test/python/alltests.py in its directory will do all unit tests.

Current framework uses 'unittest', not 'Nose'

Bug in XML import: constraints

There seems to be a bug in the XML import with respect to constraints. Consider the following model:

model VDP
// Parameters
parameter Real p1 = 0;             // Parameter 1
parameter Real p2 = 1;             // Parameter 2
parameter Real p3 = 2;             // Parameter 3

Real x1(start=0,fixed=true);
Real x2(start=1,fixed=true);
input Real u(start=0);
equation
der(x1) = (1 - x2^2) * x1 - x2 + u;
der(x2) = x1;
end VDP;

optimization VDP_Opt (objective = cost(finalTime),
startTime = 0,
finalTime = 20)

VDP vdp(u(max=0.8)=u);
Real cost(start=0,fixed=true);
input Real u(start=0);
equation
der(cost) = exp(vdp.p3 * 1/*time*/) * (vdp.x1^2 + vdp.x2^2 + vdp.u^2);
constraint
vdp.u<=0.75;
vdp.x1>=-4;
end VDP_Opt;

When imported with Casadi, only one of the constraints show up:

In [91]: print be_colloc.xmlocp.ocp
Variables
time: time
dependent: vdp.p1
dependent: vdp.p2
dependent: vdp.p3
differential state: vdp.x1
differential state: vdp.x2
algebraic state: vdp.u
differential state: cost
control: u
dependent: startTime
dependent: finalTime

Dynamic equations
0 == (der(cost)-(exp(2)*(((vdp.x1*vdp.x1)+(vdp.x2*vdp.x2))+(vdp.u*vdp.u))))
0 == (der(vdp.x1)-((((1-(vdp.x2*vdp.x2))*vdp.x1)-vdp.x2)+vdp.u))
0 == (der(vdp.x2)-vdp.x1)
0 == (vdp.u-u)

Time state(s):                  [1](time)
Differential states (implicit): [3](vdp.x1,vdp.x2,cost)
State derivatives:              [3](der(vdp.x1),der(vdp.x2),der(cost))
Differential states (explicit): <empty vector>
Algebraic states:               [1](vdp.u)
Controls:                       [1](u)
Parameter:                      <empty vector>
Dependent variables:            [5](vdp.p1,vdp.p2,vdp.p3,startTime,finalTime)

Differential-algebraic equations (implicit)
0 == (der(cost)-(exp(2)*(((vdp.x1*vdp.x1)+(vdp.x2*vdp.x2))+(vdp.u*vdp.u))))
0 == (der(vdp.x1)-((((1-(vdp.x2*vdp.x2))*vdp.x1)-vdp.x2)+vdp.u))
0 == (der(vdp.x2)-vdp.x1)
0 == (vdp.u-u)

Differential equations (explicit)

Algebraic equations

Initial equations
0 == vdp.x1
0 == (vdp.x2-1)
0 == cost

Dependent equations
vdp.p1 == 0
vdp.p2 == 1
vdp.p3 == 2
startTime == 0
finalTime == 20

Mayer objective terms
cost at time == 20

Constraint functions
-inf <= vdp.u <= 0.75

Time horizon
t0 = 0
tf = 20


In [92]:

Created by None at: 2010-11-23T20:32:20
Last updated at: 2010-11-24T15:00:51

---

Comment 1 by jaeandersson at 2010-11-24T15:00:51

This bug (in fact the problem was simply that upper bounds weren't implemented) has been fixed in revision 553. At the same time I have changed the upper and lower bounds from being vectors of doubles to being vectors of SX. This makes sense for example when the bounds depend on time or on parameters (that should be fixed during an optimization).

"Function not initialized"

Trying to use an non-initialized function now gives strange errors (though not causing crashes). A message like "Function not initialized" should be thrown instead.

Created by jaeandersson at: 2010-12-09T15:23:38
Last updated at: 2011-01-21T19:35:27

---

Comment 1 by jaeandersson at 2011-01-12T15:04:53

Joris: did you change this? Can I close the ticket?

---

Comment 2 by jgillis at 2011-01-21T19:35:27

I did throw in some assertInit()'s , yes

Clearing the static counters of ACADO

The static counters of ACADO should be cleared in the destructor of AcadoInternal, allowing new instances to be created.

I tried to add:

ACADO::AlgebraicState              dummy1;
ACADO::Control                     dummy2;
ACADO::DifferentialState           dummy3;
ACADO::DifferentialStateDerivative dummy4;
ACADO::Disturbance                 dummy5;
ACADO::IntegerControl              dummy6;
ACADO::IntegerParameter            dummy7;
ACADO::IntermediateState           dummy8;
ACADO::Parameter                   dummy9;

dummy1.clearStaticCounters();
dummy2.clearStaticCounters();
dummy3.clearStaticCounters();
dummy4.clearStaticCounters();
dummy5.clearStaticCounters();
dummy6.clearStaticCounters();
dummy7.clearStaticCounters();
dummy8.clearStaticCounters();
dummy9.clearStaticCounters();

but it didn't seem to help.

Created by jaeandersson at: 2010-11-11T13:05:21
Last updated at: 2010-11-13T01:04:09

---

Comment 1 by jaeandersson at 2010-11-13T01:04:09

The issued was solved after moving the above code from the destructor to the constructor. Checked in in revision 533.

Compilation issues in old gcc

The compilation fails due to ambiguity for operator+=.

Created by jaeandersson at: 2010-11-09T22:57:29
Last updated at: 2010-11-10T09:24:50

---

Comment 1 by jaeandersson at 2010-11-10T09:24:50

The problem had to do with automatic typecasting rules. Since it can be expected that other compilers will experience similar difficulties, a safer but less efficient way of accessing elements in SXMatrix has been implemented. There is only a difference when using CasADi from C++ and using the ()-operators. From Python, there is no difference. For speed, users are encouraged to use ublas matrices and stl vectors in C++.

Reorganize folder structure

All the programs in the "test" sub-directories could be moved into a a folder called "examples". This would be a good idea because many examples use more than one interface so there is no reason they are located in a specific test folder. Several test programs could be removed.

All the interfaces could be moved into a directory called "interfaces":
interfaces
|-acado
|-sundials
|-ipopt
|-...

The directory "swig-interface" could be renamed just "python"

Created by None at: 2010-10-29T21:42:20
Last updated at: 2010-12-01T15:24:24

---

Comment 1 by jaeandersson at 2010-11-02T15:41:34

Hello! I support the idea of moving the examples to a single directory, it makes sense. I don't think it is a good idea to make an "interfaces" folder. The interfaces are not interfaces in the usual sense, they add functionality to the tool. There is also a quite large difference between the sundials-interface, which interfaces sundials TO casadi and the swig interface which interfaces casadi to python.

We have been talking about calling CasADi from JAVA and Octave using SWIG, so calling the swig interface python interface is a bit too specific.

---

Comment 2 by jaeandersson at 2010-11-23T12:35:23

As agreed on the meeting, the structure will also have the traditional trunk/tags/branches structure.

---

Comment 3 by jaeandersson at 2010-12-01T15:24:24

An examples folder has been created and the well working examples will be gradually moved there. 548c799.

Identify version of dependent software in CMake

The build system should verify that the Sundials and ACADO versions are correct.

Created by jaeandersson at: 2010-10-29T14:51:39
Last updated at: 2012-10-05T23:14:57

Problem linking with gfortran on mac

gfortran is missing from the libraries linked to when building the Python interface. Adding it is not a good option since it would make the build system gcc specific.

Adding "Fortran" to the project definition doesn't help.

Created by jaeandersson at: 2010-10-28T21:12:26
Last updated at: 2010-11-15T19:53:43

---

Comment 1 by jaeandersson at 2010-11-12T11:47:35

A simple solution has been checked in: revision 528. Set EXTRA_LIBRARIES when running cmake:

cmake .. EXTRA_LIBRARIES=gfortran

If this works, the ticket will be closed.

---

Comment 2 by None at 2010-11-15T19:53:43

The command above should be:

cmake .. -DEXTRA_LIBRARIES=gfortran

%inplicitconv does not work with Octave

The %inplicitconv command is new and is not recognized by Octave. There should be a conditional compilation, only add %inplicitconv when compiling for Python.

Created by jaeandersson at: 2010-11-11T12:59:49
Last updated at: 2010-11-23T11:59:05

---

Comment 1 by jaeandersson at 2010-11-23T11:59:05

Solved this by having it commented out by default.

Costum linear solver/preconditioner for CVodes

Right now only built-in linear solvers (banded/dense/iterative) work.

Created by jaeandersson at: 2010-12-09T15:25:23
Last updated at: 2011-01-12T14:53:32

---

Comment 1 by jaeandersson at 2011-01-12T14:53:32

fixed, forgot to close this ticket.

Put the doxygen documentation online

Could be a good idea to put a reasonable recent copy of doxygen generated documentation online.

Created by jaeandersson at: 2010-11-10T13:24:15
Last updated at: 2010-12-28T21:34:43

---

Comment 1 by jgillis at 2010-12-28T21:34:43

There has been a publishing script in /doc/publish.sh for some time now.
Any administrator can run the script to upload the doxygen files.

The files are put here: http://casadi.sourceforge.net/api/html/annotated.html

Update XML import to latest Jmodelica version

Created by jaeandersson at: 2010-11-09T22:58:58
Last updated at: 2010-11-10T15:24:38

---

Comment 1 by jaeandersson at 2010-11-10T15:24:38

Problem seems to have solved from itself with the latest jmodelica revision. Bug in jmodelica?

Problem with forward mode AD by source code transformation

There seams to be a problem with the forward mode AD by SCT. Pending a solution, this has been turned off, relying entirely on reverse mode AD.

Created by jaeandersson at: 2010-11-09T14:41:57
Last updated at: 2011-06-06T11:50:52

---

Comment 1 by jaeandersson at 2011-06-04T12:15:42

Since the function will be rewritten from scratch, there is no use in fixing the bug. Invalidating the ticket.

---

Comment 2 by jaeandersson at 2011-06-06T11:50:52

With the new design (#127), fwd mode AD by SCT works fine.

Add docstrings to Python interface

The Python user should be able to obtain the same information as is given to doxygen.

Created by jaeandersson at: 2010-10-29T14:57:36
Last updated at: 2010-12-29T21:24:11

---

Comment 1 by jgillis at 2010-12-29T21:13:37

Preliminary workflow is present now, and described https://sourceforge.net/apps/trac/casadi/wiki/gendoc here.

The http://casadi.sourceforge.net/api/python/html/index.html Python documentation uses sphinx's autodoc feature to import docstrings. Docstrings are generated by a doxygen tool.

The result can badly use some clean-up.

Write or interface a "Lifted Newton"-solver

Optimal control problems can currently be solved with collocation, single shooting or full space multiple shooting. To support multiple shooting, a "Lifted Newton"-solver need to be written or interfaced.

Created by jaeandersson at: 2010-10-28T22:19:20
Last updated at: 2010-11-24T15:09:24

---

Comment 1 by jaeandersson at 2010-11-24T15:09:24

This ticket is removed, since there is limited interest to take care of it. Instead, we shall focus on the implementation of an SQP method with inexact derivatives, but without automatic condensing.

Compilation with Visual C++

The tool currently does not compile with the Visual C++ compiler (tested Visual C++ 2010 Express). The code has to be modified so that it also compiles with VC, in addition to GNU.

When the code has been fixed, installation instructions should be added.

This is how to compile with Visual C++ in Windows:

1. Install CMake, Visual C++ and TortoiseSVN
2. Checkout CasADi from SVN using TortoiseSVN
3. Start Visual C++, open the command prompt from inside the program
4. Start the CMake gui from the command prompt by typing "cmake-gui"
5. Follow the instructions on the screen to generate an "nmake" makefile
6. Compile the program by typing "nmake" in the build directory from the VC command prompt

Created by jaeandersson at: 2010-12-10T13:51:19
Last updated at: 2011-06-28T10:29:38

---

Comment 1 by jaeandersson at 2010-12-10T15:40:14

The code now compiles with Visual Studio (26a2644) but det-minor crashes. Need to create some more simple tests.

Change file extension of octave interface

Octave only recongnizes dynamic libraries with the .oct extension. Therefore, the generated .so / .dylib /.dll file should be renamed removing the lib prefix and changing the suffix to .oct.

Created by jaeandersson at: 2010-11-11T13:02:02
Last updated at: 2011-02-18T01:28:20

---

Comment 1 by jaeandersson at 2011-02-18T01:28:20

See ticket #87. I will invalidate the ticket, since after adding a lot of Python specific features to the SWIG interface, one cannot expect it to be able to work for Octave anymore.

Transmit sparsity information to Python

CasADi data structure uses a general sparse (CRS) format. This should translate to an equivalent format in Python, e.g. sparse numpy arrays.

Created by jaeandersson at: 2010-10-29T15:01:02
Last updated at: 2011-01-12T15:03:09

---

Comment 1 by jaeandersson at 2011-01-12T15:03:09

This now works fine since both the CRSSparsity class has been added and interfaced. Also Matrix<> contains sparsity information.

Interface all ACADO options

All ACADO options needs to be mapped to the interface. Since ACADO uses enums in the options, an automatic procedure is not possible. The enums should be replaced by a corresponding string name.

Two options for the naming convension:

1. All string options lower case versions of the enum options (current implementation)
2. Upper and lower case kept in the names

Created by jaeandersson at: 2010-11-08T10:27:13
Last updated at: 2011-09-14T16:45:46

Complete or replace the Matrix class

The current template class Matrix<> is not complete. It must either be completed or replaced by something more mature. A good implementation should be based on the following principles:

1. As now, use row compressed storage
2. Be reference counted: Copying should copy the reference, changing the object involves creation of a new node if the node pointed to is not unique.
3. Be easy to interface with Python via SWIG
4. Be able to type convert to Scipy types
5. Use C++ standard syntax with iterators and so on

It must be researched if there is a current class which, at least partially, fulfills these needs.

One idea would be to write a reference counting system around the Boost type.

Created by jaeandersson at: 2010-12-10T17:21:51
Last updated at: 2011-01-12T14:36:07

---

Comment 1 by jaeandersson at 2010-12-10T17:24:13

A very good alternative is probably:
eigen.tuxfamily.org

License is LGPL, no perverse misuse of template meta programming. No dependencies. Runs on many compilers. A lot of bindings. Very promising at first glance.

---

Comment 2 by jaeandersson at 2011-01-12T14:36:07

The class has now been fixed and works well, also for interfacing with Python. The storage type is reference counted CRS sparsity, meaning several matrices can share the same sparsity pattern (important for AD, where all the seeds and sensitivities have the same sparsity pattern).

The class is not reference counted, but allows lazy copying via the SwapOnCopy() function.

Create a SWIG typemap between numpy matrix and SXMatrix

Create a SWIG typemap between numpy matrix and SXMatrix.

Even though SXMatrix is a sparse type and numpy matrices are dense, this is probably the best match. Scipy's sparse matrices does not support general objects (only built-in types) and can thus not be used.

To use numpy matrix rather than array is a good idea since numpy matrices are always rank-2 (like SXMatrix) and the numpy arrays are already typemapped to std::vector. Another typemap for the same type would cause confusion.

Created by jaeandersson at: 2010-11-05T14:27:50
Last updated at: 2011-01-12T15:01:32

---

Comment 1 by jaeandersson at 2011-01-12T15:01:32

Since SXMatrix as well as DMatrix and others are now easy to work with from Python, this is no longer needed.