[Radiance-general] Python Radiance Package

[Guglielmetti, Robert]

All:

This is an interesting idea and the excitement over supporting it is inspiring. Many of you provide a good glimpse of the possibilities with a system like this, and the path forward. I should add that at NREL we are working on an analysis platform (written in C++) for combined Radiance and EnergyPlus simulations, that provides Ruby bindings to the underlying C++ components.  I don't think it's a total duplication of this effort being discussed here, and in fact it may be more what Thomas is thinking of (more of a Radiance API).  It's very much in developmental stage, but I wanted to mention it nonetheless. Regardless, our emphasis is on open source, and cross platform tools here.

This leads me to another topic, that of a reliable Windows build environment for Radiance. As part of our efforts mentioned above, NREL is looking into getting a cmake-based cross-platform build env for Radiance and hosting it. The goal is to get a cmake dashboard setup for Radiance (nightly) builds. This would allow us to provide a repository for Windows Radiance binaries, updated nightly and monitored for breakage. Windows functionality is important to us for our tools mission, so we are currently scoping this effort. Stay tuned!

- Rob

Rob Guglielmetti  IES, LEED AP
Commercial Buildings Research Group
National Renewable Energy Laboratory
1617 Cole Blvd
Golden, CO 80401

On 11/9/10 9:35 AM, "Thomas Bleicher" <tbleicher at googlemail.com> wrote:

Hi Chris.

On Tue, Nov 9, 2010 at 10:33 AM, Christopher Rush
<Christopher.Rush at arup.com> wrote:
> It sounds like what you're looking to write is an enhanced version of the
> 'rad' program with ability to go through multiple geometries or light
> conditions for batch processing and comparison purposes with the additional
> flexibility of file naming that would be required, and maybe automatic
> falsecolor generation or pcond calls, rtrace data processing routines, etc.

We haven't discussed the actual nature of this package yet,
I think. My understanding was that at first it would be only
a wrapper for the Radiance binaries that would provide a
less complicated way of accessing their features from
Python.

Your idea of an enhanced 'rad' is interesting but I don't feel
that this is the main goal here. However, the Python package
should allow anyone inclined to do so to write an enhanced
'rad' without having to deal with all the gritty details of file
handling and process control.

> I think the challenge would be to make it generic enough that it is still
> useful for all the unique scenarios that come up, but at the same time make
> it worth the effort of creating and maintaining this extra interface -
> instead of the current M.O. of any user putting to use whichever shell or
> scripting package they're most comforable with.

For a start it should be very 'generic' because it only exposes
the Radiance features on a Python level. I doubt that we
can achieve all the flexibility of Radiance on a Unix shell
because that's what all the binaries are designed for. But
within a Python script you can achieve the same results
with a few more Python commands. In most cases this
will also improve the readability of the script.

> There is a danger that it makes it makes Python expertise
> necessary to keep up to date with the most current
> developments, and be able customize as needed.

Knowledge of Python will definitely be required. It's a
Python module after all. However, all of those who have
shown an interest in the project already have done some
programming in Python and I expect that we have a fair
amount of duplicated features in our common code base.

If nothing else this project could help the known Python
enthusiasts to share parts of their code.

> Although maybe there's something to be said for moving
> toward a common cross-platform scripting language
> amongst the community.

Unfortunately even within the official distribution there
is already quite a spread of scripting languages:
Python/CSH for building
CSH for some scripts
Perl for other scripts
TCL/Tk for trad

I expect that it will always be true that on Unix you are
spoiled for choice of scripting environments and on Windows
most users rely on a graphical frontend like Ecotect.

> PS, I write this from the perspective of someone using bash and unix
> commands and who has (very briefly) looked into Python several times, but
> could never figure out why I would want to re-write the bash shell commands
> I'm already familiar with into Python with all the same information just
> within parantheses and with the word "subprocess" before it  = )

That's because you haven't discovered the beauty of
Python OO code yet. I agree that there is little benefit
in rewriting shell scripts in Python unless you do
something more with it (or you are not that familiar
with CSH/Bash programming).

Python has it's strength where you extend the basic
Radiance tools to a more complex application. That
could be an image manipulation app that combines
the various p-something tools or a script that automats
rendering and analysis of a scene with variations.

Thomas

_______________________________________________
Radiance-general mailing list
Radiance-general at radiance-online.org
http://www.radiance-online.org/mailman/listinfo/radiance-general