Hi everyone, sorry to be a pain again, but here is the deal: I’m currently on my masters degree and learning how to use Honeybee, I’m modelling a famous street in my city in two distinct moments in history, so I can run simulations within Honeybee in order to assess thermal comfort parameters, however, this is probably the third time I’m modelling this street, I tried the simplest geometries I could, but still, in the end of the first simulation, I still get this error at the end:
The simulation has not run correctly because of this severe error:
** Severe ** ProcessSurfaceVertices: Suspected non-planar surface:“ZONE_301_SRF_4”, Max “out of line”=0.15680 at Vertex # 1
So which kind of surfaces or polygons does Energy Plus supports in order to run a simulation? How can I detect which one of the geometries is causing the error so i dont have to model it all over again? Could some one help me?
The files I’m using are bellow, there’s one for each moment in the history of my city (1940-1980-2020) I pasted them on Google Drive
EnergyPlus exclusively accepts planar geometry (and it has a few other annoying geometry rules that we try to automatically take care of under the hood but, as you can see, our legacy honeybee translators are not 100% error proof).
As a start, it would probably help to planarize your geometry before you convert it into HBZones. The new LBT plugin has a component for planarizing geometry, which you can use for this purpose:
At the least, this will allow you to see what the geometry looks like in EnergyPlus so you can identify the places where you should clean up your geometry.
Hi @chris, first of all, thanks for being so helpful, I’m trying the HB Planarize Brep, but I’m getting the following error at my end, you know what probably is doing this?
Wow, taking a look at one of your Rhino models, I think you might have found a bug in Rhino. I have the RhinoCommon Surface.IsPlanar method returning True for one of your geometries that is definitely not planar to within the tolerance. And I can see that Rhino subdivides it into faces when it meshes it:
Given that McNeel team is not really developing Rhino 6 anymore, I don’t know if we have much hope for the bug getting fixed but, instead of my suggestion with the “Planarize Brep” component, I recommend you just mesh all of your geometry (see below) and then you can find all of the places where you get crazy subdivision like what you see in the screenshot. Those are the places that need to be cleaned up into something planar.
FYI, if you extrude the footprints, the geometry will always be planar. Maybe you were able to get a model like this because you were working with one set of units and tolerance and then you changed it. But I would guess that you probably did not create this geometry by extruding it.
Good morning @chris! So, summarizing, this that I’m going through is actually a bug within Rhino? I’ll try these steps that you mentioned to see if i can run the simulation properly, I’m trying to simplify the whole geometry as much as I can, but still, I’m getting this error.
So, as you were saying, if I mesh the whole geometry, maybe it works?
And by the way, I modelled the whole geometry by creating surfaces, and then extruding by turning to solid polygons, is it a good way to model?
Yes. But thankfully it looks like all of your footprints are ok. I would just re-extrude each footrpint to the height of the building and then it should all be planar. You can even write a small Grasshopper script to automate this.
Gosh, really confusing, I ran a simulation perfectly before, now it doesn’t work anymore, I tried to remodel the whole geometry by only using solids, not creating surfaces then extruding it, and still doesn’t work.
I’m a real rookie when it comes to computer scripts, which one is it? to check if it is planar or not?
Hi @chris! I managed to do a workaround and now each plan from each timestep that I’ll analyse is working just fine, thanks a lot for all the help as usual
Thanks for making sure that this did not fall through the cracks, @wim . I just tested it in Rhino 7 and it seems the bug is completely fixed there. So another option for @Dconforte is to just use Rhino 7 instead of Rhino 6.
