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

# Custom BSDF file script

The current Radiance measure has a few different built-in BSDF choices but I need to write a script that can take a any arbitrary user-specified BSDF XML file and run it in the Radiance engine of OpenStudio.

My planned approach is that the user-specified BSDF files would be made outside of OpenStudio (genBSDF). I would then rewrite the RadianceMeasure's measure.rb. Specifically in calculateDaylightCoeffecients I'd rewrite mapping.rad to look at a different BSDF XML (e.g. replace "blinds.xml" with "my_slats.xml" in mapping.rad). I would also of course rewrite the measure interface to ask which BSDF file the user wanted to use.

This seems workable even though I think this is kind of a work-around because on first inspection it looks like the usual BSDF files (blinds.xml, etc.) may actually be hard-coded into the OpenStudio to Radiance translation program.

Does anyone foresee any problems in using this approach?

edit retag close merge delete

Sort by » oldest newest most voted

Yes! This is cool, good on ya for taking this on. You are correct, the BSDF assignments (and the control algorithms) are hard coded into the Radiance forward translation step. This was in the interest of expedience, as we did not have time to build the interface required to facilitate user-specified BSDFs. There is a very basic mapping done, based on the shading control chosen by the user, here in WindowGroup.cpp.

The easiest way to use your own BSDFs would be to add a loop that rewrites mapping.rad sometime after the translation but before all the Radiance simulation crap happens. Actually I'd just do it right before calculateDaylightCoeffecients. Were you to embark on this today, I'd recommend you just hack this, and simply rewrite mapping.rad using full path(s) to the BSDF(s) you want to use. OpenStudio 2.0's API will have much better support for accessing files and assigning and referencing them in measures. At that point, I think the right answer would be to change the measure interface to allow users to specify the BSDFs in the GUI.

Speaking of hacks, you had also asked about the purpose of the air.bsdf file in your earlier comment. This is basically a unit matrix that passes all the flux through the window interface, unaltered. It's used for calculating the illuminance for a window group's "shades up" condition. This way we only have to compute one 3-phase pair of daylight coefficients per (shaded) window group. We sacrifice a bit of accuracy (the perfectly specular transmission is being smeared out to the 145 Klems hemispherical subdivisions) in the interest of speed and conservation of disk space. For windows with no shades, we simply do a "single phase" daylight coefficient calc for flux at the points of interest (with the actual glazing in the windows). The best solution for shaded windows is to use the 5-phase methodology but that comes with its own issues and challenges in the context of a GUI and what we were trying (and funded) to do. So, the basic workflow is dumbed down a bit and it is what it is. The beauty is it's all there in the repository and you are welcome to improve it. I look forward to seeing what you come up with! Please let us know if you have more questions as you get into it.

more

2

Thanks Mr. Keitel. This is very very helpful and I will keep you informed of the progress (and problems of course)...more to come.

( 2016-11-15 18:05:02 -0500 )edit

+1 for "Mr. Keitel".

( 2016-11-16 16:09:15 -0500 )edit

That was my rationale for the +1. What happens when you change your photo, though?

( 2016-11-16 16:37:18 -0500 )edit

Determinant is a very strong name, also. Very matrix-y.

( 2016-11-16 16:38:15 -0500 )edit

How close is the 5-phase implementation? Also, one of the measures I'm exploring will be automated shades, so it would be nice to have windows partially covered...is this possible with these tools? feature coming soon?

( 2016-12-14 18:45:39 -0500 )edit