Hello all,
I am encountering validation error after assigning interior aperture as seen below
This error is quite similar to the post from @martin6here.
I have around 600 zones for a shopping complex and need to provide indoor apertures (opening) opening to corridors. So I tested with two small zones with adjacent windows to avoid/bypass validation error.
Test 1:
I modeled single aperture to a single face of one zone and then performed solve adjacency and I encountered this error.
Test 2:
I modeled two individual aperture to the two adjacent surfaces and then performed solve adjacency and I got this error with duplication of windows in each face as below.
Test3:
Model individual zone and add individual aperture separately for each zone (not at single selection of all zone and aperture to automate addition). Once individual apertures are added to each zone than select all to do solve adjacency. This time no validation error.
Though the 3rd test didn’t threw any validation error but performing this step for 600 zone is quite a lengthy process. Can we create internal windows following test 1 without error or is there any other alternative for this.
Hi @asisnath! Thank you for documenting the issue clearly.
The reason you get this error is that when the aperture is created from a Rhino geometry, the Rhino plugin uses the geometry UUID to set the ID for the object. That means:
In Test 1: when you use the same geometry. It creates two unique apertures with the same UUID.
In Test 2: you are facing the same situation as test 1, with the difference that now there are two apertures that are being added to both faces.
It works in Test 3 because you are helping the Rhino plugin by indicating which aperture belongs to which face.
I agree that we should make it easier for creating these apertures using a single face but I don’t have an ideal implementation in mind. I assigned this to @mingbo so we can discuss it more and come up with a better solution.
My preference is to use the first approach but duplicating the face can be tricky. That’s why I suggest reversing the steps. As we discussed in the other topic, I feel the Rhino plugin should automate the process of adding the apertures to interior walls when it is added to one of the two. If we can do that, then the process will look like this:
User solves adjacency for the rooms without the apertures first.
User adds the apertures. If an aperture is added to an interior face the plugin checks if the adjacent face already has the reversed version of this aperture.
If it does then sets the boundary condition for both of them.
If it doesn’t it automatically creates the inverse of this aperture for the adjacent face and then sets the boundary condition.
Basically, we need to change the add_apertures/doors/sub-faces method for interior faces. The same is to be said about remove_apertures/doors/sub-faces. If it is removed from an interior face, it should be removed from the other one.
One thing that I don’t know is if we do this for add_apertures/doors/sub-faces, do we also duplicate the geometry in Rhino? I feel the answer is yes because for every object in the Pollination Model we need an object inside Rhino but I’m not sure.
Thank you @mostapha for the insight. The process you explained would be the ideal one. One more thing to add. When we visualize the Geometry (internal apertures) under face property tab, indoor windows are denoted as skylight.
Hi @asisnath, after discussing with @mostapha, we have some ideas to support a workflow for adding single interior aperture geometry to rooms after solved adjacencies. I will start working on it in next a few days, and will keep you posted once it is ready for you to test.
Hi @asisnath, I just finished the first draft of this update to support adding interior apertures. The new version will be ready in an hour. Please take a look and let me know if it works as expected.
Thank you @mingbo . Perfect time to test as I have more 400 zones to built.after an hour I ill download from the link. I will let you know how it goes.
What can go wrong with only 400 zones? Thank you for testing this @asisnath. I’m sure you will find some minor bugs but I believe this is a step in the right direction. We will get you there sooner than later!
Thank you for testing this