Error with IWEC weather file-Honeybee+ climate sky

grasshopper honeybee[+]
1

Hi everyone,

I tried to run point in time grid-based and image-based analysis in Honeybee +, but if I use an IWEC weather file the simulation doesn’t work.
The sky component generates the sky in the command line, but the calculation does not produce any results.
Same test with a TMY3.epw works. I tried different IWEC and dates, using also the sample file.
Furthermore, the same weather IWEC file (you can find attached) works for annual analysis.

Does anyone have the same problem?

Thank you so much.

Best

Andrea

ITA_Milan.160660_IWEC.epw (1.5 MB)

2

I think this is similar to the issue that @AbrahamYezioro has reported before. I opened an issue but didn’t get the chance to test and fix it.

3

Sorry, didn’t find the post.

Thank you so much.

Andrea

4

@mostapha I did little investigation and found that the issue is occurring because gendaylit is not getting the meridian values assigned to it.

c:\radiance\bin\gendaylit 6 21 12 -W 773.0 253.0 -o -34.8 -O 0 -a 31.25

The default value for gendaylit corresponds to San Francisco (-m 120). So as long as we do a simulation for a location within the continental United States (or locations with longitudes in the vicinity of 120 degrees Standard Meridian, the results will look okay, but still be slightly off. The error will increase for other locations. That’s why Abraham is getting a dark sky as the local time as per gendaylit is 10:30 PM

exe

This is only an issue with HB[+] point-in-time simulations at present, which I hope people are still doing through Honeybee legacy. For all the matrix based stuff, the meridian values are added automatically through Radiance based epw2wea and gendaymtx. The fix should be simple, just add the -m flag in gendaylit either in the plus plugin or downstream in core ( I will let you handle that :stuck_out_tongue: ! ).

This might also explain the difference in results that @MingboPeng was getting. Thank you to @AbrahamYezioro and @AndreaZani905 for pointing this out.

1 Like
5

Thanks @sarith,
Hopefully this will fix the issue.
-A.

6

Thank you for checking this out. I don’t think it will change the results for @MingboPeng’s study. In the annual run we use the gendaylit.py and sun position is calculated using the SunPath class. It should address the issue for the point-in-time cases though.

7

This is finally addressed. As @sarith mentioned meridian was missing from gendaylit. This change should address the issue here and for @AbrahamYezioro’s case.

I’m going to check @MingboPeng’s case next by comparing gendaylit.py vs Radiance’s gendaylit command.