DO NOT MERGE - FOR EXECUTABLES ONLY RTEi

[Milos-RTEi]

This PR is created to generate executables for the beta-12 version of adequacy patch for Elia.

From Daniel's Email:

What we need now is a beta 12 version as follows

•    We take  Antares v8.5.0 (released)
  

•    We bypass the isolated simulation
  

•    We thus do NOT impose the ENS < DENS_0 constraint in the interconnected simulation
  

•    We just run Antares “without any Adq Patch” in the first place anyway. Then we calculated DENS_new as we do now in beta 11 but just on the results without any such constraint ENS < DENS_0
  

•    We follow the same LMR+CSR procedure as now in beta11
  

Hence on paper it seems rather feasible to provide us a “beta 12 version on Antares v8.5.0” quite fast since the steps to take are just*

•    Deactivate & bypass the isolated step
  

•    Deactivate the ENS < DENS_0 constraint
  

•    The rest remains the same
  

[Milos-RTEi]

@hugo-antoine-rtei
ok. The pipeline is running ok. That is great.
Since I'm going to do this really fast. Please try to review the logic (I'll do the testing and the dev).
So at least I have the second pair of eyes take a look at the code logic.
To try to avoid some really stupid mistakes.

[Milos-RTEi]

I'll remove you as the reviewer now. Not to fill up your outlook with stupid mails. Will let you know when I finish.

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
23 Code Smells

9.1% Coverage
0.0% Duplication

[Milos-RTEi]

Hi, @hugo-antoine-rtei @flomnes

please take a look (Florian volunteered himself).
I hope there is no major flaw in my thinking.

I did lots of testing.

• First. If you run the simulation without the adequacy patch and then run it with the adequacy patch but with CSR disabled,
  You get identical results, As expected.
• Second. I logged out again the complete formulation (input data) for the CSR solver. And all looks ok.
• Third. I do not have any issues when running simulations with beta-12 on Daniel's networks.

SonarCloud is going crazy cause of the unused variables, functions.. commented-out lines...
But I don't want to worry about code quality now. If we get thumbs up for beta 12 then we do the cleanup later.

[flomnes]

Careful, ValeursHorairesDENS[hour] = 0, see src/solver/optimisation/adequacy_patch_local_matching/adequacy_patch_weekly_optimization.cpp.

Suggested change

	priceTakingOrders = problemeHebdo->ResultatsHoraires[area]->ValeursHorairesDENS[hour]; // densNew value taken! OK!
	priceTakingOrders = problemeHebdo->ResultatsHoraires[pays]->ValeursHorairesDeDefaillancePositive[hour];

[Milos-RTEi]

I'm positive we are good here. According to spec:

s0 PTO=DENS not PTO=ENS.
if ValeursHorairesDENS[hour] = 0 function calculateQuadraticCost will just return zero. It will not try to divide with zero.
If you meant that by this point in the code the column DENS is going to be all zeros, It is not the case. Zeros are overwritten for areas inside adq-patch in
src/solver/optimisation/post_process_commands.cpp line 231

[flomnes]

Ok, LGTM

[flomnes]

You don't need to change the definition of this class (revert all changes).

We made a nice factory method just for that, see file src/solver/optimisation/base_weekly_optimization.cpp. Just return std::make_unique<DefaultWeeklyOptimization> in all cases (adq patch enabled/disabled), it's much simpler.

[Milos-RTEi]

Yes, I saw that. Nice. I agree it's a proper way to do it.
I just wanted to be sure that AdequacyFirstStep = false. Even though I think I overwritten all the code where AdequacyFirstStep is used.
Also for areas outside adq-patch we need to set zero values for DENS somewhere.
I agree DENS should be initialized to zero somewhere else if just defaultWeeklyOptimization is required.
On TODO list.

[flomnes]

We will add a new option to disable the LMR, probably in 8.6.

I'll be closing this temporary solution.