No correspondence between Annual Radiation and PVWatts Optimal Orientation


I hope you can help me with this issue.

While analyzing the best tilt and azimuth for PV orientations, I came to notice a big difference in the case I was working on.

Before using the Ladybug Tilt and Orientation component, I had created a way using the radiation analysis, in which I would run an annual radiation over a sphere and took the orientation of the patch of that sphere that had more radiation. It is not the most accurate, but to still have an approximated idea of tilt and azimuth.

Seeing strange values coming out from my method I tested with the ladybug one, and I had good results.

The EPW files that I am using are extracted from AMeDAS data ( converted into EPW file. In this data direct normal and diffuse horizontal radiation are not provided, but it has been derived from the global horizontal that it is provided. Knowing that the error could be in the EPW file itself, I checked then the data that these two method of calculation are using, the gen cumulative sky ([1] D. Robinson and A. Stone, “Irradiation modelling made simple: the cumulative sky approach and its applications,” PLEA - Passiv. Low Energy Archit. Eindhoven, Netherlands, no. September, pp. 19–22, 2004.) and the PVWatts ( And it seems like that both are considering diffuse horizontal and direct normal irradiation for the calculation (perez sky needs).

So if both are considering these two values, how come just the radiance method gives odd results?

Any insight would be helpful.

I tried to upload the files but it tells me that new users cannot upload files.
Let me know if it is possible to upload them.

Thanks! (547.9 KB)
363Tokyo_2010.epw (2.1 MB)
363Tokyo_2000.epw (2.2 MB)

Since you are “new” to the Discourse forum, you are automatically given "trust level 0". At some point (e.g. by reading for 10 minutes), you move on to the next level and you’ll be able to attach files to your posts. [I suppose that people that were moved from the Grasshopper forum should ideally get a higher trust level right away].

That, or an admin elevates you to the next level …

It’s quite possible that you now already have access to that feature.

1 Like

Thanks wim!
already uploaded them

I’m not sure how you set up the run with Honeybee/Radiance but I used Ladybug’s radiation dome component and the results are very similar to PVWatts.

Hi @mostapha!

Thanks for taking a look.
The issue here is that with ladaybug I have understandable results, while when I use honeybee, with gencomulativesky component to run the annual radiation on a sphere, I get quite odd results. Although I use the same EPW, the results I get from ladybug and honeybee are way off.
An educated guess here is that there could be an issue with the gencomulative sky component.
I know that the comulative sky function approximate the position of the sun, but I think here the error is not cause by this.
The file I am working on along with the EPW files are uploaded at the top of the post, if you can have a closer look.

Thanks for the support.
best regards,


Here is the analysis with Honeybee/Radiance. There is a difference between the sky that is generated by Honeybee and the one that is generated by Ladybug. Ladybug uses radiance’s gendaymtx utility which is more recent than gencumulativesky which is used by Honeybee.

I replaced the button with a toggle in the definition. (89.9 KB)

Hi @mostapha,

thanks for analyzing this problem.
I have checked the file you uploaded and indeed the results from ladybug (gendaymtx) are way more reliable that the ones I got from honeybee (gencomulativesky) as also it can been seen from the pic (left honeybee, right ladybug). Is the same problem I got from my study.

now what is interesting me very much is knowing which sky is using the annual daylight simulation component: is it using genskymtx or gencomulativesky?

Also do you think this problem is due to the sky generation or maybe is the EPW?



Here is the summary:

Ladybug cumulative radiation uses gendaymtx.
Honeybee cumulative radiation uses gencumulativesky.
Honeybee annual daylight is using Daysim which is using gencumulative sky.
Honeybee[+] annual daylight is using Radiance and gendaymtx.

Based on this topic the issue can be because of the weather data. Gencumulativesky had a known issue for low sun angle calculation which was fixed while ago but if possible I suggest using gendaymtx. We’re removing all the dependencies to gencumulativesky in the [+] libraries.

Thanks for the clarification @mostapha

Hi Federico, Mostapha,

I can’t contribute much to this as seems like the issue is resolved.
Federico I can only confirm your previous finding: Ladybug Photovoltaics components (based on PVWatts) do use both DNI and DHI.

Hi @mostapha,

I have run some test to see whenever I can spot the source of the error. I run the radiation in ladybug, honeybee, and to check the gencomualtivesky I also run it in DIVA. I test it for both the original tokyo file I provided, and also the one you modified to match the integer numbers as per default, as per this post
The results are shown in the picture below

The deviation in the radiation analysis with gencomulativesky of honeybee legacy it appears to be quite visible.

Based on what I read and what I understood, gencomulative sky and gendaymtx are using the perez sky to generate the sky vault. This means that they both use DNI, DHI plus latitude and longitude.
So, what it differs, and maybe it is here that I am confused, is that while in gencomulativesky the sun position is approximated, in gendaymtx the sun position is exact.
Also something that I could not find is which sky model gencomulativesky and gendaymtx in honeybee-ladybug are usign: Tregenza or Reinhart or else.

If you could clarify this would be fantastic.

Thanks again for the fantastic tool!


They both diffuse the direct sun contribution.

By default Tregenza sky. By my knowledge you can’t change it in gencumulativesky. In gendaymtx you have access to density which can be used to generate skies with higher density (e.g. Reinhart).

Finally I don’t have access to DIVA so I can’t check but doe it use the same version of gencumulativesky? This looks like a bug.

@sarith do you have any inputs on this?

@mostapha I think gendaymtx was implemented before I got involved…are you just adding the time series vectors together and color the patches in Rhino?

Yes. In this case gendaymtx is fine. Any comments about gencumulativesky?

@mostapha @sarith

Thanks for looking into this issue.

It could be possible that in this specific case with these file, there is something that is no working properly.

Because honeybee [+] is still under development and since I am looking for an daylight-energy study, i think that my best option for now would be stick with the legacy version, but I would like to be sure that the results from the daylight analysis are exact.

I will wait for your insight.
Thanks for helping me here and for the development of such amazing tool.

Best regards,


@mostapha @Federico587 I have always wanted to do a side-by-side comparison between gencumulative sky and gendaymtx. However, it will be a while before I can get to this. (Mostapha knows why :slight_smile: !)

Anyway, just on the basis of what is posted here:

  1. The scales appear to be different for DIVA (which is following the Radiance palette) and LB/HB.
  2. Are you sure that you are using the same view definition for both DIVA and HB ? Below are two sky renderings that are entirely same except for an additional “-” in one of the view definitions.

-vth -vp 0 0 0 -vd 0 0 1 -vu 0 1 0 -vh 180 -vv 180 -vo 0 -va 0 -vs 0 -vl 0 -x 800 -y 800

-vth -vp 0 0 0 -vd 0 0 1 -vu 0 -1 0 -vh 180 -vv 180 -vo 0 -va 0 -vs 0 -vl 0 -x 800 -y 800

Daylight analysis is using gencumsky through Daysim and Honeybee’s cumulative sky calculation doesn’t affect the results for daylighting. Give me some time and I will get back to this issue. It’s a quick check between the skies. You can also use watch_the_sky component in Honeybee which renders an image to what @sarith shared in his post.


thanks a lot to have a look at it although you are busy.

In this case what it seems to be the problem is not the different luminances generated by the two software, but the completely two different directions to where the radiation from the sky volt is hitting the sphere, as you can see in one of the pictures I uploaded before in this post. I know that because of Monte Carlo there is always a difference between simulations, but the differences you can see here are quite large.

For what I can understand I am using the same definitions, that is why I rise this issue.

Thanks again for having a look at this, and I would like to have your insight whenever you will have time.

Best regeards,



I appreciate greatly you are taking time to solve this issue. I will wait of course until you will have time to have a look at it .

I tried to use this component but I had two different errors and could not plot the skyes. One (in the first picture) is that it could not find the irr file.
I changed the directory to an easier one and I got the other (second picture) where it says that the parameter is not valid.
I also check this post but would like to know if you have an easier way to solve it now.
Also I can post this issue in the post directly.


Thanks always for your help.

Best regards,


Does HDRImagePath really have a valid path to the directory?