Optional property construction for ThermalBoundary

[JoachimBenner]

While developping an interface of the Energy ADE to the commercial Energy Simulation System we are using, we got a problem. Our system needs the material/construction properties and the area of the complete Thermal Boundary (i.e. the area including windows), and directly related with the Thermal Boundary the material properties and areas of the corresponding Openings (windows or doors), The area of Openings is always regarded as difference areas, which need to be subtracted from the total area of the Thermal Boundary.

Because gxXML models openings in a similar way, I expect the other simulation systems implement a similar logics. However, the actual version 0.7.0. of the Energy ADE is not very good suited to represent a hierarcy of Thermal Boundaries and corresponding Openings, because all ThermalComponents are on the same level, regardless whether they represent opaque or transparent parts of the Thermal Boundary.

I therefore propose to allow a Thermal Boundary optionally to be related with a Construction. This would introduce much more flexibility into our data model.

[pgcipriano]

I agree with your proposal.

[RomainNouvel]

Hi Joachim, It is right that EnergyPlus and other energy simulation systems use this hierarchy between opaque walls and openings. However in our case, by trying to relate our new introduced thermal objects and the existing CityGML _Boundary, we've defined (after long discussion) the ThermalBoundary as " the physical relationship between two ThermalZone, or one ThermalZone and the building environment. " while "A ThermalComponent object is a part of the thermal boundary corresponding to a homogeneous construction component". The opaque/transparent character of the ThermalComponent is actually indicated in the AbstractConstruction.

This allows in particular to have fassade with different constructions and insulation levels, and to not distributes the AbstractConstruction at different hierarchical levels

Is a mapping between our actual version of the Energy ADE and GbXml impossible/too difficult, @JoachimBenner ?

[JoachimBenner]

Yes, in the most general case that a ThermalBoundary consists of more than one opaque material and simultaneously has transperent parts, a mapping is impossible. In all cases, it is unnecessarily laborious to detect whether a ThermalComponent represents a window or a opaque part of the facade.

If an EnergyADE concept is not compatible with the needs of existing simulation systems, I think this concept must be adapted, regardless what has been theoretically discussed beforehand.

I do not see any disadvantage when a ThermalBoundary optionally referrs to one Construction. We can explicitly specify that this Construction either represents "avarage" material parameters of the facade part, or models the opaque part of an (except of transparent openings) homogeneous facade part.

Alternitavily, we can introduce a new class ThermalOpening with a 0..n relationship to ThermalComponent.

[RomainNouvel]

Well, this is an important decision to discuss Joachim, which changes our definitions of ThermalBoundary and ThermalComponent. If ThermalComponent is now used only for opening, we have also to adapt the _AbstractConstruction class...

[JoachimBenner]

Yes, in case we define a new class ThermalOpening, it might be useful to distinguish between "opaque construction" and "transparent construction". With my original proposal, I think we do not need any change. For the specification of "avarage" material parameters for a facade, it might be useful also to specify a transparency and a glacingRatio, which in this case refers to whole facade.

[RomainNouvel]

transparency is a parameter ("Transmittance") of the OpticalProperties of the _AbstractConstruction. This parameter wouldn't then be relevant for opaque construction attached to ThermalBoundary. The information about "glazingRatio" is also considered within the parameters "area" of ThermalBoundary and ThermalComponent. If we leave the schema as it is, then Construction in ThermalBoundary and opaque Construction in ThermalComponent would lead to conflict...

I think that if we choose to follow the hierarchisation of gbXML and IDF concerning opaque fassades and openings, then we must reorganize our schema...

[JoachimBenner]

I can live with the necessacity to dig into the Construction object in order to detect whether the component is transparent or not. However, I would like to be able to represent a hierarchy of (at least) one "opaque" construction and an arbitrary number of transparent ones. The easiest way, without major modifications of the model, would be to allow ThermalBoundary an optional reference to a Construction.

[RomainNouvel]

I will try to make a proposition during the next workshop of such a Boundary and Construction Modelling, dear @JoachimBenner and @gioagu .

Some points to clarify before:

• If we add the attribute "construction" to the ThermalBoundary, it might be redundant (or conflictual) with the boundarySurfaceConstruction of ADE:_BoundarySurface, isn't it?
• Same for "ThermalOpening" and _Opening. Each one is holding a "construction".
• However, Could it be useful to define construction for _BoundarySurface and _opening before modelling each ThermalZone of the building (e.g. data collected from municipality or from on-site survey)? If yes, how to tackle this problem? Would a Double relations between _BoundarySurface and ThermalBoundary solve this problem?
• Is the ADE:_Opening necessary, additionally to the "ThermalOpening"? If not, we could delete it and transfer its parameters to "ThermalOpening"...
• Same questions for ADE:_BoundarySurface? Would it be possible (and correct according to CityGML definitions) to attach a Construction Object directly on _BoundarySurface (as _CityObject)?
• The term "ThermalOpening" actually does not fit to the characteristics of the "new ThermalComponent" (-> thermal and optical properties, shadings, group of openings). Actually, only one attribute may refer to the "Opening" nature of this object (openableRatio), while the rest rather relates to its transparent characteristics. Then, why not "TransparentElements", "TransparentComponents" or "TransparentParts"... Other suggestions?

[JoachimBenner]

Hello Romain, here some answers to your points:

if we add the attribute "construction" to the ThermalBoundary, it might be redundant (or conflictual) with the boundarySurfaceConstruction of ADE:_BoundarySurface, isn't it? Same for "ThermalOpening" and _Opening. Each one is holding a "construction".

Yes, in that case Construction might be directly attached to WallSurface, RoofSurface, ... objects, to the corresponding ThermalBoundary objects, or to both. We already have this potential redundancy with openings: Attribute openingConstruction in the extension of _citygml:Opening and energy:construction in ThermalComponent. We should write into the guidelines that in the latter case only one Construction object must be instanciated, which is references (via xlinks) from both the CityGML object and the ADE object.

However, Could it be useful to define construction for _BoundarySurface and _opening before modelling each ThermalZone of the building (e.g. data collected from municipality or from on-site survey)? If yes, how to tackle this problem? Would a Double relations between _BoundarySurface and ThermalBoundary solve this problem?

Sorry, I do not understand this. Construction is an ADE concept, standard CityGML (at least version 2.0) will never have a Construction. If I remember correctly, we had the backward relation from _BoundarySurface to ThermalBoundary in a previous version, but what does it help?

Is the ADE:_Opening necessary, additionally to the "ThermalOpening"? If not, we could delete it and transfer its parameters to "ThermalOpening"...

The ADE extension of Opening supports applications needing additional information on the material and/or the shading of a door or window, but do not use Thermal Zones. Thus, the question is whether such applications exist and (if yes) shall be supported by the Energy ADE.

Same questions for ADE:_BoundarySurface? Would it be possible (and correct according to CityGML definitions) to attach a Construction Object directly on _BoundarySurface (as _CityObject)?

In the actual version, Construction is a feature, but not a "city object" being derived from CityObject. This could be easily changed, but does not make much difference. It is already possible that a BoundarySurface object references a Construction object.

The term "ThermalOpening" actually does not fit to the characteristics of the "new ThermalComponent" (-> thermal and optical properties, shadings, group of openings). Actually, only one attribute may refer to the "Opening" nature of this object (openableRatio), while the rest rather relates to its transparent characteristics. Then, why not "TransparentElements", "TransparentComponents" or "TransparentParts"... Other suggestions?

TransparentComponent surely is a better name

[RomainNouvel]

Outputs of the discussion of the workshop in Ferrara with @gioagu , Volker and @pascal-schetelat:

• "ThermalOpening" fits finally better to the concept that "TransparentComponent, since it should also include Doors.
• ThermalBoundary does not depend on the Building model LoD. Its geometry, and the attribute SurfaceGeometry and area as a consequence, includes the Openings related to it. The attribute "area" could be precised -> "boundaryArea" or "totalArea". The ThermalBoundary Construction refers then to the Area = boundaryArea - area of related Openings.
• Construction should not be an attribute of ADE:_BoundarySurface and _Opening because of redundancy with ThermalBoundary and ThermalOpening. In the data collection phase, Construction information can be directly stored in ThermalBoundary and ThermalOpening, even if the building is not thermally modelled. Later, once Construction will be a CityGML module, it will be attacheable with any _CityObject, but now, let's keep it clear and simple. "ADEElement" _BoundarySurface and _Opening are not useful anymore then.

Here is a schema of the actual proposition:

BuildingPhysics_0.7.3.pdf

Please give your feedbacks asap so that we can include this change in the EnergyADE v0.8

[JoachimBenner]

This issue has been solved with version 0.8.0 and can be closed.