Changed Location of the Department of Energy Weather File Database

Ladies and Gentlemen of the Ladybug Community,

I write to inform you of a change that has been made in the US Department of Energy’s climate file database, which many of you know is the lifeblood of the Ladybug + Honeybee project as well as a cornerstone for a large fraction of the building energy modeling practice. In accordance with the moving of all EnergyPlus documentation from the Department of Energy’s website to Energyplus’s own website, the entire climate file database has now been removed from its original location and relocated to the EnergyPlus site, causing what I am sure is many broken links across a lot of platforms.

Many of you will not notice the effects of the change immediately since many of us work from weather files that have been already downloaded to our machines. However, when you go to begin working in a new climate with the Ladybug + Honeybee tools, here is what you have to know:

For TYPICAL USERS of the last stable release of Ladybug + Honeybee, you will have to manually download, unzip, and open all weather files with the “Open EPW” component until the next stable release. In other words, the automatic download of the “Open EPW and STAT” component will not work correctly since it was built to reference weather file URLs from the old database. To download your weather files, we recommend that you use the epwmap interface, which the “Download EPW” component currently sends you to:
http://mostapharoudsari.github.io/epwmap/
All links on the epwmap interface have been updated to sync with the new database location and so you should not experience any issues using it. If you are a big fan of going straight to the source of the climate database, you can find the new location of the database here on the EnergyPlus website:
https://energyplus.net/weather
Again, note that all links that you had to the old Department of Energy database will no longer work.

For USERS SYNCED WITH OUR GITHUB, just sync your components now and you should not experience any issue here on out. The “Open EPW and STAT” component on the github is fully compatible with the new database location.

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Claudio on December 12, 2015 at 8:34am

Thank you Chris for the update. You guys are awesome making out professional life easier and more productive

Cheers
Claudio

Permalink Reply by Paul Wintour on January 10, 2016 at 8:40pm

Hi Chris

How does this work with sharing scripts? If I have the latest Github components and someone else has v0.61, will they need to sync ladybug with Github first before being able to use my updated script?

Permalink Reply by Paul Wintour on January 10, 2016 at 9:00pm

Also does the update tool work on nested components in clusters?

Permalink Reply by Mostapha Sadeghipour Roudsari on January 11, 2016 at 6:09pm

99% the answer is no unless we got lucky and the components inside clusters get listed as components in the document.

Permalink Reply by Paul Wintour on January 11, 2016 at 6:36pm

so whats the solution - place the update component in each cluster? Will this work or because it's in a cluster its still going to fail?

Permalink Reply by Mostapha Sadeghipour Roudsari on January 11, 2016 at 6:48pm

That should work but then it will add so much to the analysis time as it will download the components and update each component in cluster every time it gets executed. The solution is for us to search inside userobject and update the components. I'm not sure how is that possible but if we figure that out then it's just adding them to the update process which is pretty straight forward.

Permalink Reply by Mostapha Sadeghipour Roudsari on January 11, 2016 at 7:18pm

I checked the SDK and the group. There is no good documentation about accessing the objects inside a GH_Cluster but it's a very interesting problem. I'll give it another try and I will open a new discussion if I couldn't figure it out.

Permalink Reply by Mostapha Sadeghipour Roudsari on January 11, 2016 at 7:54pm

Ok! I think I figured it out. If you use the new update components (Dated JAN_11_2016) they update components inside clusters as far as clusters are not password protected. Let me know if you found any bugs.

Permalink Reply by Paul Wintour on January 11, 2016 at 11:12pm

Still not working for me. If I have both to set to True, no clusters are updated. If I have just 'update this file' set to True I get an error message (refer below). And if I try to update within the cluster it says "cannot assign to code with parameter exists".

Attachments:

error2.JPG, 74 KB

Permalink Reply by Mostapha Sadeghipour Roudsari on January 12, 2016 at 3:36pm

At least it shows that it detects the files. Can you share a small example file with me? The error seems to be a Grasshopper permission issue. Maybe I should not ExpireSolution the component inside the cluster. My simple test example worked fine.

Permalink Reply by Paul Wintour on January 12, 2016 at 3:41pm

sent via gmail

Permalink Reply by Mostapha Sadeghipour Roudsari on January 12, 2016 at 4:15pm

Thanks. The reason was the "code" input. For some reason you had the code input to be shown for Orientation Study Parameters. You need to remove the input and try again. I added a warning to the update component to catch this case.