in src/internet/hello_web.cpp:172 there is a file handle not removed:

//TODO : removed because cause crashes on windows (maybe related to curl version tested (7.53.1) : does curl close file handle ?
//fclose(pFile);

This should be investigated.

A typical properties.ini for a link looks like this

[target_node]
hurdles-cost = false
loop-flow = false
use-phase-shifter = false
transmission-capacities = enabled
asset-type = ac
link-style = plain
link-width = 1
colorr = 112
colorg = 112
colorb = 112
display-comments = true
filter-synthesis = hourly, daily, weekly, monthly, annual
filter-year-by-year = hourly, daily, weekly, monthly, annual

Proposal : Separate UI elements from technical elements.

UI elements :

• link-style = plain
• link-width = 1
• colorr = 112
• colorg = 112
• colorb = 112
• display-comments = true

Technical elements :

• hurdles-cost = false
• loop-flow = false
• use-phase-shifter = false
• transmission-capacities = enabled
• asset-type = ac
• filter-synthesis = hourly, daily, weekly, monthly, annual
• filter-year-by-year = hourly, daily, weekly, monthly, annual

For Ortools integration there is support for building of ortools tag.
When using stable branch there is an error when building antares-solver with ubuntu-latest

2020-10-15T12:53:20.3146653Z [ 96%] Building CXX object solver/CMakeFiles/antares-7.3-solver-swap.dir/misc/options.cpp.o

*Other files warning*

2020-10-15T12:53:23.3881025Z In file included from /home/runner/work/Antares_Simulator/Antares_Simulator/src/ext/yuni/src/yuni/core/getopt/parser.h:14:0,
2020-10-15T12:53:23.3882414Z                  from /home/runner/work/Antares_Simulator/Antares_Simulator/src/ext/yuni/src/yuni/core/getopt.h:12,
2020-10-15T12:53:23.3883537Z                  from /home/runner/work/Antares_Simulator/Antares_Simulator/src/solver/misc/options.cpp:30:
2020-10-15T12:53:23.3886435Z /home/runner/work/Antares_Simulator/Antares_Simulator/src/ext/yuni/src/yuni/core/getopt/option.h: In instantiation of ‘bool Yuni::Private::GetOptImpl::Option<T, Visible, AdditionalParam>::addValue(const char*, Yuni::CString<>::size_type) [with T = std::__cxx11::basic_string<char>; bool Visible = true; bool AdditionalParam = true; Yuni::CString<>::size_type = unsigned int]’:
2020-10-15T12:53:23.3888266Z /home/runner/work/Antares_Simulator/Antares_Simulator/src/solver/misc/options.cpp:344:1:   required from here
2020-10-15T12:53:23.3890235Z /home/runner/work/Antares_Simulator/Antares_Simulator/src/ext/yuni/src/yuni/core/getopt/option.h:391:45: error: ambiguous template instantiation for ‘class Yuni::Private::GetOptImpl::Value<std::__cxx11::basic_string<char> >’
2020-10-15T12:53:23.3891510Z     return Private::GetOptImpl::Value<T>::Add(pVariable, c_str, len);
2020-10-15T12:53:23.3892323Z            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
2020-10-15T12:53:23.3893203Z compilation terminated due to -Wfatal-errors.

This seams to be related to Yuni use.

For now swithing to ortools v7.8.

Release Candidate version is not displayed in NSIS installer.

Change CPack generated .deb name to add Release Candidate version

Add tests with MC years weight in Scenario Playlist

For now CI is done on Ubuntu and Windows, we need to check GitHub Action with docker use so we can compile on Centos for instance.

Check this article for a simple docker use : https://www.edwardthomson.com/blog/github_actions_5_building_in_containers.html

It seems to be simple as :

jobs:
  build:
    runs-on: ubuntu-latest
    container: 'centos:latest'

• Update application version to 7.2
• Update documentation Antares-general-reference-guide.pdf
• Update changelog.txt changelog.txt
• Update NEWS.txt NEWS.txt

Hi I am trying to install this on Ubuntu but coming across an error that I do not understand. Could you please help me with this. I have attached cmake log files.

CMakeError.log
CMakeOutput.log

Also, I believe in the INSTALL.txt file: section 3.2.1. should be :

$ cd ${ANTARES}/src/

Running sirius behind ortools causes regression in regard to running sirius alone.
For a given study :

• Results files can be different (though differences are tiny)
• checkIntegrity.txt files can be different as well, but more rarely. Most of the time they are equal.
• Time duration of a study are often quite different : running sirius behind ortools is much slower, up to 3 times the duration when running the same study with sirius alone.

Hello,

Thanks for your impressive work.

I am interested by your method of generation of time series. So, what method do you use ? Do you have some documentation about it ?

Thank you in advance for your reply

In debug mode, assert window panes open up.
See attached zipped study in order to reproduce the problem.

• Open the study with an Antares 7.2
• Go to Thermal tab
• Click on Area 2
• Click on "Summary for the area"
• assert window panes show up

The assert is located in wxwidgets sources, not in Antares sources.

BC_with_special_clusters_03-v7.2.zip

To accept more use case of MC years weight it is necessary to accept positive or null double values for weight.

With this feature user can define weight between 0.0 and 1.0 and so easily define weight as percentage values.

When changing status with 0 or 1 value, MC years weight is reset to 1.

Problem resolution fail when using OR-Tools glop solver with many examples.

Here is an very simple example :
Valid-800-RC1.zip

Up to now, all years are given the same weight in a simulation, which is consistent with the regular Monte-Carlo method. However, it may happen that the user has a specific knowledge regarding the probability density with which some time-series are likely to appear. As a consequence, it would prove handy to be able to give explicit relative weights to Monte-Carlo years built in such context. A suitable enhancement of the simulator would be to give the ability to indicate, in the "playlist" GUI, the specific weight Wi that should be given to the i-th Monte-Carlo year.

In the course of the computation of expectations and standard deviations, the probability
(Wi / Sigma { k) ( Wk ) will be assigned to year number i

GUI behaviours:

In the scenario builder hydro levels tab, user's input are reframed if they are not contained inside bounds 0 and 100.
Indeed, if user gives a number < 0 or > 100, the GUI automatic correction does not respond in the same way :

• if value<0 -> 0
• if value>100 ->100
• if values is not a double -> rand

StudyReader behaviour:

• if value is <0 ->0
• if value >100 -> 100
• if values is not a double -> rand

UN certain nombre d’études multilatérales (TYNDP notamment) requièrent que les outils de simulation puissent initialiser les réserves à un niveau explicitement défini par l’utilisateur.
Le processus actuel de détermination du niveau initial des lacs, pour chaque année Monte-Carlo est le suivant :

Date d'initialisation←(mois M_i  choisi  par l'utilisateur)
if (MC year number k ≥2 AND hydro mode==hot start )
{Niveau  au 1er jour de M_i   ← Niveau atteint en fin de mois M_(i-1)   lors de l'annee k-1} 
else 
{Niveau  au 1er jour de M_i   ← random (bêta)(Niveau min,Niveau max,Niveau moyen)} 

Ce niveau initial est ensuite utilisé dans les différents modules de pré-traitement hydraulique, dont un des résultats est le calcul de 365 niveaux heuristiques D_j , utilisés pour déterminer le niveau de départ effectif de la simulation, si celle-ci commence au jour j
Par exemple :
Mois d’initialisation choisi pour une zone donnée: septembre
Calendrier de simulation : du 15 septembre au 31 mai
Phase 1 : on tire au sort une valeur de niveau initial pour le 1er septembre
Phase 2 : on élabore une série de 365 niveaux (heuristiques) passant au 1er septembre par la valeur tirée au sort
Phase 3 : la simulation (hebdomadaire ou journalière) démarre avec un niveau de départ égal au niveau heuristique du 15 septembre
(note : si la simulation démarre au 1er septembre, alors le niveau de départ est égal au niveau initial

L’objet de l’évolution décrite par ce ticket est de rendre possible la détermination du niveau initial par l’utilisateur, en passant par le module scenario builder.
Ceci suppose une évolution du module scenario builder permettant d’indiquer, pour chaque zone et chaque année MC, si le niveau initial est de type « rand » (c’est-à-dire tiré au sort comme précédemment) ou bien de type déterministe (valeur explicite en pourcentage)

Like units tests added for matrix access and read/write from stream we should add integration test for matrix save and load from file :

• load file and check matrix content

  • empty file
  • invalid file content
  • correct content
  • not available file
  • ...

• write file and check file and matrix content

  • empty matrix
  • matrix without jit and jit disabled => matrix content is kept
  • matrix without jit and jit enabled => matrix content is cleared and jit is created
  • matrix with jit and jit enabled => matrix content is cleared

Please feel free to add more tests in issue description.

Asking MPS problems generation in the study and running Antares with sirius behind orTools does not print MPS problems.
When a resolution with sirius only is asked, MPS problems are printed.

This issue to list things to do before tagging with v8.0 :

• update of changelog and news with what this new version contains
• Update documentation available from GUI : user's guide for advanced hydro option
• Check version number: remove RC before final tag
• Run all non regression tests
• Need of a new licence key

similar to #5
but this time splitting solar into pv & csp

On Ubunu application crash when saving a new study.

Steps to reproduce :

• launch antares-simulator
• start a new empty study
• save

First assertion :

It seems that wxAutoBufferedPaintDC in void WizardHeader::onDraw(wxPaintEvent&) can't be called outside a paint event.
This is the case because onDraw is called in WizardHeader::Create

Some would be easy to fix :

• Unused variables
• Unused parameters

Some look harder to fix.

It would be nice to have fewer compilation warnings since some of them may be related to undefined behavior. While we don't really care about unused variables and such, we absolutely want to avoid undefined behavior.

I am running Antares v7.1
I just tried to change the selection of the "dependencies" of one area in the "inspector" tab.
As soon as I try to change the value selecting one specific link or one specific cluster Antares crashes.
The Antares study I am using is very small
STA-mini.zip

Need to update src/ui/simulator/application/main/main.h with new activation keys (line 42 to 72).

Currently the user can set 1 timeseries for other res & other non res per area. We have however created temperature (and hence climate year) dependant series for these production categories (e.g. CHP's have a negative temperature correlation as more heating is required when it's cold).

Currently we have to model this using virtual area's where it is inserted as 'solar' & wind production. It would be better to have separate input categories in each antares area. Is it possible to incorporate this into the antares development roadmap?

In release automatic asset upload we use set-env function to add created installer name to environnement so we can define asset name.

This function is deprecated, see github action warning log :

The set-env command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/

releaseWindows.yml must be updated.

Ce problème n'apparaît pas dans la 7.1 d'Antares.
Lorsque qu’on ouvre une étude au format 7.1 avec une IHM 7.2 et qu’on sauvegarde cette étude (save as) en une étude 7.2, le répertoire d'input est copié correctement mais l'IHM affiche des cases vides pour un tableau particulier de la partie hydro (hydro > area > Local data > Daily power & Energy credits). A ce stade il n'y a pas encore de problème : lancer un calcul n'affectera pas les résultats.
En revanche, si on sauve cette nouvelle étude en cliquant sur "save" (même sans modification), le vide constaté dans le tableau est transmis aux fichiers correspondant du répertoire d'input, qui sont donc vidés. Et lancer une simulation transforme les résultats.

Regression tests must be updated with test for new feature of MC years weight.

We are observing cases where the Antares output variable NODU is resulting in 2 (viewing per separate Monte Carlo year, on hourly basis), although there is only one unit defined in the thermal cluster. The NODU variable will change from 2 to 0 and back to 2. The output of the respective cluster is also not above its defined capacity.

Antares documentation is uncorrect, 7.1 version is used in installer.

When reversing MC years status in MC scenario playlist with an activated year with weight :

The label still indicates a custom weight and there is a glitch in the display :

There seems to be the same issue when using Enable All or Disable All actions.

Tdoay, a user can still configure the monte carlo builder, even if the building mode is set to automatic.
This might lead the user to believe that he is changing the way the timeseries are combined even though he isn't.

Also, if you are using flowbased the results will be off because the right hand side is in a thermal time series list.

Therefor I think it would be best to grey out the monte carlo scenario builder option when the setting is set to auto.

This would be in line with for example results filtering, where you can only see the filtering options in the inspector when the setting is set to custom.

When trying to run an Antares study, antares estimates a memory use of about 8GiB with more than 25GiB available (1st screenshot) but when actually running the simulation, it fails with the error message : not enough memory available (2nd screenshot).
Running the solver in swap mode doesn't solve the issue, with a new memory related error message (3rd screenshot).

Caution : this issue cannot be reproduced on any computer

073 Hydro Reservoir Model -enhanced-06.zip

See the attached simple study, of which main properties are :

• 1 area (named F)
• 1 MC year
• For this area, in hydro management options tab, reservoir management and use heuristic are turned to yes
• In scenario builder, the initial level is set to 15% for the year and area F.
• Initial level month : january

We expect that, after running the simulation, the hydro level at the end of the year is 15%, that is the same level than the initial level, as all year inflows have been used.

This is not the case : we get a final level of 31%.

For information, if we do not set a initial level in the scenario builder (rand), initial and final levels are equal.

this issue is related to the PR #108

Antares requires the user to enter wind as a single category for each area. If the user want's to separate wind output in onshore & offshore wind farms he has to create virtual areas.

We often work with very big models (> 200 areas) for which this solution is undesired. It would be nice if a separate input option was available per area.

Could this be added to the roadmap?

When using CMake 3.14 as a minimum version, Ortools dependency compilation fail because of CMP0053 cmake policy.

build_git_dependency function defined in cmake\utils.cmake set invalid value for BINARY dir with CMake 3.14.

See CMake warning :

CMake Warning (dev) at cmake/utils.cmake:73 (set):
  Policy CMP0053 is not set: Simplify variable reference and escape sequence
  evaluation.  Run "cmake --help-policy CMP0053" for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.

  For input:

    '@CMAKE_CURRENT_BINARY_DIR@/${GIT_DEP_NAME}/build'

  the old evaluation rules produce:

    'D:/Projet_SRO/rte-antares/ortools_release/src/build_deps/sirius/build'

  but the new evaluation rules produce:

    '@CMAKE_CURRENT_BINARY_DIR@/sirius/build'

  Using the old result for compatibility since the policy is not set.
Call Stack (most recent call first):
  cmake/dependencies/CMakeLists.txt:141 (build_git_dependency)
This warning is for project developers.  Use -Wno-dev to suppress it.

With CMake 3.14, new evaluation rules is used and invalid directory is used ``'@CMAKE_CURRENT_BINARY_DIR@/sirius/build'```

Issue

Source files do not follow formatting rules. In some PRs, manual formatting is done. This greatly reduces the readability of these PRs, since the reviewers must separate real code editing from manual formatting.

Suggested solutions

• Use a code formatter such as clang-format or astyle
• Do not manually format code

Binding constraints involving only weights either equal to zero or neutralized weights (equivalent to zeroes : must-run or disabled thermal clusters) should be given the "skipped" status so to avoid transmission of an (empty) meaningless constraint to the solver. Conversely, re-introduction of actuallty active terms should reactivate the binding constraint.

Sometimes we need to change the commit of a tag in case bugfixes.

This can't be done with GitHub but with git commands, for example :

git tag --force v7.2.0 fe3c7f20520930808b2a0c32c9329188d3a196fa
git push --force --tags

It would be nice if the release asset could be regenerated in case of tag commit change.

I guess it mean removing the current asset and upload new asset because we shouldn't be able to upload the same asset name twice.

OrTools is downloaded, built and installed during cmake configuration step.
By default, an Rte OrTools version is used. On demand (still at cmake configure step), last stable version can be used instead.
This latter option requires the download of an archive scip-7.0.1.tgz (not required by the default orTools), which is then unzipped.
On some Rte computers, this unzip operation goes wrong, stops the cmake configure step and prevents orTools from being installed.

When using antares-8.0-solver with antaresXpansion it appears that previous antares study can be used with a new version of antares.

This differs from antares-simulator behavior which require a study upgrade before any simulation.

We must define the behavior of antares-solver :

• reject any study with a different version ?
• auto upgrade of study with a different version ?
• allow use of previous study if parameters are compatible ? (current behaviour)

Decision

After further discussions the behaviour to be retained is :

• antares-solver should exit when the study-version differs from the solver-version except for the last number (x) V.v.x

If the TS draw for a disabled thermal unit is predefined in a ruleset this will throw a warning upon executing the simulation. However, it seems this warning is generated for every MC ruleset, and not just for the active one.

More generally, I've just built a model with 2000 thermal units, a lot of which are disabled, and predetermined the draw for each of the 1320MC years. This results in hundreds of thousands of warnings generated, slowing down antares quite a lot. Maybe this warning / check can just be cancelled?

Procedure to reproduce

Compile the "develop" branch with default options.
Execute either the solver or the GUI
The following error message appears
_build/solver/antares-7.2-solver: error while loading shared libraries: libsirius_solver.so: cannot open shared object file: No such file or directory

Mitigation

Before running the solver or the GUI, execute
export LD_LIBRARY_PATH=/home/florian/Antares_Simulator/src/build_deps/install/lib/

This directory contains libsirius_solver.so

Possible fixes

• Install libsirius_solver.so into /lib or /usr/lib
• At linking, give the full path for libsirius_solver.so (check if it is possible)
• Statically link libsirius_solver (ugly)

Remove dead code related to the legacy "PNE" solver.

Example :

    if (ProblemeHebdo->SolveurDuProblemeLineaire == ANTARES_SIMPLEXE)
    {
        result = OPT_AppelDuSimplexe(ProblemeHebdo, numSpace, NumIntervalle);
    }
    else
    {
        result = OPT_AppelDuSolveurPne(ProblemeHebdo, numSpace, NumIntervalle);
    }

Label for unfeasible problem option are not uniform with documentation

Labels must be updated.

Integrate ortools in antares-solver with work from : RTE https://github.com/rte-france/Antares_Simulator/tree/feature/Sirius_extraction.

Need compilation of :

• sirius solver : https://github.com/rte-france/sirius-solver/tree/Antares_VCPKG
• ortools : https://github.com/rte-france/or-tools/tree/rte_dev_sirius

CI must be updated with option for sirius solver and ortools compilation

For 7.3 version we need to be able to :

• add an option in run windows to use ortools
• define ortools solver used for simulation (sirius, glob, coin, ...) before run (with a menu)
• display in antares-solver logs which ortools solver is used (if ortools is used)