.IES Lighting Plane Visibility Issue

Hi Guys,
I’m currently trying to run a LUX analysis on a series of diagonal spotlights arrayed on a column.

The problem i’m facing is my results seem to be showing planes obstructing the light, which I would assume is the plane my .IES file is positioned on. Has anyone faced a similar issue to this or is there any way to hide the visibility of the source plane?

I’ve run a comparison in Vray with the same .IES file in order to show the desired result.

Model Link: https://drive.google.com/open?id=1KEAvbGFLGEoRFy1zI9qbDI_UYaPAmSKx

Any help would be greatly appreciated,
Thank You!

Yup, thats what is happening. You can avoid that if you replace the light with illum objects. I dont have access to Rhino, can you share your Honeybee/Ladybug folder here? It might be a couple of days before I can get to your files, but if you’d like to get a headstart, see the -i option in ies2rad.
The idea is to maintain the data-driven distribution of the luminaire while replacing the physical light emitting object with a point source or to a distribution mapped to a spherical (illum) object. These assumptions will hold as long as the five-time-rule is being maintained.
By the way, if you’d like to a deep dive into this topic, Randolph Fritz’s thesis specifically on this subject is worth reading.

1 Like

Great! glad to hear its possible @sarith

Here’s the link to my files: https://drive.google.com/open?id=1KEAvbGFLGEoRFy1zI9qbDI_UYaPAmSKx
Yes, so the -i option looks like the soluiton = "Ignore the crude geometry given by the IES input file and use instead an illum sphere with radius rad. "

Apologies though, I’m just a bit confused as to how this conversion is made? Is there an option within Honeybee or is this a process I have to do outside of the program and then relink the .IES

Thank you for your help

Hi @jcmv_design, the IES paths are missing:
Can you share the contents of your c:/ladybug/ies/ directory? It might be useful if you share a screenshot of your grasshopper canvas too.


1 Like

Hi @sarith yes it looks like the problem solved itself with your last comment.

I remade the luminaire component and relinked it as a different name, giving me the results I wanted.
So I think it may have been an error in the radiance calculation because I kept switching the .IES that was connected to the Grasshopper file component. (between a 15° and 60° file of the same fixture)

For future reference is it bad practice to switch the .ies file linked to luminaire input?

E.g. should I create two separate luminaire files and then change the geometry inputting them. As opposed to creating one luminaire file and constantly updating it?

Hi @jcmv_design, the way things are setup in Honeybee is that we call ies2rad to create a Radiance description of luminaire (this is stored physically as a file on the disc). The origin of the that luminaire in the Radiance coordinate system is at 0,0,0. Then xform is used to translate that luminaire to locations specified by the user using inline commands (something like !xform -t xloc yloc zloc light.rad) in a separate file. This file is suffixed with arr.rad. The rationale for doing so is that multiple instances of the same luminaire are grouped together with the only variable being their rotation and position.

This is somewhat analogous to how luminaires are grouped together in zones in software like AGI32 or Dialux. The array file is appended to rest of the geometry as a “additonalRadFiles” (as shown in the hydrashare example). Ideally you should be using one “IES luminaire” (Honeybee component) per ies file. I am not sure how your .bat file ended with multiple instances of the same arr file.

By the way, I did a quick test to check the shadows due to light and illum:

For the same luminaires, left is with illum and right is with the default output. The view point and geometry is too close to the source so, the calculation isnt accurate. However the shadows visible with light are not visible with illum. (I didnt try to optimize the ambient settings.)

I think I ended up with multiple instances because I kept changing the file link and then relinking it back to the original (Honeybee must have duplicated it each time, which is probably what lead to the inaccurate results).

I’ve tried a few different techniques but it seems the best methodology for me at the moment is to get rid of custom luminaire name, and plugin the IES file to .additionalradfiles
This way it seems to be running the simulation purely on the inputs of the file rather than referencing the custom Luminaire from ladybug, does this sound correct?

Not sure if my ultimate goal is possible, but ideally i’d like to be able to quickly change the IES file asscociated to the file path without potentially ruining my definition.

Thanks again for the great help :slight_smile: