---

Like all objected-oriented frameworks, Iotr consists of several abstract interfaces that may each have several concrete implementations. For instance the abstract interface class GenMatrix has been concretely implemented by the classes SparseGenMatrix and DenseGenMatrix. Similarly, the abstract interface Formulation has been concretely implemented by the AmplFunctional and CuterFunctional classes, which represent functionals that interface with the Ampl and Cuter problem libraries.

As is also typical with object-oriented code, there are several layers to Iotr:

• A Solver Layer that implements the high-level algorithms and heuristics needed so solve a NLP;
• A Problem Formulation Layer that represents an individual problem instance in its natural format;
• A Foundation Layer that provides an interface to fundamental objects like functions, vectors and matrices without explicitly specifying how these are implemented in the system; and
• A Concrete Utility Layer that provides low-level services that may be used to build the foundation layer.

Note:

The abstract interface for the solver and problem formulation layers has not yet been written. This confuses the issue (and the documentation) somewhat.

As a concrete example, suppose the iotr framework is used to create a trust-region based solver that uses slack variables and that is implemented sequentially using dense linear algebra. At one point in the solution of the problem, a trial step is generated.

• Because this is a trust-region based implementation, the NlpIotrTrustRegion::trustkktqp2 is used to generate the step. The NlpIotrTrustRegion class is part of the Solver Layer.
• At some point in the generation of a trial step, a linear system based on the primal-dual equations is solved. The NlpIotrTrustRegion object invokes the NlpLinsys::factor and NlpLinsys::newtonStep methods to solve this system, which are abstract virtual functions in the Problem Formulation Layer. Because in this instance the problem formulation has been concretely implemented using slacks, the NlpSlackLinsys::factor and NlpSlackLinsys::newtonStep respond to the virtual method calls.
• The instance of NlpSlackLinsys simplifies the system, condensing all blocks corresponding to simple bounds or to slacks. It then invokes the PrimalDualSystem::factor and PrimalDualSystem::newtonStep abstract virtual methods. A PrimalDualSystem is an object in the Foundation Layer that solves linear systems having the simplified form.
  

  Different problem formulations may apply different transformations to reduce the system to this form. Because this is a dense implementation, methods of the DensePrimalDualSystem class will respond to the virtual method calls.

• The DensePrimalDualSystem will assemble the matrix, and use BLAS routines to solve the system. Althouth BLAS is not part of iotr, the BLAS functions may be seen as Concrete Utilities.

Thus classes and functions from each layer of iotr were used to generate a trial step. Each layer invokes functionality from the layer directly below it. Furthermore as the computation progresses from layer to layer, the operations grow more concrete.

---