I found out when checking the IDF file of a simulation that the EPGlassMat component automatically sets the Back Side Solar Reflectance at Normal Incidence and the Back Side Visible Reflectance at Normal Incidence to 0.
Is there a particular reason for that ?
I’m comparing a base case simulation between a honeybee model and a Design builder model, and after having eliminated most of the potential sources of differences, I came across this difference in the idf files. It seems that Design Builder glass materials are almost always with a back side relectance equals or rougly equals to the front side reflectance. That doesn’t make DB’s way of doing things the right way necesseraly but I was wondering why it was otherwise in HB…
Also, I ran a test simulation for which I modified these backside reflectance values (0.06 and 0.08 for the inner/outer glazing of my double glazing system) and the result was kind of counter intuitive :
When applying a non-null value for these back side reflectance, over all, it was chiller (by 0.1 degree in average) in the test room (unconditionned) than when the values were 0. I was expecting the opposite since having reflectance towards the inside of the zone should tend to increase the solar gains…
The definition of these relfectance from energy plus is pretty poor and I still don’t quite understand there true meaning : https://energyplus.net/sites/all/modules/custom/nrel_custom/pdfs/pdfs_v8.7.0/InputOutputReference.pdf page 158
You raise a good question that probably deserves to be re-visited. I believe that we set the component up that way many years ago because we saw several glass constructions in the OpenStudio library using a back reflectance of 0 and (I think) the only reason why the OpenStudio library creators did that was to make the simulation faster, particularly given that the back reflectance isn’t used at all when there are no interior reflections. Also , as you can see from your test that adding in a back reflectance really doesn’t change the zone-level simulation results nor does it actually have that significant impact on the simulation runtime. So really, it can go either way without much consequence.
Still, in the new honeybee[+] libraries that we are working on now, we are following the convention of setting back reflectance equal to front relfectance by default (with the option to edit them separately in our API). However, we did this more to smooth over coordination between energy model properties and daylight simulation properties and not for any anticipated impact on the energy simulation.
Taken altogether, I would be totally fine switching the honeybee legacy glazing component over to use the same HB[+] convention if that puts people’s mind at ease (just let me know here if that’s something you would prefer).
I will also note, however, that if you are trying to match a glazing construction in the real world, the recommended workflow is to assemble your glazing system in LBNL WINDOW using their international glazing database with all glass materials currently on the market as well as their functionality that allows you to specify the framing systems for the window. Then you can export your glazing system from WINDOW to an IDF format and import it as a honeybee construction using this component. This makes sure that all of the properties of the window glazing system are translated to Honeybee and, ultimately, EnergyPlus (including the detailed framing objects).
Particularly because we have this workflow set up for the people who need accurate results, I am really ok with whatever we decide is best here for the EP glazing material component.
Thanks for your answer. And thanks for the tip about the LBNL WINDOW. Right now I am testing a tool on just a few specific case and making a comparaison with a Design Builder simulation so it’s ok if my windows don’t match perfectly a real world system, as long as I have the same input in the IDF files.
The impact was not so significant indeed, but surprising don’t you think ? Even though I was doing the calculations with a FullExteriorWithReflection solar distribution, I was thinking that the back solar reflectance of the outer glazing of my double glazing system would have a positive impact (even if very small) on solar gains, as it would “trap” inside the air layer some of the reflected solar radiation coming from the inner glazing… but it seemed like it was the opposite…
I think it would be nice to be able specify the back and visible solar reflectance when making a glazing system. In my case it seems to be not so useful given the difference I had in the simulation results, but I’ve spotted some glazing in the DB library with Back side solar/visible reflectance going up to 0.49. Although I haven’t tested the impact on simulation results with these kinds of values.
Ok, I just updated the component to set the back reflectances equal to the front reflectances by default:
And, if you ever want to change the back reflectances to anything other than the default, all that you have to do is edit those same 2 lines inside the component that I edited in that git commit.
Your findings don’t really surprise me much. When you are modeling complex systems over time (like a building energy simulation), one small change can have cascading effect through the system and through time (similar to the butterfly effect where “a buttferfly flaps its wings and a hurricane forms next year”). It could be that the increased reflectance causes the cooling system to run ever more intensely, or that the reflectance affects something else with then affects conduction through surface X. The only thing that would surprise me is if the back reflectance had a significant impact since, like the butterfly effect, butterflies usually aren’t what we blame for hurricanes and a good engine like E+ has built-in mechanisms to ensure these cascading effects don’t get out of hand.
Yeah I see what you mean, basically the change is so small I shouldn’t see a sepcific meaning in it, it could have been the opposite as well as long as it is small.