After creating the environment, a Concert application is ready to create one or more optimization models. Doing so consists of creating a set of modeling objects to define each optimization model.

Modeling objects, like IloEnv objects, are handles to implementation objects. Though you will be dealing only with the handle objects, it is the implementation objects that contain the data that specifies the optimization model. If you need to remove an implementation object from memory, you need to call the end method for one of its handle objects.

At this point, it is important to note that the environment is passed as a parameter to the constructor. There is also a constructor that does not use the environment parameter, but this constructor creates an empty handle, the handle corresponding to a NULL pointer. Empty handles cannot be used for anything but for assigning other handles to them. Unfortunately, it is a common mistake to try to use empty handles for other things.

Once an IloModel object has been constructed, it is populated with the extractables that define the optimization model. The most important classes here are:

You create objects of these classes for each variable, constraint, and objective function of your optimization problem. Then you add the objects to the model by calling

Modeling variables are constructed as objects of class IloNumVar, by defining variables of type IloNumVar. Concert Technology provides several constructors for doing this; the most flexible version, for example, is:

This definition creates the modeling variable x1 with lower bound 0.0, upper bound 40.0 and type ILOFLOAT, which indicates the variable is continuous. Other possible variable types include ILOINT for integer variables and ILOBOOL for Boolean variables.

For each variable in the optimization model a corresponding object of class IloNumVar must be created. Concert Technology provides a wealth of ways to help you construct all the IloNumVar objects.

Once all the modeling variables have been constructed, they can be used to build expressions, which in turn are used to define objects of class IloObjective and IloRange. For example,

Consider in more detail what this line does. The function IloMinimize takes the environment and an expression as arguments, and constructs a new IloObjective object from it that defines the objective function to minimize the expression. This new object is returned and assigned to the new handle obj.

After an objective extractable is created, it must be added to the model. As noted above this is done with the add method of IloModel. If this is all that the variable obj is needed for, it can be written more compactly, like this:

This way there is no need for the program variable obj and the program is shorter. If in contrast, the objective function is needed later, for example, to change it and reoptimize the model when doing scenario analysis, the variable obj must be created in order to refer to the objective function. (From the standpoint of algorithmic efficiency, the two approaches are comparable.)

Creating constraints and adding them to the model can be done just as easily with the following statement:

The part -x1 + x2 + x3 <= 20 creates an object of class IloRange that is immediately added to the model by passing it to the method IloModel::add. Again, if a reference to the IloRange object is needed later, an IloRange handle object must be stored for it. Concert Technology provides flexible array classes for storing data, such as these IloRange objects. As with variables, Concert Technology provides a variety of constructors that help create range constraints.

While those examples use expressions with modeling variables directly for modeling, it should be pointed out that such expressions are themselves represented by yet another Concert Technology class, IloExpr. Like most Concert Technology objects, IloExpr objects are handles. Consequently, the method end must be called when the object is no longer needed. The only exceptions are implicit expressions, where the user does not create an IloExpr object, such as when writing (for example) x1 + 2*x2. For such implicit expressions, the method end should not be called. The importance of the class IloExpr becomes clear when expressions can no longer be fully spelled out in the source code but need instead to be built up in a loop. Operators like += provide an efficient way to do this.