Hi @chris,
Our local meteorological Service has made some refinements on the OneBuilding’s EPW files. They said it is related to Wind data Standarizing. Those files will become soon the official ones to be used for energy rating of buildings.
As part of the Rating Committee i’m checking the validity of those files (basically, right now just checking they work with LBT). There is one file that is not, with the error pasted below. I’m comparing the drybulb temperatures of the new and OB’s but can’t find where it fails.
Do you mind taking a look? Want to be sure if this is something that can be fixed on LBT or i need to tell the Service to look again and fix it.
The working and faulty files are attached below.
Thanks,
-A.
Runtime error (ValueErrorException): invalid literal for float():
Traceback:
line 536, in _import_body, “C:\Program Files\ladybug_tools\python\Lib\site-packages\ladybug\epw.py”
line 387, in _import_data, “C:\Program Files\ladybug_tools\python\Lib\site-packages\ladybug\epw.py”
line 863, in _get_data_by_field, “C:\Program Files\ladybug_tools\python\Lib\site-packages\ladybug\epw.py”
line 936, in dry_bulb_temperature, “C:\Program Files\ladybug_tools\python\Lib\site-packages\ladybug\epw.py”
line 113, in script
Also, I realized that EnergyPlus is actually OK with the extra blank line so I tweaked the Ladybug EPW class so that it will also succeed for this case.
Hi @chris,
Just to be sure about the status of this topic. The solution is to delete the empty line or it will be possible to use the existing EPW.
Just updated with the Versioner and the error is still there. Probably i should try later or tomorrow …
Deleting the extra line break from the EPW is good practice and I would recommend you do that no matter what. But, in the very latest version of Ladybug Tools that finished releasing 20 minutes ago, the extra line break won’t stop the EPW from being imported and the line-break EPW can also be simulated in EnergyPlus.
Hi @chris,
After updating i’m getting this error instead the previous one:
Runtime error (ValueErrorException): Failed to parse EPW data for field “Year” at index 8760.
invalid literal for int() with base 10: ‘’
Traceback:
line 544, in _import_body, “C:\Program Files\ladybug_tools\python\Lib\site-packages\ladybug\epw.py”
line 387, in _import_data, “C:\Program Files\ladybug_tools\python\Lib\site-packages\ladybug\epw.py”
line 871, in _get_data_by_field, “C:\Program Files\ladybug_tools\python\Lib\site-packages\ladybug\epw.py”
line 944, in dry_bulb_temperature, “C:\Program Files\ladybug_tools\python\Lib\site-packages\ladybug\epw.py”
line 113, in script
The fix clearly made it through since this new line of code should be catching the extra line break and continuing.
It’s just that this fix is somehow working on my machine but not yours. I guess I can try implementing a different fix to see if it will address your situation.
And, to confirm again, are you using Rhino 7 on Windows to test this?
Weird. Just cheked the ladybug/epw.py and it has the fixed lines.
In the meantime i’ll use the fixed EPW file. I let know the Standards committee about this so they can ask the meteorological service to fix the file themselves .
Hi @AbrahamYezioro - out of curiosity, what is the refinement being done related to the wind data standardizing?
It’s great to see that updated EPWs from Climate One Building are being recognized as official ones as usage of reanalysis data in building energy community remains low. Recently, a national agency in Poland (can’t remember their name) also adopted ERA5 data for their standard weather files (for about 200 locations in Poland) although they did not use the files from Climate One Building.
Hi @josephyang ,
I’m nor really aware of the changes done, but i know they were related to some standardization of the winds data. I sent a request to explain in more detail. What i know is that they revised the data and endorsed the files.
Hi again,
Some of the EPW’s data didn’t correspond to open field conditions (like airports). It was decided to adapt/convert, for those cases, the wind data to be “open field”.
The conversion was done in accordance with the relevant ASHRAE coefficients for each station, as determined by Meteorological service.
I’m not sure on what basis @AbrahamYezioro’s meteorological centre determined this but in general, ERA5 reanalysis data can be considered more or less ‘open field’ as you see below, with roughness length corresponding to short grass:
For the updated Climate One Building EPW files, I think Linda and Dru used a mix of observation and reanalysis data and if the wind data was from non-airport stations, I’m guessing that it might make sense to adjust as mentioned by @AbrahamYezioro.
As for the effect on UTCI calculation… I’m not sure how big the implication would be so it might be worth doing a small sensitivity analysis with wind speed parameter to see how it affects the UTCI values.
Hi @josephyang and @charlie.brooker ,
It is indeed airport conditions what i meant.
i believe our meteorological service check the coordinates of the site defined in the EPW and from there they decided the data’s land condition. But just for my sake (and maybe yours) i’ll ask about this too.
As for the UTCI calculation, beyond what @josephyang said, my intuition says that it might have an influence since the wind profile is different for various conditions (open, suburban, urban, …).
In the Legacy version there is a component to adjust the wind profile. It is still not implemented yet in LBT but hopefully it will be soon. It remains to the user to check what the weather conditions in the EPW file are.
At the end a very technical post question became into an interesting chat …
-A.
Hi,
Checked it.
They took each station and according to their location they defined a fix coefficient for the wind data. Coefficient value 1.0 means no fix needed.
So it was not a binary situation but rather each case required small/big fix.
