Share via


Developing with Solver Foundation Services (SFS)

You can access the Microsoft Solver Foundation by using the Solver Foundation Services (SFS) level or by using the solver-specific APIs. We recommend the SFS level for modeling, data binding for parameters and decisions by using LINQ, educational use, automatic selection of a suitable solver, and construction of models that may require more than one solver. Using the Solver Foundation Services can make models more maintainable, and you can use third-party solvers without changing your code. The SFS provides a clean API for defining optimization models. You can build and improve your model without worrying about the details of solver capabilities.

Choosing a .NET Framework Version

When you use a Solver Foundation project template, the target .NET Framework must be .NET Framework 4. There is no support for .NET Framework 4 Client Profile in Microsoft Solver Foundation 3.0.

Default and Third-Party Solvers

Microsoft Solver Foundation includes built-in solvers and the ability to add solvers provided by third-parties. Gurobi Optimization supplies a Mixed Integer Programming (MIP) solver, which is included as the default MIP solver in the Solver Foundation Services (SFS) layer of Microsoft Solver Foundation. For more information, see the Gurobi Solver Programming Primer in the Program Files\Microsoft Solver Foundation\3.0.1.nnnn\Documents folder.

The following table shows the complete list of third-party solvers that can be used in Microsoft Solver Foundation.

Solver

Website

CPLEX

IBM ILOG CPLEX Optimizer

FICO Xpress

FICO Xpress Examples Repository

Gurobi

Gurobi Optimizer 3.0

LINDO

LINDO Systems - Optimization Software: Integer Programming, Linear Programming, Nonlinear Programming, Global Optimization

lp_solve

lpsolve

Mosek

The MOSEK Optimization Software

Ziena

Knitro

Frontline Systems

Frontline Systems solver

Additionally, you can create your own solvers and integrate it into Microsoft Solver Foundation by implementing interfaces such as ILinearModel, ITermModel or INonlinearModel. For more information, see the MSF MILP Solver Plugin SDK document in the \Installation Folder\Microsoft Solver Foundation\3.0.1.nnnn\Documents folder.

Changing the Default Solver

To register a solver or change the default solver, add a file called app.config to the Visual Studio solution. A solver can be registered more than once, as long as the capability of the solver is different.

More than one solver can be registered for the same capability. If the Solve method is not passed any directive instance, the first registered solver for the requested capability is used. If there are no registered solvers for the requested capability, the default Solver Foundation solver is used. If the Solve method is passed a directive instance, that particular solver is invoked if the solver is registered with that capability.

The following table lists the elements of the configuration file.

Element

Attribute

Description

MsfConfig

none

Defines the configuration for Microsoft Solver Foundation.

MsfPluginSolvers

none

Groups all the solvers. All solvers must have a unique combination of solver name and capability.

MsfPluginSolver

name

Optional. The description of the solver.

capability

Required. Describes the capability of the solver.

  • LP: linear programming.

  • MILP: mixed integer linear programming.

  • QP: quadratic programming.

  • MIQP: mixed integer quadratic programming.

  • CP: constraint programming.

  • NLP: non-linear programming

  • MINLP: mixed integer non-linear programming

interface

Optional. The name of the interface to use for the solver and model type, typically used for a non-linear solver. Valid interfaces include ITermSolver and INonlinearSolver. If no interface is specified, ILinearSolver is the default interface.

assembly

Required. The fully qualified name of the solver.

solverclass

Required. The name of the solver class that implements the ILinearSolver, ILinearModel, ISolver, ITermModel, INonlinearModel, ITermSolver, or the INonlinearSolver interface.

directiveclass

Optional. The name of the directive class for the solver. If missing, the solver is assumed to only support the Directive class instance.

parameterclass

Required. The name of the solver-specific parameter class that implements the ISolverParameters class.

The following XML shows the contents of an app.config file for a Microsoft Solver Foundation project.

<?xml version="1.0" encoding="utf-8" ?>
  <configSections>
    <section 
      name="MsfConfig"  
      type=
        "Microsoft.SolverFoundation.Services.MsfConfigSection, 
        Microsoft.Solver.Foundation, 
        Version=3.0.1.xxxx, 
        Culture=neutral, 
        PublicKeyToken=xxxxxxxxxx"
      allowLocation="true" 
      allowDefinition="Everywhere" 
      allowExeDefinition="MachineToApplication" 
      restartOnExternalChanges="true" 
      requirePermission="true" />
  </configSections>

  <MsfConfig>
    <MsfPluginSolvers>
      <MsfPluginSolver name="solver1"
        capability="MILP"
        assembly="SampleMilpAssembly"
        solverclass="SampleMilpSolvers.Solver1"
        directiveclass="SampleMilpSolvers.Solver1Directive"
        parameterclass="SampleMilpSolvers.Solver1Parameter" />
      <MsfPluginSolver name="solver2"
        capability="MILP"
        assembly="SampleMilpAssembly"
        solverclass="SampleMilpSolvers.Solver2"
        parameterclass="SampleMilpSolvers.Solver2Parameter" />
      <MsfPluginSolver 
        capability="LP"
        assembly="SampleMilpAssembly"
        solverclass="SampleMilpSolvers.Solver2"
        parameterclass="SampleMilpSolvers.Solver2Parameter" />
      <MsfPluginSolver name=”solver4”
        capability="NLP"
        interface="INonlinearSolver"
        assembly="Solver4PlugIn.dll" 
        solverclass="SolverFoundation.Plugin.Solver4.Solver4Solver"
        directiveclass="SolverFoundation.Plugin.Solver4.Solver4Directive"
        parameterclass="SolverFoundation.Plugin.Solver4.Solver4Parameter" />
</MsfPluginSolvers>
  </MsfConfig>
</configuration>

Solver Selection Process

SFS uses the following process to select a solver:

  1. Analyzes the current model.

  2. Determines the model that matches the current model.

    The model type can be LP, MILP, QP, MIQP, CP, NLP, or MINLP. The most specific matching model is selected. For example, if both QP and NLP match, QP is selected because it is a more specific type.

  3. Examines the configuration file for all solvers.

  4. Selects the first solver in the configuration file that matches the model type.

  5. Determines which interface is supported by the selected solver.

  6. If a solver implements ITermSolver or INonlinearSolver, which are typically implemented for NLP solvers, SFS determines whether the solver can support additional capabilities required by the model. If the solver cannot support the additional capabilities, it tests the next solver in the configuration file.

  7. If a match is found, SFS sends the model to the solver. If SFS cannot find a match, an error occurs.

Solvers are prioritized for consideration based on the order in which they appear in the configuration file.

Additional considerations for solver selection include the following:

  • Directives override the solver selection logic and instruct SFS to use a specific solver. You can use a directive to force the selection of a lower priority solver or a Solver Foundation solver over a higher priority solver that is registered in the configuration file. For example, by using a directive you can specify the Solver Foundation CP solver instead of a registered third-party solver.

  • If a solver implements more than one interface for a model type, you must create multiple MsfPluginSolver entries in the configuration file. You can specify only one interface for each solver.

    Tip

    If a solver implements multiple interfaces, test whether the solver works using ILinearModel as the interface. If this interface works, use ILinearModel.

  • A third-party solver that implements ITermModel and supports the CP model type can be registered. Registration of CP model types in the configuration file was not supported prior to Microsoft Solver Foundation 3.0.

The Solver Foundation solvers do not use a configuration file. They use an internal configuration, similar to the configuration file above, to match a model to a solver. If no configuration file is present, SFS uses the internal configuration. If a configuration file is present and no matching solver is found, SFS tries to match the model by using this internal configuration. Conceptually, this works as if the configuration file is appended with the internal configuration.

The following table shows the prioritization of the solvers in the internal configuration. If no directive is provided, or if a generic directive is provided, the first installed solver for the matching model type is used. If a directive is provided, the first installed solver that takes the specified directive for that model type is used.

Model type

Solver

Directive

LP

Simplex

SimplexDirective

Gurobi

Gurobi directive, MixedIntegerProgrammingDirective

Simplex

MixedIntegerProgrammingDirective

Interior point method

InteriorPointMethodDirective

MILP

Gurobi

Gurobi directive, MixedIntegerProgrammingDirective

Simplex

SimplexDirective, MixedIntegerProgrammingDirective

QP

Interior point method

InteriorPointMethodDirective

Gurobi

Gurobi directive

MIQP

Gurobi

Gurobi directive

CP

Constraint satisfaction programming

ConstraintProgrammingDirective

NLP

Hybrid local search

LocalSearchDirective

Compact quasi-Newton

CompactQuasiNewtonDirective

MINLP

Hybrid local search

LocalSearchDirective

Non-Linear Programming and the Hybrid Local Search Solver

For information on using non-linear programming and the hybrid local search solver, see Solving Nonlinear Models using the Default Solver.

Events in Solver Foundation Services

You can use data binding and solving events to track progress. Any event handlers that you write must be thread-safe because the SFS may call an event from multiple threads. We recommend that you implement any necessary locking.

Data Binding Events

You can use the DataBindingEventArgs object to find solver information during data binding. For more information, see How to: Respond to the Solver Data Binding Event.

Solving Events

The SolvingEventArgs object can be used to screen for a specific type of event, such as an improved incumbent solution. Make sure that more events are not fired after the CancelAll method is called on an event object. For more information, see How to: Respond to the Solving Event from a Solver.

If you are creating a third-party solver plug-in, you must implement the ISolverEvents interface, which defines the Solving property. To retrieve the values of the Solving property, implement the ISolverProperties interface or override these methods by inheriting from the LinearModel object. If the third-party solver plug-in does not support get or set accessors on a property, we recommend that you throw the NotSupportedException exception.

Improved Reporting

You can use Solver Foundation to programmatically access report information. For more information, see How to: Create a Solver Report. In addition, you can add custom properties on third-party solvers and include the values of those properties in results. For more information, see How to: Create a Custom Solver Report using the SFS APIs.

If you are creating a third-party solver plug-in, you can subclass the LinearReport class and then implement the IReportProvider interface, which defines the GetReport method. Then, the plug-in could create an instance of the specific solver report and return that instance.

See Also

Concepts

Developing Models using Solver Foundation

Microsoft Solver Foundation 3.1