OMEGAlpes issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues2021-11-18T11:17:19+01:00https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/75Self-Consumption informations2021-11-18T11:17:19+01:00Pierre-Thomas Demarspierre-thomas.demars@grenoble-inp.orgSelf-Consumption informationsAs I used Omegalpes on the self-consumption theme, I think it may be interesting and realisable to implement self-consumption indicators. The simple case of a node with one consumption unit connected can easily be investigated, and furth...As I used Omegalpes on the self-consumption theme, I think it may be interesting and realisable to implement self-consumption indicators. The simple case of a node with one consumption unit connected can easily be investigated, and further works on the architecture to implement it with the whole units and possibilities of Omegalpes represent a massive but really interesting work.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/61Alternate operation (i.e. non-simultaneous) of 2 or more Variable units2020-10-22T15:40:22+02:00EXT Jaume FitóAlternate operation (i.e. non-simultaneous) of 2 or more Variable unitsIn some studies, it may be necessary to force 2 or more Variable units to **never** operate simultaneously.
Current OMEGAlpes' tools maybe allow reaching an equivalent scenario by the means of "tricks" such as limiting maximal power ou...In some studies, it may be necessary to force 2 or more Variable units to **never** operate simultaneously.
Current OMEGAlpes' tools maybe allow reaching an equivalent scenario by the means of "tricks" such as limiting maximal power outputs, or dissociating fixed energy profiles, or perhaps through a more complex node structure. Anyway, enabling users to use this feature easily could be worth the effort.
Perhaps a good start would be coding it within AssemblyUnits, and making it activatable through a binary variable ("alternate_operation") which defaults to 0. This way, units meant to not proceed simultaneously can be instantiated within an AssemblyUnit and alternate operation can be switched on and off.Sacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/54Assessment of e_max for units with variable profiles, through an "extremist" ...2020-06-08T15:51:14+02:00EXT Jaume FitóAssessment of e_max for units with variable profiles, through an "extremist" pre-approachCurrently, all instantiations set a default value for e_max. This approach has 2 shortcomings :
1) If the default value is below the actual e_tot needed to solve the optimization, the problem is rendered infeasible.
2) If the default v...Currently, all instantiations set a default value for e_max. This approach has 2 shortcomings :
1) If the default value is below the actual e_tot needed to solve the optimization, the problem is rendered infeasible.
2) If the default value is way above the actual e_tot, the calculation routine may be far less efficient than if e_max was an educated guess.
Users can manually enter values of e_max themselves, but this does not guarantee efficient calculations if the user gives a wrong estimate of e_max. Besides, it makes the definition of the problem a bit less user-friendly.
To solve all these issues, OMEGAlpes could have an internal routine to get an educated guess of e_max for each and every unit with variable profile. The idea is similar to the (already existing) calculation of e_max for Fixed units, but a bit trickier.
Before the actual optimisation, this routine would assume that each variable unit has to take care of the fixed profiles of ALL its counterparts, through ALL possible ways.
In an example with these units:
* TVPU = VariableProductionUnit [Thermal]
* TFCU = FixedConsumptionUnit [Thermal]
* EVPU = VariableProductionUnit [Electrical]
* EFCU = FixedConsumptionUnit [Electrical]
* ETTCU = ElectricalToThermalConversionUnit
* NT = EnergyNode [Thermal]
* NE = EnergyNode [Electrical]
and these connections between units:
* TVPU -> NT -> TFCU
* EVPU -> ETTCU -> NT -> TFCU
* EVPU -> NE -> EFCU
the educated guess for e_max of each variable unit would be:
* e_max_TVPU = e_tot_TVPU_extremist = e_tot_TFCU
* e_max_EVPU = e_tot_EVPU_extremist = e_tot_TFCU / elec_to_therm_ratio_ETTCU + e_tot_EFCU
Of course, the routine can get a lot trickier depending on the case. But it seems worth investigating whether the calculation time for this routine is compensated afterwards thanks to avoiding infeasibility issues and loss of performance due to sub-optimal guesses of e_max.
It can be coded to trigger only if the user does not set an e_max for the unit. That way, users still have the freedom to limit the maximum production/consumption of a unit themselves.Sacha HodencqSacha Hodencqhttps://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/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/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/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/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/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/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/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/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ó