Data exchange in memory for Mosel models

The development process of an optimization application typically includes several phases with very different needs in terms of data handling:

1. Feasibility study: development and implementation of the mathematical model, spending the least possible effort on data handling, test data possibly even defined directly in the model
2. Initial testing: running the model with different data sets (i.e., need for parameterization of data instances), possibly producing some performance statistics
3. Prototype for presentation to end users and decision makers: formatted display of results, possibly including graphics, `hiding' the mathematical model behind a graphical interface that makes accessible only the most important input and output parameters and data
4. Embedding into the company's information systems: incorporate the model into a host application using efficient mechanisms for communicating data and results

With Mosel it is possible to carry through the whole development process using a single model, adding different interfaces on top of this model that all employ the same mechanism for data input and output directly in memory.

The following series of examples works with the model file foliomemio.mos located in the directory examples\getting_started\Mosel of your Xpress installation. This model file implements the same MIP problem as in foliomip3.mos with the difference that all input and output data (arrays, sets, and scalars) have been turned into model parameters and the result display has been removed from the model.

1. Standalone mode: run the model foliomemio.mos in Xpress Workbench or from the Mosel command line. With all settings at default, this model run reads in data from a text file (folio10.dat) and produces an output file listing the result values (file sol10out.dat).
2. Submodel to another Mosel model: now run the model runfolio.mos. This model does not perform any optimization run of its own, it merely serves as an interface to execute the model foliomemio.mos from which it retrieves the results and generates text output formatted as an HTML page. Data are exchanged in memory between the two models.
   The file runfolio.mos can easily be extended to run several instances of the optimization model (e.g., with different parameter settings), in sequence or in parallel, and produce the corresponding summary statistics—an example of such parallel solving is shown in runfoliopar.mos.
3. Embedding into a host application: the C program runfolio.c compiles and runs the Mosel model foliomemio.mos, initializing its data arrays from data held in C and retrieving result data into the C application. The Java program runfolio.java does exactly the same for a Java application, and runfolio.cs is the equivalent C# program. In the place of the fixed-size memory blocks used in these examples you can also exchange data dynamically using Mosel's I/O callback functionality—generating data on-the-fly or flexibly (re)sizing output structures (see example files runfoliod.[c|java|cs]). And yet another option, in Java or C# it is possible to pass data through buffers (see files runfoliob.java and runfoliob.cs respectively).

Further information

• Further examples: ``Xpress Mosel User Guide'', Part III: `Working with the Mosel Libraries' and Chapter 17: `Language extensions'; Xpress whitepapers ``Generalized file handling in Mosel'' and ``Multiple models and parallel solving with Mosel''.
• Documentation of Mosel C libraries: ``Xpress Mosel Library Reference Manual''.
• Documentation of Mosel Java libraries: ``Xpress Mosel Library Reference Manual JavaDoc''.
• Documentation of the Mosel .NET interface: ``Xpress Mosel .NET Interface''.