# A step-by-step description of Vizir

{{
    "```{" "figure" "} " + parent_dir +
        "/usermanual/reoptimizer/figures/VizirSchemaBlock.png\n"
    ":align: center\n"
    ":name: reoptimizer_VizirSchemaBlock\n"
    + figure_scale + "\n"
    "\n"
    "Schematic description of the requested steps of an optimisation procedure once this one is 
    performed with Vizir\n"
    "```"
}}

The global organisation of an analysis performed within {{uranie}} with the Vizir package is as 
followed: the user request a certain number $N_{\rm Cand}$ of elements to describe correctly the 
Pareto set and front.

1. The first step is to create randomly, only using the research space definition, a population of 
the requested size. An evaluation is performed for all candidates, meaning that the criteria and 
constrains will be tested and the results will be stored in a vector for all candidates. All the 
calculation concerning a candidate will count as one evaluation (this notion will be important later 
on when considering the number of evaluation $N_{\rm Eval}$). This step (the turquoise blue box in 
{numref}`reoptimizer_VizirSchemaBlock`) is followed by the ranking of all the candidates (red step in 
{numref}`reoptimizer_VizirSchemaBlock`).

2. As already discussed, ranking single criterion results is simple because there is an obvious 
relation order, but this is not the case when dealing with multi-criteria. The chosen solution in the 
{{uranie}} implementation is to affect a rank to a candidate under study, corresponding to the number 
of other candidates that dominate it. The best candidates have then a rank 0 (they are not-dominated), 
following by rank 1, rank 2... With the ranking step completed the next step is to test whether the 
algorithm has converged or not.

3. The test of convergence can reach three possible states:
    - all the tested candidates are not-dominated. This means the algorithm have converged and the 
    loop will stop as the objective of having a description of both Pareto set and front is achieved.

    - not all candidates are not-dominated but the maximum number of evaluation has been reached. In 
    this case, the algorithm stopped as well but this time without having converged. Restart the 
    algorithm with different configuration might be a possibility.

    - not all candidates are not-dominated and the maximum number of evaluation is not reached.

4. In the latter case, a certain fraction of the candidates will be selected and used as a new 
starting point to recreate a new population. A fraction $\lambda$ is indeed kept (this fraction 
value being set by changing the survival rate in the genetic case, whose default value is 40%) in 
order to produce a new generation that will hopefully converge better than the current one. The 
evolutionary algorithm uses the selected fraction ($\lambda N_{\rm Cand}$) to complete the total 
population (meaning re-generating $1-\lambda N_{\rm Cand}$). This procedure is explained more deeply, 
in the case of a genetic algorithm, in {{metho}}.