OMEGAlpes issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues2019-07-17T19:55:20+02:00https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/2add version and docformat2019-07-17T19:55:20+02:00Lou Morrietadd version and docformatAdd in each module:
__version_info__ Version sous forme de tuple d’entiers :(1, 0, 0)
__version__ Version en chaîne de caractères : “1.0.0”, ou encore
[str(x) for x in __version_info__]
__docformat__ Format de documentation (“restructur...Add in each module:
__version_info__ Version sous forme de tuple d’entiers :(1, 0, 0)
__version__ Version en chaîne de caractères : “1.0.0”, ou encore
[str(x) for x in __version_info__]
__docformat__ Format de documentation (“restructuredtext en”Camille PajotCamille Pajothttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/3check pep82019-12-09T14:23:16+01:00Lou Morrietcheck pep8afin de s’assurer d’avoir une qualité de code correcte sont :
— black: formate automatiquement le code source (non configurable)
— flake8: mesure le respect de la PEP-8
— pylint: mesure la qualité du code (PEP-8 et analyse statique)
Le ...afin de s’assurer d’avoir une qualité de code correcte sont :
— black: formate automatiquement le code source (non configurable)
— flake8: mesure le respect de la PEP-8
— pylint: mesure la qualité du code (PEP-8 et analyse statique)
Le formatage par défaut de black respecte en grande partie la PEP-8, tout en faisant l’impasse sur
certaines règles. Par défaut, black s’assure que les lignes ne dépassent pas 88 caractères (contre 80 selon
la PEP-8) et ajoute des espaces, virgules et parenthèses afin de simplifier la lecture et l’ajout de lignes au
code. Ce comportement déclenche des alertes lors des analyses par les outils flake8 et pylint, qui devront
être configurés en conséquence.Camille PajotCamille Pajothttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/4typing2019-12-09T14:23:07+01:00Lou Morriettyping— mypy: analyse statique du code (typage)
L’ajout du typage, validé par mypy et utilisé par PyCharm, permettra de faciliter le développement. La
documentation sur le typage de Python est associée au module typing.
https://docs.python.or...— mypy: analyse statique du code (typage)
L’ajout du typage, validé par mypy et utilisé par PyCharm, permettra de faciliter le développement. La
documentation sur le typage de Python est associée au module typing.
https://docs.python.org/3/library/typing.htmlhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/5docstring2019-07-17T19:53:24+02:00EXT HodencqdocstringFilling in the doscstrings for the different modules and classes.Filling in the doscstrings for the different modules and classes.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/6License2019-07-17T19:53:10+02:00Lou MorrietLicenseDefine a license (?)
Write the license fileDefine a license (?)
Write the license filehttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/7Add AUTHORS.rst and README.rst2019-03-27T09:01:11+01:00Lou MorrietAdd AUTHORS.rst and README.rst— AUTHORS.md : Liste des auteurs et contributeurs. Ce fichier peut être divisé en sections ( e.g. Ini- tiateurs , Développeurs , Contributeurs ). L’ajout des adresses mails à ce fichier est sujet à caution (risque de spam).
— README.md...— AUTHORS.md : Liste des auteurs et contributeurs. Ce fichier peut être divisé en sections ( e.g. Ini- tiateurs , Développeurs , Contributeurs ). L’ajout des adresses mails à ce fichier est sujet à caution (risque de spam).
— README.md : Description générale du projet, comprenant : — Une description rapide (en quelques lignes/paragraphes), avec indication du type de licence et l’origine du projet — Une description des grandes fonctionnalités — Un paragraphe sur la manière de tester le projet (installation, docker, . . .) — Les liens importants (papiers, documentation, projets annexes)Lou MorrietLou Morriethttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/8Add INSTALL.rst2019-07-17T19:52:11+02:00Lou MorrietAdd INSTALL.rstINSTALL.md : Description de l’installation complète du projet et de ses dépendances, avec des commandes prêtes à être copiées/collées. Le fichier a généralement une section par système d’ex-ploitation, si c’est nécessaire.INSTALL.md : Description de l’installation complète du projet et de ses dépendances, avec des commandes prêtes à être copiées/collées. Le fichier a généralement une section par système d’ex-ploitation, si c’est nécessaire.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/9Prepare and add CONTRIBUTING.rst and2019-07-17T19:51:21+02:00Lou MorrietPrepare and add CONTRIBUTING.rst andCONTRIBUTING.md : Définition des règles de contributions, comprenant notamment :
— Quelles sont les contributions pouvant être acceptées et celles devant faire l’objet d’un projet à part
— Qui contacter (adresses mail ou URL pour crée...CONTRIBUTING.md : Définition des règles de contributions, comprenant notamment :
— Quelles sont les contributions pouvant être acceptées et celles devant faire l’objet d’un projet à part
— Qui contacter (adresses mail ou URL pour créer un ticket) — Un rappel sur le fait que les contributions doivent être soumises à la même licence que le projet
— Une description des règles de formatage et des outils utilisés
— Une indication claire concernant l’obligation ou non de fournir des tests unitaires avec chaque
contribution.
— Une description rapide du système de prise de décision du projet. Ceci permettra à un contribu-
teur de savoir pourquoi sa contribution a été refusée.
CODE_OF_CONDUCT.md
(optionnel) : Définition des règles et usages de la communauté, aussi
bien dans le code que dans les discussions, en ligne ou lors de réunions/conférences, . . . Ce fichier
est de plus en plus présent dans les projets et leur sert de support de décision lorsqu’un membre doit
être exclu suite à un comportement inapproprié répétéhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/10unit tests2018-11-14T17:25:45+01:00EXT Hodencqunit testsDefining the various unit tests for the OMEGALPES modules when the code is modified or when external contributions are added. The package coverage should be installed.
Afin d’éviter toute régression lors de modifications du code, mais a...Defining the various unit tests for the OMEGALPES modules when the code is modified or when external contributions are added. The package coverage should be installed.
Afin d’éviter toute régression lors de modifications du code, mais aussi lors de l’intégration de contri- butions, il est nécessaire d’avoir une base de tests unitaires couvrant la majorité des cas d’usage du code source. Dans la structure du projet, les tests sont généralement placés dans un package Python à part, dans un dossier frère de celui du projet, au même niveau que la documentation. Les tests sont déclarés dans des modules Python, chacun pouvant contenir un ou une plusieurs jeux de tests, i.e. une classe héritant de unittest.TestCase 7 . Ces classes contiennent des tests, i.e. des méthodes dont le nom commence par test_ . Les tests peuvent être exécutés : — en ligne de commande avec py.test ou nose . Chacun doit être installé à l’aide de pip . — avec PyCharm, qui détecte les tests automatiquement et peut les exécuter à l’aide de py.text ou nose , selon leur disponibilité. Il est recommandé d’installer le paquet Python coverage , permettant de calculer la couverture de code des tests unitaires. Si ce paquet est installé, PyCharm est capable d’afficher directement la couverture des tests sur chaque fichier du projet.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/11setup.py2019-07-17T19:53:42+02:00Lou Morrietsetup.pyDo the setup.py
Une fois que la structure de projet standard aura été respectée, il sera possible d’ajouter le fichier setup.py 3 . Ce fichier définit la description du paquet qui sera transmis au Python Package Index 4 e...Do the setup.py
Une fois que la structure de projet standard aura été respectée, il sera possible d’ajouter le fichier setup.py 3 . Ce fichier définit la description du paquet qui sera transmis au Python Package Index 4 et devra être appelé directement pour généré les binaires diffusables.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/13Examples improvements2018-10-24T14:22:14+02:00EXT HodencqExamples improvementsImproving the examples, and especially the system operation dataImproving the examples, and especially the system operation dataCamille PajotCamille Pajothttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/14Documentation review2019-07-17T19:50:33+02:00Lou MorrietDocumentation reviewLa dernière étape avant la première diffusion du projet est la revue complète de la documentation. Il est absolument nécessaire de s’assurer qu’elle respecte les règles suivantes : — l’installation du projet et de ses dépendances doit ê...La dernière étape avant la première diffusion du projet est la revue complète de la documentation. Il est absolument nécessaire de s’assurer qu’elle respecte les règles suivantes : — l’installation du projet et de ses dépendances doit être décrites pour tous les environnements suppor- tés. Les commandes indiquées doivent être testées par copier/coller (comme le feront les lecteurs) — les concepts ne doivent pas être utilisés sans avoir été définis précédemment — les exemples de code sources doivent être testés et associés à la sortie attendue (résultats affichés, . . .) — la documentation automatique des modules/classes/méthodes doit être vérifiée régulièrement.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/15Storage units upper and lower bound definitions2018-10-24T14:23:28+02:00EXT HodencqStorage units upper and lower bound definitionsIn storage units line 67, the upper and lower bounds of the SOC are respectively defined as soc_min*capacity and soc_max*capacity. Generally speaking the user will define the capacity, but when the objective is to minimize the capacity (...In storage units line 67, the upper and lower bounds of the SOC are respectively defined as soc_min*capacity and soc_max*capacity. Generally speaking the user will define the capacity, but when the objective is to minimize the capacity (such as in the storage_design example), the capacity remains None, and so these upper and lower bounds of the SOC cannot be defined.
An alternative upper and lower bound version should be coded for the SOC.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/16Create templates for issues2019-03-14T10:47:41+01:00EXT HodencqCreate templates for issuesSee https://gricad-gitlab.univ-grenoble-alpes.fr/help/user/project/description_templates, and especially the example down of the page.See https://gricad-gitlab.univ-grenoble-alpes.fr/help/user/project/description_templates, and especially the example down of the page.EXT HodencqEXT Hodencq2018-12-21https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/17Plots : plotting both node_energetic_flows and quantities2018-10-24T14:24:30+02:00EXT HodencqPlots : plotting both node_energetic_flows and quantitiesAt the moment, you can't use both plot_node_energetic_flows AND plot_quantity, because for this last function, you need to define figures, axes and legend, and to do a plt.legend=legend1, whereas it is all defined in the function for plo...At the moment, you can't use both plot_node_energetic_flows AND plot_quantity, because for this last function, you need to define figures, axes and legend, and to do a plt.legend=legend1, whereas it is all defined in the function for plot_node_energetic_flows.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/18Having soc_0 < soc_min for storage units2018-10-24T14:24:42+02:00EXT HodencqHaving soc_0 < soc_min for storage unitsAs the soc_min defines the SOC[t] boundaries, soc_0 cannot be defined as inferior to its value. But in some cases, it should be possible, for instance having soc_0=0, and at the moment the soc[t] goes beyond soc_min, the soc_min boundary...As the soc_min defines the SOC[t] boundaries, soc_0 cannot be defined as inferior to its value. But in some cases, it should be possible, for instance having soc_0=0, and at the moment the soc[t] goes beyond soc_min, the soc_min boundary begins to be taken into account.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/20Selection from date1 to date2 into a CSV file2018-10-24T14:25:33+02:00Camille PajotSelection from date1 to date2 into a CSV fileAdding the possibility to select data into a CSV file, by selecting a date range.Adding the possibility to select data into a CSV file, by selecting a date range.Camille PajotCamille Pajothttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/21Taking into account the different pulp outputs2018-10-24T14:27:12+02:00EXT HodencqTaking into account the different pulp outputsPulp outputs :
OPTIMAL
Optimal solution exists and is found.
Not Solved
Is the default setting before a problem has been solved.
INFEASIBLE
The problem has no feasible solution.
UNBOUNDED
The cost function is unbounded.
UNDEFINED
Fea...Pulp outputs :
OPTIMAL
Optimal solution exists and is found.
Not Solved
Is the default setting before a problem has been solved.
INFEASIBLE
The problem has no feasible solution.
UNBOUNDED
The cost function is unbounded.
UNDEFINED
Feasible solution hasn't been found (but may exist).
This is now being put in the examples.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/22elec_to_heat_ratio <1 case for conversion units2018-11-14T17:23:40+01:00EXT Hodencqelec_to_heat_ratio <1 case for conversion unitsAt the moment, if the elec to heat ratio is a float or an int and has a value below 1, the power flow Dynamic constraint is not considered, only the conversion constraint is :
`self.conversion = DynamicConstraint(
exp_t='{0}...At the moment, if the elec to heat ratio is a float or an int and has a value below 1, the power flow Dynamic constraint is not considered, only the conversion constraint is :
`self.conversion = DynamicConstraint(
exp_t='{0}_p[t] == {1} * {2}_p[t]'.format(
self.heat_production_unit.name,
elec_to_heat_ratio,
self.elec_consumption_unit.name),
t_range='for t in time.I', name='conversion', parent=self)
if elec_to_heat_ratio >= 1:
self.power_flow = DynamicConstraint(
exp_t='{0}_p[t]*(1+{1}) == {2}_p[t] + {3}_p[t]'
.format(self.heat_production_unit.name, losses,
self.heat_consumption_unit.name,
self.elec_consumption_unit.name),
t_range='for t in time.I',
name='power_flow', parent=self)
else:
# TODO
pass`
If this ratio is a list, there is no <1 checking and both constraints are considered.
This should be corrected, taking into account the waste_heat_recovery example (or LNCMI examples) where elec2heat ratio is 0.9 so <1.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/24déplacement du projet2018-11-20T09:03:08+01:00Benoit Delinchantdéplacement du projetIl y a des conséquences au déplacement du projet.
Par exemple il faut mettre à jour les informations d'installation :
pip install git+https://gricad-gitlab.univ-grenoble-alpes.fr/OptimisationQuartier/omegalpes.gitIl y a des conséquences au déplacement du projet.
Par exemple il faut mettre à jour les informations d'installation :
pip install git+https://gricad-gitlab.univ-grenoble-alpes.fr/OptimisationQuartier/omegalpes.gitLou MorrietLou Morriet2018-11-21https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/25Pmin, Pmax, Emax for Fixed ConsumptionUnits and ProductionUnits2019-05-21T09:24:01+02:00EXT HodencqPmin, Pmax, Emax for Fixed ConsumptionUnits and ProductionUnitsThe Pmin and Pmax of Fixed_consumption_unit cannot be chosen, and are automatically set to the default values for Consumption_units, i.e. 1e-5 & 1e+5. So if the fixed consumption is out of the range, the model is infeasible.The Pmin and Pmax of Fixed_consumption_unit cannot be chosen, and are automatically set to the default values for Consumption_units, i.e. 1e-5 & 1e+5. So if the fixed consumption is out of the range, the model is infeasible.EXT HodencqEXT Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/26time-depending self_disch2018-11-20T09:09:18+01:00EXT Hodencqtime-depending self_dischCreation of a time depending self-disch parameter in Storage Units. To be more precise, a self-disch parameter depending on the value of e[t]Creation of a time depending self-disch parameter in Storage Units. To be more precise, a self-disch parameter depending on the value of e[t]EXT HodencqEXT Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/29Setting a quantity ef in storage units2019-02-04T11:28:54+01:00EXT HodencqSetting a quantity ef in storage units### Summary
Setting a quantity ef, the energy in a storage unit at the end of the time horizon. Its value will be the consequence of the last charging and discharging powers applied, the losses and the energy level at the last time step...### Summary
Setting a quantity ef, the energy in a storage unit at the end of the time horizon. Its value will be the consequence of the last charging and discharging powers applied, the losses and the energy level at the last time step. This very energy level is not the final energy level because the last power values have not been applied.
### Example
Studying an energy system with a storage unit over a day, i.e. 24 time steps (hours).
e[24]!=e[23] <=> ef!=e[time.I[:-1]] because the time steps go from 0 to 23.EXT HodencqEXT Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/31Time consistency when plotting with dt!=12019-02-04T15:59:38+01:00EXT HodencqTime consistency when plotting with dt!=1<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Bug" label, following this link :
- https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/issues?label_name%...<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Bug" label, following this link :
- https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/issues?label_name%5B%5D=bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
When dt is different from 1 in the time definition, the power values from dict or lists (fixed consumption units and variable production unit for instance) are not plotted in the same way with plot_quantity. The other plotting classes should also be checked.
### Steps to reproduce
With the electrical system operation example, set dt to 1/2 and plot. You can also plot_node_energetic_flows
### What is the current *bug* behavior?
The time axes have different timescales
### What is the expected *correct* behavior?
The time axes should have the same steps.
### Relevant logs and/or screenshots, python output
![image](/uploads/5de297d07e553e5a29df01d78b366dbd/image.png)
### Possible fixes
To correct the relevant plot_classes
### Note : we will only investigate if the tests are passingEXT HodencqEXT Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/34Double print of unit creation2019-11-26T16:18:24+01:00EXT HodencqDouble print of unit creation<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Bug" label, following this link :
- https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/issues?label_name%...<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Bug" label, following this link :
- https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/issues?label_name%5B%5D=bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
The created units have several messages showing they have been created instead of one
### Steps to reproduce
Can be checked in any example
### Possible fixes
The bug may be caused by the multi-inheritances of units
### Note : we will only investigate if the tests are passingCamille PajotCamille Pajothttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/36Problem on the linearization processing - t is not defined2019-04-26T12:37:01+02:00Mathieu BrugeronProblem on the linearization processing - t is not definedDynamic constraint with an assigned list is blocking because of t is not definedDynamic constraint with an assigned list is blocking because of t is not definedLou MorrietLou Morriethttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/37HeatPump not based on ConversionUnit2019-05-17T18:34:50+02:00Lou MorrietHeatPump not based on ConversionUnit### Summary
The HeatPump is not based on the ConversionUnit
### Steps to reproduce
Put a breakpoint on ConversionUnit.__init__(...)
launch the test_wast_heat_recovery() as debug
you will never reach the breakpoint.
### Possible fixes...### Summary
The HeatPump is not based on the ConversionUnit
### Steps to reproduce
Put a breakpoint on ConversionUnit.__init__(...)
launch the test_wast_heat_recovery() as debug
you will never reach the breakpoint.
### Possible fixes
We should switch the following lines, it seems to work....
self.COP = Quantity(name='COP', value=cop, parent=self)
ConversionUnit.__init__(self, time, name,
prod_units=[self.heat_production_unit],
cons_units=[self.heat_consumption_unit,
self.elec_consumption_unit],
operator=operator)Lou MorrietLou Morriethttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/38double inheritage induce two creation information2019-05-21T09:26:02+02:00Lou Morrietdouble inheritage induce two creation information### Summary
creation information "Creating the unit_name." is said twice due to the double inheritage
### Steps to reproduce
launch waste_heat_recovery example
(If you are using an older version of GitLab, this will also determine w...### Summary
creation information "Creating the unit_name." is said twice due to the double inheritage
### Steps to reproduce
launch waste_heat_recovery example
(If you are using an older version of GitLab, this will also determine whether the bug has been fixed in a more recent version)
### What is the current *bug* behavior?
It appears:
Creating the indus_heat_prod.
Creating the indus_heat_prod.
Creating the indus.
Creating the indus.
Creating the dissipation.
Creating the dissipation.
...
### Possible fixes
Need to change something link to double inheritagehttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/40Considering Series for p for FixedEnergyUnits2020-02-12T13:56:01+01:00Lou MorrietConsidering Series for p for FixedEnergyUnits### Summary
OMEGAlpes only considers int / float / list / dict in order to create new quantity.
(see omegalpes.general.optimisation.elements.quantity class)
It does not consider array (dataframe) and so raises a TypeError if an Serie i...### Summary
OMEGAlpes only considers int / float / list / dict in order to create new quantity.
(see omegalpes.general.optimisation.elements.quantity class)
It does not consider array (dataframe) and so raises a TypeError if an Serie is used to create a FixedEnergyUnit : `raise TypeError('Unknown type for argument \'value\'')`
If a serie is considered, the time should be compared to the TimeUnit of the project if possible.
For the moment on can use `df = df['value'].values.tolist()` to convert the dataframe into a list of the values.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/44Conversion & production units are not "reversible" at the moment2020-02-11T17:36:29+01:00Sacha HodencqConversion & production units are not "reversible" at the moment### Summary
In the conversion unit, the energy can only flow in a unique way since the conversion unit is made of one or several consumption and production units, while in some cases it needs to flow in both ways. **Moreover, there is n...### Summary
In the conversion unit, the energy can only flow in a unique way since the conversion unit is made of one or several consumption and production units, while in some cases it needs to flow in both ways. **Moreover, there is no such thing as a reversible production unit at the moment** (unit that can either produce or consume energy, such as an electrical motor).
### Possible fixes
Creating new conversion units doubling units in the sense that any consumption unit will have its associated production unit and vice versa. This way, the conversion unit will be reversible.
*Example :* for a HV/LV electrical transformer, HV production AND consumption units are created and LV production AND consumption unit are created. The HV and LV units are respectively linked to HV and LV node, and the units are linked through typical transformer equations (efficiency for instance).
### Work at the moment
This issue will be investigated in the ONIRI example available on dev_example_sh branch of OMEGAlpes examples.Sacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/47Wrong calculation for power dictionnary in FixedEnergyUnit2020-02-12T13:56:00+01:00Lou MorrietWrong calculation for power dictionnary in FixedEnergyUnit### Summary
OMEGAlpes recognizes if the data power are a list or a dictionnary.
However, the calculations are inaccurate for dictionnaries for e_tot, p_max and p_min.
**Bug1:**
The dictionnaries are not well updated once the optimisatio...### Summary
OMEGAlpes recognizes if the data power are a list or a dictionnary.
However, the calculations are inaccurate for dictionnaries for e_tot, p_max and p_min.
**Bug1:**
The dictionnaries are not well updated once the optimisation is done
**Bug2:**
if p is a dictionnay, sum(p) takes into account the keys and not the values.
### Example Project
```
def main(work_path):
# Creating the unit dedicated to time management
time = TimeUnit(periods=4, dt=1 )
# Creating an empty model
model = OptimisationModel(time=time, name='elec_prod_simple_example')
# Creating the production units - the production profile are unknown
grid_production_a = VariableProductionUnit(time=time,
name='grid_production_A',
energy_type='Electrical)
dwelling_consumption = FixedConsumptionUnit(time, 'dwelling_consumption',
energy_type='Electrical',
p={0: 162.0, 1: 138.0,
2: 91.0, 3: 100})
# Creating the energy nodes and connecting units
elec_node = EnergyNode(time, 'elec_node', energy_type='Electrical')
elec_node.connect_units(dwelling_consumption, grid_production_a)
# Adding the energy node to the model
model.add_nodes(elec_node)
# Optimisation process
model.writeLP(work_path + r'\optim_models\elec_prod_simple_example.lp')
model.solve_and_update() # Run optimization and update values
return model, time, dwelling_consumption, grid_production_a
def print_results():
if LpStatus[MODEL.status] == 'Optimal':
print("\n - - - - - OPTIMIZATION RESULTS - - - - - ")
print('Dwelling consumption = {0} kWh.'.format(
DWELLING_CONSUMPTION.e_tot))
print('Dwelling consumption = {0} kWh.'.format(
DWELLING_CONSUMPTION.p))
print('grid_production A production = {0} kWh'.format(
GRID_PRODUCTION_A.e_tot))
print('grid_production A production = {0} kWh'.format(
GRID_PRODUCTION_A.p))
elif LpStatus[MODEL.status] == 'Infeasible':
print("Sorry, the optimisation problem has no feasible solution !")
elif LpStatus[MODEL.status] == 'Unbounded':
print("The cost function of the optimisation problem is unbounded !")
elif LpStatus[MODEL.status] == 'Undefined':
print("Sorry, a feasible solution has not been found (but may exist). "
"PuLP does not manage to interpret the solver's output, "
"the infeasibility of the MILP problem may have been "
"detected during presolve")
if __name__ == "__main__":
WORK_PATH = os.getcwd()
# *** RUN MAIN ***
MODEL, TIME, DWELLING_CONSUMPTION, GRID_PRODUCTION_A, \
= main(work_path=WORK_PATH)
# *** SHOW RESULTS ***
print_results()
```
### What is the current *bug* behavior?
**Bug1:**
Dwelling consumption = 6.0 kWh.
Dwelling consumption = {0: 3.0, 1: 3.0, 2: 0.0, 3: 0.0} kWh.
**Bug2:**
Infeasible because of the following constraint:
dwelling_consumption_calc_e_tot: dwelling_consumption_e_tot = 491.0
### What is the expected *correct* behavior?
Dwelling consumption = 491.0 kWh.
Dwelling consumption = {0: 162.0, 1: 138.0, 2: 91.0, 3: 100} kWh.
### Possible fixes
**Solving Bug1:**
In model.py, updating dictionnary should be fixed as follow:
```
# If the values are stored in a dictionary
if isinstance(q_val, dict):
if any(i for i in q_opt.values()):
globals()[q_name] = LpVariable.dict(name=q_name,
indexs=q_val.keys(),
lowBound=q_lb, upBound=q_ub,
cat=q_type)
else:
globals()[q_name] = q_val
```
In elements.py, correct
```
elif isinstance(value, dict):
# The value is a dict
** if any(isinstance(n, (int, float)) for n in list(
value.values())):**
# At least one value of the dict is specified
self.opt = {}
# The opt parameter is a dict of False
self.opt.update({i: False for i in list(value.keys())})
```
**Solving Bug2**
in EnergyUnits.py class FixedEnergyUnit
```
if isinstance(p, list):
e_tot = sum(p) * time.DT
p_min = min(p)
p_max = max(p)
elif isinstance(p, dict):
# Checking the length of the dictionary corresponds to the length
# of the time unit
if len(time.DATES) == len(p):
e_tot = sum(p.values()) * time.DT
p_min = min(p.values())
p_max = max(p.values())
```Lou MorrietLou Morriethttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/48Getting data more easily - list and dataframe2020-03-13T14:10:11+01:00Lou MorrietGetting data more easily - list and dataframeIt is quite difficult to know how to get easily the data as it is different if it is an int, a float, a list or a dict.
Solution:
**We created the method: get_value()**
see commit ad2a27efc6edef8288e58d43fa6fe8fd95b90739
return the v...It is quite difficult to know how to get easily the data as it is different if it is an int, a float, a list or a dict.
Solution:
**We created the method: get_value()**
see commit ad2a27efc6edef8288e58d43fa6fe8fd95b90739
return the value of the quantity according the type of the value in order to be able to use it easily in print and plot methods:
int -> int
float -> float
list -> list
dict -> list
**and the method: get_value_with_date() -> to be able to associate data to dates (with framadates)**
return the values of the quantity associated to a date in a dataframe if the values are a list or a dict (only).Lou MorrietLou Morriethttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/49HourlyDynamicConstraint for dt<12020-02-27T16:28:59+01:00Sacha HodencqHourlyDynamicConstraint for dt<1HourlyDynamicConstraint can now only be used for dt=1, i.e. for initial and final time defined as hours. It is for instance used in add_availability. Moreover, HourlyDynamicConstraint are actually Daily Dynamic Constraints: the constrain...HourlyDynamicConstraint can now only be used for dt=1, i.e. for initial and final time defined as hours. It is for instance used in add_availability. Moreover, HourlyDynamicConstraint are actually Daily Dynamic Constraints: the constraint is renewed everyday between the init and final hour.Sacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/52Cycle error in the storage2020-02-28T12:06:56+01:00Lou MorrietCycle error in the storage### Summary
There is a problem when a storage is create with a number of cycle.
Following error:
TypeError: slice indices must be integers or None or have an __index__ method
I think linked with the creation of the following constraint
...### Summary
There is a problem when a storage is create with a number of cycle.
Following error:
TypeError: slice indices must be integers or None or have an __index__ method
I think linked with the creation of the following constraint
Adding constraint : storage_set_cycles , exp = storage_e[t] == storage_e[t+1.0] for t in time.I[:-1.0]
### Steps to reproduce
```
from omegalpes.energy.units.consumption_units import *
from omegalpes.energy.units.production_units import *
from omegalpes.energy.energy_nodes import *
from omegalpes.general.time import *
from omegalpes.general.optimisation.model import *
from omegalpes.general.utils.plots import *
from omegalpes.general.utils.output_data import save_energy_flows
from pulp import LpStatus
def main():
time = TimeUnit(periods=24, dt=1)
storage = StorageUnit(time, name='storage', energy_type='Electrical',
cycles=1)
variable_production = VariableProductionUnit(time, name='variable_production', energy_type='Electrical')
node = EnergyNode(time, name='node', energy_type='Electrical')
node.connect_units(variable_production, storage)
model = OptimisationModel(time, name='optimization_model')
model.add_nodes(node)
model.solve_and_update()
return model, time, storage, variable_production, node
if __name__ == '__main__':
MODEL, TIME, STORAGE, VARIABLE_PRODUCTION, NODE = main()
```
### What is the current *bug* behavior?
Raise an error
TypeError: slice indices must be integers or None or have an __index__ method
But the cycle indicated is an int.
The problem is in the calculation of the cycle
### What is the expected *correct* behavior?
No errorhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/53pmin & pmax instead of p_min & p_max for VariableEnergyUnits parameters2020-03-13T14:09:43+01:00Lou Morrietpmin & pmax instead of p_min & p_max for VariableEnergyUnits parameterspmin & pmax instead of p_min & p_max for EnergyUnits parameters
- SeveralEnergyUnit
- VariableConsumptionUnit
- SeveralConsumptionUnit
- VariableProductionUnit
- SeveralProductionUnit
Changing it into p_min & p_maxpmin & pmax instead of p_min & p_max for EnergyUnits parameters
- SeveralEnergyUnit
- VariableConsumptionUnit
- SeveralConsumptionUnit
- VariableProductionUnit
- SeveralProductionUnit
Changing it into p_min & p_maxLou MorrietLou Morriethttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/55Graphical representation of AssemblyUnits2020-03-18T15:56:14+01:00Sacha HodencqGraphical representation of AssemblyUnitsThe graphical representations of assembly units, i.e. conversion units and reversible units have been discussed on the 31st of January 2020 with the following conclusions (see the attached picture):
1. The historical representation of ...The graphical representations of assembly units, i.e. conversion units and reversible units have been discussed on the 31st of January 2020 with the following conclusions (see the attached picture):
1. The historical representation of conversion units should be kept
2. The production and consumption units in reversible units will not appear as in conversion units but will be represented as single units, like storage units BUT double arrows will indicate the power flows in reversible units.
3. Storage units will eventually inherit from AssemblyUnit. At the moment, there is a single power flow that can go both ways, represented by a single arrow with two heads. Eventually, it will consists in double arrows, just like other assembly units.
4. ReversibleConversionUnits will abide by these rules.
![GraphReprAssembly](/uploads/8d9c533801db61f2447a0603e00750bb/GraphReprAssembly.JPG)
Other ideas for graphical representation were rejected (see the attached picture):
5. Reversible units with detailed production and consumption, which seemed useless to detail and that would make reversible conversion unit to hard to represent.
6. Conversion units with less detailed units, which seem to make things less understandable.
![GraphReprAssemblyRejected](/uploads/1f580ec3e58a0b77254bebfdfe4a11dc/GraphReprAssemblyRejected.JPG)Sacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/56PuLP version changed2020-05-05T10:37:17+02:00Sacha HodencqPuLP version changedPuLP version recently changed and caused the notebooks to get the following error:
`/srv/conda/envs/notebook/lib/python3.7/site-packages/omegalpes/general/optimisation/model.py in <module>`
`27 import time as pytime`
`28`...PuLP version recently changed and caused the notebooks to get the following error:
`/srv/conda/envs/notebook/lib/python3.7/site-packages/omegalpes/general/optimisation/model.py in <module>`
`27 import time as pytime`
`28`
`---> 29 from pulp import LpProblem, LpStatus, LpVariable, lpSum, LpVariableDict`
`30 from pulp.solvers import LpSolver`
`31`
`ImportError: cannot import name 'LpVariableDict' from 'pulp' (/srv/conda/envs/notebook/lib/python3.7/site-packages/pulp/__init__.py)`
The examples requirements for PuLP have been changed to the version == 1.6.10 instead of >=1.6.10 (see commit in OMEGAlpes_examples). The following steps should be followed:
1. Check if LpVariableDict is used in the OMEGAlpes source code. If not, remove it.
2. Update PuLP to its last version in OMEGAlpes and check if everything works properly (tests, examples, ...).
3. Go back to puLP version >=1.6.10 in OMEGAlpes examples.Sacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/60No attribute _external_constraint_list in EnergyNode2020-10-22T14:35:00+02:00Sacha HodencqNo attribute _external_constraint_list in EnergyNode<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Bug" label, following this link :
- https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/issues?label_name%...<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Bug" label, following this link :
- https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/issues?label_name%5B%5D=bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
When running a simple use case (LNCMI notebook), the following error occurs :
```
AttributeError Traceback (most recent call last)
D:\00 - Eco-SESA\02 - Outils\OMEGAlpes\omegalpes_examples\notebooks\python_scripts\NB_LNCMI.py in updateData(click)
292 lncmi_case(elec2heat_ratio=ELEC_TO_HEAT_RATIO, capacity=CAPA_STORAGE,
293 cop_hp=COP,pmax_elec_hp=P_MAX_HP,
--> 294 storage_soc_0=SOC_0_STORAGE, pmin_recovery=PMIN_RECOVERY)
295
296 display(runPlotButton)
D:\00 - Eco-SESA\02 - Outils\OMEGAlpes\omegalpes_examples\notebooks\python_scripts\NB_LNCMI.py in lncmi_case(elec2heat_ratio, capacity, cop_hp, pmax_elec_hp, storage_soc_0, pmin_recovery)
172 heat_node_lncmi.export_min = \
173 ExtDynConstraint(name='pmin_recovery', exp_t=pmin_rec_cst_exp,
--> 174 t_range='for t in time.I', parent=heat_node_lncmi)
175 # OBJECTIVE CREATION
176 # Minimizing the part of the heat load covered by the heat production plant
d:\00 - eco-sesa\02 - outils\omegalpes\dev_omegalpes\omegalpes\general\optimisation\elements.py in __init__(self, exp_t, t_range, name, active, description, parent)
646 ExternalConstraint.__init__(self, exp='', name=name,
647 description=description,
--> 648 active=active, parent=parent)
649 DynamicConstraint.__init__(self, exp_t=exp_t, t_range=t_range,
650 name=name,
d:\00 - eco-sesa\02 - outils\omegalpes\dev_omegalpes\omegalpes\general\optimisation\elements.py in __init__(self, exp, name, description, active, parent)
600 warnings.warn(deprecated_msg, DeprecationWarning)
601
--> 602 self._add_ext_cst_list()
603
604 def _add_ext_cst_list(self):
d:\00 - eco-sesa\02 - outils\omegalpes\dev_omegalpes\omegalpes\general\optimisation\elements.py in _add_ext_cst_list(self)
604 def _add_ext_cst_list(self):
605 if self.parent:
--> 606 if self not in self.parent._external_constraints_list:
607 self.parent._external_constraints_list.append(self)
608 else:
AttributeError: 'EnergyNode' object has no attribute '_external_constraints_list'
```
### Steps to reproduce
Run the Notebook LNCMI in examples/notebooks
### How to fix it?
Inspect the last commits in elements to check the previous version of OMEGAlpes with which it was working properly to understand the bug.
### Note : we will only investigate if the tests are passinghttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/65lpfics - print problem2021-02-03T15:48:31+01:00Mathieu Brugeronlpfics - print problem### Summary
lpfics infesible search function having an error message during the run
!!! pulp version 2.0 !!!
### Steps to reproduce
download the lpfics package and then use the find_infeasible_constraint_set on a infeasible model
as ...### Summary
lpfics infesible search function having an error message during the run
!!! pulp version 2.0 !!!
### Steps to reproduce
download the lpfics package and then use the find_infeasible_constraint_set on a infeasible model
as follows
from lpfics.lpfics import find_infeasible_constraint_set
find_infeasible_constraint_set(optim_model)
### Example Project
Any example project where you create a infeasible data set entry
### What is the current *bug* behavior?
the method isn't working because the LpConstraint object doesn't have any cst attribute
### What is the expected *correct* behavior?
a set of constraint which contains the infeasible constraints should be printed on the pycharm terminal
### Relevant logs and/or screenshots, python output
![image](/uploads/ff96b96e0825bc7312a4200f7f1d466e/image.png)
### Possible fixes
I would say that it's due to a change from the lp creation from pulp, which have modified the attributes od the LpConstraint which doesn't contain the type of Constraint the same way. I'm looking forward a way of solving thisMathieu BrugeronMathieu Brugeronhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/66e_max & e_min and time step consideration2021-02-26T12:06:03+01:00Sacha Hodencqe_max & e_min and time step considerationThe time step is considered twice in e_max and e_min calculation:
- in the e_tot calculation, that is consistent to get an energy value for e_tot from a power values sum : `{0}_e_tot == time.DT * lpSum({0}_p[t] for t in time.I)`
- ...The time step is considered twice in e_max and e_min calculation:
- in the e_tot calculation, that is consistent to get an energy value for e_tot from a power values sum : `{0}_e_tot == time.DT * lpSum({0}_p[t] for t in time.I)`
- in the e_max and e_min : `'time.DT*{0}_e_tot >= {1}'.format(self.name, e_min),`Sacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/67Question pour ajouter nodes2021-10-26T09:57:46+02:00EXT HaichengLINGQuestion pour ajouter nodesBonjour,
J'ai utilisé OMEGalpes pour créer model d'autoconsomation collective(image ci-dessous). J'ai utilisé un boucle for pour créer des nodes et des utité connecté. Mais quand je veux ajouter des nodes, ça ne marche pas d'ajouter les...Bonjour,
J'ai utilisé OMEGalpes pour créer model d'autoconsomation collective(image ci-dessous). J'ai utilisé un boucle for pour créer des nodes et des utité connecté. Mais quand je veux ajouter des nodes, ça ne marche pas d'ajouter les nodes 1 par 1 dans boucle 'for', il faut que j'ajoute tous les nodes en même temps.
Ce que je veux faire est de générer automatiquement le model pour tous les autoconsommation collectif, donc je cherche un moyenne de regrouper les nodes qui est créé dans le boucle 'for'(pour différent opération, le nombre de node est varié) et les ajoute avec add_nodes.
Est-ce que vous saver comment le faire
Merci en avance,
Cordialement
![image](/uploads/7216afd41fb2fab3e6a01c4c0975afda/image.png)Mathieu BrugeronMathieu Brugeronhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/78Import incident when using mybinder2022-04-29T09:51:58+02:00Sacha HodencqImport incident when using mybinderWhen launching mybinder for an OMEGAlpes notebook, an import error often occurs. For instance, when importing LpDictVariable on the [BS2019 PV self-consumption notebook](https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes_ex...When launching mybinder for an OMEGAlpes notebook, an import error often occurs. For instance, when importing LpDictVariable on the [BS2019 PV self-consumption notebook](https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes_examples/-/blob/master/notebooks/article_2019_BS_PV_self_consumption.ipynb)Sacha HodencqSacha Hodencq