Question-and-Answer Resource for the Building Energy Modeling Community
Get started with the Help page
Ask Your Question

why did the illuminance results become so much higher when put several points together

asked 2019-01-20 05:20:19 -0500

William Chen's avatar

updated 2019-01-21 15:00:47 -0500

I create a txt file containing the coordinates of four points in a room, why did the illuminance results become so much higher ? The simulation results were several times of the results when I used individual txt file for a point. For example, for calculation of the illuminance of four points in a room, first I create four txt files containing the coordinates, the results were around 100 lux, but then, I put the coordinates of the four points in a single txt file (one point in each line), the results were around 800-1000lux.

I don't know why? Any suggestions would be appreciated. Thank you.

edit retag flag offensive close merge delete


Can you please share your model files, points files and commands? It’s hard to determine what happened without seeing exactly what you were doing.

Andyrew's avatar Andyrew  ( 2019-01-20 18:17:45 -0500 )edit

Thank you. Since I do not have 10 points to upload the files, I will just paste all the texts here: Geometry:(reflectance of wall ceiling and floor are: 0.5 0.8 0.3, glass transmittivity: 0.9; reflectance of obstruction and ground is 0.2 )

genbox wall_mat room 4 5 3

xform -t 0 0 8

!genbox.exe E_Obs Obs 20000 2 20 | xform -t -10000 -12 0 !genbox.exe E_Obs Grd 20000 20000 0.01 | xform -t -10000 -10000 -0.01 win_mat polygon window 0 0 12 4 0 9 4 0 11 0 0 11 0 0 9

William Chen's avatar William Chen  ( 2019-01-20 21:41:27 -0500 )edit

Sky material:

skyfunc glow skyglow



4 1 1 1 0

skyglow source sky



4 0 0 1 180

William Chen's avatar William Chen  ( 2019-01-20 21:42:09 -0500 )edit

All four views: 2 1 9 0 0 1 2 2 9 0 0 1 2 3 9 0 0 1 2 4 9 0 0 1

results of 4 points in one text file were different with each points in a separate text file

William Chen's avatar William Chen  ( 2019-01-20 21:44:19 -0500 )edit

Commands for the simulation:


-ang,45 0 -s -b 2000 -R 1000 -g 0.2 > sky1.rad


Sky1.rad skyMa.mat Geometry1.rad > sc1.oct


-w -h -I -ab 5 -aa 0.16 -ar 512 -ad 2048 -as 512 sc1.oct < All4View.txt > result.dat

William Chen's avatar William Chen  ( 2019-01-20 21:44:56 -0500 )edit

2 Answers

Sort by » oldest newest most voted

answered 2019-01-21 10:53:19 -0500

Hi William,

Thanks for posting your files, it makes it a lot easier to find problems.

I think your issue stems from your window surface being coincident with a wall surface. When to surfaces with different materials overlap, the surface found first in the ray intersection check is the one that is used and the other ignored. The first surface to be found is essentially random, but generally repeatable for the same exact simulation.

Instead of using this completely enclosed box for your room with the window overlapping one surface like this:

!genbox wall_mat room 4 5 3 | xform -t 0 0 8

win_mat polygon window 
12  4 0 9 
    4 0 11
    0 0 11
    0 0 9

Try using separate boxes for each wall like this:

#This first wall is only 1m tall to make room for the window above:
!genbox wall_mat room 4 0.1 1 | xform -t 0 -0.1 8

!genbox wall_mat room 4 0.1 3 | xform -t 0 5 8
!genbox wall_mat room 0.1 5.2 3 | xform -t -0.1 -0.1 8
!genbox wall_mat room 0.1 5.2 3 | xform -t 4 -0.1 8
!genbox ceiling_mat room 4.2 5 0.1 | xform -t -0.1 -0.1 11
!genbox floor_mat room 4.2 5 0.1 | xform -t -0.1 -0.1 -0.1

win_mat polygon window 
12  4 0 9 
    4 0 11
    0 0 11
    0 0 9

Also, a ground plane of 20km is maybe a bit bigger than is necessary for this simulation. The downside of having a 20km scene when you only care about 5 meters of the scene is poor ambient cache performance. you could either turn off the ambient cache with -aa 0 (which I'd also encourage decreasing -lw, and increasing -ad ), or you could make the ground plane and obstructions 40m instead.


edit flag offensive delete link more


I noticed the issue with the window as well, but assumed William was hand-editing the output of genbox for the room to change the materials and lower the window wall height.

GregWard's avatar GregWard  ( 2019-01-21 11:14:18 -0500 )edit

Yeah, I wan't sure since there was no mention of editing the output. In Energy Plus you don't need to put holes in walls for windows, so with unmet hours being predominantly an energy modelling crowd I assumed the worst.

Andyrew's avatar Andyrew  ( 2019-01-21 11:24:40 -0500 )edit

Thanks a lot. I tried to cut down the size of the ground and obstruction (200m), and the result seems reasonable. I have some doubts thought: 1. what is the difference of -ab and -lr, the ambient bounces and limit reflections, I realized that if -lr is zero or negative the -lw setting must be positive, do I have to use these two options (-lr and -lw) if I want an accuracy results? whaat is the value of -lw do you suggest for my case? 2. I did hand-editit the output of genbox. I wonder what is the affect if I use surfaces (do not have thickness) instead of solid walls (have a thickness)?

William Chen's avatar William Chen  ( 2019-01-21 22:38:38 -0500 )edit

You mentioned that in E+ there is no need to put holes in walls for windows, so I wonder how EnergyPlus deals with the windows? How to deal with the windows when we use energy simulation model (i.e. *.osm file) to conduct the daylighting simulation using radiance (OpenStudio radiance measure)?

William Chen's avatar William Chen  ( 2019-01-21 22:45:10 -0500 )edit

There shouldn't be an issue with using surfaces instead of solids, assuming the surfaces touch at corners (which is true for genbox generated surfaces). There are effects of thick walls blocking some oblique daylight at windows, but is not a major effect unless the walls are thick relative to the dimension of the window and often ignored.

Andyrew's avatar Andyrew  ( 2019-01-22 00:56:01 -0500 )edit

answered 2019-01-21 11:11:42 -0500

Your ground plane is simply too large. At most, I would use something 10x as big as your space. Yours is 4000 times bigger. This causes the interreflection calculation to reuse the cached ambient value from the previous point when you give it all your points at once. In any case, the results will not be accurate, unless you turn caching off with "-aa 0".

I recommend you use a smaller ground plane (and obstruction) and specify a background below it by extending your sky to cover a 360° angle rather than 180. This is standard practice, but perhaps not as well-documented as it should be. Also, I would double-check the options you are using with gensky to make sure they are the ones you want. I don't think your -R and -b options are used consistently, and you may think you are specifying photometric units when they expect radiometric ones.

edit flag offensive delete link more


Great thanks, I found the problems. I changed the size of obstructions and ground plan (200m long). What is the value of -aa, -ab and -ad -as do you suggest for my case (indoor daylighting including internal reflections)? I am not sure about the function of -as, what is the meaning of ambient super-samples? I always use the 180 sky, I wonder what is the mainly difference of the 360 sky and 180 sky? And , for two different ways I set the ground reflectance, one is create a geometry (i.e. a thick plan) using genbox , another is using ground glow source, what is the difference? Thank you.

William Chen's avatar William Chen  ( 2019-01-21 23:00:33 -0500 )edit

Regarding the options of gensky, I used -b because I intend to create the CIE standard 15 Skies, the zenith brightness was calculated elsewhere, then I put it directly in here... I used -R , because I want to use horizontal direct solar irradiance to calculate the solar luminance/radiance, in that case the option '+s' should be used, right?
Regarding the unit, I did use lux values as the inputs, because I want to get the indoor illuminance. I thought that if I use the lux values as input, the software will calculate the luminance of the sky and sun accordingly. Is it inappropriate ?

William Chen's avatar William Chen  ( 2019-01-22 00:05:48 -0500 )edit

Read the gensky man page to be sure. The -b option expects radiance, which is roughly luminance/179. Similarly, the -R option expects irradiance, which is roughly lux/179. The -s option gives you a clear sky without a sun. To include the sun, use +s (which is the default option). The 360° sky includes an infinitely distant ground, which avoids having a black horizon where your ground plane does not cover, so it is a good way to deal with a finite ground plane. The other settings for -ab, -ad, etc. are OK.

GregWard's avatar GregWard  ( 2019-01-22 11:50:38 -0500 )edit

Thanks. I understand that if I want the irradiance values(W/m2), I need to put radiance values for -b and irradiance for -R. What will happen if I use luminance (cd/m2) as input for -b, and horizontal illuminance (lux) as input for -R. Can I get the accurate illuminance values in the simulation results? If this can work, the R G B values in the output *.dat file are identical, so, any of these three values ​​is the final result I want.

If I use the 360 sky and specify a ground reflectance using -g option, does that mean I don't need to create a ground plan manually (i.e. a 100*100m plan)?

William Chen's avatar William Chen  ( 2019-01-22 21:44:49 -0500 )edit

Best to follow standard practice of dividing photometry by 179 on the way in and multiplying by 179 on the way out. Otherwise, values reported by other tools will be invalid. Extending the sky to cover the ground avoids the need for such a large ground plane, but you still want one to capture the building shadows and so forth.

GregWard's avatar GregWard  ( 2019-01-22 22:00:26 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer


Question Tools

1 follower


Asked: 2019-01-20 05:20:19 -0500

Seen: 416 times

Last updated: Jan 21 '19