Design choices for optimization applications
Susanne Heipcke
Xpress Team, FICO
http://www.fico.com/xpressContents12
34Modeling platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Xpress-Mosel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mosel: Selected new features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1
Distributed model execution . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2
IO callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3
XML interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Application examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1
Alternative interfaces: Portfolio rebalancing . . . . . . . . . . . . . . . . . .
5.2
Distributed Mosel: Client-server . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3
Visualization: Aircraft routing . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1
3
5
10
11
14
15
17
17
21
21
24

1 Modeling platforms
Notes

Model development cycle

Model
Problemconception

Computational
problem instanceInterpretation& analysis

Computational
solution instance

Human

Model solution

ComputerWhy use modeling software?
• Developing a working model is the difficult bit• Important to have software that helps– speed to market– verify correctness– maintenance & modification– algorithmic considerations– execution speed

Modeling platforms

c 2010 Fair Isaac Corporation. All rights reserved.

page 1

MoselBCL

Model building libraries

OPL

AIMMS

Modeling + Programming

GUI

AMPL

GAMS

mp−modelConcertModeling platforms

Modeling languages
Matrix generators

70s

80s

90s

2000s

Modeling language

Modeling library

Matrix based

Verify correctness

easy

quite easy

very hard

Maintenanceeasyharderdifficult

Data handling
Building algorithms
Model execution speed
Speed to market

high level

native/some intrinsic

native language

language dependent

easy

quite easy

possibly slower

fasterfastest

fast

slow

slowestXpress modeling interfaces• Mosel– formulate model and develop optimization methods using Mosel language / environment• BCL– build up model in your application codeusing object-oriented model builder library• Optimizer– read in matrix files– input entire matrix from program arrays
Mosel• A modeling and solving environment– integration of modeling and solving– programming facilities– open, modular architecture• Interfaces to external data sources (e.g. ODBC,
host application) provided• Language is concise, user friendly, high level• Best choice for rapid development and deployment

Modeling platforms

c 2010 Fair Isaac Corporation. All rights reserved.

page 2

Xpress-BCL• Model consists of BCL functions within application source code (C, C++, Java, C# or VB)• Develop with standard C/C++/Java/C#/VB tools• Provide your own data interfacing• Lower level, object oriented approach• Enjoy benefits of structured modeling withinyour application source code
Xpress-Optimizer• Model is set of arrays within application sourcecode (C, Java, C#, or VB)• May also input problems from a matrix file
• Develop with standard C/C#/Java/VB tools• Provide your own data interfacing• Very low level, no problem structure• Most efficient but lose easy model development and maintenance2 Application design
Notes
Application
designTargetaudience?

Project
design?

Algorithms?

Targetaudience?

OR specialists/
Research

Analysts/
Business experts

End users

Preference?

’Lightweight’GUI

Applicationarchitecture?

Applicationarchitecture?

Standalone

Userinteraction?

Application design

Model + GUI

Integrated
component

Data I/O,
interfaces?

c 2010 Fair Isaac Corporation. All rights reserved.

page 3Userinteraction?
staticdynamic

Restarts (change data)

Logging/progress display

Tuning (solver parameters,
stopping criteria)

Influence solution algorithms(user−defined cuts or heuristics,
bounds, reject solutions)

Configuration(select constraints)

Data I/O,
interfaces?
Model interfaces

Application interface

Development environment
File formats, databaseconnectivity

Embedding functionality(access to andinteraction with model)

GUI

Host languages

Project
design?

Independent phases

Overlapping phases

Possiblyseveralplatforms

All−in−one (single phase)

Singleflexible
platform

Singleplatform

Development/
maintenance?

Development/
maintenance?
Persons / teams involved
Inhouse vs. externalContinuity

Algorithms?

Solver choice

Solverinteraction

Standard formats
Related problem types
Paradigm switch
User extensions

Application design

Callbacks

Decomposition/
Parallelism
Programming facilities
Communication andcoordination mechanisms
Distributed computing

c 2010 Fair Isaac Corporation. All rights reserved.

page 4

3 Xpress-Mosel
Notes• A high-level modeling language combinedwith standard functionality of programming
languages– implementation of models and solution
algorithms in a single environment• Open, modular architecture– extensions to the language without any
need for modifications to the core system• Compiled language– platform-independent compiled models
for distribution to protect intellectual
property...and also
• Mosel modules– solvers:
mmxprs, mmquad, mmxslp,
mmnl, kalis– data handling: mmetc, mmodbc, mmoci– model handling, utilities: mmjobs, mmsystem– graphics: mmive, mmxad• IVE: visual development environment (Windows)• Library interfaces for embedding models into
applications (C, Java, C#, VB)• Tools: debugger, profiler, model conversion,
preprocessor
Example: Portfolio optimization Problem description• An investor wishes to invest a certain amountof money into a selection of shares.
• Constraints:
1. Invest at most 30% of the capital into any
share.
2. Invest at least half of the capital in NorthAmerican shares.
3. Invest at most a third in high-risk shares.
• Objective: obtain the highest expected returnon investment

Xpress-Mosel

c 2010 Fair Isaac Corporation. All rights reserved.

page 5

Example:
model

Portfolio optimization Mathematicalmaximize

X

RETs · fracss∈SHARES

X

fracs ≤ 1 / 3s∈RISKX

fracs ≥ 0. 5

s∈NA

X

fracs = 1s∈SHARES∀s ∈ SHARES : 0 ≤ fracs ≤ 0. 3
Example: Portfolio optimization Mosel model

Example: Portfolio optimization Logical Conditions
1. Binary variables

2. Semi-continuous variables

Xpress-Mosel

c 2010 Fair Isaac Corporation. All rights reserved.

page 6

Example: Portfolio optimization Extended problem• We wish to– run the model with different limits on the
portion of high-risk shares,– represent the results as a graph, plotting
the resulting total return against the deviation as a measure of risk.
• Algorithm: for every parameter value– re-define the constraint limiting the percentage of high-risk values,– solve the resulting problem,– if the problem is feasible: store the solution values.

Xpress-Mosel

c 2010 Fair Isaac Corporation. All rights reserved.

page 7

Data handling• Physical files:– text files (Mosel format, new: binary format, diskdata; free format, new: XML,– spreadsheets, databases (ODBC or specificdrivers)• In memory:– memory block/address– streams; pipes; callbacks (new: IO callback)

XAD application

Xpress-Mosel

c 2010 Fair Isaac Corporation. All rights reserved.

page 8

Advanced solving tasks• Infeasibility handling– definition of slack variables– IIS (irreducible infeasible sets)– infeasibility repair meachanism• Solution enumeration– obtain the N best solutions
Solution enumeration

Standard MIP search:

Solution enumerator:

Schemes of decomposition and concurrent solving
The "multis":
Mosel instance– multi-solver

Mosel model
uses ’mmxprs’
uses ’mmxslp’

The "multis":
Mosel instance– multi-solver– multi-problem

Mosel model

Problem

Xpress-Mosel

shareddata

Problemc 2010 Fair Isaac Corporation. All rights reserved.

page 9

The "multis":
Mosel instance
Master model– multi-solver– multi-problem– multi-model

Submodelstart

Problem

eventsProblem

The "multis":
Local instance– multi-solver– multi-problem– multi-model– multi-node

Master model

ProblemRemote instance
Submodelstart

eventsProblem• Simple parallel runs
– different data instances– different algorithm configurations• Decomposition– Benders– Dantzig-Wolffe• Column generation– loop over top node
– branch-and-price• Cut generation– (cut-and-branch, branch-and-cut)– adding constraints

4 Mosel: Selected new features
Notes

Mosel: Selected new featuresc 2010 Fair Isaac Corporation. All rights reserved.

page 10

4.1 Distributed model execution• mmjobs: facilities for model management,
synchronization of concurrent models basedon event queues, shared memory IO driver.
• New: extending capacities for handling multiple models to distributed computing using several Mosel instances (running locally or on remote nodes connected through a network)• Mosel instance management: connecting anddisconnecting Mosel instances, access to remote files, handling of host aliases (new type:
Mosel)• Remote connection IO drivers: two drivers(xsrv and rcmd) for creating remote Mosel instances.
• Remote file acces IO drivers: access to physical files or streams on remote Mosel instances (rmt), usable wherever Mosel expects a (generalized) filename, in particular ininitializations blocks.
• Remote machine must run a server– Default (as specified by value of control
conntmpl): Mosel server xprmsrv (started
as separate program, available for all
platforms supported by Xpress), connect
with driver xsrv
connect(mosInst, "ABCD123")! Same as:
connect(mosInst, "xsrv:ABCD123")– Alternative: other servers, connect withdriver rcmd, e.g. with rhs, (NB: Mosel
command line option -r is required forremote runs):connect(mosInst, "rcmd:rsh ABCD123 mosel -r")

• The Mosel server can be configured.
– Use this command to display the available
options:
xprmsrv -h

Configuration options include verbosity
settings, choice of the TCP port, and thedefinition of a log file.
– Alternatively, use a configuration file formore flexible configuration and to define
multiple environments
xprmsrv myconfig.conf

Mosel: Selected new featuresc 2010 Fair Isaac Corporation. All rights reserved.

page 11

Configuration file
• Contents of myconfig.conf:# Global setting of a log file
LOGFILE=/tmp/logfile.txt# Add a password to the default environment ’xpress’[xpress]
PASS=hardone# Define new environment using a different Xpress version[xptest]XPRESSDIR=/opt/xpressmp/testing
XPRESS=/opt/xpressmp/lic
MOSEL_CWD=$XPRESSDIR/workdir• Usage:r1:= connect(inst1, "xsrv:localhost/xpress/hardone")r2:= connect(inst2, "xrsv:mypcname/xptest")

Local instances• Remote machine may be identical with the current node (new instance started on the samemachine in a separate process)connect(mosInst, "")! Same as:
connect(mosInst, "rcmd:mosel -r")connect(mosInst, "localhost")! Same as:
connect(mosInst, "xsrv:localhost")

Executing a submodel
model "Run model rtparams"
uses "mmjobs"
declarations
modPar: Model
end-declarations! Compile the model file
if compile("rtparams.mos")<>0 then exit(1); end-if! Load the bim fileload(modPar, "rtparams.bim")! Start model execution + parameter settingsrun(modPar, "PARAM1=" + 3.4 + ",PARAM3=’a string’" + ",PARAM4=" + true)
wait! Wait for model termination
dropnextevent! Ignore termination event message
end-model

Executing a submodel remotelymodel "Run model rtparams remotely"uses "mmjobs"
declarations
modPar: Model
mosInst: Mosel
end-declarations! Compile the model file
if compile("rtparams.mos")<>0 then exit(1); end-if
NODENAME:= ""! "" for current node, or name, or IP address! Open connection to a remote node
if connect(mosInst, NODENAME)<>0 then exit(2); end-if! Load the bim fileload(mosInst, modPar, "rmt:rtparams.bim")! Start model execution + parameter settingsrun(modPar, "PARAM1=" + 3.4 + ",PARAM3=’a string’" + ",PARAM4=" + true)
wait! Wait for model termination
dropnextevent! Ignore termination event message
end-model

Mosel: Selected new featuresc 2010 Fair Isaac Corporation. All rights reserved.

page 12

model "Compile and run model rtparams remotely"uses "mmjobs"
declarations
modPar: Model
mosInst: Mosel
end-declarations
NODENAME:= ""! "" for current node, or name, or IP address! Open connection to a remote node
if connect(mosInst, NODENAME)<>0 then exit(2); end-if! Compile the model file remotely
if compile(mosInst, "", "rmt:rtparams.mos", "rtparams.bim")<>0 thenexit(1); end-if! Load the bim fileload(mosInst, modPar, "rtparams.bim")! Start model execution + parameter settingsrun(modPar, "PARAM1=" + 3.4 + ",PARAM3=’a string’" + ",PARAM4=" + true)
wait! Wait for model termination
dropnextevent! Ignore termination event message
end-model

New and overloaded subroutines• Instance connection/disconnection
r:= connect(myInst, "")disconnect(myInst)• Remote compilation & loading
r:= compile(myInst, "", "filename.mos", "filename.bim")load(myInst, myModel, "filename.bim")• Redirecting Mosel streams
setdefstream(myInst, F_OUTPUT, "rmt:instoutput.txt")

Some utilities• System information
compName:= getsysinfo(SYS_NODE);
currNode:= getparam("NODENUMBER");modelID:= getparam("JOBID");

allinfo:=getsysinfo(myInst)parent:= getparam("PARENTNUMBER")
instID:= getid(myInst)• Instance status information
if getstatus(myInst)<>0 thenwriteln("Instance is not connected")
end-if• Aliases
sethostalias("localhost2","localhost")
r:= connect(myInst, "localhost2")
sysName:= gethostalias("localhost2");
clearaliases

getaliases(allAliases)

Distributed model execution• Documentation: ’Mosel Language Reference
manual’, Chapter 7 mmjobs• Examples: see newest version of the whitepaper ’Multiple models and parallel solving with
Mosel’, Section 2.8 Working with remote Mosel instances• Another introductory example in ’Guide for
evaluators 2’, Section 6 Working in a distributed architecture

Mosel: Selected new featuresc 2010 Fair Isaac Corporation. All rights reserved.

page 13

4.2 IO callbacks• In-memory communication so far: fixed data
structure sizes• New: alternative communication mechanism
working with flows enables dynamic sizing ofdata structures on the application level– particularly useful for solution output
where effective data sizes are not knowna priori– available in C, Java, .NET
• Pass the address of the function (C) or class(Java) implementing the callback to Mosel via
model parameters• initializations to: use the Mosel postprocessing library functions to retrieve datafrom Mosel into the application• initializations from: new set of functions to send data to Mosel, using the sameformat as the default text file format
IO callbacks (C)mydata: [ ("ind1" 3) [5 1.2] ("ind2" 7) [4 6.5] ]XPRMcb_sendctrl(cb, XPRM_CBC_OPENLST, 0);
XPRMcb_sendctrl(cb, XPRM_CBC_OPENNDX, 0);
XPRMcb_sendstring(cb, "ind1", 0);
XPRMcb_sendint(cb, 3, 0);
XPRMcb_sendctrl(cb, XPRM_CBC_CLOSENDX, 0);
XPRMcb_sendctrl(cb, XPRM_CBC_OPENLST, 0);
XPRMcb_sendint(cb, 5, 0);
XPRMcb_sendreal(cb, 1.2, 0);
XPRMcb_sendctrl(cb, XPRM_CBC_CLOSELST, 0);
XPRMcb_sendctrl(cb, XPRM_CBC_OPENNDX, 0);
XPRMcb_sendstring(cb, "ind2", 0);
XPRMcb_sendint(cb, 7, 0);
XPRMcb_sendctrl(cb, XPRM_CBC_CLOSENDX, 0);
XPRMcb_sendctrl(cb, XPRM_CBC_OPENLST, 0);
XPRMcb_sendint(cb, 4, 0);
XPRMcb_sendreal(cb, 6.5, 0);
XPRMcb_sendctrl(cb, XPRM_CBC_CLOSELST, 0);
XPRMcb_sendctrl(cb, XPRM_CBC_CLOSELST, 0);

! [
!
(
!
"ind1"
!
3
!
)
!
[
!
5
!
1.2
!
]
!
(
!
"ind2"
!
7
!
)
!
[
!
4
!
6.5
!
]
! ]

IO callbacks (Java)mydata: [ ("ind1" 3) [5 1.2] ("ind2" 7) [4 6.5] ]ictx.sendControl(ictx.CONTROL_OPENLST);
ictx.sendControl(ictx.CONTROL_OPENNDX);
ictx.send("ind1");
ictx.send(3);ictx.sendControl(ictx.CONTROL_CLOSENDX);
ictx.sendControl(ictx.CONTROL_OPENLST);
ictx.send(5);ictx.send(1.2);
ictx.sendControl(ictx.CONTROL_CLOSELST);
ictx.sendControl(ictx.CONTROL_OPENNDX);
ictx.send("ind2");
ictx.send(7);ictx.sendControl(ictx.CONTROL_CLOSENDX);
ictx.sendControl(ictx.CONTROL_OPENLST);
ictx.send(4);ictx.send(6.5);
ictx.sendControl(ictx.CONTROL_CLOSELST);
ictx.sendControl(ictx.CONTROL_CLOSELST);

Mosel: Selected new features

! [
!
(
!
"ind1"
!
3
!
)
!
[
!
5
!
1.2
!
]
!
(
!
"ind2"
!
7
!
)
!
[
!
4
!
6.5
!
]
! ]

c 2010 Fair Isaac Corporation. All rights reserved.

page 14

IO callbacks• Documentation: ’Mosel Library Reference
manual’, Section 1.5.2.2 cb driver – Handlingof initializations blocks• Examples: see newest version of the ’Mosel
User Guide’, Sections 13.4.3 Dynamic data (C),14.1.6.3 Dynamic data (Java)

4.3 XML interface• The module smew provides an XML interface
for the Mosel language.
• smew relies on two external libraries without
which the module will not work:– scew (’simple C expat wrapper’) — handling of the XML tree
– expat — the parser
Structure of an XML document<?xml ... ?>Preamble<root><parent><element attrname="attrvalue">
contents<child><leaf>leafcontents</leaf></child><child>2nd child contents</child></element><emptyelement attrname="attrvalue" /></parent></root>smew functionality• New types:– xmldoc represents an XML document– xmleltref is a reference to anode/element in the document.
Several xmleltref may reference thesame element and the module does
not check consistency: if an element isremoved, it is up to the user to makesure none of its references will be used
afterwards

Mosel: Selected new featuresc 2010 Fair Isaac Corporation. All rights reserved.

page 15• Subroutines:– File access: load, save
– Document
structure:
getroot,
setroot, isvalid, getpreamble,
setpreamble, getchildren,
getparent, add, remove– Handlingelements:
getname,setname, getcontent,
get[int|real|bool|str]content,
setcontent, getattr,
get[int|real|bool|str]attr,
setattr, delattr, getallattr
Example: Portfolio optimization XML data format
declarations
SHARES: set of string
RISK: set of string
NA: set of string
RET: array(SHARES) of real
AllData: xmldoc
ShareList: list of xmleltref
end-declarations! Set of shares! Set of high-risk values among shares! Set of shares issued in N.-America! Estimated return in investment! XML document! List of XML elements! Reading data from an XML fileload(AllData, "folio.xml")
getchildren(getroot(AllData), ShareList, "share")
RISK:= union(l in ShareList | getattr(l,"risk")="high"){getstrattr(l,"name")}
NA:= union(l in ShareList | getattr(l,"region")="NA"){getstrattr(l,"name")}forall(l in ShareList) RET(getstrattr(l,"name")):= getintattr(l, "ret")• Data file folio.xml:<portfolio><share name="treasury" ret="5" dev="0.1" country="Canada"region="NA" risk="low" /><share name="hardware" ret="17" dev="19" country="USA"region="NA" risk="high" />...
<share name="electronics" ret="21" dev="16" country="Japan"
region="Asia" risk="high" /></portfolio>

declarations
SHARES: set of string
frac: array(SHARES) of mpvar
AllData: xmldoc
Share,Root,Sol: xmleltref
end-declarations! Set of shares! Fraction of capital used per share! XML document! XML elements! Create solution representation in XML format
Root:= setroot(AllData, "result")
Sol:= add(Root, "solution")
forall(s in SHARES) do
Share:= add(Sol, "share")setattr(Share, "name", s)
Share.content:= frac(s).sol
end-dosave(AllData, "result.xml")
save(AllData, "")Mosel: Selected new features! Save solution to XML format file
! Display XML format solution on screen

c 2010 Fair Isaac Corporation. All rights reserved.

page 16• Generated output file result.xml:<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?><result><solution><share name="treasury">0.3</share><share name="hardware">0</share>...
<share name="electronics">0</share></solution></result>

smew distribution• Available for download from the Mosel open
source webpage• Archive contains– module source file: smew.c– module library file: smew.dso (copy into
subdirectory dso)
– library files: *expat.* and *scew.*(copy into subdirectory bin [Windows] orlib [Unix])– documentation: smew.txt– examples:
folioxml.mos,
folioxmlqp.mos,booksearch.mos,
xmltest.mos

5 Application examples
Notes

5.1 Alternative interfaces: Portfolio rebalancing
Portfolio rebalancing: Problem description• Modify the composition of an investment portfolio as to achieve or approach a specified investment profile.
Application architecture• Single, configurable model file
• Different interfaces for model execution– stand-alone mode (command line or
through Xpress-IVE) for development– graphical interface (written with XAD) for
single model runs and simulation– Java application for running batches ofmodel instances

Application examples

c 2010 Fair Isaac Corporation. All rights reserved.

page 17

Optimization application in Mosel
Standalone

IVE
start application
return results

Mosel model

Data files

Output files

Optimization application in Mosel
XAD GUI
Configu−
ration file

XAD

Summary
outputstart application
return results

Mosel model

Data files

Output files

Optimization application in Mosel
Embedded into host application

Java

Data files
Summary
outputstart application
return results

Mosel model

Output files

Optimization application in Mosel
Alternative interfaces
Configu−
ration file

XAD

IVE

Summary
outputstart application
return results

Data files

Mosel modelJava

Data files

Summary
outputOutput files

Application examples

c 2010 Fair Isaac Corporation. All rights reserved.

page 18

Input• Stand-alone and XAD: data input from text
files directly into Mosel– uses a filter module to accomodate different number formats• Java: data read and stored by host application;communication with model instances throughmemoryOutput• Textual output log on screen or to file
• Optionally detailed HTML output• Java: summary statistics of multiple runs
• XAD:– summary statistics in the case of multiple
runs– optional output to Excel
XAD interface• Graphical user interface (Windows)• Configuration of model runs
– data files– parameter settings– selection of constraints• Choice of solving mode:– repeated runs for a single model (simulation)– solve all instances from customer file(evaluation of parameter settings)• Graphical comparison of results
XAD interface: Detailed results

Application examples

c 2010 Fair Isaac Corporation. All rights reserved.

page 19

XAD interface: Parameter and version log

XAD interface: Multiple run summary

Some highlights• Model:– easy maintenance through single model– deployment as BIM file: no changes tomodel by end-user– language extensions according to specificneeds• Interfaces:– several run modes adapted to different
types of usages– efficient data exchange with host application through memory– parallel model runs (Java) or repeated sequential runs (XAD)

Application examples

c 2010 Fair Isaac Corporation. All rights reserved.

page 20

5.2 Distributed Mosel: Client-server
Distributed Mosel: Problem description• Multi-user optimization application processing a large number of optimization model instances• Idea: replace the preselected, static assignment of optimization runs by a Mosel serverthat controls the job queues
Distributed Mosel: Client-server architecture

User

Production
machineMosel server

...

...

Database

User

Production
machineDistributed Mosel: Highlights• Use Mosel lists for representation of dynamic
queueing system• Mosel master (’server’) model communicateswith database and handles remote submodels

5.3 Visualization: Aircraft routing
Aircraft routing: Problem description• For given sets of flights and aircraft, determine
which aircraft services a flight.
• Aircraft are not identical– they cannot all service every flight– a specific maintenance site must be used
per plane– some scheduled long maintenance breaks• Starting condition: each aircraft has a starting
position and a specific amount of accumulated
flight minutes

Application examples

c 2010 Fair Isaac Corporation. All rights reserved.

page 21

Aircraft routing: Representation• Temporal (activity on node) network:– a flight corresponds to a node
– ’cost’ of node: flight minutes ( 6= elapsedtime)– successor nodes: flights starting from a
destination within a given time window
after arrival of predecessor– maintenance: represented by a node
– aircraft: commodity traveling through the
network

Aircraft routing: Decomposition• Different views are possible:– per time unit (e.g., day)– per commodity (aircraft)• Idea: generate set of feasible routes per
aircraft by solving optimization subproblems
maximizing the flight minutes up to eachmaintenance stop
– iteratively force usage of ’less preferred’
flights– may keep suboptimal solutions
Aircraft routing: Application architecture• Master problem: route selection• Subproblems: route generation (one instanceper plane)– parallel, possibly remote, execution of
submodels• User interface (optional): XAD GUI

Application examples

c 2010 Fair Isaac Corporation. All rights reserved.

page 22

Aircraft routing: Application GUI

Aircraft routing: Visualization• Visualization of input data helps with understanding and analysis of the problem• Representation of intermediate results during
development (IVE) or as progress report tousers (XAD)

Aircraft routing: User interaction• Manual construction of routes• Editing generated plans

Application examples

c 2010 Fair Isaac Corporation. All rights reserved.

page 23

Summary
Notes• Have seen:– design choices for optimization applications• Xpress-Mosel:– recent developments make possible implementation of complex algorithms anda high degree of user interaction– unique features for handling large-scale
problems:
support of decomposition, concurrent
solving, distributed computing, and also
64bit coefficient indexing
Where to get more information• Xpress website:– http://www.fico.com/xpress• Xpress resources (documentation, whitepapers)– http://optimization.fico.com• Searchable on-line examples database:– http://examples.xpress.fico.com• Trial download:– http://decisions.fico.com/downloadTrial.html

Summaryc 2010 Fair Isaac Corporation. All rights reserved.

page 24