Fix mingen issues with several modifications

[flomnes]

1. Remove truncation from weekly turbine credits (was done previously)
2. Always enable monitoring of stock levels (including overflow)
3. Take overflow into account in the "HydroPower" constraint (was done in 9.1.0)
4. Remove recomputation of reservoir levels & overflow
5. Correct infeasibility in hydro heuristic problem, related to mingen > 0

[guilpier-code]

It seems that removing the weekly truncation involves removing the whole block :

double weekGenerationTarget = 1.;
double marginGen = 1.;

if (area.hydro.reservoirManagement && area.hydro.useHeuristicTarget
    && not area.hydro.useLeeway)
{
     double weekTarget_tmp = 0.;
     for (uint j = 0; j < 7; ++j)
     {
          uint day = study.calendar.hours[PasDeTempsDebut + j * 24].dayYear;
         weekTarget_tmp += hydroVentilationResults[k]
                        HydrauliqueModulableQuotidien[day];
     }

     if (weekTarget_tmp != 0.)
     {
         weekGenerationTarget = weekTarget_tmp;
     }
     marginGen = weekGenerationTarget;
}

As well as the truncation coefficient marginGen / weekGenerationTarget.

[flomnes]

You mean that since marginGen = weekGenerationTarget, marginGen / weekGenerationTarget is always 1 ?

[guilpier-code]

Exactly.
When we removed the troncation, we did not remove all what should have been.

[guilpier-code]

Whatever the purpose of this change is (it could be so that CI completes and generates artefacts), we'll have not to forget reverting it.

[sonarqubecloud]

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
51.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[guilpier-code]

So we no longer need to use TurbineCible in this function H2O_J_InitialiserLesBornesdesVariables(...).
Hence we should remove line :

const std::vector<double>& TurbineCible = DonneesMensuelles->TurbineCible;

[guilpier-code]

About :

Xmax[Var] = TurbineMax[Pdt];
Xmin[Var] = std::min(TurbineMax[Pdt], TurbineMin[Pdt]);

It's strange that we give the lower bound of variable Turbine like this.
Reader could expect instead :

Xmin[Var] = TurbineMin[Pdt];
Xmax[Var] = TurbineMax[Pdt];

It seems that TurbineMax is not necessarily greater than TurbineMin for every day, which is strange.

[nikolaredstork]

I agree, since there is a precheck for each hour in checkGenerationPowerConsistency function, I don't see how TurbineMax in any situation can be lower than TurbineMin, but maybe I am wrong.

[guilpier-code]

In the current PR presentation, it's said that the re-computation of hydro levels after weekly optimization should be removed.
And indeed, the post process class HydroLevelsUpdatePostProcessCmd was largely simplified : it now only converts levels from their adimensionnel version into MWh.
In that context, we can also see that this post-process is still called twice for modes adequacy & economy, which leads to wrong hydro levels values.

What we should do :

• This class should therefore be renamed into HydroLevelsConversionIntoMWhCmd for more clarity.
• Its method execute(...) should be called once (for a given simulation mode).
• We should take advantage of this to remove boolean remixWasRun, no longer useful.
• If it turns out the other boolean computeAnyway is not really needed, then remove it.

[guilpier-code]

About SuiviNiveauHoraire : if this boolean equals reservoirManagement, let's call it reservoirManagement and avoid a parameter to be named in two different ways.
It would lower complexity.

[flomnes]

I agree, if we go on with this change, we'll simply remove SuiviNiveauHoraire.

[guilpier-code]

About :

ProblemeAResoudre->NombreDeContraintes += nombreDePasDeTempsPourUneOptimisation;

This instruction suddenly appears.
Why ? Was the previous code incorrect ?
Or is it about overflows back in the game ?
We should add a comment.

[flomnes]

No the estimation of variables & constraints is incorrect. There was an underestimation, which lead to segfaults.

[guilpier-code]

This file contains no comment that relates a count increment to a set of constraints.
It's unclear : which increment correspond to which set of constraints ?
Besides, this way of counting constraints apart from the constraints themselves is very much error prone : it's very easy to add / remove constraints and not update the constraints count.
Adding / removing a constraint should automatically update the constraint count.

But this will be for another PR.

[guilpier-code]

We should update the comment that explains the cost we give to the hydro overflow