Sorry for the late response here,
@CharlesCollin, yes more complicated surface subdivisions may cause issues. However in most cases this can be eliminated (or at least reduced) by logically subdividing your mass into thermal zones to reduce awkward surface overlaps (i.e convex overlaps), which is the main reason why the OS method is producing lots of subdivisions in this case.
@chris, thanks for explaining this in such detail, it’s clear that you and Mostapha have thought this through in detail.
While it is unfortunate that the OpenStudio team isn’t also releasing python bindings, why not just support tight integration by accessing the OpenStudio.dll through the C# bindings, like you guys are doing so already?
if openStudioLibFolder not in sys.path:
import OpenStudio as ops
And then just use ops to create an osm.spaces that can be coupled with an HBZone? The C# bindings are supported so it should be a safe choice I think.
However, I will admit there are some advantages to keeping the osm model and hb model separate (i.e reducing redundancy between the two, preventing state mutations upstream etc) so I can understand if you guys would prefer to keep them separate until the Run OSM component.