Conditional generation the | operator

Suppose we wish to apply an upper bound to some but not all members of a set of variables x_i. There are MAXI members of the set. The upper bound to be applied to x_i is U_i, but it is only to be applied if the entry in the data table TAB_i is greater than 20. If the bound did not depend on the value in TAB_i then the statement would read:

forall(i in 1..MAXI) x(i) <= U(i)

Requiring the condition leads us to write

forall(i in 1..MAXI | TAB(i) > 20 ) x(i) <= U(i) 

The symbol `|' can be read as `such that' or `subject to'.

Now suppose that we wish to model the following

In other words, we just want to include in a sum those x_i for which A_i is greater than 20. This is accomplished by

CC:= sum((i in 1..MAXI | A(i)>20 ) x(i) <= 15

Conditional variable creation and create

As we have already seen in the transport example (Section A transport example), with Mosel we can conditionally create variables. In this section we show a few more examples.

Suppose that we have a set of decision variables x(i) where we do not know the set of i for which x(i) exist until we have read data into an array WHICH.

model doesx
 public declarations
  IR = 1..15
  WHICH: set of integer
  x: dynamic array(IR) of mpvar
  Obj,C: linctr
 end-declarations

! Read data from file
 initializations from 'doesx.dat'
  WHICH
 end-initializations

! Create the x variables that exist
 forall(i in WHICH) create(x(i))

! Build a little model to show what esists
 Obj:= sum(i in IR) x(i)
 C:= sum(i in IR) i * x(i) >= 5

 exportprob("", Obj)                 ! Display the model
end-model

If the data in doesx.dat are

WHICH: [1 4 7 11 14]

the output from the model is

Minimize
 x(1) + x(4) + x(7) + x(11) + x(14)
Subject To
C: x(1) + 4 x(4) + 7 x(7) + 11 x(11) + 14 x(14) >= 5
Bounds
End

Note: exportprob("", Obj) is a nice idiom for seeing on-screen the problem that has been created. The public declaration of decision variables and constraints ensures that the display employs the entity names from the model, by default it will only show automatically generated names.

The key point is that x has been declared as a dynamic array, and then the variables that exist have been created explicitly with create. In the transport example in Section A transport example we have seen a different way of declaring dynamic arrays: the arrays are implicitly declared as dynamic arrays since the index sets are unknown at their declaration.

When we later take operations over the index set of x (for instance, summing), we only include those x that have been created.

Another way to do this, is

model doesx2
 public declarations
  WHICH: set of integer
  Obj,C: linctr
 end-declarations

 initializations from 'doesx.dat'
  WHICH
 end-initializations

 finalize(WHICH)

 public declarations
  x: array(WHICH) of mpvar        ! Here the array is _not_ dynamic
 end-declarations                 !  because the set has been finalized

 Obj:= sum(i in WHICH) x(i)
 C:= sum(i in WHICH) i * x(i) >= 5

 exportprob(0, "", Obj)
end-model

By default, an array is of fixed size if all of its indexing sets are of fixed size (i.e. they are either constant or have been finalized). Finalizing turns a dynamic set into a constant set consisting of the elements that are currently in the set. All subsequently declared arrays that are indexed by this set will be created as static (= fixed size). The second method has two advantages: it is more efficient, and it does not require us to think of the limits of the range IR a priori.

Note: The explicit call to finalize has become optional with Mosel 3.0 as the automatic finalization mechanism of Mosel performs this operation by default.