Ladybug solar radiation results don't agree with IES Virtual Environment 2014

Hello Mostapha,

First off, thank you for the awesome open source tool and all the support you’ve rendered!

My question: I have been using Ladybug to calculate solar radiation for a base case window and then the solar radiation reduction with different shading types. Everything seemed to be working great until an engineer compared the values I was getting with the values she calculated (same geometry and weather file (Mountain View, CA) for June 21st all 24 hours) using IES. I’m attaching my grasshopper definition (geometry internalized), the weather file I’m using and an excel file showing the solar radiation values (highlighted) from both IES and Grasshopper. I assume that Ladybug’s calculation process has been vetted and compared to other known procedures/methods, so can anybody shed some (sun) light on what’s going on? The engineer would like to know how the solar radiation is calculated, I assume with radiance, is this correct?

Also, when I set the analysis period on June 21st from 15hr - 16hr and from 16hr - 17hr the Ladybug_Radiation_Analysis component gives the nebulous error message: “1. Solution exception:index out of range: 12”

Thank you in advance,


USA_CA_Mountain.View-Moffett.Field.NAS.745090_TMY3.epw (1.56 MB) (391 KB)
IES and Grasshopper Comparison.xlsx (14.1 KB)

Hi Dustin. Be careful when comparing with IES. IES includes ground reflectance by default, which Ladybug does not. You can uncheck ground reflectance in the settings of IES. Doing this should give you the same result with both IES and Ladybug. Hope this helps.

Thanks for the quick response, Örn. That’s a good suggestion, but the thing that’s weird is that the differences between IES and grasshopper aren’t linear, i.e. over the course of each hour the delta between the two methods varies (see the attached spreadsheet). Either way, I’ll confirm with the engineer that ground reflectance is turned off. Thank you.

I would suggest to use Honeybee (which uses Radiance under the hood) for comparative studies with IES.

Thanks for replying, Mostapha, are you implying that the results from the Ladybug Radiation Analysis component aren’t accurate?

I’m not sure how to set up solar radiation analysis with Honeybee - here’s what I have so far (attached screenshot). Can you tell me which components I’m missing?

Thank you.

Hi Dustin. Accuracy is always relative. Ladybug’s radiation analysis has it’s own limitations as it is mentioned in components description.

This component allows you to calculate the radiation fallin on input _geometry using a sky matrix from the selectSkyMxt component.
This type of radiation study is useful for building surfaces such as windows, where you might be interested in solar heat gain, or solar panels, where you might be interested in the energy that can be collected.
This component is also good for surfaces representing outdoor spaces (such as parks or seating areas) where radiation could affect thermal comfort or vegetation growth.
No reflection of sunlight is included in the radiation analysis with this component and it should therefore be used
neither for interior daylight studies nor for complex geometries nor for surfaces with high a reflectivity.
For these situations where the reflection of light is important, the Honeybee daylight components should be used instead of this one.

You can check example for Grid-based analysis to see how you can run a radiation analysis with Honeybee >



Differences in radiation results are most likely the result of the number of light bounces in the simulation, as Orn and Mostapha mention. Other reasons for difference could be in the sky files that each use. I don’t know what type of sky IES is using but you can get a visualization of the Ladybug radiation sky using the sky dome component (in attached GH file and image below).

You can see the sky used in honeybee radiation studies by using the “watch the sky” component and the “HDR to GIF” component.

If the grid sizes of the analysis are very coarse in one of the cases, this can also cause discrepancies. As Mostapha says, accuracy is always relative and the best tools I find are usually the ones that give you the most control over whether you want high accuracy or fast calculation speed.

The error that you were getting for the radiation study was a bug (albeit a very weird one that only happens when all of your radiation study results are the same value). It has been fixed in the attached file.

-Chris (412 KB)


Thanks for the debugging help.

Which component did you fix? Radiation_analysis or Analysis_period?

Also, can you explain why if I “flip” a surface (change the direction of the normal through the rhino command line) the radiation values change? I was expecting the radiation value to go to zero. That is one side gives a value when exposed to the sun and the value would go to zero when this same side is turned away from the sun due to flipping the surface and it being hidden by context…

Thank you


The bug I fixed was in Ladybug_Ladybug and had to do wit the function that creates the legend for all of the other components that use legends.

When I flip the surface in your file, I get zero radiation:

You must be doing something wrong. Maybe make sure that the surface is flipped in grasshopper instead of Rhino.