citygml-energy issueshttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues2022-12-07T15:54:10+01:00https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/176windDirection as WeatherDataTypeValue2022-12-07T15:54:10+01:00Giuseppe PeronatowindDirection as WeatherDataTypeValueWind direction is crucial to calculate Heat Transfer Coefficients for each surface and is normally contained in weather files for Building Performance Simulations. However, this parameter is not part of the Enumeration **WeatherDataTypeV...Wind direction is crucial to calculate Heat Transfer Coefficients for each surface and is normally contained in weather files for Building Performance Simulations. However, this parameter is not part of the Enumeration **WeatherDataTypeValue**.
In my opinion, the arguments against a soilTemperature parameter (see https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/154) do not apply in this case, as the wind direction is a basic parameter in weather stations and does not need a specific model.
I would then propose to extend the Enumeration **WeatherDataTypeValue** with a new item **windDirection**.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/175Missing Inclination and Azimuth attributes for SolarEnergySystems2021-06-17T16:05:04+02:00Giorgio AgugiaroMissing Inclination and Azimuth attributes for SolarEnergySystemsAs of Energy ADE v. 1.0, we can optionally store the geometry of the (solar/PV/...) panels. In that case, azimuth and tilting angles can be derived from geometry. But if we do not have geometry (which sometime happens...), we have no way...As of Energy ADE v. 1.0, we can optionally store the geometry of the (solar/PV/...) panels. In that case, azimuth and tilting angles can be derived from geometry. But if we do not have geometry (which sometime happens...), we have no way to store those attributes.
I'd propose to add them (back) again.
Any comments?https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/174Lack of "equippedWith" association for EnergySystems2021-06-17T15:59:51+02:00Giorgio AgugiaroLack of "equippedWith" association for EnergySystemsAlthough the Energy Systems module may need a major overhaul for the next version (or a drastic simplification?), I noticed that as of now an EnergySystem has a "installedIn" association, but we are missing a rather useful "equippedWith"...Although the Energy Systems module may need a major overhaul for the next version (or a drastic simplification?), I noticed that as of now an EnergySystem has a "installedIn" association, but we are missing a rather useful "equippedWith" association of a _CityObject to an EnergySystem. I fear, this has been "lost" in the process of moving from previous versions to v. 1.0... ;-)
As of now, EnergySystems are written as root elements with an Xlink to the _CityObject they are installed in. But it'd be more reasonable to have them as child elements of the _CityObject they are installed in (e.g. of a building).
Any thoughts?https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/173Use of <gml:targetElement>2021-06-17T15:55:28+02:00Ghost UserUse of <gml:targetElement>The xsd of the Energy ADE v1.0 makes use of the GML element `<gml:targetElement>`. This element is part of the GML 3.2 encoding rule. It does not exist in GML 3.1.1. Was there a specific reason, why you made use of this element, altough ...The xsd of the Energy ADE v1.0 makes use of the GML element `<gml:targetElement>`. This element is part of the GML 3.2 encoding rule. It does not exist in GML 3.1.1. Was there a specific reason, why you made use of this element, altough the xsd of the Energy ADE is based on GML 3.1.1.?
I am asking, because we came across this issue in the Utility Network ADE recently: https://github.com/TatjanaKutzner/CityGML-UtilityNetwork-ADE/issues/12https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/172Provisional removal of the energy source model from the Energy ADE 2.02019-10-28T11:33:32+01:00Alexandru NichersuProvisional removal of the energy source model from the Energy ADE 2.0Dear colleagues,
As concluded at EnergyADE Stuttgart workshop 2019-10-24 we see the need to remove the existing energy source modeling schema before proceeding to the Energy ADE 2.0.
There are many reasons for this, see the slides prese...Dear colleagues,
As concluded at EnergyADE Stuttgart workshop 2019-10-24 we see the need to remove the existing energy source modeling schema before proceeding to the Energy ADE 2.0.
There are many reasons for this, see the slides presented by Joachim at the workshop for more details. Most importantly there are currently no users that have implemented an energy source with the Energy ADE and we (KIT) believe that a new schema, that makes implicit rather than explicit descriptions is required.
A short example is: in a house, we have a gas boiler, a heater and a heating network, implicitly they belong to the same network. This would replace the existing explicit description which we find to be too detailed in the current scope of the ADE (modeling districts, not a single house).
As a conclusion, we will remove it from version 2.0 (which will include all the issue changes) and will work on making a better version to include this in 2.1.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/171Heating and Cooling system availability schedules2019-10-24T16:45:07+02:00Joachim BennerHeating and Cooling system availability schedulesThe *UsageZone* class enables to specify schedules for heating and cooling set-point temperatures. It is implicitly assumed that the corresponding building systems are operating at any time. In practice, building systems may be not avail...The *UsageZone* class enables to specify schedules for heating and cooling set-point temperatures. It is implicitly assumed that the corresponding building systems are operating at any time. In practice, building systems may be not available at specific times of the year (e.g. heating in summer times) or of the day. At the moment, this could only be realized by specifying very low set-point temperatures for heating (or very high temperatures for the cooling system).
In order to decouple system set-point temperatures and system availability, it is proposed to introduce 2 new poptional properties in *UsageZone*:
***heatingAvailabilitySchedule: DailyPatternSchedule[0..1]***
***coolingAvailabilitySchedule: DailyPatternSchedule[0..1]***
In both schedules, there are only the values 0 (not available) and 1 (available).https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/170New Time Series type MonthlyTimeSeries2019-10-24T16:47:42+02:00Joachim BennerNew Time Series type MonthlyTimeSeriesIn the building simulation area, there are quite often monthly averages, and time series consisting of 12 monthly averages for a certain year. In principle, such a time series could be modelled as *IrregularTimeSeries*, but the processin...In the building simulation area, there are quite often monthly averages, and time series consisting of 12 monthly averages for a certain year. In principle, such a time series could be modelled as *IrregularTimeSeries*, but the processing would be much easier if only 12 monthly values and the corresponding year need to be specified.
It is therefore proposed to add a new class **MonthlyTimeSeries**, derived from *IrregularTimeSeries*, for specifying one value for each month of a specific year.![MonthlyTimeSeries](/uploads/74292351c03115ba65ca1103ed318c79/MonthlyTimeSeries.png)https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/169ThermalZone should have isVentilated2019-10-24T15:36:35+02:00Peter RemmenThermalZone should have isVentilatedThe ThermalZone class should have an object, that describes if the thermal zone is ventialted through mechanical ventilation (similar to isHeated, isCooled).
Interesting enough: the UseageZone class already has an attribute "ventilatio...The ThermalZone class should have an object, that describes if the thermal zone is ventialted through mechanical ventilation (similar to isHeated, isCooled).
Interesting enough: the UseageZone class already has an attribute "ventilationSchedule".https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/168How to model multiple Buildings supplied by one EnergyConversionSystem2019-09-09T16:14:51+02:00Peter RemmenHow to model multiple Buildings supplied by one EnergyConversionSystemI want to model multiple buildings that are supplied by one `EnergyConversionSystem`. I only want to model the conversion system and attach a timeseries to the system. I do **not** want to model the `EnergyConversionSystem` . `EnergyFlow...I want to model multiple buildings that are supplied by one `EnergyConversionSystem`. I only want to model the conversion system and attach a timeseries to the system. I do **not** want to model the `EnergyConversionSystem` . `EnergyFlow` or the `EmitterSystem` in detail.
In previous version (I think) there was something like `EnergyConversionSystem.provides` where it was possible to link multiple `CityObject`. I do not see this link anymore.
I tried using `EnergyDemand`, but the link to `CityObject` with `demands` (in German: "verlangt") and `demandedBy` (in German: "wird verlangt von") is **very** confusing. Any ideas how to model that?
Suggestion: A direct link between `EnergyConversionSystem` and `EnergyDemand` (`EnergyDemand -> isProvidedBy -> AbstractEnergyConversionSystem`) would helpful.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/167Possibly rename HeightAboveGround?2019-10-24T14:35:25+02:00Giorgio AgugiaroPossibly rename HeightAboveGround?Looking at the values in the enumeration, there are now indeed some values that might fit better as Height_Below_Ground, e.g. the entry "bottomThermalBoundary" or "bottomOfConstruction"
I wonder whether the overall name heightAboveGroun...Looking at the values in the enumeration, there are now indeed some values that might fit better as Height_Below_Ground, e.g. the entry "bottomThermalBoundary" or "bottomOfConstruction"
I wonder whether the overall name heightAboveGround still holds or we should rename it (or add an equivalent property heightBelowGround to ADE_AbstractBuilding)...
Any comments?https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/166Link SystemOperation to AbstractEnergySystem?2019-09-09T15:34:14+02:00Giorgio AgugiaroLink SystemOperation to AbstractEnergySystem?This is a question for the experts.
So far we have the SystemOperation class tied to AbstractConversionSystem.
It is (my guess) rather for historical reasons, as it was so before we changed the overall structure of the EnergySystem modul...This is a question for the experts.
So far we have the SystemOperation class tied to AbstractConversionSystem.
It is (my guess) rather for historical reasons, as it was so before we changed the overall structure of the EnergySystem module in v. 0.9.
Now, would it not make more sense to move the SystemOperation class one step higher (hence linked to AbstractEnergySystem? I can imagine that also the other systems might have some operation schedules, not only the conversion ones.
@malhotra, what do you think?https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/165Rename AbstractStorageSystem2019-09-09T15:31:43+02:00Giorgio AgugiaroRename AbstractStorageSystemFor naming coherency, I'd propose to rename class AbstractStorageSystem to AbstractEnergyStorageSystem. This would be in line with what we do with distribution and conversion systems.For naming coherency, I'd propose to rename class AbstractStorageSystem to AbstractEnergyStorageSystem. This would be in line with what we do with distribution and conversion systems.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/164Minor changes to Facilities2019-10-24T16:34:20+02:00Giorgio AgugiaroMinor changes to FacilitiesFor design coherency and simmetry, I'd propose to make class Facilities abstract, and to add a subclass GenericFacilities. This would reflect what we do for example in the EnergyConversionSystems.For design coherency and simmetry, I'd propose to make class Facilities abstract, and to add a subclass GenericFacilities. This would reflect what we do for example in the EnergyConversionSystems.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/163Minor renaming (demandedBy)2019-10-28T08:28:19+01:00Giorgio AgugiaroMinor renaming (demandedBy)For naming coherency, I'd propose to rename the role "demandedBy" to "isDemandedBy" (see EnergyDemand class).
This would be then in line with the other names we use between EnergySystems and EnergyFlow.For naming coherency, I'd propose to rename the role "demandedBy" to "isDemandedBy" (see EnergyDemand class).
This would be then in line with the other names we use between EnergySystems and EnergyFlow.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/162Add attributes for File-based TimeSeries2019-10-24T16:53:35+02:00Giorgio AgugiaroAdd attributes for File-based TimeSeriesI was thinking that it might be useful to add one or two fields to the file-based TimeSeries classes, i.e.
is_compressed:Boolean=FALSE
compression_type:CompressionTypeValue[0..1]
CompressionTypeValue could be either an enumeration or a...I was thinking that it might be useful to add one or two fields to the file-based TimeSeries classes, i.e.
is_compressed:Boolean=FALSE
compression_type:CompressionTypeValue[0..1]
CompressionTypeValue could be either an enumeration or a codelist.
The attributes could be added to both classes, or an abstract class _TimeSeriesFile could be created between them and AbstractTimeSeries. In the latter case, other shared existing attributes (uom, file, etc...) could be moved to _TimeSeriesFile.https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/161Redundant attribute stationName in WeatherStation?2019-10-24T17:09:18+02:00Giorgio AgugiaroRedundant attribute stationName in WeatherStation?I may be wrong, but a WeatherStation is derived from a _CityObject, which itself inherits a number of attributes (e.g. id, description AND name).
I think therefore that this attribute could be dropped. Is there a specific reason for not ...I may be wrong, but a WeatherStation is derived from a _CityObject, which itself inherits a number of attributes (e.g. id, description AND name).
I think therefore that this attribute could be dropped. Is there a specific reason for not using the standard gml:name one?https://git.rwth-aachen.de/energyade/citygml-energy/-/issues/160Modelling of multi-pane windows2019-10-24T16:31:28+02:00Joachim BennerModelling of multi-pane windowsIn the Energy ADE 1.0 construction model, optical properties like transmittance or reflectance can only be related with a complete construction, and not with individual layers. Due to this limitation, it is not possible to model the diff...In the Energy ADE 1.0 construction model, optical properties like transmittance or reflectance can only be related with a complete construction, and not with individual layers. Due to this limitation, it is not possible to model the different glass panes and gaps of a multi-pane window **individually**. This is inconsistant with the data model for opaque constructions, and in some cases complicates the usage of existing window data.
It is therefore proposed to enable an optional specification of optical properties on material level by introducing a new class **TransparentSolidMaterial**, derived from SolidMaterial. Furthermore, for representing gaps in multi-pane windows filled with different kinds of gases, an optional attribute **gasType** should be added to the class **Gas**.
![TransparentSolidMaterial](/uploads/a0b54c3b15d3d57dc4a38b1871dcc678/TransparentSolidMaterial.png)Joachim BennerJoachim Bennerhttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/159Multi-zone models2019-10-24T15:25:33+02:00Joachim BennerMulti-zone modelsFor thermal models containing more than one thermal zone, it is essential to know the topological structure of the zones. This especially means that internal thermal boundaries and their relations to the correnponding thermal zones need ...For thermal models containing more than one thermal zone, it is essential to know the topological structure of the zones. This especially means that internal thermal boundaries and their relations to the correnponding thermal zones need to be identified.
Energy ADE 1.0 represent an internal thermal boundary by **one object ThermalBoundary** (with thermalBoundaryType **interiorWall**, **intermediaryFloor**, ...), being related with **two objects ThermalZone**. This sounds good, but in fact is incorrect. In reality, thermal boundaries are **oriented surfaces** bounding the volume of the different thermal zones. The normal convention is that the **orientation** of a thermal boundary- in the Energy ADE either represented by the attributes **azimuth** / **inclination** or by an explicit surface (attribute **surfaceGeometry** ) - points out of the zone volume. In consequence, an **internal thermal boundary cannont be correctly represented by only one ThermalBoundary object**.
In the process of transforming an Energy ADE 1.0 model into a specifc simulation model like EnergyPlus IFD-file, it might principally be possible to correct this unavoidably error and switch the surface orientation for one of the two adjacent zones, but this is very difficult to implement. Therefore, a new concept is proposed to specify the topological structure in multi-zone models:
**Each ThermalBoundary object belongs to exactly one ThermalZone object. In consequence, internal thermal boundaries (and if necessary also internal thermal openings) are represented by two ThermalBoundary / ThermalOpening objects, refering each other by a relation isAdjacentTo of cardinality 0..1**.
![TwoThermalZones](/uploads/8a2e10ff479f292a55f08721ae619382/TwoThermalZones.png)
![MultiZoneModel](/uploads/741ae56a7d2e0a5067dca04cd1e53458/MultiZoneModel.png)Joachim BennerJoachim Bennerhttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/158Revision of dataType OpticalProperties2019-10-24T16:18:32+02:00Joachim BennerRevision of dataType OpticalPropertiesThe dataType OpticalProperties enables to specify reflectance, transmittance and emissivity of a construction, but not the **absorptance**. Especially for opaque materials, simulation systems like EnergyPlus support the specification of ...The dataType OpticalProperties enables to specify reflectance, transmittance and emissivity of a construction, but not the **absorptance**. Especially for opaque materials, simulation systems like EnergyPlus support the specification of this parameter. That due to physical laws the absorptance can principally be calculated on base of reflectance, transmittance and emissivity is totally irrelevant in this context: It is much better to directly specify the needed parameter instaed of three non-needed parameters.
In addition to reflectance, transmittance and emissivity, the dataType OpticalProperties has a parameter glazingRatio, specifying the glazing ratio of a ThermalOpening referencing the Construction. Conceptionally, glazing ration is not an optical property, but a structural parameter of either a Construction or a ThermalOpening.
It is therefore proposed
* to introduce a new dataType **Absorptance**,
* to extend OpticalProperties with a new attribute **absorptance: Absorptance [0..*]**,
* to eliminate the attribute **glazingRatio**.
In which class (Construction or ThermalOpening) the glazingRation shall be specified is open for discussion.
![Absorptance](/uploads/dce7226cf9a3ea76ef3882f5eeb3159f/Absorptance.png)Joachim BennerJoachim Bennerhttps://git.rwth-aachen.de/energyade/citygml-energy/-/issues/157Modelling of Layer and LayerComponent2019-10-24T16:22:33+02:00Joachim BennerModelling of Layer and LayerComponentAn Energy ADE Construction may refer to an ordered list of Layer objects, and a Layer is composed of one or more LayerComponents. In version 1.0, the layer thickness can be specified individually for each LayerComponent. This enables to ...An Energy ADE Construction may refer to an ordered list of Layer objects, and a Layer is composed of one or more LayerComponents. In version 1.0, the layer thickness can be specified individually for each LayerComponent. This enables to specify highly complex constructions (see below), which cannot be processed by existing building energy simulation systems. It is therefore proposed to ransfer the attribute thickness from LayerComponent to Layer.
![ComplexLayerModel](/uploads/3c91320f9856c9d7fb8891dd228b3bc0/ComplexLayerModel.png)
![NewLayerModel](/uploads/ae5259b84ba9f208bdc3bede516e5ed4/NewLayerModel.png)Joachim BennerJoachim Benner