Leveraging the Python language in Building Performance Simulation

Python_Projects · December 3, 2012, 2:10pm

Hi Aksel,

There is indeed interest in the Radiance community (I'm speaking as a
voyeur, not a Radiance expert), see i.e.;

Etc.

I would love to have a Radiance script as a demo of how flexible Python is,
maybe there is some smallish task that we can tackle?

When I use Radiance, I see the input files, and all I can think of is; this
should be XML... Maybe there is interest in a 2-way parser?

As far as a more complete "wrapper" project is concerned, we would be happy
to also support in any way.

-Marcus

···

On Mon, Dec 3, 2012 at 1:40 PM, Aksel Groß <[email protected]> wrote:

I am a big fan of Python myself, and wrote a few simple scripts for me to
use with radiance. I am no programmer, so can encourage and support any
designer to take a look at the Python language, it's quite fun!

Btw, would be interested: are there professional Radiance modules for
Python out there already? I once googled for them but without success.

--

Aksel Groß
[email protected]

Am 03.12.2012 um 12:57 schrieb info info <[email protected]>:

> 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:
> [email protected]
>
> 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 [email protected].
>
> 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
> [email protected]
> http://www.radiance-online.org/mailman/listinfo/radiance-general

--

Aksel Groß
Dipl.Ing.Arch.
Dipl.Szeno.

Electric Gobo
Schönhauser Allee 182
10119 Berlin, Germany

[email protected]
T +49 30 559 531 75
M +49 179 394 30 92

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Thomas_Bleicher3 · December 4, 2012, 1:41am

Marcus

You can find some advanced scripts on Francesco's web site:

http://www.bozzograo.net/radiance/index.php?module=Downloads&func=view&cid=2&start=0

These are complete scripts that create new features on top of the Radiance
tool set. If you don't mind digging a bit you can look for the b/rad script
on his web site. It is a Radiance exporter for the 3D modeller Blender
(outdated though, won't work with the current Blender version). This
exporter has also a lot of import features and so the scripts modules show
how to read Radiance files.

As far as an "official" Radiance Python module goes there was some
discussion about it quite a while ago but that pretty much was it. I wrote
(or re-wrote) the base image class for wxfalsecolor specifically to allow a
reuse in other scripts but I don't think anyone has ever used it. I think
one of the reasons is that with Radiance even trivial scripting can go a
long way in terms of automation. Most scripts will be written quick and
dirty and don't need big complicated wrappers to serve their purpose.
Radiance encourages this because it's composed of numerous command line
tools, each with a simple task.

I don't know too much about EnergyPlus and the options to use it on the
command line. Perhaps there is not much to do about the actual calculation
part of the process and the automation comes in when the input is created
or the output is processed. In both cases a parser library for the file
formats used by EP would come in quite handy.

Regards,
Thomas

···

On Mon, Dec 3, 2012 at 9:10 AM, info info <[email protected]>wrote:

Hi Aksel,

There is indeed interest in the Radiance community (I'm speaking as a
voyeur, not a Radiance expert), see i.e.;
https://sites.google.com/site/tbleicher/radiance/python-radiance
http://code.google.com/p/pyrat/
Etc.

I would love to have a Radiance script as a demo of how flexible Python
is, maybe there is some smallish task that we can tackle?

When I use Radiance, I see the input files, and all I can think of is;
this should be XML... Maybe there is interest in a 2-way parser?

As far as a more complete "wrapper" project is concerned, we would be
happy to also support in any way.

-Marcus

On Mon, Dec 3, 2012 at 1:40 PM, Aksel Groß <[email protected]> wrote:

I am a big fan of Python myself, and wrote a few simple scripts for me to
use with radiance. I am no programmer, so can encourage and support any
designer to take a look at the Python language, it's quite fun!

Btw, would be interested: are there professional Radiance modules for
Python out there already? I once googled for them but without success.

--

Aksel Groß
[email protected]

Am 03.12.2012 um 12:57 schrieb info info <[email protected] >> >:

> 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:
> [email protected]
>
> 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 [email protected].
>
> 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
> [email protected]
> http://www.radiance-online.org/mailman/listinfo/radiance-general

--

Aksel Groß
Dipl.Ing.Arch.
Dipl.Szeno.

Electric Gobo
Schönhauser Allee 182
10119 Berlin, Germany

[email protected]
T +49 30 559 531 75
M +49 179 394 30 92

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Thomas_Bleicher3 · December 4, 2012, 2:04am

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 < [email protected]> 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
[email protected]

________________________________________
From: info info [i[email protected]]
Sent: Monday, December 03, 2012 4:57 AM
To: [email protected]; [email protected];
[email protected]; [email protected]
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:
[email protected]<mailto:
[email protected]>

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 [email protected]
.<mailto:[email protected]>

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
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Guglielmetti_Robert · December 4, 2012, 2:44am

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
[email protected]

···

________________________________________
From: Thomas Bleicher [[email protected]]
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 <[email protected]<mailto:[email protected]>> 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>
[email protected]<mailto:[email protected]>

________________________________________
From: info info [[email protected]<mailto:[email protected]>]
Sent: Monday, December 03, 2012 4:57 AM
To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
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:
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>

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 [email protected]<mailto:[email protected]>.<mailto:[email protected]<mailto:[email protected]>>

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
[email protected]<mailto:[email protected]>
http://www.radiance-online.org/mailman/listinfo/radiance-general

Michael_Donn · December 4, 2012, 6:31pm

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
[email protected]

···

Sent from my iPad

On 5/12/2012, at 0:39, "[email protected]" <[email protected]> wrote:

Send Radiance-general mailing list submissions to
   [email protected]

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
   [email protected]

You can reach the person managing the list at
   [email protected]

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" <[email protected]>
To: Radiance general discussion <[email protected]>
Subject: Re: [Radiance-general] Leveraging the Python language in
   Building Performance Simulation
Message-ID:
   <[email protected]>
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
[email protected]

________________________________________
From: Thomas Bleicher [[email protected]]
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 <[email protected]<mailto:[email protected]>> 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>
[email protected]<mailto:[email protected]>

________________________________________
From: info info [[email protected]<mailto:[email protected]>]
Sent: Monday, December 03, 2012 4:57 AM
To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
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:
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>

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 [email protected]<mailto:[email protected]>.<mailto:[email protected]<mailto:[email protected]>>

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
[email protected]<mailto:[email protected]>
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 <[email protected]>
To: Radiance general discussion <[email protected]>
Subject: [Radiance-general] Persistent problems on dctimestep and
   Install
Message-ID:
   <[email protected]om>
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/20121204/e5169690/attachment-0001.html>

------------------------------

Message: 3
Date: Mon, 3 Dec 2012 21:29:09 -1000
From: Greg Ward <[email protected]>
To: Radiance general discussion <[email protected]>
Subject: Re: [Radiance-general] Persistent problems on dctimestep and
   Install
Message-ID: <[email protected]>
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 <[email protected]>
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 <[email protected]>
To: Radiance general discussion <[email protected]>
Subject: Re: [Radiance-general] Persistent problems on dctimestep and
   Install
Message-ID:
   <[email protected]om>
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 <[email protected]>

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 <[email protected]>
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
[email protected]
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/20121204/544f10fe/attachment.html>

------------------------------

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

End of Radiance-general Digest, Vol 106, Issue 5
************************************************

Guglielmetti_Robert · December 5, 2012, 10:07pm

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
[email protected]

···

On 12/4/12 11:31 AM, "Michael Donn" <[email protected]> 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
[email protected]

Sent from my iPad

On 5/12/2012, at 0:39, "[email protected]" ><[email protected]> wrote:

Send Radiance-general mailing list submissions to
   [email protected]

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
   [email protected]

You can reach the person managing the list at
   [email protected]

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" <[email protected]>
To: Radiance general discussion <[email protected]>
Subject: Re: [Radiance-general] Leveraging the Python language in
   Building Performance Simulation
Message-ID:
   <[email protected]>
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
[email protected]

________________________________________
From: Thomas Bleicher [[email protected]]
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 >><[email protected]<mailto:[email protected]>> >>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>
[email protected]<mailto:[email protected]>

________________________________________
From: info info
[[email protected]<mailto:[email protected]>]
Sent: Monday, December 03, 2012 4:57 AM
To:
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected].

;

[email protected]<mailto:[email protected]
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:

[email protected]<mailto:[email protected].

<mailto:[email protected]<mailto:[email protected]

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
[email protected]<mailto:[email protected]>.<ma
ilto:[email protected]<mailto:[email protected]

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

[email protected]<mailto:[email protected]
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 <[email protected]>
To: Radiance general discussion <[email protected]>
Subject: [Radiance-general] Persistent problems on dctimestep and
   Install
Message-ID:
   <[email protected]om>
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 <[email protected]>
To: Radiance general discussion <[email protected]>
Subject: Re: [Radiance-general] Persistent problems on dctimestep and
   Install
Message-ID: <[email protected]>
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 <[email protected]>
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 <[email protected]>
To: Radiance general discussion <[email protected]>
Subject: Re: [Radiance-general] Persistent problems on dctimestep and
   Install
Message-ID:
   <[email protected]om>
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 <[email protected]>

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 <[email protected]>
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
[email protected]
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
Radia[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

End of Radiance-general Digest, Vol 106, Issue 5
************************************************

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Python_Projects · December 7, 2012, 1:34pm

Hi Radiance list,

I posted also to TRNSYS, BLDG-SIM, E+, ESPR, but so far Radiance listers
are in the lead for discussion!

We believe that Python is the best language for "the community". Therefore,
we are trying to take the first steps in introducing Python to the
community.

I am digesting a lot of feedback and can see some next steps.

First: There are several Large projects out there which are very exciting,
and I will try to summarize them on our website, and maybe we can assist
with some of them in the future. So I can see that one aspect of this
initiative will be simply a website which lists these potential ideas and
more developed projects and promotes contributions to them, alongside some
"getting started" examples, and how-to-install-python guides.

So far from Radiance;

www.bozzograo.net/radiance/index.php?module=Downloads&func=view&cid=2&start=0

Second: We will work on getting some simple example python "scripts" using
Radiance, maybe something from the above sites, just 100 lines, well
commented, as getting started examples. (Anyone want to help? I can give
you authorship access to the site!)

Third: I believe that Python scripting can benefit any of the users of the
aforementioned lists, a cross community initiative, this is a big
advantage. However, I can see, after re-subscribing to 6 lists and sifting
through messages, that the community is rather fragmented. So I will need
to think about how to build a better network.

Ok, that's my thinking-out-loud for now. I'm now also subscribed to the
dev- list if this discussion is moved.

Thanks!

-Marcus

···

On Wed, Dec 5, 2012 at 11:07 PM, Guglielmetti, Robert < [email protected]> wrote:

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
[email protected]

On 12/4/12 11:31 AM, "Michael Donn" <[email protected]> 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
>[email protected]
>
>Sent from my iPad
>
>On 5/12/2012, at 0:39, "[email protected]" > ><[email protected]> wrote:
>
>> Send Radiance-general mailing list submissions to
>> [email protected]
>>
>> 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
>> [email protected]
>>
>> You can reach the person managing the list at
>> [email protected]
>>
>> 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" <[email protected]>
>> To: Radiance general discussion <[email protected]>
>> Subject: Re: [Radiance-general] Leveraging the Python language in
>> Building Performance Simulation
>> Message-ID:
>> <[email protected]>
>> 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
>> [email protected]
>>
>> ________________________________________
>> From: Thomas Bleicher [[email protected]]
>> 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 > >><[email protected]<mailto:[email protected]>> > >>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>
>> [email protected]<mailto:[email protected]>
>>
>> ________________________________________
>> From: info info
>>[[email protected]<mailto:[email protected]>]
>> Sent: Monday, December 03, 2012 4:57 AM
>> To:
>>[email protected]<mailto:[email protected]>;
>>[email protected]<mailto:[email protected]>;
>>[email protected]<mailto:[email protected]
.
>>>;
>>[email protected]<mailto:
[email protected]
>>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:
>>
>>[email protected]<mailto:[email protected]
.
>>><mailto:[email protected]<mailto:
[email protected]
>>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
>>[email protected]<mailto:[email protected]
>.<ma
>>ilto:[email protected]<mailto:
[email protected]
>>>>
>>
>> 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
>>
>>[email protected]<mailto:
[email protected]
>>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 <[email protected]>
>> To: Radiance general discussion <[email protected]>
>> Subject: [Radiance-general] Persistent problems on dctimestep and
>> Install
>> Message-ID:
>> <[email protected]om>
>> 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 <[email protected]>
>> To: Radiance general discussion <[email protected]>
>> Subject: Re: [Radiance-general] Persistent problems on dctimestep and
>> Install
>> Message-ID: <[email protected]>
>> 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 <[email protected]>
>>> 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 <[email protected]>
>> To: Radiance general discussion <[email protected]>
>> Subject: Re: [Radiance-general] Persistent problems on dctimestep and
>> Install
>> Message-ID:
>> <[email protected]om>
>> 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 <[email protected]>
>>
>>> 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 <[email protected]>
>>>> 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
>>> [email protected]
>>> 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
>> [email protected]
>> http://www.radiance-online.org/mailman/listinfo/radiance-general
>>
>>
>> End of Radiance-general Digest, Vol 106, Issue 5
>> ************************************************
>>
>
>
>_______________________________________________
>Radiance-general mailing list
>[email protected]
>http://www.radiance-online.org/mailman/listinfo/radiance-general

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general