changes_1_8_0

Joel Andersson edited this page Feb 17, 2014 · 22 revisions

Changes from version 1.7.0beta to 1.8.0beta.

Safer callback mechanism (#882)

Callbacks for NLPs are now made as follows in Python:

@pycallback
def simplecallback(f):
  print "====Hey, I'm an iteration===="
  print "X_OPT = ", f.getOutput("x")
  print f.getStat("iteration")

solver = IpoptSolver(nlp)
solver.setOption("iteration_callback",simplecallback)

In C++, solver.setOption("iteration_callback",c) with c a function pointer: typedef int (*CallbackCPtr)(FX &f, void* user_data);

CFunction is replaced by CustomFunction. PyFunction is dropped but its functionality is preserved as follows:

class Fun:
  def evaluate(self,(x,y),(z,)): 
    z0 = 3*y
    z1 = x+z0
    z2 = sin(z1)
    z.set(z2)

c = PyFunction(Fun(), [sp_dense(1,1),sp_dense(1,1)], [sp_dense(1,1)] )
c.init()

There is also an alternative simpler syntax:

@pyfunction([sp_dense(1,1)], [sp_dense(1,1)])
def fun((x,y)):
  return [sin(x+3*y)]

sq.init()

In C++, CustomFunction takes a function pointer as first argument: typedef void (*CustomEvaluateCPtr)(CustomFunction &f, void* user_data);

Check the in-doc examples.

Call/eval arguments are more strict now.

Previously, one could call call or eval on FX with a vector of size smaller than the number of inputs of the function. This has been removed. You are strongly encouraged to use IOScheme helpers syntax in all cases.

e.g.

Do not use:

integrator.call([x0,p])

But use:

integrator.call(integratorIn(x0=x0,p=p))

Custom IOscheme helpers, improved

There is now a cleaner mechanism to define your own IOScheme helpers:

from casadi import *
farmIn = IOScheme(["sheep","wolves"])

x = ssym("x")
y = ssym("y")

f = SXFunction(farmIn(sheep=x,wolves=y),[x/y])
f.init()

f.setInput(12,"sheep")

AD by operator overloading no longer supported (#884)

In the past, there have been two different ways of calculating derivatives in CasADi:

  • Calculating directional derivatives during the numerical evaluation using the syntax, using the "operator overloading" (OO) approach in AD literature:
f.setInput(...)
f.setFwdSeed(...)
f.setAdjSeed(...)
f.evaluate(nfdir, nadir)
f.getOutput(...)
f.getFwdSens(...)
f.getAdjSens(...)
  • Generating new expression for the derivatives, using the "source code transformation (SCT)" approach in AD literature:
f.jacobian()
f.hessian()
f.derivative(3,4)
f.gradient()

The support for the former approach has now been dropped, which means that henceforth, only the SCT will be possible. The main reasons for this move are as follows. Firstly, the SCT approach in CasADi has now reached a mature state and gradually replaced the OO approach, rendering the OO approach of limited usefulness. Secondly, dropping support for OO improves the maintainability of the code.

Apart from no longer being able to access the operator overloading mode directly (as above), certain functions that are only relevant for the OO mode has been removed:

f.updateNumSens()
f.requestNumSens(...)
f.numAllocFwd()
f.numAllocAdj()
f.evaluateCompressed(...)

as well as some options:

f.setOption("number_of_fwd_dir",...)
f.setOption("number_of_adj_dir",...)
f.setOption("max_number_of_fwd_dir",...)
f.setOption("max_number_of_adj_dir",...)
f.setOption("store_jacobians",...)
f.setOption("numeric_jacobian",...)
f.setOption("numeric_hessian",...)

For two classes, Simulator and ControlSimulator, OO was the only supported way of calculating derivative information. The drop of support means that AD for these two classes are no longer possible. Plans exist to address this, cf. #929.

Changes to linear solvers (#889)

The input scheme of linear solver no longer accepts a "transpose" argument. You can still solve transposed linear solver by calling the LinearSolver::solve methods or by creating a linear solver for the transposed system. Linear solvers can now be embedded more efficiently into symbolic expressions (better sparsity propagation).

Changes to nonlinear solvers (#823, #952)

The nonlinear root-finding solvers (ImplicitFunction and derived classes) have been generalized to support auxiliary outputs. The input signature has also change to include an initial solution guess (earlier, the user had to "set the output"). Nonlinear solvers can now be embedded more efficiently into symbolic expressions (better sparsity propagation).

Major update of the ODE/DAE integrator classes (#794)

A major update of the ODE/DAE integrator classes have taken place. The changes include:

  • Major refactoring of the RKIntegrator class, which implements a classical fixed-step Runge-Kutta method (RK4). It should be mature enough for use.
  • Reimplementation of the CollocationIntegrator class, which implements a fixed-step collocation method (a type of implicit Runge-Kutta schemes). The new implementation replaces a previous "all-time-points-at-once" implementation, which is still available, but has been renamed OldCollocationIntegrator.
  • The signature of integrators have changed to include an initial guess for the algebraic variables and the algebraic variable at the end. This applies to both the forward problem "z0", "zf" (i.e. INTEGRATOR_Z0, INTEGRATOR_ZF) and the backward problem "rz0", "rzf" (i.e. INTEGRATOR_RZ0, INTEGRATOR_RZF). Cf. (#504). This also replaces the "init_z" option for IdasIntegrator.
  • Integrators can now be embedded more efficiently into symbolic expressions (better sparsity propagation).