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/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/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/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/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ó