OMEGAlpes issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues2019-05-21T09:26:02+02:00https://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/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/35Product Linearization Module2019-04-01T11:34:54+02:00Mathieu BrugeronProduct Linearization ModuleI'm working in a linearization module for OMEGALPES.
Update:
The code is running, but the results aren't coherent in the first tests. I think it's coming from the fact that the widespan of discretisation is too big.
The idea here would ...I'm working in a linearization module for OMEGALPES.
Update:
The code is running, but the results aren't coherent in the first tests. I think it's coming from the fact that the widespan of discretisation is too big.
The idea here would be to try a normalization of the problem in order to reduce the study space for linearization.Mathieu BrugeronMathieu Brugeronhttps://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/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/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 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/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/27Stopping capacity related self_disch when no energy left2018-11-21T14:19:14+01:00EXT HodencqStopping capacity related self_disch when no energy leftThe energy calculation could be rewritten in order for the self_disch (not self_disch_t) to stop when the remaining energy is insufficient. For instance, is self_disch = 1% and e[t]=0.8%, e[t] should be set to 0% at the next time step if...The energy calculation could be rewritten in order for the self_disch (not self_disch_t) to stop when the remaining energy is insufficient. For instance, is self_disch = 1% and e[t]=0.8%, e[t] should be set to 0% at the next time step if the storage was not charged, and remain at this zero value.
At the moment, if no charging power is available AND e[t]<self_disch * capacity + self_disch_t * e[t]+ pd[t] * dt, the model is infeasible.https://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/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/23Integration test example2018-11-14T17:05:49+01:00EXT HodencqIntegration test exampleCreating an example using a large amount of modules and methods with an associated integration test, in order to check the proper operation of the modules.Creating an example using a large amount of modules and methods with an associated integration test, in order to check the proper operation of the modules.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/19New parameters for storage and conversion units2019-05-02T16:45:04+02:00EXT HodencqNew parameters for storage and conversion unitsAdding auto-discharging, charging and discharging efficacities parameters for the storage units, and losses for Elec2Heat conversion units as a percentage of the produced heat. Possibility to make losses a convesion unit attribute. Still...Adding auto-discharging, charging and discharging efficacities parameters for the storage units, and losses for Elec2Heat conversion units as a percentage of the produced heat. Possibility to make losses a convesion unit attribute. Still has to be checked.
Already in the dev_omegalpes_sh repositoryEXT Jaume FitóEXT Jaume Fitó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/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.