EPW to WEA Component Error


#1

Hi!

I was checking out the workflow of the new honeybee plus, to be specific the annual radiation gridbased, and a problem occurred with the EPW to WEA component.

It gave me a couple of different errors while changing the file:

    1. Solution exception:invalid integer number literal
    1. Solution exception:KeyError

Any help would be great.
Best,

Federico


#2

Hi @Federico587, are you using the Tokyo weather file in this case? If you can share the weather file I can take a closer look.


#3

Hi @mostapha!

Thanks for helping!
I upload the two files I am working on.

Best regards,363Tokyo_2010.epw (2.1 MB)
741Oita.epw (2.1 MB)


#4

@Federico587,
Thank you for reporting. This appears like a bug. Please do the following and it should work fine.

Go to "C:\Users*YOURUSERNAME*\AppData\Roaming\McNeel\Rhinoceros\5.0\scripts\ladybug\epw.py"
On line 127 you should have

value = valueType(data[fieldNumber])

Please replace this line of code with this


#5

Hi @devang,

Thanks for checking the code.
I replace the line with the ones you post, and it seems that the EPWtoWEA component is working, but now the component to run the radiation analysis is giving me this error (also in the pic):

    1. Solution exception:Warning: direct illuminance exceeds solar constant.

I checked the EPW that I am usign (363Tokyo_2010) and the the maximum value for the Direct Normal illuminance is around 100 klux, that should be ok.

If you need the file I am working on, let me know, but it is the same I downloaded from github: 05_annual_radiation_gridbased

Best regards,

Federico


#6

Please upload your file and I will take a look.


#7

Hi @devang,

Here is the file.
My additions are grouped, so they are easy to spot.

best regards,

Federico

05_annual_radiation_gridbased_POST.gh (871.1 KB)


#8

Hi @Federico587, Thank you for sharing the files. Your epw file doesn’t follow the standard types. For instance the Radiation values should be integers and not float numbers. We can add an extra check similar to what @devang has suggested to handle this but then you may get other unexpected issues using these epw files.


#9

This is an internal check inside gendaylit. The constant value is set to 127500. It’s above my knowledge why they picked this value but that’s why you get the error.

Based on both discussions here I suggest you to quality check the epw files before moving forward.


No correspondence between Annual Radiation and PVWatts Optimal Orientation
#10

@mostapha,
In the tokyo EPW file provided by @Federico587, The maximum direct iluminance is less than the 127500.

So I believe, we should have something to handle such a case. Don’t you think?


#11

Yes we do! I’m working on a number of improvements on Ladybug[+] this weekend and will add this feature and test it against this weather file. Will also check to see what’s going on with the error.


#12

Hi @mostapha,

This file is indeed a no standard weather file.
It is derived from the AMeDAS using a macro.
I have checked it against the file from E+ site, and indeed there are several differences with it.
Thanks for improve the tool so it can handle such a case.
Best,

Federico


No correspondence between Annual Radiation and PVWatts Optimal Orientation
#13

@Federico587, here is the modified version of your epw file which follows the typing standards.
tokyo_modified.epw (1.6 MB)

I need more time to check the other error. To address @devang’s comment, it’s true that the maximum direct illuminance in the weather file is smaller than maximum but the error is still valid since gendaylit doesn’t use the direct illuminance value directly but calculates it based on the radiation values inside the weather file. It will be interesting to do a check between the values calculated by gendaylit vs the values in the weather file.

Also since this error happens in gendaylit.py which I rewrote based on gendaylit.c I need to do a check and see if the error can be recreated with the original gendaylit.


#14

@mostapha, thanks for fixing this problem.
I run the radiation analysis and as you can see per picture below it seems is working quite well, a part for the title and legend values (that I admit I did not try to change). I run it for the fixed EPW and also for the one with floating numbers.


#15

1367 W/m² is the value of solar constant (even though new measurement is 1361 W/m²) and 127.5 kilolux is solar illuminance constant based on Wehrli 1985 solar spectrum. I heard somewhere that in the IES Lighting Handbook 10th edition there’s a new value of solar illuminance constant but haven’t found it yet.


#16

@mostapha I have already proceeded to “fix” the floating and integer numbers to be similar to the default version of the EPW as per E+ website, just in case.
The irradiance and illuminance values in these EPWs are completely derived from just the GHI, that yes has been measured, through the Perez model. So it can also be the case that there could be some errors compared with a standard weatehr file.

That will be very helpful for me. How you would suggest I could do this?


#18

@mostapha, @devang,

Although previously I posted that the simulation had worked (with the Tokyo files), now I have to tell you that it is not working. It gives me the same errors I have already posted. I have tested the EPWtoWEA as long as the Radiation components with others files, the ones I had plus the modified to match integers and floating numbers with the default E+ ones, and I still got errors.
I upload just a couple of them so you can test them: one is the one I had, the other (modified) is the one with the integers and floating numbers fixed.
I have tested the files in ladybug and DIVA and they are working.

Please let me know if you need more info from my end.

Best,

Federico

207Yuzawa_modified.epw (1.8 MB)
207Yuzawa.epw (2.1 MB)


#19

If you know Python you can use gendaylit.py to generate the values. That’s what I was planning to do but I didn’t get a chance to do it yet.


#20

The new version which can handle weather files with a different branch. I haven’t pushed it to the master branch on GitHub yet. Once it’s merged it should work fine. If you’re in rush I can pass the files through the script and generate a clean version for each that will work with the current version of Honeybee[+].


#21

I am not into coding, so whenever you could have a look, it would be very helpful for me.

Nonetheless I gave it a try and checked both links to gendaylit.py you leave me before in this post

And for what I can understand it does not make any sense that gendaylit is giving this error when the max illuminance for this file is way less than the 127 klux set as a treshold, as also @devang pointed out.

Anyways I always appreciate your help, whenever you can have time to have a look at it.
For my end I will try to see if I can get more into coding and also checking these epws.

Thanks for the support.
Best regards,

Federico