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.
@mostapha,
In the tokyo EPW file provided by @Federico587, The maximum direct iluminance is less than the 127500.
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.
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
@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.
@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.
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.
@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?
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)
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.
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[+].
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
I appreciate greatly your support.
I will try first to narrow down the stations I will need the most and leave the others out.
I will let you know!
Best regards,
Federico
Hi @Federico587, I checked the file for Yuzawa today and the error was because there were several extra , at the end of each line. I added an extra check to handle cases like this:
I cannot recreate this error. Can you update your installation and use the latest version from GitHub and test the files again. It might be fixed after the recent modification that @devang has made to sunpath.
Hi @mostapha,
thanks very much for having a look at this.
How should I do this? You mean install the last version of HB and LB legacy? Or use the update components on GH canvas?
Another thing: for what I can understand you solved the problem for ladybug (legacy). Do you think it can be done also for HB legacy and HB[+]?
I am gonna check the files as soon as I can and I will get back at you.
Best regards,
Federico
Hi @Federico587, The fixes are all for Ladybug[+] and Honeybee[+]. Ladybug legacy doesn’t have a WEA component. By updating the plugins I meant updating Honeybee[+] plugins which can be done manually or by using this component.
I’m wrapping up a new installation package for the [+] plugins. If you can wait until the end of the week then you can download the new version which has multiple bug fixes and improvements.
i seem to have a similar issue with this component but not sure it comes from the same reasons.
I tried both with an epw. file on my computer and from url directly
i got this error message : “1. Solution exception:from_epw_file() takes exactly 2 arguments (3 given)”
Any idea about it ?
Related to my HB[+] version maybe ?
It’s OK finally, my version of the component wasn’t the last updated one available
