Meeting the Challenges of Solver Independence

Steven DirkseGAMS

Lou Hafer SimonFraser University

Kipp MartinUniversity of Chicago

Ted RalphsLehigh University

November 6, 2007

1

Motivation

The context: a loosely coupled modeling language and a solver.

2

MotivationThe problem:

3

Motivation

Here is another view of solver side

4

Motivation

Here is another view of solver side – with Ipopt

5

Motivation

Here is another view of solver side – with Lindo

6

Motivation

An ideal world – no solver interface!

If the instance interface and option interface are robust enoughthen we have:

load(problem_instance);solve(options_list);

It is up to the solver to implement the problem instance andinterpret what is in the options list

7

COIN-OR Open Solver Interface

Problem 1: Only works for mixed-integer linear.

8

Extensions

I General nonlinear

I Cone

I Stochastic

I Constraint

9

COIN-OR Open Solver Interface

Problem 2: Does not distinguish between instance, solver options,instance result, and instance modification.

10

Important Concept

It is important to distinguish between:

I The model instance

I Solver options

I Solver results

I Model modifications

11

Important Concept

The Optimization Services project is designed to help provide thisframework.

I The model instance – OSInstance class

I Solver options – OSOptions class

I Solver results – OSResult class

I Model modifications – to be completed

12

COIN-OR Open Solver Interface

Problem modification: borrow from the Gang of Four DesignPatters

Use the command class for storing modifications.

13

COIN-OR Open Solver Interface

Two key classes:

I OsiXFormMgr

I OsiXForm

14

OsiXForm

Has pure virtual functions:

I virtual void record() = 0;

I virtual void modify() = 0;

15

Example

class ModifyConstraintBounds : public OsiXForm

I virtual void record() = 0;

I virtual void modify() = 0;

16

Algorithmic Differentiation – some motivation

Key Idea: The API of nonlinear solvers not really setup tomaximize the efficient use of AD.

A typical API will have methods such as:

I get an objective function value

I get constraint values

I get objective gradient

I get constraint Jacobian

I get Hessian of Lagrangian

An Issue: from an AD perspective, when, for example, calculatingfirst derivatives it would be nice to know if a second derivative isalso required.

17

Motivation

Here is another view of solver side

18

Algorithmic Differentiation – some motivation

The Problem: Many nonlinear algorithms, such as interior pointmethods do not calculate all orders of derivatives for the currentiterate.

For example, they may do a simple line search and not use anysecond derivative information.

In the API method calls for function evaluations they do notcommunicate if a higher order derivative is required for thecurrent iterate.

19

Algorithmic Differentiation – gradientcalculation

calculateAllConstraintFunctionGradients()

The method arguments are:

I double* x

I double* objLambda

I double* conLambda

I bool new x

I int highestOrder

20

Algorithmic Differentiation – Hessiancalculation

In our implementation, there are exactly two conditions thatrequire a new function or derivative evaluation. A new evaluationis required if and only if

1. The value of new x is true

–OR–

2. For the callback function the value of the input parameterhighestOrder is strictly greater than the current value ofm iHhighestOrderEvaluated.

In the code we keep track of the highest order derivativecalculation that has been made.

21