9.2. Problem definition

An optimisation problem is a kind of parametric studies, so, it could make the best of the Relauncher architecture. Having this in mind, having a look at The Relauncher module is crucial in order to get good understanding of the following, already-introduced, concepts.

In this module, one will introduce new masters, meaning classes that inherit from TMaster which will handle the distribution of evaluations, with extra specificities linked to their optimisation purpose. But before using them, the runners (inheriting from TRun) and assessors (inheriting from TEval) have to be defined as well, respecting the pattern separation between study and evaluation sides. Only the study side is concerned by optimisation objects (all these notions are defined in The Relauncher module). The standard steps to solve an optimisation problem are:

to declare the optimisation input parameters.
to choose a solver (eventually configure it).
to create a master (eventually configure it).
to declare the objective and constraints of the problem.
to run the optimisation.
to analyse the results.

The Rosenbrock example script provided in Relauncher abstraction levels gives a simple example of these steps.

There are few TMaster sub-classes depending of the local or global algorithm that is chosen (the underlying library). The constructor has three arguments: the two TMaster usual arguments (a TDataServer and a TRun), and the solver. A common method to all masters is setTolerance with a double as only argument. It defines a threshold to stop the search. However, its interpretation is solver dependant.

As we saw in the TMaster section, item definition parameters are defined in the TDataServer used as first constructor argument. These attributes generally need to be defined with a domain, whose boundaries are used for the optimisation.

The master and solver declaration will be covered in next section. Running the optimisation is done by the solverLoop method, and results will be found in the TDataServer.

Tip

Before Uranie version 4.2, only the final results were kept in the dataserver and no option was allowing the user to keep track of all performed estimation (either to see how the algorithm is driving the parameters evolution, or just for bookkeeping). From version 4.2, it is possible to create an empty TDataServer and to provide it to the chosen Master so that every computation will be stored in this specific object. For a single objective optimisation this should look like this:

// ... Problem definition
runner.startSlave(); // Usual Relauncher construction
if(runner.onMaster())
{
    // Create the main TDS
    TDataServer tds("nloptDemo", "Param de l'opt nlopt pour la barre");
    tds.addAttribute(&x);
    tds.addAttribute(&y);

    // Defining the optimisation condition
    TNloptCobyla solv; // algorithm

    // Create the single-objective constrained optimizer master
    TNlopt opt(&tds, &runner, &solv);
    // ... + objective, constraint...

    // Create the dataserver in which all computation will be stored
    TDataServer trc("allevents","dataserver containing all events");
    opt.setTrace(&trc); // pass the dataserver to the master

    opt.solverLoop(); //perform the optimisation
}