Hello everyone,
I am trying to do an annual daylight simulation of a school building which has a courtyard. But the wall of the corridor cannot be recognized as interior walls.
Does anyone have suggestions of the right method?
Thanks a lot!
Welcome to the discourse @icy!
Will help if you upload your model or send a link to any cloud service you have.
-A.
the file is uploaded, thanks for your helping!
It was a bit challenging but can be solved.
I built an example where you can see 2 versions:
- Where the internal walls are not recognized (bottom white group)
- Where the internal walls are solved (top white group).
For the sake of the understanding you can pick which to visualize (Middle red group).
The thing is the IntersectMass component is having trouble when the courtyard is exactly in the middle of the outer building. This is your file and option 1 above. When you move a little bit this courtyard it works fine. This is case 2 above, where i move the courtyard half a centimeter.
I add @SaeranVasanthakumar to the discussion. Maybe he can explain better why this is happenning.
In any case, hope it helps.
-A.
AdjacencieIssue_CenteredVSMoved.gh (495.5 KB)
Thanks a lot!
The internal walls can be recognized now using the method you offer!
Unfortunately this isnât a component I worked on, so I canât be of much help debugging the core issue. However, from my general experience working with Grasshopperâs API, I believe this could just be due to the fussiness of Grasshopperâs geometry methods.
The LB community has developed some alternatives to this component that relies on alternative ways of computing the geometric intersections.
Specifically, I believe Mingbo developed a version in C#, available in HB as IntersectMassesII, which you can find in your Honeybee tab. If that doesnât work, I also developed a version using the OpenStudio API (here: Masses intersections issues). I think both of these alternatives should be more robust.
S
Thanks @SaeranVasanthakumar,
I remember wel that you were related somehow to the issue here.
Iâve tested both @MingboPeng and yours. Unfortunately non of them solves the issue better than the original IntersectMass. As a matter of fact yours is not outputting the closed breps for this case (if you donât mind to check why from the example attached here it will be great).
-A.
AdjacencieIssue_CenteredVSMoved.gh (502.2 KB)
Damn! Once again my code has been shown up by the sophisticated technique of moving things slightly off-center.
Two thoughts on alternative solutions to this problem:
-
If you split the courtyard in two, the original geometry will intersect correctly. The âdonutâ shape is challenge for most geometry methods, as evidenced here by the fact that two different geometry APIs (Rhino/OpenStudio) had issues with it.
However you will get an interior wall at that split, which may not be desirable for daylighting. -
I believe you can construct all the surfaces using the HBSurfs and input that into the daylighting simulation, without going through the hassle of making zones like this.
Mingbo or Chris might have some better insight about whatâs causing the off-center trick to work in this case, and solve the components accordingly. Iâd try to fix it with my component, but as Chris alluded to in the original post I linked, using the OpenStudio API in upstream components doesnât fit in with HB plans, so I think itâd be better to focus on improving the two existing components.
S
Thanks @SaeranVasanthakumar,
Well, this is not a case iâm dealing right now. It was for help @icy.
Hopefully the issue will be fixed.
-A.
Hi @icy @AbrahamYezioro @SaeranVasanthakumar
I checked the model, this is not the issue of any intersectMasses components, as there is no need to use this intersectMass component in this file.
That is because theoretically the inner brepâs outer surfaces have already perfectly matched with the outer brepâs inner surfaces in this case.
After removed the IntersectMass component, the next component might cause the issue is the SolveAdjacency.
So I just drew polylines myself, and everything works perfectly⌠So it is likely the problem from the three curves at beginning.
I havenât really look into whatâs the problem of those initial curves, but I attached my file here for anyone want to double check.
NotAdjacencieIssue_MP.gh (477.3 KB)
Mingbo
1 Like
Thanks @mingo,
Weird indeed. Your solution is not working with the original geometry.Though it does with yours.
Well, good to know that there are possibilities to solve issues.
-A.
Hello All,
Glad to hear that it was not an issue with the intersect masses component as the last revision of the intersect masses component was done by someone who I am not sure is in the forum but he definitely improved the component:
If there is an @Larry7707 on the forum, I hope he sees this so we can match the github account to the forum member.
I might put forward an inference about why the old geometry might not be working. Geometry in Rhino is bound to the tolerance of the Rhino model in which it was created so, if you change the model tolerance after making the geometry, it can cause two surfaces of the model that were previously adjacent to read as too far apart to be adjacent in the new tolerance. I know that we added the tolerance_ input to the Solve Adjacency component in an attempt to address this situation but I donât know if it really works that well. If you are able to get it to solve correctly by changing the tolerance_, then we know what the issue is.
H i@chris,
Tried a full spectrum of the tolerance in rhino but no luck.
Anyways, as i said, the issue was solved with some alternatives.
-A.
I have had the same problem about a year ago. I discovered that both honeybee (find adjacencies) and Energy plus canât deal with donut like spaces. I had the same problem with the Dutch energy simulation tool âVabi Elementsâ. The problem can be solved by spliting the donut like spaces into two spaces.
The best practice of modeling zones in EnergyPlus is making all zones as convex geometries.
Such as:
