Classification of Emitter in EnergySystem module
Closed this issue · 22 comments
In a first attempt to reorganise hierarchically most of the entities in the Energy System module, the classification of Emitter is somehow unclear. We have so far three "big families" of classes: Conversion, Storage and Distribution. The emitter is however alone and only connected to a Distribution class.
I was wondering, together with Joachim and Romain, whether there could be a way to characterise it a bit better. On one side, it is delivering energy to satisfy an energy demand, but it is not connected to it. On the other side, is it really a device which distributes energy (e.g. heat?), or just the end node of a distribution system?
The general idea is to define a general abstract class _EnergySystem which generalises all Conversion, Distribution and Storage Systems. An UML diagramme, and a new ticket, will be ready issued soon (thx Joachim!).
Dear members of the Energy System team, could you please help?
Thank you for your help!
g
Thanks for picking up that idea!
First of all, defining an emitter is somewhat vague. Technically, it is nothing else than (passive) conversion system or a heat exchanger. A radiator transforms heat to heat of a lower temperature. However, it does not makes sense to model it as a conversion system, because that will confuse everybody and brake our structure. But we could see it as an own specification of the general _EnergySystem. Then we have all four components of a typical system separately, conversion, distribution, storage and emitter.
I see huge advantages having that general _EnergySystem class. We could collect general attributes here and the users gets an idea of the fact, that these subsystems share commonalities. In addition, I would add a relationship to that _EnergySystem class that allows connecting multiple _EnergySystems in a row (with supplies for one direction and is supplied by for the reverse direction, or something similar). Together with consequently distinguishing between Thermal and Power systems and allow for all of them producing or consuming final energy, this looks like a really flexible structure. You could then model heat recovery for all systems (even recover the heat losses of a storage or of an oven, see #129).
I tried to sketch that in an UML, focussing on parts related to that discussion (there are few missing objects that we could connect to _EnergySystem).
Is that somewhat the direction you were thinking of? What are your opinions? Others from the Energy Systems group? I'm not sure if I got all implications of that radical change in the structure.
This flexibility is the structure might greatly support modelling of complex energy systems, e.g. industrial applications as by @kwakuwulf
Hi!
One comment: from your proposal, the FinalEnergy class is be moved to _EnergySystem, as it is common to all subclasses.
You are right, thanks! That simplifies a lot. I quickly updated my "UML"
And it could be even simplier by connecting different _EnergySystem using FinalEnergy, so we maybe don't need that new supplies and is supplied by connection. But for that I would definitely like to have more opinions.
Hi Moritz, Giorgio,
Some ideas looks very nice (I like this _EnergySystem which supply "itself"), but be careful with (too abstract) generalizations.
- For instance, Thermal/Power distinction for all EnergySystem. ConversionSystem will be rather categorized in systems that we've already defined (SolarEnergySystem, HeatPump, Chiller...). What is a "Power Emitter"? Would it be relevanter to subcategorized DistributionSystem in power / steam / liquid (or even dual phase)? And _StorageSystem in power / liquid / ice?
- The relation _EnergySystem <-> FinalEnergy is not the same depending on the system which inherits from _EnergySystem : provides, stores, emits, distributes...
- How should we consider decentralized ConversionSystem (electrical resistance, micro-heatpumps, split-units) ? In ConversionSystem or Emitter? How can we distinguish them clearly (in the definitions)?
-
good question if we need distinguishing between
ThermalandPowerfor all parts, it came up in my mind as a native way seeing theses systems. But you are right, we could skip this level and directly distinguish between power /steam/ liquid / ice. This is related to #124 -
A
PowerEmittercould be a light bulb or aPC. Of course, both system also convert the power to heat, but that's the same for all emitters (radiator transform heat to heat). If we collect them all asConversionSystems, its hard for the user to see the differences. So we need a clear definition, maybe defining emitters as systems that 'transform final energy to used energy'. They should be the last element in a typical row (without heat recovery). -
Do we need this different relations to
FinalEnergyor is one general relationship precise enough? Like our current relationships 'produces', 'consumes', 'is produced by', 'is consumed by'? For me both ways (general or specific) are okay. -
Your last point is a good point, that clearly show the problem distinguishing emitter and conversion systems. I would rather decentralized systems as conversion systems, specifying emitters as last part of a row of systems.
@mlauster
Your 2nd bullet point brings us back to a old discussion : How do we distinguish "ConversionSystem" (or EmitterSystem) of the module "Energy Use and System", from the "Facility" of the module "Occupancy".
We agreed to say that ConversionSystem are only HVAC System (which actively control the room comfort), whereas Facility satisfy primarily other needs that comfort (lighting, working etc...).
Other point: Decentralised HVAC systems (electrical radiators, split unit) all transform final energy to used energy, however I would consider them as ConversionSystem rather than Emitters...
Looking quickly in the BEDES data specification from DOE in USA (https://bedes.lbl.gov/bedes-online/), they separated "Heating" and "Heating Delivery (radiator, air handler, fan coil, micro heat pump etc...). Moreover, they have also a "Air Distribution" that we haven't considered until now (maybe rather in Occupancy/Facility
Anyway, all this should be discussed together, as well as with participants of Occupancy module like @jaykae26, if possible face to face (otherwise by telco)...
@RomainNouvel, you are right, that's a difficult distinguishment. The existing definition is fine for me, as long as the occupancy module allows all specifications we need. E.g. @kwakuwulf had once the question, if we can model heat recovery from lighting systems in shops. There you would need to have FinalEnergy that represents the heat to recover attached to the lighting object. I don't think that's currently possible. Another option is to say that we do not support the modelling of such things and leave it to BIM applications. The same applies for ovens, which you typically model as internal gains. We then do not allow modelling of heat recovery of such systems.
Proposed common attributes of _EnergySystem:
- number
- model
- productAndInstallationDocument
- serviceLife
- yearOfManufacture
In order to support the doscussion of a new Energy Systemj module, I tried to generate an UML model besed on the actual state of discussion. Please let me know whether I understoof everything correctly.
EnergySystem_0_9_0_Proposal.pdf
I vote for that! Thanks, @JoachimBenner for putting that into a structure! I didn't check your proposal in detail so far (and if all elements of the old version have been transferred), but it looks good from what I could assess!
Hi Joachim, I have a problem with the relation between EnergyDemand and _EnergySystem (at least wording). If _EnergySystem is not an EnergyConversaionSystem, the name of the present relation "consumes / isconsumedby" does not fit.
The best would be to have the same relation names as between the FinalEnergy and the different _EnergySystems. Otherwise, I would propose a general provides/isProvidedBy relation (like in CitySim if a remember well @jaykae26 )
For me, the distinction between TotalEnergy and EnergyDamand is not really clear. What are the exact definitions of these two FeatureTypes? I understand that TotalEnergy is that amount of energy that is stored in a specific _StorageSystem, emitted by an Emitter, distributed with an EnergyDistributionSystem or converted by an EnergyConversionSystem. What is, in contrast to this, the EnergyDemand of these components? At the moment, the relation to EnergyDemand is defined in the super class _EnergySystem. Is this appropriate, or do we need specific relations in the derived classes?
@JoachimBenner from my site this already looks good and much more straight forward as EnergySystem module in version 0.8.0.
Concerning EnergyDemand and FinalEnergy I guess this was introduced to account for some kind of energy conversion and efficiency e.g. we can use a HeatPump that uses Electricity as EnergyDemandbut provides HotWater, another example is to use NaturalGasin a Boiler. Another example is CHP where it consumes NaturalGas but provides HotWater and Electricity as FinalEnergy. Also a StorageSystemcan e.g. loaded with Electricity (simple electric heater) or HotWater and stores HoatWater. So the relation seems to be appropiate (also I would say modelling complex systems e.g. with several EnergyConversionSystem, EnergyDistributionSystem and StorageSystem that are connected will get quite complex)
I also have another remark to your new UML. In previous versions the feature EnergyDemand had a relation to CityObject (thus also to`Building, ThermalZones, etc.). I think this would be quite beneficial to include this relation also in 0.9.0.
Do you mean FinalEnergy and EnergyDemand?
According to the Guidelines:
- EnergyDemand is the useful energy required to satisfy the specific end-use -> In the case of the space heating demand for instance, it is the heat provided directly to the room (through emitters like radiators etc)
Concerning the FinalEnergy, the definition of the guideline is not precise enough. A standard definition could be: Form of energy which reaches the final consumer's door following the conversion from primary energy carriers. It corresponds actually to the energy commercialised to the consumer (e.g. gas, electricity...).
However, with this definition, we see that we don't cover all forms of energy, for instance the heat produced by a thermal solar panels, or the heat stored in a tank, or the electricity produced by a CHP (which are neither EnergyDemand nor FinalEnergy).
We need to find a global solution for it. What about a general Energy object instead (which could be called EnergyFlow for instance), defined by an EnergyCarrier and an EnergyAmount, which could be final energy, stored energy, distributed energy, produced energy, wasted energy...
In this case, EnergyDemand would remain unchanged, since it is not linked to an energy carrier but an energy end-use.
- In your example of the heat pump, the Electricity consumed by the Heat pump is not the energy demand but the final energy. energy demand would be the energy provided to the room by the heat pump, to maintain the indoor air temperature at 20°C
- Agree with the forgotten relation (0..*) between EnergyDemand and _EnergyObject which allows to associate an EnergyDemand to an ThermalZone, UsageZone, AbstractBuilding, BuildingUnit etc.
In your example of the heat pump, the Electricity consumed by the Heat pump is not the energy demand but the final energy. energy demand would be the energy provided to the room by the heat pump, to maintain the indoor air temperature at 20°C
In that case the relation consumes and isConsumedBy is in my opinion ambiguous
I agree that relations between EnergyDemand and _CityObject are missing. Up to version 0.8.0, there was only a unilateral relation: _CityObject --> EnergyDemand. In the new proposal, I modelled a bilateral relation, what do you think about this?
I furthermore agree that the relation names consumes / isConsumedBy are not optimal. Taking Romains proposal, I changed them to provides / isProvidedBy.
EnergySystem_0_9_0_Proposal_V2.pdf
@RomainNouvel, if I got you correct, you would like to rename FinalEnergy to EnergyFlow, right? I vote for renaming! What about simply Energy?
Energy might be confused with other names including this term (EnergyDemand, EnergyCarrier, _EnergySystem etc...), don't you think?
EnergyFlow refers to the Energy Flow Chart which corresponds well to the process of multiple transformation of Energy, in ist different forms, for different Energy Needs, that we want to enable in our XML scheme...
Ok, @RomainNouvel, that makes sense. Although, in a technical sense, EnergyFlow is really a flow (e.g. Q_dot), in contrast to Energy, what is an amount of energy. So you can store Energy and you have a current and a maximum EnergyFlow.