Topologic <> HBJSON

I have started writing a translator from Topologic in Blender/Sverchok to HBJSON. It was suggested by the ladybug tools team that I start a thread here to get advice and feedback. In particular, it would be great if the community can contribute python code snippets for adding more features to the translator and to also verify the outputted HBJSON file. I will soon share everything on github. For now, there is one file that I am outputting as a test. It is called TopologicBuilding.hbjson. It has four perimeter zones per floor and one central core shaft. Floor heights are not realistic (10m) with a total height of 60m. The file can be found at:
TopologicBuilding.hbjson

3 Likes

Thanks for doing this @wassimj . This is exciting!

You can find plenty of sample HBJSONs and the code snippets that generate them on the honeybee-schema repo. The samples that contain the word “model” are going to give you complete Honeybee model definitions that you can use for reference.

You will also probably find this central page on the Ladybug Tools SDK helpful, specifically this link on that page to the docs of the HBJSON schema objects and this high-level overview of the HBJSON schema.

Lastly, If you install the Ladybug Tools core libraries using:

pip install lbt-dragonfly -U

Then, you can use this command to validate any HBJSON file that you have produced:

honeybee validate model [MODEL_JSON]

If I run the command on the TolologicBuilding.hbjson that you uploaded here, I can see that there are several cases of mis-matching adjacent constructions, which would make this HBJSON un-simulate-able in EnergyPlus:

Hope that helps and let us know if any questions arise.

1 Like

Thanks @chris! This is very helpful. I will share my script soon so people can take a look and perhaps spot the errors and gaps. Obviously I am new to HB, but have written the software to build an OSM file, simulate it, and display the results. This geometry was used for that. What is surprising is that I didn’t actually assign any construction material (as you can see it is generic). What I did is that I added all the topologic cells as rooms and asked HB to resolve room adjacencies. So ceilings and floors should be perfectly matched because the faces originated from a non-manifold model (so the exact copies of the same face end up as floor of one cell and ceiling of the one below it).
Thanks again and I will download the validation tools and continue to check. This is really helpful.

Hi again @chris . Found out something strange. If I do NOT call Room.solve_adjacency(rooms, 0.01), it reports that my model is VALID. If I do call it, it reports the errors that you listed above!

Does that mean your floors and ceilings have the same surface orientation, i.e. the normals have the same sign? Auto-assignment of mirrored materials for adjacent surfaces probably requires surfaces to have the opposite sign, (should be convention for 3D volumes?). Although I would be surprised if this is the problem, since I would expect flipped normals to create issues further downstream though…

Makes sense, if there’s no adjacency solving, then default assumptions for surface constructions and boundary conditions don’t have to account for their neighboring surface, so you won’t get errors.

Does that mean your floors and ceilings have the same surface orientation, i.e. the normals have the same sign? Auto-assignment of mirrored materials for adjacent surfaces probably requires surfaces to have the opposite sign, (should be convention for 3D volumes?). Although I would be surprised if this is the problem, since I would expect flipped normals to create issues further downstream though…

First, thank you for your reply and help.

In the original non-manifold model, surface orientation of interior surfaces cannot be assumed to be one way or the other, but once I create Topologic Cells (manifold solids – which is what I am doing here), all surface normals point the correct way (outwards).

Makes sense, if there’s no adjacency solving, then default assumptions for surface constructions and boundary conditions don’t have to account for their neighboring surface, so you won’t get errors.

OK, but then does this then mean I have to encode the adjacencies myself? Will it simulate accurately if I leave it as is without resolving the adjacencies?

Obviously, given that Topologic is all about topology, reporting on the adjacent surfaces and cells is trivial for it. I just didn’t think I would need to do that in my own code. However, for my code for openstudio, I actually classify each and every surface according to: exterior wall, interior wall, interior ceiling, interior slab/floor, roof, and ground slab. I will try to see in the code examples if HB have similar assignments for deciding how to assign construction material. Any pointers are welcome. Thanks again.

Your simulation will work, but your adjacent surfaces will be interpreted as being exposed to the outdoors, so it’s not correct from an accuracy perspective, you’ll need to resolve the adjacencies at some point. One exception is that floors/roofs for multistory buildings can be assign a boundary condition of “Adiabatic” if we assume there’s marginal heat transfer between floors. This is usually the case given conditioned floors, and thermal resistance from plenums/structure/fire protection in floors. You don’t have to solve adjacencies when you are using the “Adiabatic” boundary condition, since there’s no heat transfer between surfaces that’s going to occur.

I was going to ask why a software called Toplogic was using HB’s surface adjacency matching method :slight_smile:
How does Toplogic identify adjacent surfaces, and what’s the time complexity? HB uses bounding boxes to omit surfaces, and then has a quadratic time complexity for bounding boxes that intersect with the surface looking for adjacencies.

The Dragonfly repo has a to_honeybee method that illustrates how to assign the correct surface properties from a simplified model, similiar to the model you’re describing.

That won’t do of course. OK, so I first I will check who resolve_adjacency is not working. I have followed the exact same code as in the examples. I am not doing anything fancy. Failing that, I will encode the adjacencies myself using Topologic.

Yeah. Same issue with openstudio. The problem is that most energy analysis software assume you are coming from a traditional CAD/3D modelling environment (all manifold) and you are not able to compute topology. So, it is more expedient for Topologic to simply ‘dumb down’ to manifolds and pass that data on to be re-computed. Sad really!

I don’t know what the time complexity is because we depend on the opencascade engine to do the non-manifold stuff. We don’t roll our own intersections etc. Once a CellComplex is built, then all adjacencies are cached (until you modify it of course): Topologic Github Repo

Thanks. Will look into it.

Hmm, I thought I understood what you meant by topology, but this comment confuses me. Why can’t you compute topology with typical CAD assumptions?

What’s a manifold versus non-manifold geometry in context of thermal zones? My interpretation of manifolds is that they’re a type of projection onto another (usually lower dimension) space. And I interpret topological geometry as geometry that preserves its properties when its being deformed (i.e. like a graph that preserves adjacencies). I’m not sure I see the connection between the two in the way you are referring to them.

Please see my video playlist to see how Topologic work:

Here is a paper (not by our team) that explains non-manifold topology (as we use it):

3 Likes