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 a master 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 master problem; data exchange via shared memory.
• Benders decomposition: solving iteratively a sequence of several different subproblems; data exchange via shared memory.

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