Introduction

Release 1.6 of Mosel introduced the possibility to work with multiple models directly in the Mosel language. The new functionality, provided by the module mmjobs, includes facilities for model management, synchronization of concurrent models based on event queues, and a shared memory I/O driver. Release 3.2 of Mosel (see [Hei12]) extended the capacities for handling multiple models to distributed computing using several Mosel instances (running locally or on remote nodes connected through a network). The following list gives an overview on the available functionality. For the complete documentation of this module the reader is referred to the section mmjobs of the `Mosel Reference Manual'.

• Mosel instance management: connecting and disconnecting Mosel instances, access to remote files, handling of host aliases.
• Model management: compilation of source model files, loading of bim files, model execution and interruption, retrieval of model information (status, exit code, ID), redirection of I/O streams.
• Synchronization mechanism: sending and retrieving events, waiting for events or event classes, retrieval of event information (class, value, sender model).
• Shared memory I/O driver: shared memory version of the mem driver for exchanging data between concurrent models (write access by a single model, read access by several models simultaneously), usable wherever Mosel expects a (generalized) filename, in particular in initializations blocks.
• Memory pipe I/O driver: memory pipes for exchanging data between concurrent models (write access by several models, read access by a single model), usable wherever Mosel expects a (generalized) filename, in particular in initializations blocks.
• Remote connection I/O drivers: two drivers for creating remote Mosel instances.
• Remote file access I/O drivers: access to physical files or streams on remote Mosel instances, usable wherever Mosel expects a (generalized) filename, in particular in initializations blocks.

mmjobs introduces three new types, Mosel, Model and Event. The type Mosel is used to reference a Mosel instance. Before an instance can execute commands (like loading or running a model), it must be connected, that is, an additional operating system process running Mosel must be started.
The type Model is used to reference a Mosel model. Before using the reference to a model it has to be initialized by loading a bim file.
The type Event represents an event in the Mosel language. Events are characterized by a class and a value and may be exchanged between a model and its parent model. An event queue is attached to each model to collect all events sent to this model and is managed with a FIFO policy (First In – First Out).

The first section of this paper introduces the reader to the basic tasks that are typically performed when working with several models in Mosel, namely:

• Executing a submodel from another model: the compile – load – run – wait sequence
• Stopping the submodel execution
• Output from the submodel: redirection to a file, making the submodel silent
• Compilation to memory
• Passing runtime parameters
• Running several submodels
  • in sequence
  • in parallel
• Communication of data between different models: using the shared memory and memory pipe I/O drivers
• Working with remote Mosel instances

The remainder of the paper gives some more advanced examples of the use of mmjobs with a detailed explanation of their implementation. All examples are available for download from the Xpress website.

• Column generation: re-implementation of the column generation example from the Mosel User Guide with two separate models that are solved sequentially, passing data via shared memory.
• Parallel solving: several instances of the same model are run concurrently with different solution algorithm parameterizations. Improved solution values are sent for bound updates to all running models and the first model that finishes stops all others.
• Dantzig-Wolfe decomposition: an iterative sequence of concurrent solving of a set of subproblem instances, followed by solving of the updated main problem; data exchange via shared memory.
• Benders decomposition: solving iteratively a sequence of several different subproblems; data exchange via shared memory.
• Start solution heuristic: working with cloned models sharing data structures; several concurrent submodel instances use the same input data as the main problem and communicate back results via shared data structures.

All the advanced examples are documented as standard (single-instance) models. However, multi-instance versions are provided with the set of example implementations.

Multi-problem vs. multi-model

At this place we would like to stress the difference between multiple models and multiple problems — Mosel releases prior to version 3.0 always associate a single problem with every model. This means, for instance, if a model contains several calls to a solver such as Xpress Optimizer, then the solver will work with a single problem representation, and only the solution to the last optimization run can be obtained from the solver at any time.

Release 3.0 of Mosel introduces the possibility of defining several problems within a single model. At any point a single problem is active. It is possible to switch back and forth between problems, e.g., to retrieve solution information for a decision variable from different problems. To represent a 'problem', the Mosel language defines the type mpproblem, modules can provide their own problem types and users may equally create new problem types on the language level.

Here is a comparison of the main characteristics of multi-problem and multi-model implementations with Mosel.

Multi-problem (mpproblem)			Multi-model (mmjobs)
Single model file			Several model files
–	problems share data		–	communication of data (in memory)
–	integrated; no direct access to (sub)problems by other models/applications		–	stand-alone execution of submodels or use of submodels with other (parent) models/applications
Sequential access to problems only			Sequential or parallel execution of models

Problem solving approaches that involve parallel execution of (sub)models can only be implemented as multiple models, whereas sequential solving can be formulated with either one. For sequential algorithms (such as in Column generation and Benders decomposition) the developer may choose among the two design options.