Relation ThermalZone --> UsageZone

[JoachimBenner]

The relation relates from ThermalZone to UsageZone has cardinality 0.., which means that one ThermalZone may be related with multiple UsageZones. Furthermore, the UML model indicates that one UsageZone may be related with more than one ThermalZone. From my point of view, both cardinalities are not useful.

1.) Thermal Zone referencing multiple UsageZones (BLDG_1 in attached example)

A basic feature of a ThermalZone is to be isotherm, which means that heat transfer can only occur via a ThermalBoundary, but not within a ThermalZone. However, if we have two UsageZones with different temperature level within one ThermalZone, there will be heat transfer within the ThermalZone. Thus, a ThermalZone cannot be geometrically separated into different UsageZones. What is the sense to partition the same volumetric part of a building into different UsageZones, how are, for instance, different heating or cooling schedules overlayed?

2.) Two ThermalZones reference the same UsageZone (BLDG_2 in attached example)

For energy simulations, the main purpose of the UsageZone concept is to provide the different ThermalZones with input data like set-point temperatures and internal gains. I can imagine that different ThermalZones can use the same heating, cooling or ventilation schedules, but the UsageZone also has a property internalGains (specifying the total internal losses or gains within this UsageZone), and relations to the building units, occupants and facilities related with the UsageZone. If the UsageZone is related with different ThermalZones, how shall the heat sources and heat sinks be distributed among the ThermalZones? There is no information available for doing this, and therefore the concept is not really useful in practice. ThermalZone-UsageZone.zip

[RomainNouvel]

Thanks for raising this issue Joachim! 1.) In some simplified tools (casaNova, Monthly energy balance workflow of SimStadt), there is the possibility to model some mixed buildings with monozone model. In these cases, the different zones of the building are indicated with their related area (e.g. A theater has "theater scenes: 300m²" and "theater hall: 100 m²"). The boundary usage conditions used for the energy balance are then the weighted average of the single usage zone boundary conditions (e.g. Tset_average = 3/4 * 21°C + 1/4 * 16°C). It is quite approximative indeed, but in the urban context, we often just know the floor area and not the precise geometry of the different building zones.

2.) This issue relates more to detailed building performance simulation. Let's take the example of the storey of a office building, occupied by the company X. We know here the total number of occupants and devices, and then the total average gains. However, to simulate precisely the overheating in the southern rooms, it would be useful to model separately the south-facing and north-facing part of the storey. In this case, we may either: a/ split before the original usage zone (as well as the building unit, occupants and facilities) in 2 usage zones corresponding to the thermal zones, speculating about the uniformity of the intern gain repartition (here a cardinality 1 is enough) b/ relate the two thermal zones to the original usage zone, and then splitting the total intern gains etc. to the different thermal zones (here a cardinality 1..n is necessary)

The case 2.) is maybe not so current in urban energy simulation, moreover 2.b/ would require from the compatible tools, a processing step to split all objects and quantity of the Occupancy module in two (which could lead to 2.3 persons or 0.5 wash-machine!...).

Therefore, here would be proposition related to this issue: set as pre-requirement "1 Usage Zone at less per Thermal Zone", leading to a cardinality 0..1 -> 0..n between Thermal Zone and Usage Zone.

[JoachimBenner]

Hello Romain, some remarks to stimulate the discussion in the whole group

To point 1.)

I understand that SimStadt (and perhaps also other tools) have implemented specific strategies to calculate the "average" homogeneous thermal conditions from multiple, thermally different usage zones.

1. I still think it is conceptually wrong to define (in the guidelines) a ThermalZone as "isotherm" and "... serves as the smallest homogeneous, geometrically defined space unit for building heating/cooling simulations*" and simultaneously divide it into thermally different sub-zones. In my eyes, this is a contradiction.
2. We want to specify a general data model, which is independent from a specific simulation system and which can be uniquely interpreted by any software without additional information. I think, this is not the case at the moment.
3. Your avaraging mechanism only works under specific conditions. In particular, the floor areas - used as weighting factors - must be known. This means that in this case the optional property floorArea must be mandatory. At least, the specific conditions necessary for relating multiple UsageZones with one ThermalZone must be described in the guidelines.

To point 2.)

I cannot see much difiference between 2a and 2b. In both cases, some heuristics is needed to distribute the internal gains among the two ThermalZones. If we follow the principle of a 1:1 relationship between ThermalZone and UsageZone, it becomes transparent in the input data how this splitting has been performed. Otherwise, you leave it to the simulation system how to split the internal gains, and different software tools may use different strategies. From my point of view, one important goal of the ADE development is to define a system independent, neutral interface format for energy simulation systems, supporting the reproducibility of simulation results.

[RomainNouvel]

1.1 - That's right, then we should adapt the definition: "thermal zone is the spatial unit for heating and cooling demand modelling". We could however add in the guidelines: "A thermal zone will be generally defined as an isotherm space, related to a unique set of usage boundary conditions (i.e. unique usage zone). However, a thermal zone may also model a space with a mixed usage (i.e. several usage zone), in which case the usage boundary conditions should be aggregated, respectively averaged. 1.2 - We're presently working on it... 1.3 - in a former version of the Energy ADE, the floorArea was mandatory, before becoming optional. I would also set this attribute as mandatory.

2) I would introduce a 0:1 relationship. First because of modelling reasons: it should be possible to model a thermalzone first, and then later a usage zone (not systematically both together). Then, if a thermalzone is not occupied, instead of setting all boundary condition on null or -50°C (heating schedule), let's just attach no usage zone to it. I agree with you on the point that we should not allow to have several thermal zone for one usage zone.

[gioagu]

So, my little contríbution to the discussion.

I agree that one thermal zone can contain multiple usage zones. In this case, however a) the definition of thermal zone as "container" should be made more clear b) the averaging factor, namely: floorArea, should be compulsory for each existing usage zone.

What is more, I would restrict the usage zones to belong to only one "parent" thermal zone. In this way, we create a simple hierachy, and we just need to define the cardinality from thermal zone to usage zone to 0..n, while in the other way (usage zone to thermal zone) it is just 1.

[JoachimBenner]

Rename relation name: relates --> contains. Cardinality 0..1. Attribute Attribute "floorArea" is mandatoty in case multiple UsageZones are contained in a ThermalZone (guidelines).

[oliviertournaire]

Implemented in latest version of the UML model