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.
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.
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.
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).
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.
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)
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.
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.
Tried a full spectrum of the tolerance in rhino but no luck.
Anyways, as i said, the issue was solved with some alternatives.
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.