Missing Type of ThermalBoundary
Closed this issue · 23 comments
As of now (v. 0.6), a there is a "IntermediaryFloor" type.
However, "IntermediaryCeiling" is missing.
The distinction is needed when, for example, modelling each ThermalZone explicitly by means of surfaceGeometry.
I would add it to the enumeration list for v. 0.7
According to the definition of ThermalBoundary, "In the case where the ThermalBoundary separate two adjacent ThermalZone, corresponding then to an intermediate floor, ceiling, or a shared wall, its geometrical representation coincides with the plan laying at the middle of this construction thickness."
Then having both ThermalBoundaryType IntermediaryCeiling AND IntermediaryFloor would be redundant. We keep then only IntermediaryFloor.
Yes, we are using the same "plane", not necessarily the same geometry.
What about when you need to have geometries oriented in different way?
You can flip and reuse the geometry (via xlinks), but you may want to assign different constructions: one for the floor and one for the ceiling, at least in those cases where you want/must do like this.
Giorgio, the construction is the whole intermediary floor, we do not distinguish between the lineleum of the floor and the BA13 and half of the beton slab of the ceiling...
Why would you like to do so? Do you have an example?
Concerning the orientation, this is the purpose of the ConstructionOrientation class.
In principle, I agree with both of you. We have only one object ThermalBoundary between two ThermalZones on different floors. Whether be characterize this object as "IntermediaryFloor" or "intermediaryCeiling" is not really relevant, but we do not need both.
This ThermalBoundary is related with a Construction, and the order of the different layers in this construction indeed may be a problem. To be totally correct, the two ThermalZones need to to use the layers in different order, but at the moment we have no property to determine this order. The FeatureType ConstructionOrientation does not help here, because the Construction/ConstructionOrientation is related with the ThermalBoundary, not with the ThermalZone. May be we need an additional property (e.g. "constrictionOrientation") for ThermalBoundary.
ConstructionOrientation is related with a CityObject, not necessary with a ThermalBoundary, isn't it?
That is correct, but it does not help in this case. In order to simulate the energy transfer between different ThermalZones, we need to know the physical properties of the ThermalBoundary. It does not make much sense to relate a ThermalZone with one or more Construction or ConstructionOrientation objects.
I mean to define the layerOrder. If ConstructionOrientation is related to a ThermalZone with orientation = true if this ThermalZone faces the first layer of the Construction, and orientation = false if orientation = false if ThermalZone faces the last layer of the Construction, here is all what we want.
The XML example of ConstructionOrientation of the Guidelines presently no show how to use it. We should improve it.
Actually, instead of having this boolean attribute orientation, it would be easier/clearer to have an object ConstructionOrientation with two optional attributes for the ThermalZone facing the first construction layer and the ThermalZone facing the last Construction Layer.
@gioagu : How is it done in EnergyPlus for intermediary floors and partitions ?
Sorry, but this does not work. We can attach a Construction or ConstructionOrientation to any BoundarySurface or to a ThermalBoundary, but it does not make any sense to relate a ThermalZone with Constructions. In most cases, more than one Construction must be related with a ThermalZone (one for the floor / ground plate, one for the ceiling / roof, and at least one for the different walls.In this case, there is no way to specify which Construction is related with which ThermalBoundary.
Each ThermalBoundary has an unique orientation, defined by its surface geometry or by the azimuth/inclination angles. This orientation defines the layer order of a related Construction / OrientedConstruction, which may either be in the surface direction or in the opposite direction (must be defined). If the ThermalZones related with the ThermalBoundary have own (volumetric) geometries, a geometrical analysis can detect whether the ThermalBoundary surface points into the ThermalZone or out the ThermalZone, and by this analysis it can be decided which of the Layers (the first or the last one) is in contact with the ThermalBoundary. In consequence, an additional "orientation" attribute for the ThermalZone is not needed.
Hi Joachim,
Careful, i haven't proposed to link Construction with ThermalZone but ConstructionOrientation with the ThermalZone facing the Construction.
One ThermalBoundary separating two adjacent ThermalZone may be access through one or the other ThermalZone (with relation boundedBy) with contrary ConstructionOrientation in both case (which can't be simply connected to the ThermalBoundary then, but to the ThermalZone from which we "see" it).
Hi Romain,
sorry, I don't understand this. Can you provide an UML diagram for clarification?
Here is a proposition to deal with the construction orientation, which would avoid both making the geometry of the ThermalBoundary mandatory, and using the ConstructionOrientation object:
BuildingPhysics.pdf
The relation "delimits [1..2]{ordered} from ThermalBoundary to ThermalZone allows to define which ThermalZone is considered to be facing the first layer of the Construction attached to the ThermalComponent (for instance: always the first one by convention), and which ThermalZone is considered to be facing the last layer of the same Construction (for instance: always the second one, if existing, by convention).
Then, the construction orientation information would be fully defined within this new ordered relation.
Do you judge this solution applicable, Joachim? Giorgio?
I principally agree with this proposal, but instead of expressing the semantics "Zone Is in contact with first layer" and "Zone is in contact with last layer" by the order of the related objects (which is tötally unusual and thus difficult to understand and implement), I would introduce two relations ("delimitsFirstLayer" and "delimitsLastLayer") of cardinality 0..1 from ThermalBoundary to ThermalZone. A conformance requirement is that at least one of the two relations must be set.
Why not 2 relations. However, I wouldn't introduce explicitly the layers concept in the relation name between ThermalBoundary and ThermalZone, since layers are defined, optionally, in another place of the Schema.
Maybe we can rather speak about "face" or "side" instead of "layer" -> delimitsByFirstFace / delimitsBySecondFace or delimitsByInnerSide / delimitsByOuterSide or delimitsBySideA / delimitsBySideB.
How gbXML have dealt with this case?
Sometimes it is good to look into the documentation, because I found that my koowledge on gbXML in this area was incomplete. In fact, gbXML has quite the same procedure as you propose, Romain, for the references from a ThermalBoundary (in gxXML called Surface) to the relevant ThermalZones (in gbXML called Space: A Surface can relate to either one or two Spaces (vai a spaceId), and the order of these relations determines which layer of the construction is in contact with which Space, Furthermore, the relation has an optional attribute surfaceType, which for interior horizontal surfaces can be used to distinguish between "floor surfaces" and "ceiling surfaces". This was the proposal of Giorgio at the very beginning of the discussion.
gbXML definition of the spaceId
References the ID of a Space that is bounded by this surface. First AdjacentSpaceId entered will determine how the referenced construction layers are ordered with the first construction layer being in contact with the outside or 2nd space listed and the last layer in contact with the first space listed. The outward normal of the surface, as defined by the right hand rule of the coordinates in the planar geometry element, is always pointing away from the first AdjacentSpaceID listed.
gbXML definition of surfaceType
With interior horizontal surfaces, this attribute can distinguish between ceiling and floor surfaces to avoid double-counting of floor areas, etc. If not present, the surface type can be assumed based on the description of the surface type enums. When the surfaceTypeEnum is provided and the surface attributes (i.e. adjacency, tilt angle) do not match the enumeration's description, the enumeration should have precedence.
Shall we adapt the gbXML model for the EnergyADE?
Interesting! Is SurfaceType still necessary in our case? How do you plan to integrate this "relation attribute" in our modell? The easiest and most comprehensive solution should be chosen
The Surface type would be integrated as a DataType with one attribute. Technically, this is no problem, but it makes an EnergyADE instance file a little bit more complex. @gioagu this attribute was your proposal, what do you mean?
After thinking a little bit about the issue, I think to understand the reason for introducing the SurfaceType. A ThermalBoundary between two storeys would be classified as "IntermediaryFloor". For one of the two ThermalZones involved this ThermalBoundary would represent a floor and for the other one a ceiling, but without additional information it is not possible to detect which is the "Floor-Zone" and which is the "Ceiling-Zone". Obviously, at least Energy+ needs this information, and therefore I propose to follow the gbXML model.
What if we include this information in the definition of the ordered relation between ThermalBoudary and ThermalZone. For instance:
"By convention, in the case of a horizontal ThermalBoundary of type intermediaryFloor, the first ThermalZone "delimitsBy" the ThermalBoundary is the zone below the ThermalBoundary, while the second ThermalZone is the one above. If a Construction object with several layers characterizes a ThermalComponent of the ThermalBoundary, its first layer faces the first ThermalZone of the relation "delimitsBy", while the last layer faces the second ThermalZone."
@gioagu : would it be enough from your side?
Following the presentation of @JoachimBenner and Patrick during the EnergyADE and the following discussion, can we state on this issue?
Here is the proposition recap:
- ordered relation "delimitsBy" of cardinality [1..2] from ThermalBoudary to ThermalZone
- Conventions :
1* First Construction Layer is facing outside, last Construction Layer is facing inside (or contrary if ConstructionOrientation is false).
2* Last layer is facing the first ThermalZone and First layer is facing the second ThermalZone of the relation "delimitsBy"
3* For intermediaryFloor, first layer face the thermalZone below while last layer face the ThermalZone above
I agree with this latest proposition.
This would allow to solve the workarounds required in 0.6 for EnergyPlus.
Done
Implemented in latest version of the UML model