Question-and-Answer Resource for the Building Energy Modeling Community
 | 1 | initial version |
Yes, the docs are thin. Apologies. At this point, there simply is no funding for new features or even minor bug fixes to the Radiance-related work in OpenStudio. That said, there is a great start on Radiance-EnergyPlus interoperability in OpenStudio, and the good news is since it's open source, anyone can join the fun of making it better. =)
This is actually a great place to post all these questions since they are all related. As I see it, it's not just about the OpenStudio Radiance measure, but the entire effort of embedding Radiance support in the OpenStudio SDK. There are objects, some of which could use more features, and some missing objects altogether. There is a measure that was largely meant to be a proof-of-concept, that needs some refactoring. And there is no support for spatial illuminance data visualization. Let me try and answer your bulleted questions list inline here...
1) There is an air wall construction for OpenStudio, which simply deletes those surfaces assigned the construction when the OS model is translated to Radiance. This gets around the opaque thermal zone boundary issue. As for placement of the illuminance map, I recommend getting the map within 2'-0" from the perimeter wall for small spaces (typical office), and you could float that out to 5'-0" for large open areas. This is derived from the LM-83 IESNA document which defines the sDA and ASE daylight metrics.
2) You’re still stuck with rectangular map areas, unfortunately, as the OpenStudio illuminance map object (and EnergyPlus' object) only support that. Radiance has no such limitation, and I could see one making tool(s) to generate arbitrarily-shaped maps, and other tools to visualize the spatial illuminance data.
3) There is no published measure to do this, but you are right, the SDK would fully support this. I have done something like this internally for a very specific project, and it's so rough I can't even think about publishing it, but you get the idea. The daylighting control and illuminance map objects in OpenStudio all have the methods in the SDK needed for creation, placement, sizing, setpoints, and connections (e.g. to thermal zones).
4) DView was willfully chosen as a replacement for Results Viewer even when it was known that DView did not support illuminance map data. So I don't see its lack of support as a point of concern to the team, unfortunately. I think the right answer going forward will be to develop something else entirely, perhaps something that supports arbitrarily-shaped maps. I believe there are examples of tools like this in the Ladybug Tools ecosystem.
5) The OS Radiance measure doesn't calculate ASE because we were trying to develop something that plays nice in a large-scale analysis framework, and the mechanics behind ASE dictate a whole extra set(s) of matrices for the daylight calculation, and we were already hitting issues with speed, memory, and data storage with complex multi-space models as it was. In my opinion, ASE is a lousy metric, besides. So, we added sDA largely because we could, but we stand behind our assertion that sDA/ASE is fundamentally broken and recommend the use of UDI as a daylighting design metric. Here again, Ladybug Tools has an offering that does compute the pair of metrics that LEED and WELL recommend for use in compliance demonstration, and again internally I have developed a modified Radiance Daylighting Measure that can work with Ladybug's ASE/direct solar calculations, but it's simply too specific to be released on the BCL, and there is no funding to get it into that kind of condition.
6) Nothing published, but people are trying to roll their own answers to this problem. As a matter of fact, there is a current thread on this, here. In this case, a user is trying to extend the (admittedly basic) SketchUp user script for assigning BSDF data to the windows for the Radiance simulation. This is a great example of the power of open source, and the utility of what is already in the OS SDK, Radiance-wise.
In short, you raise good questions; there is a good starting point in the SDK for integrated Radiance-EnergyPlus simulations; there is no funding to get a lot of these things to the finish line, or even to keep them in line with the evolving SDK; it is my hope that the OpenStudio community can carry the ball.
