OMEGAlpes issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues2020-05-05T10:37:17+02:00https://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/59add a possibility to repeat daily the ShifatbleEnergyUnit2020-05-05T09:56:08+02:00Lou Morrietadd a possibility to repeat daily the ShifatbleEnergyUnitadd a possibility to repeat daily the ShifatbleEnergyUnit
Question:
Should we you panda to simplify the calculation of the dayadd a possibility to repeat daily the ShifatbleEnergyUnit
Question:
Should we you panda to simplify the calculation of the dayLou MorrietLou Morriethttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/58Bug with Shiftable Energy Unit2020-05-05T09:54:20+02:00Lou MorrietBug with Shiftable Energy Unit### Summary
A ShiftableEnergyUnit does not respects the profil given as a parameter.
It considers the maximum of energy it can use, and if mandatory is True, e_min=e_max however, pmin != pmax
### Steps to reproduce
Create a ShiftableP...### Summary
A ShiftableEnergyUnit does not respects the profil given as a parameter.
It considers the maximum of energy it can use, and if mandatory is True, e_min=e_max however, pmin != pmax
### Steps to reproduce
Create a ShiftableProductionUnit with power_value = [1,2,3,4,5,6]
Create a VariableConsumptionUnit
show the power after solving with p.get_value()
### Example Project
[test_daily_shiftable.py](/uploads/336b5eb7b4b0b945a0ec1239a809a070/test_daily_shiftable.py)
### What is the current *bug* behavior?
The power_values given as a parameter is not respected
power_value = [4, 5, 6, 2, 3, 4, 7, 8, 13, 15]
and load.p = [0,0,..., 25,25,25,25,25,2]
### What is the expected *correct* behavior?
and load.p = [0,0,... 4, 5, 6, 2, 3, 4, 7, 8, 13, 15]
### Possible fixes
add to enable that the energy_unit is on during the same time as
indicated in the list power_values :
```
cst_name_len = 'def_len_power_values'
cst_len = DefinitionConstraint(name=cst_name_len,
exp="lpSum({0}_u[t] for t in "
"time.I) == "
"len({"
"1})".format(self.name,
power_profile))
setattr(self, cst_name_len, cst_len)
```Lou MorrietLou Morriethttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/57Good practices for OMEGAlpes' development2020-05-04T11:01:29+02:00Sacha HodencqGood practices for OMEGAlpes' development[This good to read article](https://www-ncbi-nlm-nih-gov/pmc/articles/PMC5480810/ "Good enough practices in scientific computing, Wilson et al., 2017") summarises good practices for Open Source Software development. While many are alread...[This good to read article](https://www-ncbi-nlm-nih-gov/pmc/articles/PMC5480810/ "Good enough practices in scientific computing, Wilson et al., 2017") summarises good practices for Open Source Software development. While many are already checked in OMEGAlpes project, some can be put in place:
- 3e: Make the project citable (3e) by including a CITATION file in the project's home directory
- 4b,c,d,e: src, bin, doc and results directory (see if relevant here)
- 5f Add a file called CHANGELOG.txt to the project's docs subfolder, and make dated notes about changes to the project in this file in reverse chronological order
- And other such as Continuous integration (at the end of the article).https://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/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/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/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/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/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/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/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/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/45e_tot calculation for storage2019-11-27T14:31:33+01:00Sacha Hodencqe_tot calculation for storage<!---
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 e_tot calculation is defined in EnergyUnits as :
`{0}_e_tot == time.DT * lpSum({0}_p[t]for t in time.I`
while p[t] in storage units is calculated as :
`{0}_p[t] == {0}_pc[t] - {0}_pd[t]`
### Steps to reproduce
Opening the storage design example and printing e_tot
`print(STORAGE.e_tot)`
### What is the current *bug* behavior?
The previous command gives a wrong result for e_tot but the right result for the difference between e_ch and e_disch that can be obtained as follow:
`print("sum pcharge", sum(STORAGE.pc.value.values()))
print("sum pdischarge", sum(STORAGE.pd.value.values()))`
### What is the expected *correct* behavior?
e_ch and e_disch should be created and easily accessible, and e_tot also accessible but indicated as the difference between e_ch and e_dischSacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/46Partially fixed / variable energy unit to create2019-11-26T19:55:33+01:00Sacha HodencqPartially fixed / variable energy unit to createAn energy unit with partially fixed load or production could be handy in many cases.
Two ways to do so can be considered :
- A variable energy unit with fixed pmax and pmin for the relevant time steps (easy way)
- A fixed energy unit w...An energy unit with partially fixed load or production could be handy in many cases.
Two ways to do so can be considered :
- A variable energy unit with fixed pmax and pmin for the relevant time steps (easy way)
- A fixed energy unit where only a portion is fixed. To do so, a work on the imposed vlen of p defined in Quantities and on the opt parameter as a list or dict must be lead (sophisticated way).Sacha HodencqSacha 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/33pc_max & pd_max defined as a ratio of the capacity when obj = min_capacity2019-11-25T12:15:52+01:00EXT Hodencqpc_max & pd_max defined as a ratio of the capacity when obj = min_capacity## Description of the new functionality
pc_max & pd_max can be defined by a ratio of the capacity when obj = min_capacity, i.e. pc_max_ratio = 0.5 --> if capa = 20kWh, pc_max = 10kW. pc_max and pd_max have None values because the capacit...## Description of the new functionality
pc_max & pd_max can be defined by a ratio of the capacity when obj = min_capacity, i.e. pc_max_ratio = 0.5 --> if capa = 20kWh, pc_max = 10kW. pc_max and pd_max have None values because the capacity is set to None with this obj.
## Code implementation
pc_max and pd_max set to None BUT if statement in the EnergyUnit inheritance :
`EnergyUnit.__init__(...,p_min=-pd_max if pd_max is not None else -1e5,
p_max=pc_max if pc_max is not None else 1e5,...)`
pc_max and pd_max defined as quantities (as capacity) and used in def_max_discharging and def max_charging
In minimize_capacity:
`
if pd_max_ratio is not None:
def_pd_max = ExternalConstraint(exp='{0}_pd_max == '
'{0}_capacity*{1}'.format(
self.name, pd_max_ratio), name='def_pd_max', parent=self)
setattr(self, 'def_pd_max', def_pd_max)`
## Current behaviour
At the moment, def_max_charging and def_max_discharging are not taken into account.Sacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/28Past states - Edge behaviour of the storage2019-11-25T10:48:10+01:00EXT HodencqPast states - Edge behaviour of the storageSince the energy calculation is made for t+1, wrong discharging or charging power can happen during the last timestep. Static constraints need to be set to prevent this edge behaviour.
The past states management also has to be investigated.Since the energy calculation is made for t+1, wrong discharging or charging power can happen during the last timestep. Static constraints need to be set to prevent this edge behaviour.
The past states management also has to be investigated.Sacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/30Soc min and soc max checks when lists2019-11-25T10:48:03+01:00EXT HodencqSoc min and soc max checks when lists<!---
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
In the storage unit, there are two times the soc_min and soc_max are not properly checked when their type is list :
- line 116 : the elements of a list of soc_min should be below the elements of a list of soc_max OR a float soc_min should be below any element of a list of soc_max OR the elements of a list of soc_min should be below a float soc_max.
- line 238 when e_f is not None and capacity is not None, ValueError should be raised when e_f set out of bounds, when soc_min and soc_max are floats but also when they are one of the two are lists
### Possible fixes
- l 238 : Todo : the checks hereunder, taking into account soc_min and soc_max can be int or float but also lists !
if capacity is not None and (e_f > soc_max * capacity or
e_f < soc_min * capacity):
# the e_f value should be in between :
# [soc_min*capacity; soc_max*capacity]
raise ValueError('e_f should be in the following boundaries '
'[soc_min*capacity; soc_max*capacity] but '
'is {0}'.format(e_f))
else:Sacha HodencqSacha Hodencq