Hi @Gspahr and @furtonb ,
I am sorry that it took me a while but I have finally figured out how to make this work. My initial assessment was correct that the issue only affects adjacent Faces with holes where the hole is closest to the upper-left vertex. I tried a few different ways to get the error to go away and have the simulation proceed but the only one that worked consistently was if I reversed the vertices for the Face that had the hole closest to the upper-left vertex (such that it now perfectly matches its neighbor).
I was a little nervous about doing this at first since reversing the vertices technically flips the normal direction of the surface in EnergyPlus. However, I think this should be ok because I implemented this in a way that it only affects Faces with an adjacency (Surface boundary condition). So this won’t impact the solar calculation at all given that these adjacent surfaces never have any outdoor sun exposure. Furthermore, we always override the volume of each Room/Zone in the IDF using our geometry methods in Honeybee to compute the volume. So this means that flipping the normal won’t cause EnergyPlus to incorrectly autocalculate the Room volume. Lastly, EnergyPlus runs successfully without any severe warnings related to the flipped surface. So all of this leads me to believe that this is probably a valid way to handle this case.
I imagine that the underlying source of the issue is that this E+ vertex size checking function isn’t built to handle the case where the upper-left vertex repeats itself in the list (as is the case when you need to wind inwards to cut the holes out of the shape and then come back out to the outer boundary to define the edges of the shape). So E+ must be matching the wrong one of the two repeating vertices to the adjacent Face. I might report this on the EnergyPlus GitHub since this feels a little bit like a bug. But I don’t know how interested the E+ developers are in addressing these edge cases for geometries with holes, particularly when it seems that I have found a workaround that enables us to still get a valid simulation.
In any event, the fix has just been merged into the code base:
You should be able to get it on your end using the LB Versioner within an hour or so.
I also verified that the larger 75-room model that you uploaded, @Gspahr , can simulate correctly after the fix. Let me know if it also fixes your issue @furtonb .
Thanks again for reporting the issue!