AirBoundary not considered fully transparent by Radiance?

@chris, in this example I have two rooms separated by an AirBoundary. The northern room is highly glazed; the southern room has no glazing.

When I run this through a daylighting simulation, the southern room receives daylight despite having no windows, which is expected because it shares an AirBoundary with the sunny northern side of the space.

However, the AirBoundary appears to act as a barrier beyond which there is much less daylight, almost like it was only half transparent.

I have tried defining the AirBoundary as a fully transparent glass but have noticed that the Glass Modifier doesn’t allow me to specify anything higher than 0.918:

With 0.918, I get the exact same result as when I don’t specify a modifier:

I have also tried the Translucent Modifier. I would expect that 0% reflected light and 100% transmitted light would translate to a fully transparent material, but with these settings no light appears to pass at all:

Any help on how to solve this would be much appreciated!
AirBoundary effect on UDI - mm.gh (53.4 KB)

Thanks, @MaxMarschall .
I can confirm that the air boundary is being modeled as a glass material with 100% transmissivity:
image

And you are correct that 100% transmissivity glass seems to result in this odd break in both daylight factor and point-in-time illuminance. I also seem to notice it in the point-in-time-view image as I can kinda see the 100% transmissive surface.

@mostapha , @sarith and/or @mikkel , do you have any idea why this would be the case in Radiance? Is 100% not the maximum transmissivity for glass? Or would you recommend just excluding AirBoundary geometries from Radiance models entirely instead of trying to use a 100% transmittance modifier for them?

I would go for this option.

Thanks for the input, @mostapha , but I realized that removing the air boundary geometries might involve more time to implement than I realized and Greg has already given some guidance on how to make a completely invisible modifier:

https://www.radiance-online.org/pipermail/radiance-general/2003-September/000998.html

I might just implement this invisible trans material for now and, if we decide later that we want to completely remove the geometry, we can do that at a later point.

I verified that Greg’s trans modifier is simulating as intended:

… and I am working to implement the change in the core libraries now.

The new AirBoundary material has just about made it’s way through the core libraries and, within an hour, you can get the fix on your end if you use the “LB Versioner” and set clean_standards_ to True like so:

image

Thanks for reporting the bug, @MaxMarschall . You are indeed worthy of the title, “bug-finding machine.”

2 Likes

Hi @chris I had no idea that was my nickname but I’ll happily take it :smile:

Re Greg’s solution, I can confirm that when I set the _diff_ref input to 1 instead of 0 I also get the smooth result.

Re your latest update, what exactly did you change? If there is supposed to be a new AirBoundaryMaterial component, I can’t find it. Instead, I am now getting this error message:

It persist even after pulling a new DaylightFactor component from the ribbon

FYI I have also noticed that the glass modifiers don’t reflect what is given in the input:


The values that are passed on are higher than the input. In the above example they fall just short of 1, which explains why the upper components throw an error. Is this intended?

My bad, I was too eager and forgot to restart Rhino. I realise now that airboundaries are automatically assigned that fully transparent material - thanks!

Still curious though about the above regarding the modifiers.

Radiance uses transmissivity for the glass modifier. Usually we only know the transmittance, which is the _trans input. The formula is:

tn = (sqrt(0.8402528435 + 0.0072522239 * Tn * Tn) - 0.9166530661) / 0.0036261119 / Tn

tn = transmissivity
Tn = transmittance

That’s why 0.918 becomes 0.999654936013.

You can also see formula in this definition (get_transmissivity):

2 Likes

Glad to hear that is all worked and, yes, the change was just to the air_boundary modifier that’s included in the honeybee defaults. I changed it from a glass modifier to a trans one that I am certain is invisible.

And @mikkel 's explanation is 100% correct.

@MaxMarschall
Hello, I’m sorry to bother you. My software has been updated to version 1.5, and I encountered problems similar to yours. How did you solve them?

Hi @omen,

I saw your post and looked into it yesterday. I know why it happens and will try to fix it ASAP.

The reason why it does not work in annual-daylight is because the recipe was recently changed to account for simulating aperture groups. In this change sensor grids are connected to light paths, and since your first room has no light paths it fails. Ideally it should inherit the light paths of the adjacent room.

2 Likes

Hi, @mikkel
Thank you very much for your reply, this problem has been bothering me for a long time, looking forward to your version of the fix, have a nice day! :grinning:

1 Like

Hi @omen,

I have pushed a fix. You should be able to get it within an hour by updating the core libraries with LB Versioner.

3 Likes

Hi, @mikkel
Thanks for the quick fix, I updated the core libraries with LB Versioner, and now the air wall can transmit light properly during the Annual Daylight simulation.
But there is still a problem, when I set the air wall as an interior wall and open an interior window on it, when I do the Annual Dayligh simulation, the light cannot pass through the inner window, but Daylight Factor works fine.

This is a sample file. :arrow_down:

Interior Windows effect on UDI .gh (115.6 KB)

Hi @omen,

I have pushed a temporary fix for this. By temporary I mean that it will only work for static apertures, i.e., aperture groups will not work.

1 Like