AirBoundary not considered fully transparent by Radiance?

MaxMarschall · July 14, 2021, 3:52am

@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)

chris · July 16, 2021, 9:32pm

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

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?

mostapha · July 16, 2021, 9:39pm

I would go for this option.

chris · July 16, 2021, 11:37pm

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.

chris · July 17, 2021, 12:37am

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

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

chris · July 17, 2021, 2:43am

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:

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

MaxMarschall · July 17, 2021, 8:57am

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

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

MaxMarschall · July 17, 2021, 9:01am

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?

MaxMarschall · July 17, 2021, 9:15am

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.

mikkel · July 17, 2021, 10:02am

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):

github.com

ladybug-tools/honeybee-radiance/blob/master/honeybee_radiance/modifier/material/glass.py#L343


      
          """Initialize Glass from a dictionary.
          
          Args:
              data: A dictionary in the format below.
          
          .. code-block:: python
          
              {
              "type": "Glass",
              "identifier": "",  # Material identifier
              "display_name": "",  # Material display name
              "r_transmissivity": float,  # Transmissivity for red
              "g_transmissivity": float,  # Transmissivity for green
              "b_transmissivity": float,  # Transmissivity for blue
              "refraction_index": float,  # Index of refraction
              "modifier": {},  # material modifier (Default: None)
              "dependencies": []
              }
          """
          cls._dict_type_check(cls.__name__, data)
          modifier, dependencies = cls.filter_dict_input(data)

chris · July 17, 2021, 3:52pm

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.

omen · October 4, 2022, 7:43am

@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?

mikkel · October 4, 2022, 8:04am

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.

omen · October 4, 2022, 8:15am

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!

mikkel · October 5, 2022, 8:23am

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.

omen · October 6, 2022, 7:11am

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.

Annual Daylight

image1794×809 135 KB
Daylight Factor

image1779×822 141 KB

This is a sample file.

Interior Windows effect on UDI .gh (115.6 KB)

mikkel · October 6, 2022, 8:27am

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.