Input _geo is not a closed volume

Hi @chris,

One more issue on the big Hospital project.
It could be because of the complex geometry, but on some places the defining of the zones and adjencies is not done correctly with the new LBT tools. Although all Breps are closed I get the following warning.

  1. Input _geo is not a closed volume.
    Room volume must be closed to access most honeybee features.
    Preview the output Room to see the holes in your model.

Even when I look at the output, all Breps are still closed. After passing the solve adjencies, some floor and ceilings where converted into exposed floors and roofs.

I generated the 3d breps out of the legacy HBobjects dump (Load HoneybeeObjects). With the old model there where no problems. I cleaned up the old Honeybee breps with merge faces, which went pretty well.
When I ran this cleaned up geometry trough the Legacy pluginn there are still no problems and all adjencies are well defined. In the model I attached both workflows are compared. (926.4 KB)

1 Like

Thanks @Erikbeeren ,

It looks like this was one of the cases where the Legacy components “failed silently” and didn’t let you know about an underlying issue with the geometry. What is probably happening is that the tolerance of the Rhino model changed at some point over the lifetime of this geometry. It might have been coarser at first, causing the Rhino Brep to record an attribute of “closed brep” but, in the current Rhino model tolerance, it is actually not closed and there’s probably a gap somewhere. You can narrow down the problematic room by looping through them with a slider.

In any case, you see that the components should still let you simulate the room. The only potential issue (which was not reported in Legacy) is that the vertex-ordering for the room that’s not closed might not be correct. The LBT plugin has some pretty robust checks for ensuring that all faces follow the right-hand rule in their vertex ordering (which E+ requires but Rhino does not). And there are also robust methods in LBT to ensure that Faces point outward from the room (another E+ requirement) but these checks only work when the room is closed to within the model tolerance. In Legacy, we had far less robust versions of these checks so there were times where faces would get sent off to E+ facing the wrong direction causing the issue that you see here:

For those cases in Legacy, the quality of your results could get compromised without you knowing it. So it’s actually a good thing that the “HB Room” component is alerting you to the issue here.

Also, I don’t think I get the same adjacency issues that you have:

But I know there was a bug in the LBT “Solve Adjacency” method that we fixed between the last stable release and now. Do you still get the issue after you run the LB Version an update to the latest core libraries?

1 Like

Hi @Chris,

Thank you for all the tips. Finaly I got the model running without warnings. Although all geometry was correct -I really couldn’t find any inaccuracies- the warnings kept comming. But then I tried the old intersectMassII component and warnings where gone.

I added the grasshopper script so you can have a look. (801.2 KB)

Ah, thanks @Erikbeeren . So the issue wasn’t with the “HB Room from Solid” component, then. It was with the “HB Intersect Solids” component. You can see that it’s giving you an Invalid Brep and that’s the room volume that is not closed:

I will try to investigate when I get the chance and I opened an issue for it:

1 Like

Hi @Erikbeeren , I see you are getting an error of Input_geo is not a closed volume.

I recently encounter this error too and I found the solution. But its kinda in a complex way. I had to recreate my geometry.

I got this error because I redraw my geometries by using a DupFaceBorder command on Rhino from my previous geometry. So basically, this command creates a closed curves from an object. Then I ExtrudeCrv and make a polysurfaces. And so on. And also, making sure that all zones are intersect each other using Intersect command on Rhino. Then, I put it all together the geometries into a multiple breps. The HB Intersect Solids works fine and it outputs of all Closed Brep. But somehow, when I connect it to HB RoomSolid, it came an error saying its not a closed volume. I had to look at the output of HB Intersect Solid to make sure its all Closed Brep.

By the time I got this error, I somehow, by frustration, redraw it myself manually using a polyline curves (which this takes more time) to create a geometries, but however it works. The HB Intersect Solids component doesnt output an error.

I think this error might be a bug. Maybe from Rhino, Grasshopper, or it could be LBT.

Thank you for your advise. Actualy we construct our models by splitting up the floor surface with inner wall lines and extruding them. In most cases it works realy good. Only with real complex models we discovered that the intersect mass II from mingbo peng works faster and more reliable than the new one from the LBT suite.

I want to report that lately (couple of days ago) i started to get the same warning (input _geo is not a closed volume). I didn’t change the original geometry, so i assume some update caused the warning.
For the sake of the testing i checked a single box and the error sticks.

Tried to pass it through the intersect mass (LBT and Legacy) but no use on them.

Any ideas and thoughts?

Updating to 1.2.2 solves the problem.


Yes, we updated the functions that check the room solidity. So you just need to make sure the components on your canvas and the installed version of your plugin are in sync.

Hi @chris, I have updated and synced my components but am also sometimes still getting this error, despite everything seemingly running smoothly: (196.6 KB)

@MaxMarschall ,

This is a case where the room Brep probably has an invalid Face in it, which is causing the honeybee volume to not be closed. The invalid face must be added because of the intersect masses code in the LBT plugin. I still have to investigate and fix the issue that @Erikbeeren raised at the top. In the meantime, the solution that worked for Erik works for you. Just use @MingboPeng 's IntersectMassII component until I get the chance to investigate this further:

@Erikbeeren and @MaxMarschall ,

Sorry that it took me a few months to get around to prioritizing this issue. I’m happy to say that it was really easy to take the same underlying method that @MingboPeng implemented in the Legacy “Intersect Mass II” and transfer it over to the LBT plugin. Mingbo’s solution is much more elegant and reliable and we owe a big thanks to him for figuring out the best Rhinocommon methods here. I just merged a fix into the LBT plugin that uses the new method:

And, when you update with the “LB Versioner”, you should now find that the solid intersection methods are as reliable as Mingbo’s “Intersect Mass II” but the LBT component should run in half the time when parallel_ is True:

Thanks again for reporting and helping get to the bottom of this one.


Thanks @chris!

How can I be sure that the versioner updated the components properly? I see that in your definition the new IntSolid component is still called 1.2.0?

Assuming the update was successful, I’m still getting a slight discrepancy: (140.6 KB)

@MaxMarschall ,

You don’t see the component version change because the edit was made in the ladybug_rhino core package and the code within that specific component was unchanged. As long as you run the “LB Versioner”, your core packages will all be updated. You can verify for sure by checking the version number in the following folder:


From what I can see, your sample file seems to be equivalent between the two components:

Strange, I’ve opened my original definition and it works for me now

Thanks for clarifying!

Perhaps you forgot to restart Rhino/Grasshopper after running the versioner as had happened in another topic.

1 Like

Hi @chris maybe it’s worth adding a popup message window for letting users know restarting Rhino after the update is required.

A popup sounds useful and I think there’s a way to do it in IronPython if I remember correctly. I opened an issue for it and I’ll try to add it when I get the chance:

@chris, I’ve been having some really bad luck lately with “Input _geo is not a closed volume”: (28.2 KB)

The “before” geometry is the one in the brep component; the “after” geometry is the baked geometry from the Visualize component.

The only difference I can see is that the latter has a few extra faces and diagonals in it, however you can see that both Grasshopper and Rhino consider both geometries to be closed solids, and yet I still get that warning message.

Any ideas for how I can prevent this from happening?

Hi @MaxMarschall,
Just project the building boundary on ground level, make a surface of it and re-extrude it to a volume. This will probably solve your problem. The error occurs most probably because of these triangles. It could be they are not exactly aligned to each other.

1 Like