All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Groups Pages
How to link the library with a new solver?

This part assumes the reader went through the Design choices and libraries' internals page and is familiar with the user interface.

Intregrating a solver step by step.

Prerequisite

The first step is determining if there is any interest in integrating the solver.

The solver should target one of the following optimization problems:

  • Nonlinear optimization
  • Linear optimization

...with or without constraints.

It should also support bounds and scaling. If not, emulating them should be possible.

Integrating solvers that solve very different problems will likely not match the interface and lead to major change in the package. These changes are beyond the scope of this document and should be discussed on the mailing-list.

Modifying the package.

Basically, adding a new solver means adding a new leaf in the solver hierarchy.

The new header and source files should be added in the src directory.

The naming convention is CamlCase, the name should be the solver's name suffixed by Solver.

This plug-in must be provided as a separate package to avoid cluttering RobOptim Core with useless dependencies.

Implementing the bridge.

The first step is choosing from which Solver you want to inherit from. The F parameter should be straightforward: it is the kind of objective function you expect. For the constraints, there are two cases:

  • If there is a unique constraint type: set C to const MyConstraintType* where MyConstraintType is the solver's constraints type.
  • If you want to discriminate your constraints into different categories, you will have to use a Boost.Variant. C should be: boost::variant<const MyConstraintType1*, const MyConstraintType2*>

Then, the solve method should be implemented in the bridge.

Following guidelines should be respected by any bridge:

  • Be sure to call reset if the result has to be recomputed the next time getMinimum is called.
  • Be sure that solve puts the computed value in the result_ attribute.
  • Solver's arguments should be exposed to users through the class.
  • The solver should not display anything by default. If possible, use the print method to display internal states.

Conclusion

The dummy solver can be a good starting point for anyone who wants to add a new solver as the code can be considered as the minimum stub to get a compilable bridge. It should also be quite easy to understand.

If you write a new bridge, please post an annoucement to the RobOptim Google group.