Possible error in solar gains

energyplus
#1

Hi

I am PhD candidate working on modelling non-conventional shading systems and I am currently a little confused about some of the results I am getting with Honeybee. I am modelling an external louvre-blade shading system and changing the distribution of the blades. When I use more conventional configurations (equally spaced blades) and change the number of blades, my solar gains, heating and cooling demand behave as expected. But when I started checking a little weirder configurations, like a packet of blades closer together located at the top or the bottom of my window, things stopped making sense. In these configurations, I essentially have less obstruction in front of my windows, but the solar gains are lower than if I spread my blades out, and this is true even when I have tilted spread out blades. I’m attaching a simplified version of myt script where the problem persists but I have also ran daylighting simulations and those followed expected trends with regard to the amount of obstruction in front of the window.
I’m attaching my script with the hope that someone can figure out what is happening and why Honeybee sees the packet of louvres ( called “all at the bottom” or “all at the top” in the script) as a big obstruction for solar gains.

Thank you !!
Ellika

EDIT: How do I upload my script? It tells me it’s not possible for new users…

#2

simplified shading.gh (813.2 KB)

Here is my script! :slight_smile:

#3

Hi Ellika,

I do not not wether this is the main cause of your problem but I wouldn’t recommend using Honeybee EP context Surfaces for EnergyPlus for the case you’re trying to simulate.

I believe that this component will write the shading surfaces out into Shading:Site:Detailed object in EP. This modelling method was designed to model things like buildings, trees or a simple overhang. It’s most suited for a few 2d surfaces generally spaced apart much more than a few centimeters.

The algorithm will compute where shadows overlap, and the polygon clipping method is now trying to solve overlapping shadows between all the surfaces of the 3d volumes that you are modelling. You can increase the precision with which this is done by inceasing the maximum figure field (see below).

I recommend using EP’s built in horizontal blinds model for modelling your blinds though. The large overhangs and frames you can model as EP context but I would turn them into one 2d surface per object and increase the shadowing settings.

Finally you do not need to model the ground as a surface in EP so I would take that out.

Gr,

Sam

#4

P.S.: Maybe you’re aware of this, but just in case: The ‘daylighting’ method you’re using right now only acount for directio Irradiation and the shading thereof. No reflections are taken into acount.

#5

Hi Samuel,
This could be the reason since the method works pretty well until the blades are very closely put together… so your explanation makes sense. The reason why I am not using the built in model is because in the full version of my script I’m modelling blinds with individual tilt angles and odd spacing. And as far as I know (but I’m still a noob), I can’t do that with the blind generator component. But maybe you know more than me?

For the daylighting, I deleted it in the script I uploaded so as to reduce confusion, but I am originally using radiance and calculating the illuminance in the zone with a normal independant daylight simulation :slight_smile: I just wanted to simplify my problem. And with radiance, even when the blades are close, it calculates illuminance values that make sense when I check different configurations. The issue only appears in the solar gains.

Cheers :slight_smile:
Ellika

#6

Hi Ellika,

An approach you could consider is to split the window into horizontally oriented segments. For each segment you can then set a different blind spacing and slat angle. Not sure how this would work out if literally every blind is different but if there are groups which are identical I think this would be a reasonable approach.

In EP blinds are a part of the window heat balance (so incl. radiative and convective transfer). Splitting the window will give a slight inaccuracy in convective transfer but considering you’re modelling blinds on the exterior this error will likely be negligible. I’ve done a sensitivity analyses using this method for describing the variable height indoor roller blind system I’m working on. Here the effect should be much greater but even in this case the it is negligible. In any case this situation will still be more realistic than when using Shading:Site:Detailed where the shading surfaces will only influence incident radiation.

Could be an idea to test the different methods in relation to Radiance. I think transmitted radiation behind the glazing for the whole window would then be the thing to test. In your daylight model you should be able to request irradiation (with the DAYSIM method this is possible) and enter solar spectrum properties rather than visual spectrum.

Are the blinds still static?

Gr,

Samuel

#7

Hi @SamueldeVries

There is an issue here, when you change the calculation method here to TimestepFrequency, the idf field does not change for me. Have you checked that?

And the other thing, when you use hb context, honeybee assigns 20 percent reflections by default for surfaces without any transmission.

Regards
Amir

#8

Hey guys,

This approach can be really helpful, specially you will be able to define window groups and use BSDF method for your simulations.

#9

Hey

I was hoping to be able to have pretty random blade distributions, so splitting my window is a bit tricky unless I can define the size and number of windows after I define where there are blades and where there aren’t blades. But the blades are indeed static so that simplifies the problem.
I know that using context doesn’t account for convection and radiation, when I had checked the difference between using context or shading, for my case at least, because I’m not modelling a highly reflective material, the difference wasn’t too big (I ran a bunch of cases and typically ended up with about 0.05-0.15 kWh/m2 difference in heating and cooling depending on the angle of the louvres).

@fazel.ganji I think I will try what you suggested in your email :slight_smile: I’ll let you know if I need any help

Thank you so much, everyone!

#10

Hi, just wanted to let you know in case you are interested, that there is a way to change the reflectance of context surfaces using a small piece of code in Python. I found the solution in a different conversation but it’s implemented in this file EnergyPlus_Simulation_ContextReflectance.gh (538.1 KB)

best regards
Ellika