Rhino version Rhino 8 SR10 2024-8-13 (Rhino 8, 8.10.24226.13001, Git hash:master @ c36ab43d576d4854b29b091b6b3a38e09decabf5). I am running this under the .Net Framework.
Pollination Rhino Plugin version 1.50.1
I am referring an EPW file from desktop. Don’t see any error but the commands don’t seem to work when I have a local EPW.
@mostapha, recorded two more issues in this video.
My Rhino Specs:
Rhino 8 SR10 2024-8-15 (Rhino 8, 8.10.24228.13001, Git hash:master @ f4c93f2b85de4dc69b50ed22f1b0d91445724d03)
License type: Commercial, build 2024-08-15
License details: Cloud Zoo
Windows 10 (10.0.19045 SR0.0) or greater (Physical RAM: 32GB)
.NET Framework 4.8.9261.0
Computer platform: LAPTOP - Plugged in [98% battery remaining]
Non-hybrid graphics configuration.
Primary display and OpenGL: NVIDIA RTX A4000 Laptop GPU (NVidia) Memory: 8GB, Driver date: 7-23-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 560.76
> Integrated accelerated graphics device with 4 adapter port(s)
- Windows Main Display is laptop's integrated screen or built-in port
- Secondary monitor attached to adapter port #1
Primary OpenGL: NVIDIA RTX A4000 Laptop GPU (NVidia) Memory: 8GB, Driver date: 7-23-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 560.76
> Integrated accelerated graphics device with 4 adapter port(s)
- Windows Main Display is laptop's integrated screen or built-in port
- Secondary monitor attached to adapter port #1
OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU's maximum)
Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High
Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 7-23-2024
Driver Version: 32.0.15.6076
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 8 GB
Rhino plugins that do not ship with Rhino
C:\Program Files\pollination\plugin\8.0\Pollination\Environmental_Analysis.rhp "Environmental Analysis" 0.0.0.0
C:\Program Files\pollination\plugin\8.0\Pollination\Pollination.RH.rhp "Pollination.RH" 1.50.1.0
C:\ProgramData\McNeel\Rhinoceros\packages\8.0\LadybugTools\1.38.218\Ladybug.RH.Loader.rhp "Ladybug.RH.Loader" 1.38.218.0
C:\ProgramData\McNeel\Rhinoceros\packages\8.0\Pollination\1.50.1\Pollination.RH.Loader.rhp "Pollination.RH.Loader" 1.50.1.0
C:\Users\nycdvc\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\Wb.ModelEstablishment.Rhino\1.1.3\Wb.ModelEstablishment.Rhino.rhp "Wb.ModelEstablishment.Rhino" 1.1.3.0
Rhino plugins that ship with Rhino
C:\Program Files\Rhino 8\Plug-ins\Commands.rhp "Commands" 8.10.24228.13001
C:\Program Files\Rhino 8\Plug-ins\WebBrowser.rhp "WebBrowser"
C:\Program Files\Rhino 8\Plug-ins\rdk.rhp "Renderer Development Kit"
C:\Program Files\Rhino 8\Plug-ins\RhinoScript.rhp "RhinoScript"
C:\Users\nycdvc\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\PanelingTools\2024.8.20.677\PanelingTools.rhp "PanelingTools"
C:\Program Files\Rhino 8\Plug-ins\IdleProcessor.rhp "IdleProcessor"
C:\Program Files\Rhino 8\Plug-ins\RhinoRenderCycles.rhp "Rhino Render" 8.10.24228.13001
C:\Program Files\Rhino 8\Plug-ins\rdk_etoui.rhp "RDK_EtoUI" 8.10.24228.13001
C:\Program Files\Rhino 8\Plug-ins\NamedSnapshots.rhp "Snapshots"
C:\Program Files\Rhino 8\Plug-ins\MeshCommands.rhp "MeshCommands" 8.10.24228.13001
C:\Program Files\Rhino 8\Plug-ins\IronPython\RhinoDLR_Python.rhp "IronPython" 8.10.24228.13001
C:\Program Files\Rhino 8\Plug-ins\RhinoCycles.rhp "RhinoCycles" 8.10.24228.13001
C:\Program Files\Rhino 8\Plug-ins\Toolbars\Toolbars.rhp "Toolbars" 8.10.24228.13001
C:\Program Files\Rhino 8\Plug-ins\3dxrhino.rhp "3Dconnexion 3D Mouse"
C:\Program Files\Rhino 8\Plug-ins\Displacement.rhp "Displacement"
C:\Program Files\Rhino 8\Plug-ins\SectionTools.rhp "SectionTools"
I was having the same error with Rhino-7 and Rhino Plug-in v1.48.25.0 for CIBSE weather files (epw format) for some time.
Thanks,
Levent
Thanks @devang and @hlkocalioglu,
The ProjectInfo Dialog is using the ladybug_rhino python module to retrieve location data from EPW. It seems this download.extract_project_info doesn’t support a local EPW path yet.
from ladybug_rhino import download
updated_project_info = download.extract_project_info(project_info)
This is a question for @chriswmackey, do you think we should remove the local EPW file from the ProjectInfo Dialog, or we can support a local EPW file path in Project Info?
Thank you for checking this @mingbo!
I think we should make the changes needed to support the local EPW files. @devang and @hlkocalioglu can correct me but I have seen offices using local modified EPW files frequently.
We probably need an initial check to see if the path is a URL before trying to download the file.
I can understand the confusion here, though I’ll admit that I thought calling the module download and the property weather_urls in the ProjectInfo JSON object made it clear that this module and that field are meant to with with URLs and not local paths. So I my original thought was that this module and field were not being used for local files.
What exactly were you hoping the module to do? Were you hoping to put in a local path to a folder containing EPW, STAT, and DDY files under the weather_urls property of the ProjectInfo JSON instead of a URL there? So the command would basically extract the ASHRAE climate zone from the STAT file in that folder and the other information from the EPW file in that folder? Were you then also expecting the environmental analysis commands that use annual data to parse the EPW file in that folder while the commands that worked from design days would use the DDY or STAT data?
If so, I can probably find a way to support this, though maybe we should be putting it under a new and different property in the ProjectInfo object instead of weather_urls. And we should be clear that this input needs to be the whole folder containing EPW, STAT and DDY for all of the environmental analysis commands to have what they need.
Also, the title of this post is mis-lableld as all of the environmental analysis commands are currently able to work with local files. You just paste the path to the local file in the first time when you start a given command (either EPW, DDY, or STAT). Then, the command will work fine with the local file for the remainder of your Rhino session.
So all of the Environmental Analysis commands that use EPWs are perfectly fine with working from local EPWs. It’s just the Project Information interface and schema that are not currently set up to specify the paths to local folders.
Ladybug supports using local EPW file and that’s where my personal behavior comes from. But let’s set that aside for this discussion.
Two reasons why I feel it would help to use local EPWs.
Note that there are a couple of more clicks that happen in fetching the Pollination license when the users starts Rhino for the first time. (We discourage people to never click Auto-Activate.)
Using the project info field to cache the path to a local file will reduce number of clicks that need to happen before the real work begins.
Thank you for the clarification, @devang.
Are these morphed files only EPW files or do you also include DDY files in the folder? We get more than just the EPW file from the URL.
They are only EPW files.
Thank you, @devang. That’s helpful. As @chriswmackey suggested, we need to make some adjustments to make the project information more flexible to handle cases like yours.
I assign this task to Chris and we will discuss it internally once he returns from vacation. We should be able to improve the whole workflow to match your expectations.
Hey @devang ,
I just wanted to clarify that using local solution will usually require more clicks from the user compared to URLs, though you should hopefully be able to make it the same number of clicks if the local files are on some shared drive that all of your computers can access.
The reason why I say that local files require more clicks is because, with the current URL system, the URL gets saved into the 3DM file that you are using. So, when that 3DM file gets opened on a other machine by another user, the EPW, DDY, and STAT get automatically downloaded to the default weather folder in the user folder upon starting an environmental analysis command. So it requires zero clicks once someone sets it up the first time. Conversely, if the EPW file gets set to a local path and that file is not on the new user’s system, we will require them to manually re-assign it, thereby requiring more clicks. Granted, if you know that the local file path will reliably be on every machine that you plan on opening the 3DM file, it should be as good as the URL option.
Morphing EPW files without adjusting the DDY file seems a little bit like putting the cart before the horse to me. That is, you won’t really be able to understand the impact on future energy and comfort without first understanding how your extreme sizing criteria change with the climate (or are you assuming that they do not change?) If you are building a database for many people to use, is there a particular reason why you have not morphed these files?
Hey @devang ,
I’m not sure if you have gotten the chance to think about this more but we came to the conclusion that, if you’re willing to restructure your database so that you have folder for each location, which contains an EPW, DDY and STAT, we can pretty easily support pointing the Project Information to this folder path in lieu of the URL. The DDY and STAT don’t need to be perfect if you only plan or running studies that use the EPW data. If you’re just using morphed EPW files for the publicly available weather data, then just copying the DDY and STAT files over from the publicly available ones will work with what we have in mind.
The main issue is that we set up the Project Information schema in a way that it’s meant to contain all climate information about the project. EPW files only contain a fraction of that information so it would take a lot of time and effort for us to break down the project information schema by file type so that you can specify the EPW information separately from the other data related to the climate like ASHRAE Climate Zone, clear sky radiation data, and the sizing criteria of the DDY file.
Is working from the folder with 3 files something you would consider? If so, we can probably add support for this within the next stable release of the Rhino plugin. Otherwise, you may have to be patient for a while and rely on manually pasting the path the the EPW file into the relevant commands until we can identify a good way to break down the project information data by file type.
Hi @chriswmackey,
Sorry for the delay. That sounds good.
Hey @devang ,
I’m just letting you know that I added support for specifying folder paths in the “Weather URL” slot of the PO_ProjectInfo:
It’s not in an official release yet but you can test it by running the LB Versioner component if you want. Once you run the Versioner and restart Rhino, you’ll find that you can set the “Weather URL” to a file directory that contains an epw, stat, and ddy. You’ll find that all of the Environmental Analysis commands will work form these local files by default instead of the URL.
Granted, the “Get location from EPW” feature is still broken in the Rhino plugin (both for real URLs and for folder paths). @mingbo will fix this at some point and make a new official Pollination Rhino release. So I’m going to reassign this issue to him so that he can post back here once it’s all integrated.
But it seems like we’re close to having this be fully addressed.
Thanks @chriswmackey,
I just triggered a new release with the following update. The next version should have the new local EPW support.
Hi @mingbo @chriswmackey . I tried the new update with a local folder having epw file data, but its throws an error as shown below.
