Page Comparison

The end goal of Problem modeling is the process of understanding the customer’s domain and requirements, and turning them into Modeling is to produce a problem description that is fed to feed the Multi-Agent Optimization Engine. For each new customer, we instantiate our generic meta-model into a specific problem description expressed in YAML or JSON. Then the problem description is automatically translated into an actual multi-agent system.

As soon as possible, graphical models produced with this tool are refined to instantiate an actual multi-agent system. This is done through high-level descriptions that are basically almost textual translations of the graphical models, except that they allow for more details. This problem description is to be used as an input by the Optimization Engine.

The simple case example shown earlier with the graphical norm could be translated to a problem description as follows (with an added special case where some of the list prices are excluded from the optimization). This example is only meant to illustrate the main concepts:

• A space defines the dimensions in which the following variables and criteria exist (i.e. a plate in the graphical norm, aka a rectangle or the crossing of rectangles).

• A scope is within a space and defines the perimeter in which the following variables and criteria exist (i.e. the scope of customers with turnover higher than N in the space product x customer).

• Spaces and scopes can be referred to from other spaces and scopes in order to connect computed variables to their "inputs".

...

...

...

.

In practice, this description is a Groovy map in the Run Logic. A specific API transforms this map into JSON. Then the backend transforms the JSON problem description into an actual multi-agent system.

In this section, all the code snippets are in YAML, since it is basically JSON but readable by a human.

The steps to create a specific model description are:

1. Get to know the structure of the Run.groovy logic.

2. Define the categories hierarchies.

3. Define the spaces.

4. Define the scopes inside each space.

5. Define the variables inside each scope.

6. Define the criteria inside each scope.

The easiest way to write the description space is by following the graphical description. The binding to the data is done through scopes: inputs and outputs of the Optimization Engine are model tables named after the space and scopes to which they pertain (e.g. Problem_ByProduct_All contains the data for the scope All in the space ByProduct).

Understanding the underlying concepts is important. As a reference, see Main Concepts for Optimization Problems.

This section also provides a problem description sample.

Further in this section:

A problem description does not exist in isolation and is delivered along with a Model Logic responsible for providing the mappings, in the form of Model Tables, between this high-level description of the problem and the actual values coming from the partition’s transactional and master data. This step is documented in the next section Problem Tables.