Heat gain via window conduction in summer in a cool climate

This may be related to Understanding the Load Balance Component Assumptions.

We (@MichaelDonn and I) have another weird energy balance issue.

As you can see, in the cool climate of Auckland, New Zealand, we have a significant amount of heat gain via conduction through the windows for seven months of the year.

We cannot track the error in our logic and wonder if this is another case for @chris or a mistake on our part.

Any and all help gratefully received.


And here’s the test script - the result of the first week of Anthony learning the script as part of a summer scholarship research project…

It seems odd to me that, in addition to the heat conduction from outside to in, which would makes sense only in a much hotter climate, the Delta/Storage heat loss term in the graph almost exactly matches the Window Conduction Heat Gain…

Yet more list processing I do not understand.

The goal is to sketch model a small office building.

The test script converts a plane (Rhino Surface) drawn on a Layer named Plan. One then assigns a number of storeys and interfloor height, to generate a prototype.

Running some simple sliders for window areas and shading and wall depth and so on creates in put to an Ïdeal Loads" HVAC specification which then connects to a load balance.

With the HB Straight Skeleton we create 4 perimeter and 1 core zone for a ground a middle and a top floor.

Run straight through to the HB Annual Loads component produces this weird Load Balance:

We create the 3 levels by copying the base floor.

This creates 15 Rooms

In trying to figure out this we tried separating the list of 15 rooms produced by the Ideal Loads Component, and reattaching them as individual and then grouped inputs to the HB Annual Loads component.

Individually they worked as expected. In groups by orientation they worked as expected. Finally, we had them all attached, and they still worked as expected:

In other words, with this new list configuration connected to the HB Annual Loads component, the results were very different, with no weird Window Conduction Heat Gain!

The Delta/Storage component does seem worrisomely large.

But, I am thinking that I am missing something all important. Note: each level works well fed into the ideal loads. The error seems to be when we connect more than one level to the ideal loads component (with or without the inputs and outputs flattened)

Thank you in anticipation of your kind responses

I have identified the source of the problem, but not the solution!

The issue is the circled component in this image.

The idea of a multiplier is that when we model a multi-storey tower, we model the top and bottom floor, then the representative intermediate floor is multiplied by the number of intermediate floors there are in the tower.

It is the inclusion of this multiplier that is creating the problem in the output.

WITHOUT the multiplier but combining the three levels

WITH the multiplier and combining the three levels

WITH the multiplier, but just the middle level

WITH the multiplier and the ground floor plus the (multiplied) middle floor

WITH the multiplier and linking all three outputs to the next hb_objs input in the chain

Why adding more levels to the inputs should now make the energy flows per square metre any bigger is beyond me. And why the previously used grasshopper component should do something different is also WAAY beyond me?

In Summary:
with the levels combined via a component where

  • Input D1 is the ground Floor,
  • Input D2 is the (multiplied) middle Floor(s)
  • Input D3 is the top Floor
    The result is this weird Window Conduction is Heat Gain not, as the climate would imply Heat Loss

with the levels combined via a component where

  • Input D1 is the (multiplied) middle Floor(s),
  • Input D2 is the ground Floor
  • Input D3 is the top Floor

The result is

AND WITHOUT the Multiplier and with the three levels via a component where

  • Input D1 is the ground Floor,
  • Input D2 is the (multiplied) middle Floor(s)
  • Input D3 is the top Floor

The result is this:

Given that the middle floor is multiplied this last graph is what the results should look like, even when the multiplier is applied as the results are per square metre!

Hi @MichaelDonn ,
Don’t have a solution for your questions, but have some comments.
Is there something in the workflow when using multipliers that is not clear (to me) in the HB interface and i believe is what is making you trouble.
If i wanted to use the multipliers in your case i would use only one floor and give, say, 9 as a value to multiply. This will include the ground, middle and top floors. This is how the option works in Dragonfly (i believe).
In your case you are moving the middle floor to be somewhere at mid height. The multiplier will take this floor and “copy” it from that place above it. This is a mistake (almost) for sure. BTW, the calculation of this height is wrong. It is 17.5 and should be 20.
Question: when you use the WOTHOUT multiplier option, do you solve the adjacencies between floors? Didn’t see that in the GH file, where you solve that at the floor level.

I’ll be glad to understand how the workflow with multipliers should be in HB.
Also i wish to have the possibility of visualizing the building fully (with the multiplied floors) as DF does.

Until all this is clear i recommend to model the whole building. @chris 's comments are needed here to shed some light.


Thanks @AbrahamYezioro - you make some interesting points that challenge my understanding of how LBT works.

in my mind, there is a huge difference between modelling for appearance (for the model to look like the final building) and modelling for accurate and efficient representation of energy performance. The way we are modelling has been the convention for accurate energy modelling for decades.

This approach was confirmed by a paper out of NREL https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=744a45dbc6b04a9f399a2f55b4d9edcbf3fd2b2d

Back in 2005 in relation to the original plans for the super-tall Freedom Tower Ellis and Torcellini concluded that multipliers give an accurate picture of even that 100 floor building “…as long is that [multiplier] floor was at mid-height.” They did note that if that building was in amongst a bunch of other lower buildings, then the shading from them might need a multiplied floor mid-height amongst the nearby shading buildings, plus another with a different multiplier for the floors above the shading buildings. The majorly different floors, the ground and top floors, need to be added to these multiplied floors because the ceiling and floor of the multiplied floors are not modelled as adjacent to the other floors, but as being adiabatic.

Li Jing, in a recent PhD looked more closely at the effect of the adjacent buildings Urban Microclimate Analysis for High Performance Office Buildings. This combined CFD modelling (Butterfly of course) for local winds, UHI modelling, incorporation of the decrease of temperature with height and demonstrated clearly that these microclimate effects can make a 20+% difference in the energy use.

To my knowledge, the approach @anthony.schneider is taking is energy modelling good practice. The multiplier in EnergyPlus practice just takes the mid floor (at the half way height point) and multiplied the results for those rooms/zones by the multiplication factor. No increment in building height.


Hi @MichaelDonn ,
Interest discussion becouse it will set, hopefully, the correct workflow in LBT.
Though i’m not using multipliers frequently i’m aware of the advantages in doing so, especially on high (rise) buildings. Thanks for the sources.
Made some homework after your last post. You are right the recommended way of modeling the mid floor is locating it at mid height. You can see that here in bigladder. They recommend for very high buildings to model more than one mid floor.
Saying so, i also checked the workflow used in the DF example rooms_to_stories_to_building. There the approach for the multiplied floors is not as the previous comment. The copies start from the modeled story and above.
Attached one version of the file, where I isolated the mid floor in the example.
rooms_to_stories_to_building_AY.gh (246.7 KB)

Right now i’m a bit of confused about what the “correct” procedure would it be in LBT. Hoping @chris make this clear.


Hi @MichaelDonn,

I took a look at your script and think the problem come from assigning “Air boundary” to the adjacent geometries.
I had some similar issues with Airbounadry balance visulization. I think since in airboundary enegy plus models them as solar enclosure HB balance might be still have some troubles to assign them on proper rooms as stated in this post

When I dissable the airboundary the results becomes as expected:

1 Like

Thank you for demonstrating this @Hamidreza.

Air boundaries between zones on a particular floor allows heat and radiation flow, but not mass (air) transfer. This should be a standard, default approach allowing daylight for example to spread across the core as well as perimeter zones.

However, I will look into testing this idea further. We certainly want to model a building that is open plan, not one with separate “rooms”, even though the terminology of LBT is about “rooms”.

1 Like