Documentation / User's manual in C++ :

XI.3. Using minimisation techniques

XI.3. Using minimisation techniques
	Chapter XI. The Calibration module

XI.3. Using minimisation techniques

Warning

This method is fully relying on the Relauncher architecture so the only constructor available is the runner one (discussed in Section XI.2.3.1). This means there is no constructor based on TCode or function (respectively described in Section XI.2.3.2 and Section XI.2.3.3). This is explained as this method is a using the Nlopt-algorithm bank, introduced in Chapter IX but also the Vizir package for multi and many criteria algorithm.

Even though the theory behind this method is not revolutionary, these methods are interested and are, historically and conceptually, the simplest one, one can think of. Because of the way it has been organised, it can be used with all Relauncher assessors and can call all NLopt algorithms along with the Vizir ones. This is explained in Section XI.3.2.

XI.3.1. Constructing the instance

As stated above, the only constructor available is the one whose prototype contains an instance of TRun-inheriting object. This approach allows a simple way to change the evaluator (to pass from a C++ function to a python's one or a code) but also to use either a sequential approach (for a code) to a threaded one (to distribute locally the estimations).

The constructor in this case, should look like this

// Constructor with a runner
TMinimisation(TDataServer *tds, TRun *runner, Int_t ns=1, Option_t *option="");

It takes up to four elements which are:

tds: a TDataServer object containing only an attribute for every parameter to be calibrated. This is the TDataServer object called tdsPar, defined in Section XI.2.1.
runner: a TRun-inheriting instance that contains all the model information and whose type is defining the way to distribute the estimation: it can either be a TSequentialRun instance or TThreadedRun for distributed computations.
ns: the number of samples to be produced. This field does not apply here.
option: the option that can be applied to the method. The option common to all calibration classes (so those defined in the TCalibration class) are discussed in Section XI.2.3.4.

The key step in this constructor is the TRun-inheriting instance creation. As already stated, its type is giving the lead on the way to distribute the estimations. When one is constructing such an object, it is done by passing an evaluator, whose list is already largely discussed in Section VIII.3.

XI.3.2. Setting the optimisation properties

Once the object is constructed, the optimisation properties must be set, to decide which algorithm must be used. This can be precised by calling the setOptimProperties, whose prototype is the following:

// Prototype for nlopt
void setOptimProperties(URANIE::Reoptimizer::TNloptSolver *solv, Option_t *option="");
// Prototype for vizir
void setOptimProperties(URANIE::Reoptimizer::TVizirSolverShare *solv, Option_t *option="");

In both cases, the option field is there if some option shows up at some point, even though so far it is useless. There is only one difference between these two prototype: the kind of solver to be used knowing that the minimisation will be done on the distance function value disregarding the number of parameter to calibrate.

Once the optimisation solver is chosen and configured, is provided to the TMinimisation instance, which we'll create automatically the optimisation master depending on the nature of the solver:

TNlopt: This is the optimisation master used for any TNloptSolver instance. An example can be found in Section XIV.11.1.
TVizir2: This is the optimisation master used for any TVizirSolverShare instance. Even though the optimisation will remain mono-criterion, this might be useful for some intricate issues, as discussed in Section XIV.11.6.

As shown in the latter example, it is possible to get a hand at the optimisation master by calling the getOptimMaster method. This method returns a pointer to the TOptimShare-newly created instance. This might be useful to set some properties (for instance the tolerance).

Warning

Caution has to be taken when calling the getOptimMaster method in C++, as the pointer can be either a TNlopt or TVizir2 instance. If in python this should fully transparent, in C++ it might be useful to cast the pointer returned by this method, as shown below:

// Set the calibration object
TMinimisation *cal = new TMinimisation(tdsPar,runner,1);
cal->setDistanceAndReference("relativeLS",tdsRef,"rw:l","Qexp");
bool vizir=true;
if( vizir ){ // Set Viziroptimisaiton properties
  TVizirGenetic solv;
  solv.setSize(24,15000,100);
  cal->setOptimProperties(&solv);
  TVizir2 *optimMaster = ((TVizir2*)cal->getOptimMaster());
} else{ // Set Nlopt optimisaiton properties
  TNloptSubplexe solv;
  cal->setOptimProperties(&solv);
  TNlopt *optimMaster = ((TNlopt*)cal->getOptimMaster());
}

Apart from the discussion above, there are no specific options and methods in the TMinimisation class, and more information on method can be found in Section XI.2. Examples are also provided in the use-case sections (see Section XIV.11), particularly one can have a loot at the residue distributions both a priori and a posteriori for a point-estimation, which are shown in Figure XIV.96.


XI.2. Calibration classes, distance functions, observations and model		XI.4. Analytical linear Bayesian estimation