Is LBT 1.4.0 able to model window constructions (EnergyPlus) defined with spectral glazing data (reflectance, transmittance)

IasonBournas · January 14, 2022, 5:45pm

Hi @chris,

Is this possible in LBT 1.4.0 ? Thanks!

chris · January 21, 2022, 6:11pm

No, it’s not supported right now but I have it as something that I eventually plan to implement:

github.com/ladybug-tools/honeybee-energy

Add Support for EnergyWindowMaterialGlazingSpectral

opened 06:09PM - 21 Jan 22 UTC

chriswmackey

new development wish

This should be relatively straightforward to implement. There should be a separa…te class for `EnergyWindowMaterialGlazingSpectral` that is distinct from `EnergyWindowMaterialGlazing` since the two materials have their properties defined in very different ways. I'm saying this because EnergyPlus IDF schema uses the same object for both cases and it makes things more confusing than they have to be. The only challenge with implementing this is that the spectral material should still have properties like `solar_transmittance` so that it can play nicely with the methods on WindowConstruction as well as the methods that translate window constructions to Radiance modifiers. For a first iteration, I think we can just compute a broadband `solar_transmittance` from the spectral data assuming a typical noon time solar spectrum.

I would say that it’s not too far of a priority after this one:

github.com/ladybug-tools/honeybee-energy

Add Frame objects to the WindowConstruction class

opened 04:28PM - 31 May 20 UTC

chriswmackey

new development

This is a feature that most users probably don't need but it will be really help…ful for THERM integration and for the users who care deeply about modeling window U-values as accurately as possible. I just wanted to record how I think this should be implemented. Specifically, I think it should be a property of the WindowConstruction and not a property of a fenestration surface (as it is in E+). This is because the frame performance is often tied to the type of window construction and not to a specific property of a specific window. So, on the GUI end, the user would have something like this: ![image](https://user-images.githubusercontent.com/5567574/83357373-f198ae80-a339-11ea-83fc-4cb33d3fa388.png) And the honeybee-openstudio-gem would take care of assigning the frame object to all Apertures that have the WindowConstruction with the frame.

IasonBournas · January 22, 2022, 7:35am

Thanks for considering this @chris !
I am willing to test this implementation if you want, I can run inter-software validations (e. g. compare LBT with DesignBuilder) for various glazing buildups.
This capability becomes very important when caclulating transmitted solar radiation through IGUs with selective coatings, which are typical nowadays. I have previously compared results between broadband and spectrally defined glasses, and broadband always underestimate transmitted solar significantly. This is why it would be very useful to be able to assign the properties (reflectance, transmittance) with the E+ Optical Data Type=Spectral, not SpectralAverage.

chris · January 24, 2022, 6:31pm

I have found similar differences when comparing the spectral values reported in LBNL WINDOW with what EnergyPlus actually assumes when using spectrally averaged glass properties.

I remember that the difference wasn’t too significant for most cases of double pane windows but I remember one case of a triple-pane assembly with lots of inter-reflections between glass panes where the SHGC was 0.20 using spectral data but only 0.17 when using averaged properties. So I know it makes a difference and you can rest assured that it is on our agenda.

IasonBournas · January 24, 2022, 7:19pm

Thanks! Here in Sweden TGUs are almost always the case, thus the need. Yes, mutliplying spectral transmittance of 2 different coatings (TGU: solar control + low-e) is less straightforward compared to 1 coating and a clear pane (DGU). As a mentioned before, I would gladly beta test this if you want.