Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: Using OpenStudio intersectSurfaces to more reliably intersect zone masses #700

Open
saeranv opened this issue Jul 12, 2018 · 5 comments

Comments

@saeranv
Copy link
Member

saeranv commented Jul 12, 2018

Hey guys,

This is in response to some issues that the intersect masses component has:

https://discourse.ladybug.tools/t/masses-intersections-issues/3262/5

As I explain in that post, I think we can use the OpenStudio API's built-in method to intersect coplanar surfaces in a more robust way then what Grasshopper/Rhino offers us.

I made a quick and dirty proof-of-concept last night, which is showing some promising results with some really minimal code:

Original:

IntersectMasses (left) vs OpenStudio Intersection (right)

Basically I just translated the breps into OpenStudio spaces then looped through and intersected all that fell in a bounding box range:

# Intersect Masses
for i in range(space_lst.Count):
    curr_space = space_lst[i]


    for j in range(space_lst.Count):
        chk_space = space_lst[j]


        # Check if within extents or same sapce
        if is_near_zero(i-j):
            continue


        if bounding_boxes[i].intersects(bounding_boxes[j]):
            curr_space.intersectSurfaces(chk_space)
            #Util.show($"Intersected and matched {sp.nameString()} with {bSpace.nameString()}");

... where curr_space and chk_space are OpenStudio.Space objects made from breps.

Anyway, let me know what you think. If it seems promising, I think it could be a useful back-up method within the original intersectMasses component.

Link to code: https://github.com/saeranv/Fermi/blob/master/src/openstudio_intersect.py

Gh file with component: intersect_openstudio.zip

@chriswmackey
Copy link
Member

@saeranv ,

I am sorry that I never posted here but I did post on the forum. This issue has gotten renewed interest now that we have decided that the ladybug tools core will have its own geometry library:
https://github.com/ladybug-tools/ladybug-geometry/blob/master/README.md

You will see that one of the of the items marked as difficult is intersecting masses like this. I think that we should try to borrow OpenStudio Team's code here and adapt it for the ladybug geometry library. This will enable the best of both worlds since we don't have to convert everything over to .osm format to intersect zones but we can still use the intersection capabilities.

I will ask the NREL team where the intersection code lives and see if I can add it in. Thank you for bringing this feature to our attention as it is a huge help to know that these types of intersection calculations exist within an open source library.

@saeranv
Copy link
Member Author

saeranv commented Nov 4, 2018

@chriswmackey glad to see this helped. And I'm glad to see a dedicated geometry library for ladybug appearing.

I also agree that for more complicated methods, it's beneficial to try and borrow from other geometry libraries, like Openstudio's methods for intersecting masses. However, just to hash this out a bit more: do you mean to rewrite the OpenStudio intersection code into Python?

Maybe I'm missing something, but you don't have to convert to an .osm format to intersect zones. The methods encoded in the Openstudio.dll written in C# can be accessed (via IronPython methods) programmatically as python methods.

The big benefit from using outside C# libraries, like Openstudio, is that you additionally benefit from using a compiled library to do computationally costly geometry operations, versus relying on Python's interpreted library. This is especially true for certain geometric algorithms, like intersecting masses which should grow by the power of two with every additional mass you must intersect (i.e O(n^2) complexity time)[1], so it's really beneficial to use a faster C# library. See this stackoverflow comment regarding the benefit of Shapely (python library that uses C library), vs pure python geometry methods for a similar discussion regarding this: https://stackoverflow.com/questions/30844482/what-is-most-efficient-way-to-find-the-intersection-of-a-line-and-a-circle-in-py/30998492#30998492

I'm not married to any particular method. But I wanted to clarify the cost benefit of sticking to C-based libraries when possible over Python for geometry calcs.

[1] This is traditionally done as a nested for loop, every mass must be checked for intersection with everyother mass, hence n masses x n masses. Technically the Openstudio code gets around this by using bounding box intersection checks to cheaply get rid of masses far apart from eachother, so n^2 not exactly true.

@chriswmackey
Copy link
Member

@saeranv ,

The main reason why we are starting the ladybug geometry library is so that we have a cross-platform, standard, way of doing these geometry calculations, which can be called by all of the plugins and Ladybug Tools interfaces that need it. The second priority is making it faster.

Some of the ways that we could make Python code faster once we have it in use (1. Compiling the Python code, 2. Running it via cPython and Python3 instead of ironPython, 3. Using parallel processing, 4. Having intersection calculations done on the cloud). The last one in particular might not be easily accomplished if we are working on C# since it cuts out the possibility of using Linux servers. And while I am aware that you can get more optimized speed calculations by writing it certain ways in C or C#, you have to weigh this fractional increase in speed against the windespread usability and, legibility, and ease of maintenance that you get with Python.

So I am saying that we should try translating the OpenStudio code to Python. And I think that there should be a Ruby version of the code knowing OpenStudio's development workflows. So it might be better to start from that.

@chriswmackey
Copy link
Member

I should have also been clear that by "converting to .osm format" I just meant that you don't need to create OpenStudio model objects, which definitely takes a lot of time and computer memory. I wasn't referring to writing OpenStudio model objects to .osm files.

@saeranv
Copy link
Member Author

saeranv commented Nov 9, 2018

@chriswmackey

I see, preserving cross-compatibility isn't something I had considered, and converting to Python in that case makes sense, and is the right way forward.

  1. Running it via cPython and Python3 instead of ironPython,

👍 👍 👍!!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants