optimizationcplexoplilog

Difference between OPL Interfaces and Concert Technology in IBM ILOG CMPLEX Optimization Studio


I am new to IBM's CMPLEX Optimization Studio and I try to understand what is the best approach to take for realizing my goal. I am trying to implement a decision optimization solution, expressed as a Mix Integer Linear Program by creating a relevant representation for my problem and then interface it with the CMPLEX solver.

Initially, I started developing the model in the OPL language. However, as I intend to be dynamically calling the solver with the same model but with different data, from my C++ application, I realized that it makes more sense to build the model and call the solver through the CMPLEX C++ API, part of the Concert Technology (#reff1, #reff2). Of course, the interfaces the Concert Technology exposes for building your model are much more low level, in terms of how easy it is to express it, compared to building your model in OPL and running it directly. Then, I learn about the "OPL Interfaces" which also exposes a C++ API from which if understand it correctly, you can load your model from an OLP definition and use custom data sources, and invoke the solver.

So my question is how the OPL Interfaces and CMPLEX APIs (Concert Technology) for a specific language compare if both can be used for the same purpose, to build and execute the optimization model? I understand that the OPL Interfaces and the C++ API of OPL are based on the C++ Concert Technology. If the goal is to quickly test the model but with custom data input dynamically given by my C++ application, should I go for the OPL INterfaces, or there a reason why going for the CMPLEX C++ API in Concert Technology is better?

Software Version: IBM ILOG CMPLEX Optimization Studio 20.1.0


Solution

  • In contrast to Alex's answer (we both know each other well!), I would definitely recommend using the Concert library API calls directly from C++. I have used OPL on a number of projects over the last 20 years, and I have used the Concert API calls from C++, Java and C# on many projects too. For me at least, I find the finer-grained integration of my modelling variables and constraints directly into my C++ (or C# or Java) code to be a huge advantage.

    If you are coming from a background used to modelling languages (AMPL, GAMS, MPL etc) then it may seem more complex or difficult when you first start to use the Concert API. However if you are coming from a standard coding background using C++, C# or Java then treating CPLEX as just a set of library objects and functions may seem more natural than having to learn another specialist programming language.

    We have found that working entirely with the Concert APIs from C++ (or C# or Java) changes your perception of working with CPLEX. Software developers that we have worked with seem to be happier, because then CPLEX is just another piece of software that we can use like any other. We can have the CPLEX IloNumVars etc as member variables in our normal C++ classes, put them in dictionaries, lists or arrays; generally treat them just as normal C++ objects. This makes it easy to integrate your CPLEX modelling variables and constraints into your software.

    If you want to use OPL then it definitely encourages (enforces?) a separation between your standard (C++) code and the mathematical model internals. You may find that to be an advantage (keeping the model separately in a different language) or not. Even using OPL, if your data structures (in the data, database or C++) change you will probably have to update the OPL structures and code as well, so we found that often leaves you with an extra set of things to keep updated or synchronised.

    There really is no 'correct' choice - it really depends on your (and your team's) preferences. Whether you use OPL or the Concert APIs, these are just ways to get your model into CPLEX. There should be no difference in solving performance