Sorry, can't help you with fixing what look like to be dozens (potentially hundreds) of surface conflicts with FloorspaceJS. I suspect few can, given the size and complexity of the (illustrated) geometry - fingers crossed.
Your post has a 2nd question: what are the impacts on EnergyPlus results? The resulting EnergyPlus model will inherit many, many surface "slivers" (the width of a hand, or worse a finger), surface overlaps, etc., either pushing EnergyPlus to operate outside of the intended scope of many of its underlying models (e.g. surface heat transfer coefficients), or to disable many of its automated, geometry-related calculations. Yet EnergyPlus is fairly forgiving. I'm sure you've come across warnings in the eplusout.err file on unenclosed zone geometry, with EnergyPlus instead relying on floor area (m2) x ceiling height (h) to determine zone volume (m3) - one of many examples. For fairly regular geometry (e.g. flat ceilings), that automated fix is generally OK. Yet for other room geometries, it won't be. So it really depends on the simulation objectives vs geometrical complexity.
If ...
- one had an hour (or so) to clean up such a model
- the building were fully heated/cooled (21C to 24C)
- the objective is to simply estimate e.g. monthly energy use (GJ)
- ... i.e. no detailed daylight or thermal comfort assessment
... then one could try the following:
- Run a simulation with extra warnings output.
- Retrieve the reported floor area and ceiling height of each zone, and hard-set the zone height (h), floor area (m2) and volume (m3) in the IDF. This will disable a number of automated checks/fixes.
- Prioritize envelope (e.g. outdoor-facing) surfaces over interzone surfaces. Fix the envelope surfaces first, based on what the eplusout.err file reports. If there are conflicting interzone surfaces (mismatched vertices or construction layers), either change their boundary conditions to adiabatic or delete them.
- If you delete surfaces, compensate the drop in zone thermal mass by either overloading the floor construction or via InternalMass objects.
These are worse-case, back-against-the-wall suggestions ...
