OMEGAlpes issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues2021-12-20T16:06:17+01:00https://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/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/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)