[Radiance-general] Leveraging the Python language in Building Performance Simulation

Wed Dec 5 14:07:35 PST 2012

Hi Michael,

One thing I should point out is that OpenStudio has a companion piece,
called the building component library (BCL), which is currently under
development. This is a database of "building model components" --
everything from a weather file, to discrete code for describing a piece of
mechanical equipment, what-have-you. Another element we will have in the
BCL is "measures", which are parametric snippets of code that can step
through a model and modify or perturb different elements of the model,
consistently. This speaks to your desire for a consistent database and
interface to the various tools, and will also help folks like yourself get
up and running with scripting a little bit better.

This issue is no different from the zillions of AutoLISP routines out
there for AutoCAD users -- no portal exists to all of these little
programs (some of which got subsumed by AutoCAD itself).

I absolutely agree with your first paragraph. We believe the Chicago
politics adage "vote early, and vote often" can be applied in our field:
"model early and often". Too many energy models are created simply to
document the energy savings for a LEED submittal. OpenStudio is all about
lightweight models, run rigorously.

Anyway that's my buck and a half on the topic. We should also probably
move this thread to the dev list, should it continue (which I hope it
does)...

Rob Guglielmetti
National Renewable Energy Laboratory (NREL)
Commercial Buildings Research Group
15013 Denver West Parkway MS:RSF202
Golden, CO 80401
303.275.4319
robert.guglielmetti at nrel.gov

On 12/4/12 11:31 AM, "Michael Donn" <Michael.Donn at vuw.ac.nz> wrote:

>Hi Rob/Thomas
>
>I have to express some ambivalence on this topic. Having reCently
>published a paper expressing my views on the quick 'performance sketch'
>approach to models, I confess to being a fan of small quick repetitive
>analysis tasks using fully capable software. Rather than using behemoth
>BIM models, lightweight models and sophisticated modelling software is
>The way to mainstream simulation.
>
>That said, in trying to mainstream daylight and energy analysis and
>acoustic analysis with a class of 200 architecture, building science and
>interiors students, I am struggling to get them to think about modelling
>as an abstraction exercise. There is something inherently satisfying
>about the apparent reality of the behemoth BIM with its door handles
>modelled, which students are reluctant to turn away from. They want their
>models to look real in their 3D form, not to be a simple representation
>of the lighting (or thermal, or acoustic) principles at work in their
>design.
>
>it is hard enough to focus students on this form of abstraction. If I was
>also to ask them to work with a series of tools in an analysis  toolbox
>then the push back would be immense. My student engagement with the
>results of analysis has improved out of sight as we have moved from a
>command line or script interface towards a 3D model with associated
>calculation capabilities. If I look at the OpenStudio approach, then I am
>ecstatic that the people learning simulation now engage early with
>modelling the influence of their design ideas on performance, and are no
>longer struggling with text interfaces. They come back to those text
>interfaces with a clear idea of what more they want to do. But then they
>find the same problem that even experienced users of scripts / text
>interfaces find - that there are so many scripts / tools that knowing
>which one to use or finding whether is a mind boggling task. This applies
>even when you know the script / capability exists in the toolbox. I and
>some grad students face exactly this issue with OpenStudio - we know and
>useEnergyPlus/GenOpt, we want to compare it to openStudio/Dakota as
>weaving Radiance into the optimisation would be such an improvement. We
>know and can see examples of Ruby scripts for Dakota. But getting it
>running is something we do not have the time for..
>
>Another architectural world is facing similar issues: scripting of
>parametric relationships in geometry within the Rhino modeller. There is
>some empirical research that suggests people are more effective modellers
>when they have the Grasshopper graphical interface to the scripts
>available. Grasshopper provides an interface to the Rhino script which
>represent snippets of script code as boxes which are graphically 'wired'
>together. However, even experienced users of Grasshopper+Rhino find it
>difficult to find the box/snippet of code that does the job they are
>thinking about. Many versions of the same geometrical operation are
>produced because the catalogue of box/snippets does not exist or
>describes them in unfamiliar ways.
>
>I am very keen to support this Python toolbox idea, but caution it is
>only as good as the database/interface to the tools. Clearly, the Ecotect
>approach is something to be learned from. It was constructed as a
>consistent interface to a bunch of analytical tools. It is best used in a
>mode where the interface is used to create different models for different
>analytical purposes, and the advantage is consistency of modelling
>environment. Unfortunately, this consistent modelling interface tempts
>the user to the notion it would be more efficient to have one model...
>With respect to the Python toolbox, it seems to me the Python part is the
>simple part. What we all need to think about when creating these
>suggested Python suitable tasks is
>a) a set of tags/ key words that would make the code accessible in a
>world where many hundreds of tools are in the tool box;
>b) a set of modelling guidelines that are associated with each script
>that enable the user to group tools by abstraction level /type and hence
>plan how many models might be required;
>
>With this assistance from us, Marcus, Clayton and Allen have a chance of
>building a set of tools that we all embrace. I am thinking, I'd like this
>kind of exercise to provide not just a few Python tools I can dream up,
>but make accessible a whole bunch of others' ideas as well.
>
>M
>
>Michael Donn
>+642161280
>Michael.Donn at gmail.com
>
>Sent from my iPad
>
>On 5/12/2012, at 0:39, "radiance-general-request at radiance-online.org"
><radiance-general-request at radiance-online.org> wrote:
>
>> Send Radiance-general mailing list submissions to
>>    radiance-general at radiance-online.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>    http://www.radiance-online.org/mailman/listinfo/radiance-general
>> or, via email, send a message with subject or body 'help' to
>>    radiance-general-request at radiance-online.org
>>
>> You can reach the person managing the list at
>>    radiance-general-owner at radiance-online.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Radiance-general digest..."
>>
>>
>> Today's Topics:
>>
>>   1. Re: Leveraging the Python language in Building Performance
>>      Simulation (Guglielmetti, Robert)
>>   2. Persistent problems on dctimestep and Install
>>      (Germ?n Molina Larrain)
>>   3. Re: Persistent problems on dctimestep and Install (Greg Ward)
>>   4. Re: Persistent problems on dctimestep and Install
>>      (Germ?n Molina Larrain)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 3 Dec 2012 19:44:39 -0700
>> From: "Guglielmetti, Robert" <Robert.Guglielmetti at nrel.gov>
>> To: Radiance general discussion <radiance-general at radiance-online.org>
>> Subject: Re: [Radiance-general] Leveraging the Python language in
>>    Building Performance Simulation
>> Message-ID:
>>    <FFF56A6D37A3A54F91A03601AC22DA3225FDC07EDE at MAILBOX2.nrel.gov>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hey Thomas,
>>
>> I totally agree, and that's why I have tried very hard to maintain such
>>an interface to the OpenStudio/Radiance stuff. While Application/GUI
>>integration is a priority, all of the Radiance stuff starts out as a
>>Ruby script prototype, and I build in command line switches to all of
>>the functionality. As someone who learned Radiance from the command
>>line, I totally respect the UNIX toolbox model, and feel like our tools
>>need to play nice in that arena. If anything, I've learned that most of
>>my stuff is to large and monolithic, and I'd like to break down or
>>refactor a lot of what I've written to be more modular like Radiance.
>>But as it is, everything we've implemented in Ruby has full command line
>>functionality (and help), and I expect we'll keep that interface an
>>option for the foreseeable future.
>>
>>
>> Rob Guglielmetti
>> National Renewable Energy Laboratory (NREL)
>> Commercial Buildings Research Group
>> 15013 Denver West Parkway MS:RSF202
>> Golden, CO 80401
>> 303.275.4319
>> robert.guglielmetti at nrel.gov
>>
>> ________________________________________
>> From: Thomas Bleicher [tbleicher at googlemail.com]
>> Sent: Monday, December 03, 2012 7:04 PM
>> To: Radiance general discussion
>> Subject: Re: [Radiance-general] Leveraging the Python language in
>>Building Performance Simulation
>>
>> Hi Rob
>>
>> Based on my experience with Radiance scripting in
>>Python|Ruby|Bash|Lua|whatever I'd say that it really doesn't matter much
>>which language you use as long as your application has a good command
>>line interface:
>>
>> 1) small single-purpose apps are better than one big app to rule them
>>all
>> 2) process options should be exposed via command line arguments
>> 3) good error reporting and some form of progress reporting for long
>>running processes
>>
>> I think the scripting community would be better served if you implement
>>a good command line interface to your binaries and Ruby scripts than by
>>just another language wrapper.
>>
>> My 2 CI cent,
>>
>> Thomas
>>
>>
>> On Mon, Dec 3, 2012 at 11:32 AM, Guglielmetti, Robert
>><Robert.Guglielmetti at nrel.gov<mailto:Robert.Guglielmetti at nrel.gov>>
>>wrote:
>> Hi guys,
>>
>> Not sure if you (Marcus and Alan) remember me, but I tagged along on a
>>lunch together when you visited NREL a while back. This sounds like a
>>great and ambitious project. Of course, it's tied to a specific
>>scripting language -- in this case, Python. I used to use Python a bit
>>for just this type of Radiance automation, myself. The SPOT program
>>(Radiance-based lighting photosensor placement and optimization tool) is
>>a mix of Python and VBA. OpenStudio is primarily C++, but we export all
>>of that C++ functionality to Ruby (and C#) in the form of SWIG
>>"bindings". Much of the Radiance functionality in OpenStudio is actually
>>a bunch of Ruby scripts. There are even elements of Radiance that are
>>written in Perl.
>>
>> The point being that everyone has their favorite high level language.
>>Our hand was forced to Ruby, simply because the OpenStudio project
>>leverages SketchUp quite a bit, and the SketchUp API is in Ruby. It'd be
>>great if we could leverage your (and your contributors') work in
>>OpenStudio too, though. We should talk about how we might make that
>>happen. I know SWIG supports Python, but the maintenance headache of
>>supporting even just Ruby and C# is major; I doubt the team is
>>interested in supporting yet another scripting language. However I do
>>see an opportunity here, as we are rolling out the notion of "measures"
>>in OpenStudio, which are pre-packaged energy efficiency measures (e.g.
>>modify my model to have a WWR of .10 to .90 in .10 increments, simulate
>>and compile the results, while I go have lunch). We should work together
>>to see how we can best integrate your script library with OpenStudio and
>>other tools.
>>
>> What do you think?
>>
>> - Rob
>>
>> Rob Guglielmetti
>> National Renewable Energy Laboratory (NREL)
>> Commercial Buildings Research Group
>> 15013 Denver West Parkway MS:RSF202
>> Golden, CO 80401
>> 303.275.4319<tel:303.275.4319>
>> robert.guglielmetti at nrel.gov<mailto:robert.guglielmetti at nrel.gov>
>>
>> ________________________________________
>> From: info info
>>[info at pythonpoweredbuilding.com<mailto:info at pythonpoweredbuilding.com>]
>> Sent: Monday, December 03, 2012 4:57 AM
>> To:
>>bldg-sim at lists.onebuilding.org<mailto:bldg-sim at lists.onebuilding.org>;
>>trnsys-users at cae.wisc.edu<mailto:trnsys-users at cae.wisc.edu>;
>>EnergyPlus_Support at yahoogroups.com<mailto:EnergyPlus_Support at yahoogroups.
>>com>;
>>radiance-general at radiance-online.org<mailto:radiance-general at radiance-onl
>>ine.org>
>> Subject: [Radiance-general] Leveraging the Python language in Building
>>Performance Simulation
>>
>> Dear simulation community,
>>
>> The Python programming language is well known as a powerful tool in
>>automation, scripting, and high performance scientific computing. In our
>>experience, countless hours have been saved in automating building
>>simulation tasks, allowing us to focus more on creating quality building
>>models and accurate performance results.
>>
>> We believe that Python is positioned to make a big difference in the
>>building simulation community. To get started, we have the following
>>offer: Send us your scripting problems, and we will solve them for you!
>>
>> In this phase, we are interested most in small well defined tasks.
>>Example problems would be;
>>
>> "In my research, I need to parametrize 100 EnergyPlus files with
>>different U-Values"
>> "We need to convert 1000 files from format *.yyy to format *.qqq"
>> "Our company produces a report for each project, we use Excel to
>>calculate the average Lux levels from radiance, it's easy but boring
>>after 100 projects"
>> Or anything else where you think - "I wish I had an intern do this for
>>me..." (Maybe you are this intern...)
>>
>> Help us by defining your problem with steps taken and the desired
>>result. Send them to:
>>
>>projects at pythonpoweredbuilding.com<mailto:projects at pythonpoweredbuilding.
>>com><mailto:projects at pythonpoweredbuilding.com<mailto:projects at pythonpowe
>>redbuilding.com>>
>>
>> For all problems received, we will recommend ideas, methods, and
>>modules. We will furthermore select 3 projects to solve and feature in
>>our Workshop during the Building Simulation 2013 conference in France
>>next August http://www.bs2013.fr/. We will also feature these problems
>>on our website; http://www.pythonpoweredbuilding.com.
>>
>> Problems must therefore be free of any intellectual property and will
>>be open to all. For more information and more about us, please visit
>>http://www.pythonpoweredbuilding.com. If you are already a convert and
>>want to get involved, contact us at
>>info at pythonpoweredbuilding.com<mailto:info at pythonpoweredbuilding.com>.<ma
>>ilto:info at pythonpoweredbuilding.com<mailto:info at pythonpoweredbuilding.com
>>>>
>>
>> Please excuse cross posting, we will direct further updates primarily
>>to BLDG-SIM.
>>
>> Happy simulating,
>>
>> Marcus Jones, Clayton Miller, and Alan Jackson - Python evangelists
>> _______________________________________________
>> Radiance-general mailing list
>>
>>Radiance-general at radiance-online.org<mailto:Radiance-general at radiance-onl
>>ine.org>
>> http://www.radiance-online.org/mailman/listinfo/radiance-general
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 4 Dec 2012 00:10:55 -0300
>> From: Germ?n Molina Larrain <gmolina1 at uc.cl>
>> To: Radiance general discussion <radiance-general at radiance-online.org>
>> Subject: [Radiance-general] Persistent problems on dctimestep and
>>    Install
>> Message-ID:
>>    <CAF-iH4JcUFiRJuj5t0whQubeFQJho+-Hzo5eM9E5PeG2yDLiig at mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Hi everyone,
>>
>> It's me again, with new troubles... sorry for that.
>>
>> I have been trying to implement the Three Phase Method on two different
>>PCs
>> and two different OS, and not good news so far. Long story short, the
>>NREL
>> precompiled Radiance for Windows returned only zeroes when dctimestep
>>was
>> called (Andy McNeil helped me to discard syntax errors ... THANKS FOR
>> THAT); Ubuntu used to give me no answer, then it took turns between
>> "reinhart.cal not found" and some other similar things, and now it keep
>> throwing "segmentation fault" (my sky vector is not full of zeroes). I
>> already tried reinstalling my Linux distribution, compiling the Head
>> version (I think I did it ok), searching on the web, preinstalling x11
>>dev
>> library, and installing Learnix... but "segmentation fault" keeps
>>there, in
>> the two PCs.
>>
>> anyway, until now, all my compilations "have had some errors" and
>> dctimestep has worked some times, but I haven't been able to understand
>>why
>> sometimes it works and sometimes it doesn't... I am pretty stucked
>>here. If
>> there is any trick for installing RADIANCE or getting the permissions to
>> avoid "segmentation fault", any advice would help a lot.
>>
>> THANKS
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>><http://www.radiance-online.org/pipermail/radiance-general/attachments/20
>>121204/e5169690/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Mon, 3 Dec 2012 21:29:09 -1000
>> From: Greg Ward <gregoryjward at gmail.com>
>> To: Radiance general discussion <radiance-general at radiance-online.org>
>> Subject: Re: [Radiance-general] Persistent problems on dctimestep and
>>    Install
>> Message-ID: <F4F71603-4256-4921-8168-F5C91D8BA38D at lmi.net>
>> Content-Type: text/plain; charset=iso-8859-1
>>
>> Hi Gem?n,
>>
>> You need to provide some information or no one can help you.  What were
>>the exact commands you used when you got your errors?
>>
>> Thanks,
>> -Greg
>>
>>> From: Germ?n Molina Larrain <gmolina1 at uc.cl>
>>> Date: December 3, 2012 5:10:55 PM HST
>>>
>>> Hi everyone,
>>>
>>> It's me again, with new troubles... sorry for that.
>>>
>>> I have been trying to implement the Three Phase Method on two
>>>different PCs and two different OS, and not good news so far. Long
>>>story short, the NREL precompiled Radiance for Windows returned only
>>>zeroes when dctimestep was called (Andy McNeil helped me to discard
>>>syntax errors ... THANKS FOR THAT); Ubuntu used to give me no answer,
>>>then it took turns between "reinhart.cal not found" and some other
>>>similar things, and now it keep throwing "segmentation fault" (my sky
>>>vector is not full of zeroes). I already tried reinstalling my Linux
>>>distribution, compiling the Head version (I think I did it ok),
>>>searching on the web, preinstalling x11 dev library, and installing
>>>Learnix... but "segmentation fault" keeps there, in the two PCs.
>>>
>>> anyway, until now, all my compilations "have had some errors" and
>>>dctimestep has worked some times, but I haven't been able to understand
>>>why sometimes it works and sometimes it doesn't... I am pretty stucked
>>>here. If there is any trick for installing RADIANCE or getting the
>>>permissions to avoid "segmentation fault", any advice would help a lot.
>>>
>>> THANKS
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Tue, 4 Dec 2012 07:36:25 -0400
>> From: Germ?n Molina Larrain <gmolina1 at uc.cl>
>> To: Radiance general discussion <radiance-general at radiance-online.org>
>> Subject: Re: [Radiance-general] Persistent problems on dctimestep and
>>    Install
>> Message-ID:
>>    <CAF-iH4LhLk6Upgw-+UdTyS0MNe_gc=uY=u9iBSJy0cAyAQVypg at mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Hi Greg,
>>
>> For installing I did "sudo ./makeall install" and "sudo ./makeall
>>library".
>> For the dctimestep use I did:
>>
>> *dctimestep Matrices/V.vmx
>> Matrices/Tforward.xml Matrices/D.dmx Matrices/S.skv >
>>results/3phase.txt*
>> *
>> *
>> I, of course, had a directory called Matrices where all my files were
>> stored. The *Tforward.xml* was generating using genBSDF on a simple
>>clear
>> window, and the Daylight and View matrix were computed folowing the Andy
>> McNeil tutorial.
>>
>> I tend to think it is a problem in the configuration of Ubuntu? I mean,
>>the
>> permissions or something. But I do not know how to fix it.
>>
>> 2012/12/4 Greg Ward <gregoryjward at gmail.com>
>>
>>> Hi Gem?n,
>>>
>>> You need to provide some information or no one can help you.  What were
>>> the exact commands you used when you got your errors?
>>>
>>> Thanks,
>>> -Greg
>>>
>>>> From: Germ?n Molina Larrain <gmolina1 at uc.cl>
>>>> Date: December 3, 2012 5:10:55 PM HST
>>>>
>>>> Hi everyone,
>>>>
>>>> It's me again, with new troubles... sorry for that.
>>>>
>>>> I have been trying to implement the Three Phase Method on two
>>>>different
>>> PCs and two different OS, and not good news so far. Long story short,
>>>the
>>> NREL precompiled Radiance for Windows returned only zeroes when
>>>dctimestep
>>> was called (Andy McNeil helped me to discard syntax errors ... THANKS
>>>FOR
>>> THAT); Ubuntu used to give me no answer, then it took turns between
>>> "reinhart.cal not found" and some other similar things, and now it keep
>>> throwing "segmentation fault" (my sky vector is not full of zeroes). I
>>> already tried reinstalling my Linux distribution, compiling the Head
>>> version (I think I did it ok), searching on the web, preinstalling x11
>>>dev
>>> library, and installing Learnix... but "segmentation fault" keeps
>>>there, in
>>> the two PCs.
>>>>
>>>> anyway, until now, all my compilations "have had some errors" and
>>> dctimestep has worked some times, but I haven't been able to
>>>understand why
>>> sometimes it works and sometimes it doesn't... I am pretty stucked
>>>here. If
>>> there is any trick for installing RADIANCE or getting the permissions
>>>to
>>> avoid "segmentation fault", any advice would help a lot.
>>>>
>>>> THANKS
>>>
>>> _______________________________________________
>>> Radiance-general mailing list
>>> Radiance-general at radiance-online.org
>>> http://www.radiance-online.org/mailman/listinfo/radiance-general
>>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>><http://www.radiance-online.org/pipermail/radiance-general/attachments/20
>>121204/544f10fe/attachment.html>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Radiance-general mailing list
>> Radiance-general at radiance-online.org
>> http://www.radiance-online.org/mailman/listinfo/radiance-general
>>
>>
>> End of Radiance-general Digest, Vol 106, Issue 5
>> ************************************************
>>
>
>
>_______________________________________________
>Radiance-general mailing list
>Radiance-general at radiance-online.org
>http://www.radiance-online.org/mailman/listinfo/radiance-general