Its not the first time I have some issues with the honeybee Intersect Masses component. It often didn’t work correctly, Even when I simplify my geometries. And manually adjusting everthing is a lot of time when running alot of different simulations.
Excuse, my misunderstanding, but you suggest that I downgrade my R6 ?
If its the case, I look rapidly how to do it and didn’t find. Any recommendations, website on how to ?
No need to downgrade RH version @CharlesCollin, as I mentioned above this one is the latest release candidate and it should solve the Intersect masses problem.
Just update the RH6 to the most recent Service Release Candidate.
Follow this:
Start Rhino 6
From the Tools menu, click Options
In the Options dialog box, click Updates and Statistics
From the Update Frequency drop-down box, select Service Release Candidate
I’ve been thinking about this problem recently, and I think another solution here is to resolve these intersections outside of the Grasshopper/Rhino library. Specifically, the OpenStudio API comes with built-in geometry methods that we can use to intersect coplanar surfaces in a more robust way.
Attached is a prototype that I put together this evening, it seems to be doing better with complicated intersections:
Original masses:
IntersectMasses (left) vs OpenStudio Intersection (right)
It seems that the core of the issue is that we’ve had something that always worked in Rhino 5 but, now that everyone is upgrading to Rhino 6 and McNeel keeps making edits (accidentally inteoducing bugs in Rhinocommon) the intersect mass component isn’t as reliable yet. I would assume that this issue will go away as Rhino 6 becomes more stable (the fact that the new experimental build fixes it is already evidence of that).
Still, there is definitely merit in giving people options with @SaeranVasanthakumar 's OpenStudio method. I also see that OpenStudio method as a long-term solution for HB+ since, if Rhino has difficulty supporting intersect functionality, I am sure that the vast majority of other CAD interfaces that we would want to connect HB+ to would also have these issues.
Thinking out loud here, I wonder if for HB+ it would be useful to initialize an OpenStudio.Space (or OpenStudio.ThermalZone) object, and attach it as a property to the HB+.Zone object, as soon as a closed volume is generated in a CAD interface. This tighter coupling between OpenStudio and HB+ means you can take advantage of having access to OpenStudio API methods “upstream” in the design process, like this IntersectSurfaces method, or the method to MatchSurfaces. And as you say, it would all be agonistic of the CAD interface…
That was always the dream of @mostapha and I to have that type of tight integration with OpenStudio API. The original hope was to have python bindings for OpenStudio that we can directly access from HB+ (so there would be OpenStudio ojectz initialized when you make HBSurfaces and HBZones).
Unfortunately, the OpenStudio team really does not want to maintain a new set of Python bindings for Python and so, if we wanted to got this route, we would have to build and maintain our own Python bindings.
Another option we considered for tight integration is to use different bindings for the different operating systems on which OpenStudio can be installed (and we just have a config file that finds the libraries on any system). However, the challenge with this is that the API calls would be different for the different bindings. So this option really isn’t going to work.
At the moment, the only type of integration that OpenStudio team is planning to support in the near term is measures. In this secnario, we don’t have “tight” integration and, instead, we write out HBZones into a json format and have a very large measure to parse the json into an OpenStudio model.
@SaeranVasanthakumar like you said it is more robust.
I wonder if all these subdivisions will cause issue when setting default attributes to geometry in order to run E+ analysis. Didn’t try it yet.
@CharlesCollin, yes more complicated surface subdivisions may cause issues. However in most cases this can be eliminated (or at least reduced) by logically subdividing your mass into thermal zones to reduce awkward surface overlaps (i.e convex overlaps), which is the main reason why the OS method is producing lots of subdivisions in this case.
@chris, thanks for explaining this in such detail, it’s clear that you and Mostapha have thought this through in detail.
While it is unfortunate that the OpenStudio team isn’t also releasing python bindings, why not just support tight integration by accessing the OpenStudio.dll through the C# bindings, like you guys are doing so already?
import clr
clr.AddReferenceToFileAndPath(openStudioLibFolder+"\\openStudio.dll")
import sys
if openStudioLibFolder not in sys.path:
sys.path.append(openStudioLibFolder)
import OpenStudio as ops
And then just use ops to create an osm.spaces that can be coupled with an HBZone? The C# bindings are supported so it should be a safe choice I think.
However, I will admit there are some advantages to keeping the osm model and hb model separate (i.e reducing redundancy between the two, preventing state mutations upstream etc) so I can understand if you guys would prefer to keep them separate until the Run OSM component.
