OMEGAlpes issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues2019-07-17T19:53:10+02:00https://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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.