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 master 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.