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.
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.
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.
sphere_radiation.gh (89.9 KB)
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.
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.
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
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.
Anyway, just on the basis of what is posted here:
- The scales appear to be different for DIVA (which is following the Radiance palette) and LB/HB.
- 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.
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.
Does HDRImagePath really have a valid path to the directory?
This is what is happening.
I tried with EPWs from Meteonorm and NREL.
Both give the same issue.
Any insight would be very helpful!