OMEGAlpes issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues2021-12-20T15:49:08+01:00https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/77PV_self_consumption.ipynb is not compatible with the master branch2021-12-20T15:49:08+01:00Pierre AttardPV_self_consumption.ipynb is not compatible with the master branch```PV_self_consumption.ipynb``` notebook in examples folder does not run on the master branch.
The first code cell ```from .PV_self_consumption_utils import *``` does not run because ```PV_self_consumption_utils``` does not exist.
The...```PV_self_consumption.ipynb``` notebook in examples folder does not run on the master branch.
The first code cell ```from .PV_self_consumption_utils import *``` does not run because ```PV_self_consumption_utils``` does not exist.
The code cell 4 has a wrong parameter in class constructor ```VariableProductionUnit```. It seems that the paramater is ```p_max``` and not ```pmax```.
I just realized that there is a repo dedicated to examples, maybe that's why the omegAlpes example in the main repo doesn't work !!
Thanks !https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/76Proposed simulation of self-consumption can be ambiguous2021-11-18T11:17:13+01:00Pierre-Thomas Demarspierre-thomas.demars@grenoble-inp.orgProposed simulation of self-consumption can be ambiguousIn the tutorial notebook **To_Modify__PV_self_consumption_eng** which presents the modelling and optimization of an energetic system of an individual house, maximizing the self-consumption is proposed by minimizing the imports from the g...In the tutorial notebook **To_Modify__PV_self_consumption_eng** which presents the modelling and optimization of an energetic system of an individual house, maximizing the self-consumption is proposed by minimizing the imports from the grid ( **imports.minimize_production** ). This is proposed without further explanations.
This issue is about underlining the fact that this restrictions (**imports.minimize_production**) isn't sufficient to really achieve an optimization of self-consumption with respect to the grid. Although this is going to give a great approximation of self-consomption/self-production ratio on the period, this method doesn't give restrictions on the exports behavior. Therefore, this method lead to an anormal use of exports and is not modelling a correct storage when looking at the step to step behavior.
Optimizing the self-consumption should be constructed by two restrictions : one on the imports ( **imports.minimize_production** ) and one on the exports ( **exports.minimize_consumption** ).
To illustrate this difference, here is two cases of a self-consumption optimization for a building with a load, a production and a battery. The first case doesn't include the exports restriction, while the next one includes both restrictions.
![sans_restriction](/uploads/1387416aac97e8f776190324875a5ae6/sans_restriction.JPG)
![avec_restriction](/uploads/7c9045e0e200dd7334721bd3de4bcf99/avec_restriction.JPG)
In green, it is the battery behavior (positive value is charging, negative value is discharging. It is possible to notice that without the restrictions on the exports, the battery is charging and exporting (which is not the optimal behavior) rather than storing the energy to use it when the production is low (which is optimizing the self-consumption).https://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/74API consistency2021-12-20T16:06:17+01:00Pierre-Thomas Demarspierre-thomas.demars@grenoble-inp.orgAPI consistencyWorking with a FixedProductionUnit (pv_prod) and a StorageUnit (battery), I thought that the oriented object programmation of objects would be similar. However, I found that **pv_prod.p.value** gives access to a list of produced power va...Working with a FixedProductionUnit (pv_prod) and a StorageUnit (battery), I thought that the oriented object programmation of objects would be similar. However, I found that **pv_prod.p.value** gives access to a list of produced power values on the period but **battery.p.value** gives access to a dictionnary containing the index of the period as key and the charged/discharged power as values. With the StorageUnit, to access a list of power values, the adequate command is **battery.p.value.values()** .
The question is : could it be possible to achieve an perfect similitude between behaviors of both units ? Furthermore, this problem may exist between other units as well (VariableUnit etc..).https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/73Inconsistency between units W or kW2021-11-18T11:15:51+01:00Pierre-Thomas Demarspierre-thomas.demars@grenoble-inp.orgInconsistency between units W or kWFixedProductionUnit and FixedConsumptionUnit asked to provide profile in Watts.
However, the plot_node_energetic_flows is plotting a graph with kW as y-axis, which lead to a false graph if the above unit recommandation is followed.
My a...FixedProductionUnit and FixedConsumptionUnit asked to provide profile in Watts.
However, the plot_node_energetic_flows is plotting a graph with kW as y-axis, which lead to a false graph if the above unit recommandation is followed.
My advice would be to choose a base unit (kW in my opinion) and work with it everywhere.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/72LPFICS : find_infeasible_constraint_set method doesn't exist2021-12-20T16:18:46+01:00Pierre-Thomas Demarspierre-thomas.demars@grenoble-inp.orgLPFICS : find_infeasible_constraint_set method doesn't exist### Summary
When trying to optimize a model with the method **model.solve_and_update()**, it may be possible that this is infeasible. In this case, an error message is printed and tells the user to use LFPICS to find the reason of the i...### Summary
When trying to optimize a model with the method **model.solve_and_update()**, it may be possible that this is infeasible. In this case, an error message is printed and tells the user to use LFPICS to find the reason of the infeasibility.
However, after downloading and installing the FPCIS, the method **find_infeasible_constraint_set** doesn't exist, neither than all the other methods that the massage is indicating.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/71Argument of Unit (elec, heat, etc...) - Trouble with the type of the argument2021-11-18T11:14:56+01:00Pierre-Thomas Demarspierre-thomas.demars@grenoble-inp.orgArgument of Unit (elec, heat, etc...) - Trouble with the type of the argument### Summary
Some units such as the VariableConsumptionUnit are asking an **energy_type** argument. In the tutorial notebook, this argument is for example set to **elec** or **heat** (without " " around, which means that they are defined...### Summary
Some units such as the VariableConsumptionUnit are asking an **energy_type** argument. In the tutorial notebook, this argument is for example set to **elec** or **heat** (without " " around, which means that they are defined variable and not string). In fact, these arguments are imported from class where for example the variable **elec = str(elec)**
My recommandation would be to ask directly a string as argument, coming from a detailled list available in the documentation. This is more practical than importing the variables.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/70Organization of the Git - Split between tutorial notebooks, unfunctionnal not...2021-11-18T11:14:31+01:00Pierre-Thomas Demarspierre-thomas.demars@grenoble-inp.orgOrganization of the Git - Split between tutorial notebooks, unfunctionnal notebooks and article notebooksFinding the tutorial notebooks could be improve byt dedicating a clear file, which would make them apart from the article notebooks and the other notebooksFinding the tutorial notebooks could be improve byt dedicating a clear file, which would make them apart from the article notebooks and the other notebookshttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/69Interference between zoom and scroll - Graphical interface2021-12-20T16:30:00+01:00Pierre-Thomas Demarspierre-thomas.demars@grenoble-inp.orgInterference between zoom and scroll - Graphical interface
### Summary
When you scroll in the parameters menu of an item of the graphical interface, it is also activating the zoom of the schematic.
### Steps to reproduce
- open the graphical interface
- insert an item
- open the parameters ...
### Summary
When you scroll in the parameters menu of an item of the graphical interface, it is also activating the zoom of the schematic.
### Steps to reproduce
- open the graphical interface
- insert an item
- open the parameters of the item
- scroll in these parameters
- behind the menu, you will see that it is also zooming and dezooming the schematic
### What is the expected *correct* behavior?
The scroll should not have an impact on the zoomhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/68OMEGALPES Version Bug2021-10-20T15:11:59+02:00EXT HaichengLINGOMEGALPES Version Bug
### Summary
J'ai créé un model simple d'OMEGalpes avec un node unique, un unité de énergy shiftable, un unité de énergy non shiftable, un pv production, import de réseau et export de réseau (voir graphe ci-dessous). J'ai essayé de maxi...
### Summary
J'ai créé un model simple d'OMEGalpes avec un node unique, un unité de énergy shiftable, un unité de énergy non shiftable, un pv production, import de réseau et export de réseau (voir graphe ci-dessous). J'ai essayé de maximizer le taux d'autoconsommation de ce système. Pour OMEGALPES 0.3.0, mon model marche bien, mais pour OMEGALPES 0.4.0, la somme de l'énergy shiftable est doublé après l'optimization.
![image](/uploads/ce64671e99010376c44d9b285489ddae/image.png)
### Steps to reproduce
Code ci-dessous pour mon modèle simple.
```
from omegalpes.energy.energy_nodes import EnergyNode
from omegalpes.energy.units.consumption_units import VariableConsumptionUnit, \
FixedConsumptionUnit, \
ShiftableConsumptionUnit
from omegalpes.energy.units.conversion_units import \
ElectricalToThermalConversionUnit
from omegalpes.energy.units.production_units import FixedProductionUnit, \
VariableProductionUnit
from omegalpes.energy.units.storage_units import StorageUnit
from omegalpes.general.optimisation.elements import DynamicConstraint, \
ActorDynamicConstraint
from omegalpes.general.optimisation.model import OptimisationModel
from omegalpes.general.utils.plots import plt, plot_node_energetic_flows
from omegalpes.general.utils.output_data import save_energy_flows
from omegalpes.general.time import TimeUnit
import time as pytime
ticks=pytime.time()
time=TimeUnit(periods=24*2,dt=0.5)
model = OptimisationModel(time=time, name='test1')
shiftable_profil=[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.9539886794999997,15.615420819999999,11.920456660000001,11.686931215000001,6.328051115000001,0.0,0.0,0.0,0.0,0.0,0.0,0.0,4.9798052539999995,2.3410368835,1.198254565,5.09158163,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
non_shiftable_profil=[0.37543609600000005,0.3827568758,0.41772119455,0.41300544539999995,0.37572268635000006,0.45921000115,0.40829399094999996,0.3626934204999999,0.40511711730000005,0.45187492395,0.3541168846,2.0367472584999997,5.593399205000001,3.2283945739999997,1.8756685155000001,5.161145234999999,4.257118335,0.2818472856,0.39048589219999996,0.525636969,0.39893672599999996,0.3304699479,0.35347408525,1.8127138985,19.184854825,9.824261025,2.7618319745,2.8369244629999995,2.8619368235000002,5.112723865,13.10237332,0.422179015,0.50466066,0.3183611662,0.2983260663,0.55899239,0.36345739684999995,0.2980055731,0.41351376185,1.070029914,1.1156348735000001,0.5006441875,0.4488774645,0.3891072421,0.3614403071,0.3448761461,0.38707076985,0.37071801174999996]
pv_production_j1=[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.524,4.07,4.106,8.404,7.148,10.054,9.658,14.5,4.798,8.348,17.664,8.268,6.598,24.48,28.418,22.656,21.186,10.436,6.79,3.64,2.738,3.93,4.062,5.51,0.608,0.124,0.0,0.0,0.0,0.0,0.0,0.0, 0.0]
non_shiftable_consommation=FixedConsumptionUnit(time, 'non_shiftable_consommation', energy_type='Electrical', p=non_shiftable_profil)
shiftable_consommation= ShiftableConsumptionUnit(time, name='shiftable_consommation',
power_values=shiftable_profil,
energy_type='Electrical')
# Create the electrical grid imports as a production
elec_grid_imports = VariableProductionUnit(time, 'elec_grid_imports',
energy_type='Electrical')
# Create the electrical grid exports as a consumption
elec_grid_exports = VariableConsumptionUnit(time, 'elec_grid_exports',
energy_type='Electrical')
PV_prod_j1 = FixedProductionUnit(time, name='PV_prod_j1',energy_type='Electrical', p= pv_production_j1)
imp_exp = DynamicConstraint(name='imp_exp',
exp_t='elec_grid_imports_u[t] + '
'elec_grid_exports_u[t] <= 1.5',
parent=elec_grid_imports)
# Add the constraint to the elec_grid_imports model
setattr(elec_grid_imports, 'imp_exp', imp_exp)
elec_grid_imports.minimize_production()
elec_node = EnergyNode(time, 'elec_node', energy_type='Electrical')
elec_node.connect_units(shiftable_consommation,non_shiftable_consommation,elec_grid_imports,
elec_grid_exports, PV_prod_j1)
model.add_nodes(elec_node)
new_time = pytime.time()
print('duration =', new_time - ticks)
model.solve_and_update()
flows = elec_node.get_flows
profile_table=pd.Series()
for flow in flows:
label = flow.parent.name
parent = flow.parent
# Get the power profiles
if isinstance(flow.value, list):
energy_flow = flow.value
elif isinstance(flow.value, dict):
energy_flow = list(flow.value.values())
energy_flow_data=pd.Series(energy_flow,name=label )
profile_table=pd.concat([profile_table,energy_flow_data],axis=1)
print(sum(profile_table['shiftable_consommation']))
print('*'*20)
print(sum(shiftable_profil))
```
### What is the current *bug* behavior?
Marche bien pour 0.3.0, mais pas pour Omegalpes 0.4.0,la somme de l'énergy shiftable est doubléSacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/64Color code for OMEGAlpes graphic representation2020-12-10T18:41:23+01:00Sacha HodencqColor code for OMEGAlpes graphic representationBefore updating OMEGalpes documentation regarding its graphic documentation with its current version (commit 61c9d79c97450c3929ecbfd2a7776f4c4ac0f491) , some questions and thoughts:
- What color for:
- Gas : green that is more common f...Before updating OMEGalpes documentation regarding its graphic documentation with its current version (commit 61c9d79c97450c3929ecbfd2a7776f4c4ac0f491) , some questions and thoughts:
- What color for:
- Gas : green that is more common for gas instead of the current yellow
- Electriity : blue that is also more standard, but currently for cold
- conversion_unit : black empty rectangle rather than green full one.
- Differentiating hot and cold or keeping thermal energy type. Question of the thermal dissipation units where hot and cold would not be able to mix.Sacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/63get_value() does not take into account the time step when returning a list2020-10-27T22:28:09+01:00Lou Morrietget_value() does not take into account the time step when returning a list### Summary
get_value() of a dataframe does not take into account the time step when returning a list.
So the result could be the double of expected if the time step of the study is 1/2
### Possible fixes
adding a new method or update g...### Summary
get_value() of a dataframe does not take into account the time step when returning a list.
So the result could be the double of expected if the time step of the study is 1/2
### Possible fixes
adding a new method or update get_value considering what is better
At the same time: move get_value() to utils/output_datahttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/62"Ghost" additional energy production whenever a ConversionUnit's outlet is li...2020-10-23T17:08:22+02:00EXT Jaume Fitó"Ghost" additional energy production whenever a ConversionUnit's outlet is linked to more than 1 nodeIt seems that when the production sub-unit of a Conversion Unit is linked directly to more than 1 Energy Node, OMEGAlpes "assumes" that the unit can deliver its maximum power output to **all nodes at the same time**. As a result, the tot...It seems that when the production sub-unit of a Conversion Unit is linked directly to more than 1 Energy Node, OMEGAlpes "assumes" that the unit can deliver its maximum power output to **all nodes at the same time**. As a result, the total energy delivered by the ConversionUnit can be up to X times superior to its actual maximum production, with X being the number of downstream nodes connected to the production sub-unit.
Results plotted for the energy nodes reveal this "ghost" additional production, but otherwise it goes unnoticed by the Conversion Unit. The production sub-unit's "e_tot" respects the Conversion Unit's energy balance, but the aggregated energy received by all downstream nodes connected to the production sub-unit does not. Apparently, OMEGAlpes does not give any Warning for this misformulation. The user can only notice by analyzing the profiles.
I'm aware that the proper way to code it user-level would be to connect the ConversionUnit.production_unit to just 1 Node, which then exports to all target nodes downstream. But anyway, there should be some mechanism to protect users from this issue.
----------
_**Example:**_
![issue_diagram](/uploads/d0a64ea0a1a6370874c7f86febd75947/issue_diagram.png)
_solar_thermal_collectors = ElectricalToThermalConversionUnit(time, name='solar_thermal_collectors', elec_to_therm_ratio=0.7)_
_space_heating_node = EnergyNode(time, name='space_heating_node', energy_type='Thermal')_
_dhw_node = EnergyNode(time, name='dhw_node', energy_type='Thermal')_
_space_heating_node.connect_units(solar_thermal_collectors.thermal_production_unit,
heat_pump_heating.thermal_production_unit,
zac_2_heating, zac_3_heating, hameau_heating)_
_dhw_node.connect_units(thermal_storage, zac_2_dhw, zac_3_dhw,
hameau_dhw, heat_pump_dhw.thermal_production_unit,
solar_thermal_collectors.thermal_production_unit)_
----------
**ElectricalToThermalConversionUnit's inlet and outlet power profiles:**
(It can be seen that the energy balance is respected)
![solar_thermal_panel](/uploads/1e3dc4bf206e7b13da7ab34933ee8d0b/solar_thermal_panel.png)
**Both nodes downstream:**
(At every time step between t = 9 h and t = 16 h the Energy Nodes are receiving from the ElectricalToThermalConversionUnit, in total, twice the maximum energy that that unit can possibly deliver.)
![space_heating_node](/uploads/672d698593a73203ad4206869d7ff293/space_heating_node.png)
![dhw_node](/uploads/28d9e85f40d55d5e8eb0deacc2ccfab8/dhw_node.png)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/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/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/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 Hodencq