Initializing help system before first use

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.

∀ m ∈ MEETINGS: planm ∈ {1,2,3}
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:

  1. 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.
  2. 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.
  3. 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:

  1. Compiling meeting.mos
  2. Loading the compiled model
  3. 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 Run button KalisUG/butrun.png or, alternatively, choose menu entry Run for the desired model.
KalisUG/wbentryka.png

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 output 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 (bug icon KalisUG/butdebug.png).

KalisUG/wbdbgka.png

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 KalisUG/butdebug.png or via the Debug entry of the Run menu).

© 2001-2019 Fair Isaac Corporation. All rights reserved. This documentation is the property of Fair Isaac Corporation (“FICO”). Receipt or possession of this documentation does not convey rights to disclose, reproduce, make derivative works, use, or allow others to use it except solely for internal evaluation purposes to determine whether to purchase a license to the software described in this documentation, or as otherwise set forth in a written software license agreement between you and FICO (or a FICO affiliate). Use of this documentation and the software described in it must conform strictly to the foregoing permitted uses, and no other use is permitted.