Solver Foundation Services (SFS) can automatically analyze models and determine which solver is most appropriate. If you are an advanced modeler, you can choose specific solvers and solver attributes. While solving the models, SFS manages all threading, many-core, synchronization, scheduling, and model execution issues. When finished, SFS produces reports about solver behavior and results, and provides additional information about solutions, including sensitivity. Finally, SFS allows LINQ data binding of model parameters and delivery of results in multiple formats.Lengning Liu has a blog entry on using the solver foundation from IronPython, including the magic incantations in app.config required to use plug in solvers.
Solver Foundation provides an easy-to-use and flexible plug-in infrastructure as an addition to its already rich set of solvers. Users can choose their favorite plugin solvers to solve the model, and yet leverage all features provided in Solver Foundation Services (SFS).
The information such as assembly name and solver class name can usually be found from the plug-in solver provider.
The config file then will co-exist with the compiled exe file of the user app. When, inside the app code, a Solve call is issued, SFS will pick a solver based on the model kind, directive instances passed in, and the solver registration.
The app code in this case can be written in any .NET compliant language such as C# or VB.NET.
IronPython is “an implementation of the Python programming language running under .NET …” So it is possible to use Solver Foundation, and with plug-in solvers, in IronPython code. However, one difficulty is that Python is an interpreted language. Therefore we cannot compile Python code to an exe file. So how do we register our plug-in solvers?
The trick is to register the plug-in solvers inside ipy.exe.config (or ipy64.exe.config). These two files must be put under the same folder with ipy.exe and ipy64.exe. We assume IronPython 2.6 RC2 in the following discussion.