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

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.

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

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.