Comparative study of radiation E+/H+/Daysim with differing results


Im checking my results using multiple methods so I´ve set up similar simulation on Energy+, Honeybee+ and Honeybee using Daysim. The aim is to check summertime peak radiation hour. As the results do not match I have some questions:

  1. My H+ and Daysim results differ by 14% on all hours of the year, with H+ giving a higher value. Why is this? Have I set up the simulation wrong? See attached file.

  2. The effect of G-value. When selecting a value close to 1, resulsts from hand calculations, Daysim and E+ match up. But as I decrease the value results start to diverge - by a lot (G-vlaue of 0,34 gives 27% lower value of E+). The window construction for E+ is a single pane window in one layer only (EPWindowMat). In H+/Daysim i´m placing points on outside of window and just multiplying the radiation values with G-value, for simulation speed. What trickery of window physics am I getting wrong? Which, if any, method should I trust? Im suspecting that E+ values are too low.

radiation (943.3 KB)

I found another peculiarity, concerning ambient bounces. in the Daysim analysis, I see very low results when using ab -0, while ab - 1 outputs values in line with E+ and hand calcs. There is no shading geometry besides the analysis surface itself. If I remember correctly radiance uses a certain reflectance value for base plane as default (was it as high as 0.4?). With my thinking I should therefore be using ab -0 in order to compare apples to apples/ E+ to Daysim. Then why does ab-0 produce too low results?

HB+ does not get different results when using ab-0 or ab-(whatever). Why?

All of your methods are finite-element approximations of what could be considered a truth simulation. So, an inter-comparison between them, as you are doing, will let you know that the results are deviating from each other. However, they wont tell you which of them is more precise as there is no benchmark.

EnergyPlus, if I not mistaken, traditionally uses radiosity-based split-flux method based on DELight.

Daysim uses the daylight-coefficient method based on Christoph Reinhart’s research from 1999/2000.

Honeybee[+] tweaks Reinharts workflow slightly by considering more accurate sun positions.

Have you tried doing a point-in-time radiation study with Radiance on your model (with gendaylit and not gencumulativeSky)? Within software models, thats probably the closest you’ll get to empirical truth. There have been few others on this forum who’ve done that comparision(although I think they were comparing illuminance and not irradiance).

With regards to the accuracy of EnergyPlus, LBNL recently did a comparative validation using multi-phase methods.

To add a few other comments :

The default Honeybee solar distribution settings are FullInteriorAndExteriorWithReflections so these should be closer to an ab 1 simulation with Radiance (unless you have changed the solar distribution).

Modeling the radiation on the exterior and then just multiplying by the SHGC is not going to give you a close approximation of the SimpleGlazingSystem window material in E+. Remember that SHGC is defined at the total incident solar energy that makes it into the zone from the exterior. This includes the solar that is directly transmitted as well as the solar heat that is absorbed by the glazing and then conducts to the exterior. The simpleGlazingSystem E+ object just takes the input SHGC and decides how this is split between transmitted and conducted solar using a simple model.


First off: I had set the grid based Rad Parameters in H+ wrong - hence the 14% difference between Daysim and H+, and nothing happening as I changed ambient bounces. I was doing some clumsy clicking. (Feature request: It would be nice if the analysis recipe complained about getting a “null” as an input in its rad parameters)

Sarith - good input on doing a point in time for reference. And the links. Once I start putting complicated geometry in front of the window H+ behaves very strangely. I will post about this separately.

Chris - The simpleGlazingSystem is not at all as simple as the name implies. I did not expect that.
Is it your opinion that if I were to calculate the solar heatgain into a room I would need to use this model? E+ is very slow in calculation time with intricate shading geometry and I was really hoping to be able to use Daysim/H+. Has there been any work done in lifting the SimpleGlazingSystem equations to perform something similar, but maybe yet more simplified in GH?

@LudvigNyman ,

Glad that you’ve made some progress. To share my thoughts on the need to use E+, it really comes down to how accurate of a peak loads simulation you need to run. I know that many older HVAC sizing softwares like Trace (truly the Oldsmobile of energy simulation: use simple models to account for peak load solar gain, which are not as sophisticated as E+. They basically just do what you had originally done here, which is multiply the incident solar by the SHGC and then separately compute glass conduction gain using only the air temperature difference between the outdoors and indoors.

Because some of the engineers I work with still like to drive Oldsmobiles, we did a validation of E+ against Trace and the results weren’t drastically different but the Trace methodology overestimated the peak load by a few percent. I imagine this is because, when the sun beats down on an exterior pane of glass, it actually heats up to be warmer than the exterior air so there’s actually some conduction happening from the window to the exterior (instead of the other way around).

So, in summary, the glazing conduction calculation in E+ is more sophisticated and accurate but, if you are ok with being a few percent conservative, the simple method you mentioned at the start of this discussion is fine.

1 Like

I’m interested to know more about this.