Initial fenestration glazing substrate RSxxSub.schema.yaml#2
Initial fenestration glazing substrate RSxxSub.schema.yaml#2JasonGlazer wants to merge 9 commits into
Conversation
| Performance: | ||
| Object Type: "Data Group" | ||
| Data Elements: | ||
| thickness: |
| Description: "The total thickness of the glazing." | ||
| Data Type: "Numeric" | ||
| Units: "m" | ||
| conductivity: |
| Description: "Overall conductivity of the glazing." | ||
| Data Type: "Numeric" | ||
| Units: "W/m-K" | ||
| front_side_infrared_emissivity: |
| Constraints: [">=0.0", "<=1.0"] | ||
| Required: True | ||
| Notes: "Reflectance is the ratio between the irradiance reflected by the sample and the irradiance on the sample." | ||
| back_side_reflectance: |
There was a problem hiding this comment.
Make optional with a note that the default is identical to the front side.
| is_incidence_hemispherical: | ||
| Description: "Indicates that the incidence is hemispherical" | ||
| Data Type: "[Boolean]" | ||
| Notes: "True if light arrives from all directions of the hemisphere on the sample surface. If True incidence_angle_polar and incidence_angle_azimuth should not be populated. If False they are expected to be populated." | ||
| Required: True |
There was a problem hiding this comment.
Suggest removing this since the map can indicate constant properties by only providing data at one angle.
There was a problem hiding this comment.
@nealkruis can you expand a little on how this would be expressed and explained to the vendor? What single angle should be used?
| wavelength_integration: | ||
| Description: "Spectrum over which the integral result was measured or calculated. `ultraviolet`, `visible`, `solar` and `infrared` indicate the range of the wavelengths used for the integral values. Details about the spectrum are provided by the method which has been applied to generate the data set. If neither `ultraviolet`, `visible`, `solar` and `infrared` describe the spectrum correctly, `other` indicates that all information about the spectrum is provided by the applied method. If SPECIFIC_WAVELENGTHS is used then GridVariablesOptical.wavelength is used and should be populated." | ||
| Data Type: "[{WavelengthIntegrationOptions}]" | ||
| Required: True |
There was a problem hiding this comment.
Suggest removing since the map can indicate average properties using large wavelength spans.
There was a problem hiding this comment.
@nealkruis again, I would like to understand this further. How does the vendor define a span in a map?
christoph-maurer
left a comment
There was a problem hiding this comment.
Hi @JasonGlazer , thank you for your two drafts as .schema.json! They made the review much easier for me. Please let me know if you have questions about my comments. Kind regards, Christoph
| LevelOptions: | ||
| Object Type: "Enumeration" | ||
| Enumerators: | ||
| GLAZING_SUBSTRATE: |
There was a problem hiding this comment.
You probably want to use the subtypes of IGSDB from https://igsdb-v2.herokuapp.com/docs/help/whats-changed/type-subtype :
Subtypes for GLAZING Type
| Subtype | Display Name | Legacy Value in IGDB |
|---|---|---|
| MONOLITHIC | Monolithic | 2 |
| LAMINATE | Laminate | 6 |
| INTERLAYER | Interlayer | 7 |
| EMBEDDED_COATING | Embedded coating | -- |
| COATED | Coated glass | 3 |
| COATING | Coating | -- |
| APPLIED_FILM | Applied film | 5 |
| FILM | Film | 4 |
Subtypes for SHADING Type:
| Subtype | Display Name | Legacy Value in CGDB |
|---|---|---|
| VENETIAN_BLIND | Venetian blind | 0 |
| DIFFUSING_SHADE | Diffusing shade | 1 |
| ROLLER_SHADE | Roller shade | 2 |
| WOVEN_SHADE | Woven shade | 3 |
| VERTICAL_LOUVER | Vertical louver | 5 |
| PERFORATED_SCREEN | Perforated screen | 6 |
| CELLULAR_SHADE | Cellular shade | 7 |
| PLEATED_SHADE | Pleated Shade | 7 |
| ROMAN_SHADE | Roman shade | 7 |
| SHADE_MATERIAL | Shade material | -- |
| FRITTED_GLASS | Fritted glass | 4 |
| ACID_ETCHED_GLASS | Acid etched glass | -- |
| SANDBLASTED_GLASS | Sandblasted glass | -- |
| CHROMOGENIC | Chromogenic | -- |
There was a problem hiding this comment.
Thanks, probably a good idea to utilize these existing enumerations
| Required: True | ||
| Constraints: ">=0, <=100" | ||
| Notes: "If is_ra_in_out is False, the Color Rendering Index as it is defined by EN 410 based on CIE 13. 3-1995, Method of Measuring and Specifying Colour RenderingProperties of Light Sources, 1995, ISBN: 9783900734572. It indicates how well colors are rendered after one transmission of the building envelope. For example, how the color of an object inside a building is perceived from within the building. If is_ra_in_out is True, The Color Rendering Index Raout-in is defined by T.E. Kuhn, H.R. Wilson, J. Hanek, M. Santamouris, Ra out-in Color rendering of objects in a daylit room viewed from outdoors, Energy and Buildings 118 (2016) 93�98, https://doi.org/10.1016/j.enbuild.2016.02.019. It indicates how well colors are rendered after two transmissions of the building envelope. For example, how the color of an object inside the building is percived from the outside." | ||
| is_ra_in_out: |
There was a problem hiding this comment.
Do you want to allow only one Color Rendering Index? Why not allow both, the regular for an observer inside and additional for an observer outside of the building?
There was a problem hiding this comment.
The data group "ColorTransmittance" allows for an array of ColorRenderingIndex so more than one is allowed.
|
|
||
| ColorTransmittance: | ||
| Object Type: "Data Group" | ||
| Data Elements: |
There was a problem hiding this comment.
It makes a difference whether the irradiance is isotropic or from a specific direction. It makes also a difference from which direction, especially when shading is included.
There was a problem hiding this comment.
I didn't realize this had an angular dependency, thanks.
|
|
||
| ProductInformation: | ||
| Object Type: "Data Group" | ||
| Data Elements: |
There was a problem hiding this comment.
It should be possible to define the Universally Unique Identifier (UUID) of the component in the product data network buildingenvelopedata.org .
| Units: "-" | ||
| Required: True | ||
| Constraints: [">=0.0", "<=1.0"] | ||
| back_side_infrared_emissivity: |
There was a problem hiding this comment.
Where do you define "front" and "back"? Panes can be installed "flipped".
There was a problem hiding this comment.
I will add a definition for front and back.
| Required: False | ||
| Constraints: [">=0.0", "<=1.0"] | ||
| Notes: "When this data element is missing, the value is assumed to be the same as the front_side_infrared_emissivity." | ||
| is_coated: |
There was a problem hiding this comment.
Is that what you want? Or do you want an option to define that this coated pane consists of a substrate with UUID1 and the coating UUID2?
There was a problem hiding this comment.
I'm trying to allow both the ability to define multiple levels where the film or coating is one level and the glazing substrate is another level or if the properties are only known together allow for the definition of a glazing substrate that includes the film or coating. That is what the Performance data group allows a list of Level data group children.
| Description: "Data group describing optical performance over a range of conditions. A list is provided that corresponds to the lists of wavelength_integration, is_incidence_hemispherical, and is_emergence_hemispherical." | ||
| Data Type: "[{PerformanceMapOptical}]" | ||
| Required: True | ||
| is_incidence_hemispherical: |
There was a problem hiding this comment.
Can you define that on a component level? Sometimes the irradiance is hemispherical, sometimes not. Sometimes the transmittance value for hemispherical irradiance is needed and then the transmittance value for near-normal irradiance.
There was a problem hiding this comment.
I'm not sure I'm following what you are saying but the Performance data group references a list of PerformanceMapOptical so that you can enter just one or as many as needed.
| Notes: "The properties inculde the effect of the coating or film." | ||
| performance_map_optical: | ||
| Description: "Data group describing optical performance over a range of conditions. A list is provided that corresponds to the lists of wavelength_integration, is_incidence_hemispherical, and is_emergence_hemispherical." | ||
| Data Type: "[{PerformanceMapOptical}]" |
There was a problem hiding this comment.
This array will in general contain 6 types of objects because the irradiance and the emergence can be provided as a string like "hemispherical" or bidirectional with two angles and the wavelengths can be integrated or spectrally resolved. This means a software developer who shall use the data needs to understand the differences between between the 6 types, implement them and not confuse them. Why don't exchange the the optical data as BED-JSON which is easy to understand and to parse?
There was a problem hiding this comment.
In general we are trying to stay consistent with the GridVariable and LookUp variable approach that Standard 205 is using for HVAC data. I was trying to keep this simple. I'm not sure what you are saying is confusing, could you please elaborate?
There was a problem hiding this comment.
Sorry, I try to be more explicit.
I recommend to use the structure from opticalData.json with incidence and emergence as GridVariables und results as LookUp variables.
When I imagine to be a developer of a planning software for architects / planners / engineers, then I query a database for optical data and I receive the objects performance_map_optical. The following table gives an overview of the six cases how performance_map_optical can be structured.
| 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|
| string | bidirectional | bidirectional | string | bidirectional | bidirectional |
| integral | integral | integral | wavelength | wavelength | wavelength |
| string | string | bidirectional | string | string | bidirectional |
Each of the cases needs to be processed correctly. If you are familiar with optical data, it is cumbersome to handle the six cases, but it is possible because we understand the relations between the keys. Typically, software developers are not experts for optical details. Then it is very hard to process the performance_map_optical correctly.
The structure of opticalData.json is easy to understand for software developers and it is also easy implement because there are many free high-quality software packages available to parse the data and to process it in the programming language favored by the developer.
| LookupVariablesOptical: | ||
| Object Type: "Lookup Variables" | ||
| Data Elements: | ||
| transmittance: |
There was a problem hiding this comment.
There are components for which front_side_transmittance does not equal back_side_transmittance .
No description provided.