A first model
Consider the following problem: we wish to schedule four meetings A, B, C, and D in three time slots (numbered 1 to 3). Some meetings are attended by the same persons, meaning that they may not take place at the same time: meeting A cannot be held at the same time as B or D, and meeting B cannot take the same time slot as C or D.
More formally, we may write down this problem as follows, where planm (m ∈ MEETINGS={A, B, C, D}) denotes the time slot for meeting m—these are the decision variables of our problem.
planA ≠ planB
planA ≠ planD
planB ≠ planC
planB ≠ planD
Implementation with Mosel
The following code listing implements and solves the problem described above.
model "Meeting" uses "kalis" declarations MEETINGS = {'A','B','C','D'} ! Set of meetings TIME = 1..3 ! Set of time slots plan: array(MEETINGS) of cpvar ! Time slot per meeting end-declarations forall(m in MEETINGS) setdomain(plan(m), TIME) ! Respect incompatibilities plan('A') <> plan('B') plan('A') <> plan('D') plan('B') <> plan('C') plan('B') <> plan('D') ! Solve the problem if not(cp_find_next_sol) then writeln("Problem is infeasible") exit(1) end-if ! Solution printing forall(m in MEETINGS) writeln("Meeting ", m, ": ", getsol(plan(m))) end-model
This Mosel model is saved as a text file with the name meeting.mos. Let us now take a closer look at what we have just written.
General structure
Every Mosel program starts with the keyword model, followed by a model name chosen by the user. The Mosel program is terminated with the keyword end-model.
As Mosel is itself not a solver, we specify that the Kalis constraint solver is to be used with the statement
uses "kalis"
at the begin of the model.
All objects must be declared in a declarations section, unless they are defined unambiguously through an assignment. For example, i:= 1 defines i as an integer and assigns to it the value 1. There may be several such declarations sections at different places in a model.
In the present case, we define two sets, and one array:
- MEETINGS is a set of strings.
- TIME is a so-called range set—i.e., a set of consecutive integers (here: from 1 to 3).
- plan is an array of decision variables of type cpvar (finite domain CP variables; a second decision variable type of Xpress Kalis is cpfloatvar for continuous variables), indexed by the set MEETINGS.
The model then defines the domains of the variables using the Xpress Kalis procedure setdomain. The decision variables are indeed created at their declaration with a large default domain and setdomain reduces these domains to the intersection of the default domain with the indicated values. As in the mathematical model, we use a forall loop to enumerate all the indices in the set MEETINGS.
This is followed by the statement of the constraints, in this model we have four disequality constraints.
Solving and solution output
With the function cp_find_next_sol, we call Kalis to solve the problem (find a feasible assignment of values to all decision variables). We test the return value of this function: if no solution is found it returns false and we stop the model execution at this point (by calling the Mosel procedure exit), otherwise we print out the solution.
To solve the problem Xpress Kalis uses its built-in default search strategies. We shall see later how to modify these strategies.
The solution for a CP variable is obtained with the function getsol. To write several items on a single line use write instead of writeln for printing the output.
Formatting
Indentation, spaces, and empty lines in our model have been added to increase readability. They are skipped by Mosel.
Line breaks: It is possible to place several statements on a single line, separating them by semicolons, as such:
plan('A') <> plan('B'); plan('A') <> plan('D')
But since there are no special `line end' or continuation characters, every line of a statement that continues over several lines must end with an operator (+, >=, etc.) or characters like `,' that make it obvious that the statement is not terminated.
As shown in the example, single line comments in Mosel are preceded by !. Multiple line comments start with (! and terminate with !).
Running the model
You may choose among three different methods for running your Mosel models:
- From the Mosel command line: this method can be used on all platforms for which Mosel is available. It is especially useful if you wish to execute a (batch) sequence of model runs—for instance, with different parameter settings. The full Mosel functionality, including its debugger, is accessible in this run mode.
- Within the graphical environment Xpress Workbench: available to Windows users. Workbench is a complete modeling and optimization development environment with a built-in text editor for working with Mosel models and a number of displays that help analyze models and solution algorithms in the development phase. Models can be modified and re-run interactively.
- From within an application program: Mosel models may be executed and accessed from application programs (C/C++, Java, VBA, C#). This functionality is typically used for the deployment of Mosel models, integrating them into a company's information system.
In this manual we shall use the first two methods for running the models we develop. For further detail on embedding models into application programs the user is referred to the Mosel user guide.
Working from the Mosel command line
When you have entered the complete model into the file meeting.mos, we can proceed to the solution to our problem. We start Mosel at the command prompt by typing the following command
mosel execute meeting.mos
and we will see output something like that below.
Meeting A: 1 Meeting B: 2 Meeting C: 1 Meeting D: 3 |
The Mosel command for executing the model can be abbreviated to
mosel exec meeting
or simply
mosel meeting
The model execution performed by the command execute comprises three stages:
- Compiling meeting.mos
- Loading the compiled model
- Running the model we have just loaded.
Instead of using execute, you may choose to explicitly generate the compiled model file chess.bim
mosel compile meeting.mos
followed by
mosel run meeting.bim
to load and run the compiled model.
Using Xpress Workbench
To execute the model file meeting.mos with Workbench you need to carry out the following steps.
- Start up Workbench: if you have followed the standard installation procedure for Xpress Workbench, start the program by double clicking the icon on the desktop or selecting Start » Programs » Xpress » Xpress Workbench. Otherwise, you may also start up Workbench by double clicking a model file (file with extension .mos).
- Open the model file by choosing File » Open. The model source is then displayed in the central window (the Workbench Editor).
- Click the green Run button
or, alternatively, choose menu entry Run for the desired model.

Figure 2.1: Workbench workspace after opening a model
The Build pane at the bottom of the workspace displays the model execution status messages from Mosel and any outpu generated by it. If syntax errors are found in the model they are displayed here, with details of the line and character position where the error was detected and a description of the problem, if available.
Workbench makes all information about the model available for inspection through the Debugger pane in the right hand window if the model is run in debug mode (green bug icon).

Figure 2.2: Workbench workspace after model execution in debug mode
Debugging a model
A first step for debugging a model certainly is to add additional output. In our model, we could, for instance, print out the definition of the decision variables by adding the line
writeln(plan)
after the definition of the variables' domains, or even print out the complete problem definition with the procedure cp_show_prob. To obtain a more easily readable output for debugging the user may give names to the decision variables of his problem. For example:
forall(m in MEETINGS) setname(plan(m), "Meeting "+m)
Notice that we have used the '+' sign to concatenate strings.
Calling the procedure cp_show_stats will display summary statistics of the CP solving.
To obtain detailed information about run-time errors with the command line version models need to be compiled with the flag -g, for example,
mosel exec -g meeting
For using the Mosel debugger (please see the Mosel language reference manual for further detail) the compilation flag -G needs to be used instead.
Workbench by default compiles models in standard mode, debug+trace information (option -G) is automatically enabled when launching a debugging run (the debugger is started by clicking the 'debug' button or via the Debug entry of the Run menu).