---
myst:
    substitutions:
        macro:
            python: 1-5,13-17,21-62,65-96,99-101
            cpp: 1-50,53-79,83-95,101
        bloc1:
            python: 50-59
            cpp: 39-47
        bloc2:
            python: "74"
            cpp: "62"
        dedent:
            python: ":dedent: \n"
            cpp: ""
        sentence1:
            python: "The rest of this macro"
            cpp: "This macro contains another function called `reoptimizeHollowBarVizirSplitRuns` which"
        sentence2:
            python: " (its python interplay of course)"
            cpp: ""
---
# Macro "**reoptimizeHollowBarVizirSplitRuns.{{extension}}**"

## Objective

The objective of the macro is to be able to run an evolutionary algorithm (here we are using a 
genetic one) with a limited number of code estimation and restart it from where it stopped if it has 
not converged the first time. This is of utmost usefulness when running a resource-consumming code or 
(/and) when running on a cluster with a limited number of cpu time. The classical hollow bar example 
defined in [](#reoptimizer_problem_example_problem) is used to obtain a nice Pareto set/front.

## Macro {{uranie}}


{{
    "```{literalinclude} " + parent_dir +
        "/roottest/uranie/doc/reoptimizer/use_cases/" + language + "/reoptimizeHollowBarVizirSplitRuns." 
        + extension
    + "\n"
    + ":language: " + language + "\n"
    + ":lines: " + macro[language] + "\n"
    + "```"
}}
            
The idea is to show how to run this kind of configuration: the function `LaunchVizir` is the usual 
script one can run to get an optimisation with Vizir on the hollow bar problem. The aim is to create 
a Pareto set of 500 points (SIZE) but only allowing 1200 estimation (NBmaxEVAL). With this 
configuration we are sure that a first round of estimation will not converge, so we will have to 
restart the optimisation from the point we stopped. With this regard, the beginning of this function 
is trivial and the main point to be discussed arises once the solver is created.

{{
    "```{literalinclude} " + parent_dir +
        "/roottest/uranie/doc/reoptimizer/use_cases/" + language + "/reoptimizeHollowBarVizirSplitRuns." 
        + extension 
    + "\n"
    + ":language: " + language + "\n"
    + ":lines: " + bloc1[language] + "\n"
    + dedent[language]
    + "```"
}}
            
Clearly here, the interesting part apart, from the definition of the name of the file in which the 
final state will be kept, is the first test on the solver, before using the `setSize` method. A new 
methods called `setResume` is called, with two arguments : the number of elements requested in the 
Pareto set and the name of the file in which to save the state or to restart from. This method 
returns "true" if `genetic.dump` is found and "false" if not. In the first case, the code will assume 
that this file is the result of a previous run and it will start the optimisation from the its 
content trying to get all the population non-dominated (if it's not yet the case). If, on the other 
hand, no file is found, then the code knows that it would have to store the results of its process, 
in a file whose name is the second argument, and because the function returns "false", then we move 
to the "else" part, that starts the optimisation.

Apart from this, the rest of the function is doing the optimisation, and plotting the pareto front in 
a provided canvas. The only new part here is the fact that the solver (its master in fact) is now 
able to tell whether it has converged or not through the following method

{{
    "```{literalinclude} " + parent_dir +
        "/roottest/uranie/doc/reoptimizer/use_cases/" + language + "/reoptimizeHollowBarVizirSplitRuns." 
        + extension 
    + "\n"
    + ":language: " + language + "\n"
    + ":lines: " + bloc2[language] + "\n"
    + dedent[language]
    + "```"
}}
            
this argument being return as the results of the function.

{{sentence1[language]}} plays the role of the user in front of a ROOT-console{{sentence2[language]}}. 
It defines the correct namespace, loads the function file and destroys previously existing 
`genetic.dump` files. From there it runs the `LaunchVizir` function as many times as needed (thanks 
to the boolean returned) as the used would do, by restarting the macro, even after exiting the ROOT 
console.

The plot shown below represent the Pareto front every time the genetic algorithm stops (at the fourth 
run, it finally converges !).

## Graph

{{
    "```{figure} " + parent_dir +
        "/roottest/build/uranie/doc/reoptimizer/use_cases/" + language 
        + "/bar_vizir_split/reoptimizeHollowBarVizirSplitRuns.png\n"
    + ":align: center\n"
    + ":name: use_cases_reoptimizeHollowBarVizirSplitRuns\n"
    + figure_scale + "\n"
    + "\n"
    + "Graph of the macro **\"reoptimizeHollowBarVizirSplitRuns." + extension + "\"**" + "\n"
    + "```"
}}