Missing wall-wall and roof-roof lines in thermal bridge report

Hi everyone, i have used this a bit and i think i noticed something. When we have 2 adjacent blocks and want to isolate only one block it did not get the wall-wall or roof-roof lines to the adjacent block even with including co_planar.

Hi @aishanuraaa, thank you for reporting this. Can you share a small model or a screenshot with us so we can recreate this issue?

Hi Mostapha, sorry for the late reply. Here is an example of houses side by side.

When I isolate number 102 with component HB rooms attribute the yellow line is also missing.

I expect that even when I isolate 102, the thermal bridge to 103 is still appearing.

Thank you, @aishanuraaa! Can you also upload the sample file that you used to make our life easier. :smiley:

I think this is the expected behavior. Without the adjacent room, we cannot identify what type of thermal bridge it is. You can always reset the adjacencies by using the “Merge Coplanar Faces” command and then you’ll see the line show up as a thermal bridge with an exterior boundary condition. But we don’t know that the room is adjacent to another one when that adjacent room is not passed to the thermal bridge report routine.

What you are asking for here where you still calculate all thermal bridges across the whole model and then filter the result by a selection of rooms requires a different backend architecture.

With the help of @antonellodinunzio , I think we can find a way to do this type of filtering based on the selection.

@aishanuraaa,

I still think sharing a sample file will be very helpful. Are you using the Model Editor to generate the graphics or using Grasshopper? Can you please share more context in addition to the screenshots?

Hi, sorry for the delay. Here is the GH file.

preview_envelope_edges2 - vector.gh (272.9 KB)

Thanks, @aishanuraaa .

I did not realize you were working in Grasshopper. Getting what you want in Grasshopper is far easier than changing things in the Model Editor. I can just tweak your Grasshopper script to do what I recommended above:

However, to do this, I need to have your full original model internalized in the Grasshopper file. I only have a part of it here:

If you can get me your full model, I can give you a script that does what you want.

Chris, I think that is the full model. Could you work with that or do you mean other kind of internalised model like the brep?

I also noticed other things, the lowest window frame overlaped with the floor. Is the expected outcome to keep both or the green lines should be cut by the window frame like the picture below? If it is possible, I would expect that the green line and blue line not overlapped.

Thanks, @aishanuraaa,

I had assumed that there is more to the model because there is this Surface boundary condition at the end, which I presumed connected to another part of the model:

But, if that is actually supposed to be an adiabatic boundary condition at the end, I can just patch the missing adjacency.

The more I looked at this and the other topic you posted, I think you just want to do your own custom post-processing within a GHPython component. You can see in the Grasshopper component source code that all of the edges are associated within individual room faces here in the function that classifies the edges of each room:

So you can just pull off the orientation of the thermal bridges by analyzing those Honeybee Faces and those Faces are also what tell you the room associated with each edge.

When I get the chance, I’ll put together a custom GHPython component that should give you everything you need to do your custom analyses. I am thinking it just gives you each thermal bridge edge and that Honeybee Faces associated with it so you can you your own custom analysis of these faces to evaluate what type of thermal bridge it is and what orientation it is facing. I’ll include a room_filter_ option so that you can get the result filtered by a subset of rooms in the full model.

Yes, in my experience, the way you account for thermal bridges of fenestration is very different than the way you account for things like a wall-to-slab-floor connection. So you would typically want the fenestration thermal bridge accounted for separately so that you can consider it’s impact on things like edge-of-glass U-value. And you would want the floor-to-ground connection separate to account for things like how the floor insulation wraps around the footing or whatever foundation element is holding up the exterior wall.

If you’re using some other thermal bridge method that is different from the ones I am used to, please describe it clearly and I’ll think of the best way to support it with the current core libraries and Grasshopper components. In other words, do you just want the fenestration thermal bridge discounted in this case? Or should the fenestration thermal bridge be overriding and splitting the ground slab thermal bridge.

Hi @aishanuraaa ,

You can find a script below that uses a couple of custom GHPython components with a few lines of code in them that leverage the honeybee Python SDK. These custom components use a some new methods that I just recently added to the Python SDK so that you don’t need to have as much code inside the components themsleves. So you will need to run the LB Versioner component and restart Rhino to get the latest Python libraries in order to use the following Grasshopper script:

preview_envelope_edges2 - vector.gh (284.2 KB)

After this, these new components and .gh file should allow you to do all of the customized analyses that you are hoping to perform on the different room edges by giving you access to the room face objects that adjoin each edge.

Here is what the full script looks like:

You can see that it’s broken down into two parts. The first does the whole calculation of envelope edges (including an option to filter the output by rooms) and it returns each envelop edge along with the Honeybee Face objects that adjoin it.

The second part uses the edges coordinated with faces to filter the edges by the type of edge (eg. Roof-to-Wall). It also gives you the orientation of each edge as dictated by the adjoining faces addressing your request here.

This allows you to get the individual room edges for a subset of the model along with the direction that each edge faces:



… Or you can get the orientations of edges for the whole model by disconnecting the room_filter_:

Since the script pretty clearly works to filter the edges by rooms, I am going to unassing myself from this issue but just let me know if you have any questions about it, @aishanuraaa, and I’m happy to reassign myself and answer.

And, if you have future types of custom analyses that you want to perform on the envelope edges, I would recommend opening topics on the Ladybug Tools forum instead of here on the Pollination forum.

Once you cross into the real of making custom Grasshopper components with the Ladybug Tools SDK, you are more in the realm of Ladybug Tools rather than Pollination.