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

FullInteriorAndExteriorWithReflections Solar Distribution with Concave Zones in E+

asked 2018-03-30 20:21:35 -0500

chriswmackey's avatar

updated 2018-04-01 18:54:31 -0500

Hello wonderful unmethours community,

Many of us on the forum are already familiar with the fact that E+ cannot model FullInteriorAndExteriorWithReflections solar distribution with concave zones and this usually results in a CHKBKS error.

I am posting here mostly as a sanity check that my current workflows are the best that I can do right now since I usually have a need to do for FullInteriorAndExteriorWithReflections solar distribution in order to run detailed radiant thermal comfort studies with E+. Much of the time, I end up downgrading the solar distribution to FullExteriorWithReflections, which puts all beam solar into the floor and distributes the diffuse solar to other zone surfaces by view factor.

However, someone had tipped me off that the Radiance eplus_adduvf function might be able to compute the view factors needed for this solar distribution for me and avoid this error. However, my attempts to get this to run have proven ineffective: image description [UPDATE] I was able to get eplus_adduvf to run by reinstalling Radiance and NOT using the version of Radiance that is distributed with OpenStuido (there seems to be an issue with running the function from that folder). However, after successfully running eplus_adduvf, it did not fix this solar distribution issue (I still get the error after running the IDF). This eplus_adduvf function seems to be only made to compute view factors in between surfaces and not the parameters needed for detailed solar distribution.

The only other workflow I can think of that might address the issue is using a BSDF window material in E+ but I have not tested this yet. [UPDATE] I tested it and it has not made the error go away.

Can anyone confirm downgrading the solar distribution is still the best way to deal with this situation at this time and, if not, what is the best course of action to enable the most accurate solar distribution calculation for concave zones in E+

Thank you,


edit retag flag offensive close merge delete

4 Answers

Sort by » oldest newest most voted

answered 2018-06-18 12:12:13 -0500

updated 2018-06-27 14:55:07 -0500

Another alternative is SurfaceProperty:SolarIncidentInside which allows the incident solar on each surface to be specified with schedules. This would require getting the hourly or timestep values for incident solar flux on each surface from Radiance or another tool capable of doing the full interior solar distribution calculations. Note that this is the final answer for solar incident on the surface after all internal reflected solar. The schedule value is multiplied by the surface solar absorptance to set the absorbed solar for the inside surface heat balance. No further solar distribution is done for surfaces that have one of these.

edit flag offensive delete link more


Thanks for the clarifications! Although the workflow seems a bit labour intense, it is very helpful to know that there is an accurate alternative for getting the surface temperatures right.

I'm not very familiar with how Radiance outputs hourly results - it looks that they are produced under Radout.sql in a non user-friendly format. Do you have any recommendations on how to best deal with these?

rafael.alonso's avatar rafael.alonso  ( 2018-06-25 04:04:14 -0500 )edit

@rpg777 Can you help here?

MJWitte's avatar MJWitte  ( 2018-06-27 14:58:08 -0500 )edit

I know I am several months late in posting here but I wanted to say thanks to @MJWhitte for this answer. This is definitely something that I plan to explore. @rafael.alonso , I can recommend this Grasshopper example file to get hourly solar radiation values for multiple points over a year. I am a bit less certain of the Honeybee API calls and Radiance functions that are being used under the hood but I can assure you that much of this has been automated.

chriswmackey's avatar chriswmackey  ( 2019-04-01 13:41:20 -0500 )edit

answered 2020-07-24 15:53:08 -0500

chriswmackey's avatar

I just wanted to add that, by far, the best/easiest solution that I have found for this is thanks to a new feature that was added in EnergyPlus 9.3: the new GPU-based PixelCounting method under ShadowCalculation completely solved my issues with concave zones and it's a lot easier to implement than the originally-suggested SurfaceProperty:SolarIncidentInside, which I also recognize as a suitable (though difficult-to-implement) solution.

edit flag offensive delete link more

answered 2018-06-15 07:05:55 -0500

Hi all,

Are there any updates on this?
I had a similar belief that Radiace´s module eplus_adduvf.exe would overcome E+ shortcoming regarding concave zones and assign surface view factors, thus enabling the FullInteriorExteriorWithReflections solar distribution model.

As Chris points out, it´d be very helpful to find a workaround to this issue in order to run radiant thermal comfort analysis and, additionally, to link E+ surface temperatures with CFD simulations (for spaces like glazed courtyards and atriums).

So far I cannot think of anything else that subdividing the zones - if possible - or downgrading the solar distribution calculation, as has already been mentioned.


edit flag offensive delete link more

answered 2018-04-02 11:01:31 -0500

updated 2018-04-02 15:49:19 -0500

Hi Chris,

Regarding the Radiance executables and NREL installers issue: OK so the issue there is that when you install OpenStudio, you get a copy of Radiance (installers and libraries) in [path_to_openstudio]\Radiance, but that installer does not modify your environment. We probably should, but we don't. The only piece of OpenStudio that uses Radiance is the Radiance Daylighting Measure, which sets up the proper environment variables from within the measure, so any Radiance bits called from the measure automagically work.

When you installed Radiance with the Radiance installer, that installer copied the very same executables to C:\Radiance (or wherever), AND set up PATH and RAYPATH to point to stuff in .\bin and .\lib respectively, and so it worked.

I'd recommend you install Radiance AND OpenStudio if you wish to use Radiance outside of the OpenStudio radiance measure context.

Regarding the eplus_adduvf operational issues, I'd suggest reaching out to Tianzhen Hong or @macumber here, as they worked on the development of this utility (four years ago).

edit flag offensive delete link more



Hi Rob. Sorry for cross-posting but I meant for this question to be specifically about the intended purpose of eplus_adduvf (rather than how you get it to work). For clarification, are you confirming that the intended purpose of the eplus_adduvf is NOT to deal with this solar distribution error? Also, the eplus_adduvf function automatically writes the view factors into the IDF as ZoneProperty objects. Am I missing something about the "job" you refer to?

chriswmackey's avatar chriswmackey  ( 2018-04-02 15:18:00 -0500 )edit

No worries, the question is actually two questions so three locations isn't too bad. My main dog in this hunt was addressing the issue of the executable not working at all from the OpenStudio "install", which is addressed in my (revised) answer.

rpg777's avatar rpg777  ( 2018-04-02 15:39:34 -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: 2018-03-30 20:21:35 -0500

Seen: 594 times

Last updated: Jul 24 '20