The Living Future 2012 UnConference

Current Living Building Challenge project by Miller Hull Architects, The Bullitt Center, takes shape in Seattle
This week, Portland is hosting the International Living Future Institute’s Living Futures 2012 “UnConference.”
What is an UnConference, you ask?
Well right off the bat, it’s a lot less stodgy than your typical conference. It involves tours of local Living Building projects, lunch out at one of our famous Portland food-cart pods, and a whole lot of highly inspirational talks about making sustainable design happen. It’s about being part of the 1%. That is, the 1% of people who care enough to make inspiration a part of their design lives; the 1% who have an opportunity to spend three days talking about sustainability in one of the most livable cities on the planet. And, as was pointed out by this morning’s 15 Minutes of Brilliance speaker, Jennifer Cutbill of Vancouver, BC’s DIALOG Architects, it’s about being an occupant of the 1% of the earth that is driving 99% of its ecology. (I found out that Jennifer is a kick boxer of note, as well, a skill that surely comes in handy as a green advocate.)
A common theme among the speakers so far can be summed-up in this famous quote by Margaret Mead:
“Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has.”
There have been two very interesting keynote speeches thus far. Dr. Vandana Shiva spoke last evening about the patent battles India has waged against the Monsanto Corporation. My favorite part of her talk was when she promoted the concept of Gross National Happiness (GNH) over GDP.
This morning’s talk by Jason McClennan was also highly inspirational. He discussed his home town, Sudbury, Ontario and his grandparent’s hand built home on an island in northern Canada. Clearly the contrast between the two informed his life path and the thinking that led to the Living Building concept.
Perhaps most interesting to me, however, is the number of Living Buildings currently on the boards or already completed – projects not just here in the Cascadia region, but all over the world, in Europe, Asia and Australia. I was previously unaware of the breadth of success and the traction they have achieved. A few examples are on the current Living Building Challenge website, but I hope to see more on the soon-to-be-launched new International Living Future site.
All in all, this is a great conference, providing plenty of inspiration and well worth the attendance. It’s the perfect fuel for those of us who live in the real world and yet must continue to convince those around us that business as usual isn’t working out so well, and that real alternatives exist today.
Passive Aggressive Solar Design
Passive Aggressive Solar Design happens when you incorporate the movement of the sun across the sky into your built environment design. It happens through the creation of fixed shades that cast dynamic shadows. Or with movable devices that require human involvement to change their position: a crank on the wall instead of a motor and sun sensor. It’s the solar equivalent of having a window that opens rather than a massive HVAC system.
Unlike its behavioral problem namesake, Passive Aggressive Solar Design is a good thing. After all, the sun doesn’t stop moving. It doesn’t break down and quit after a couple years of operation. You don’t pay for it. It’s just there. In Europe, they protect it with “Right to Light” laws.

Computed projection of a window frame onto the celestial sphere for heliodon analysis. Slate Shingle Studio.
Passive Aggressive Solar is about creating magical spaces by actively considering solar movement in the design. It’s about a window seat and a book at sunrise. It’s about a shady spot at noon. It’s about framing the perfect sunset. At its best, Passive Aggressive Solar is about moments no longer than the time it takes a rainbow to appear and disappear.
As architects we have a goal of expressing structure in design so to provide a sense of order and strength to our buildings. How can we do less than create a dialog between shelter and exposure? If we strive to place vertical elements that correspond to the rhythm and spacing of the structural grid, how can we do less than tell the story of orientation, light and view? How can we honor our innate understanding of gravity without showing a corresponding respect for our diurnal cycles?
Solar design provides numerous opportunities for computer design tools. The computational aspects of solar position and radiant exposure are well understood but intensive and difficult to execute by hand. The downside of over-dependence on computer analysis, however, is that we lose track of sunlight’s magic in the process. Passive Aggressive Solar Design calls for the ability to combine Steven Holl’s watercolors with computer generated shading diagrams.
I propose a “slow light” approach to solar design, in which we take the time to think about each opening in a space and how it contributes to the magic. Why not use the sun to incorporate movement into the design but on an architectural scale – somewhere between the speed of a waterfall and the stealth of a glacier.

Cats have long been Passive Aggressive Solar Design experts
To paraphrase Aalto, when you design a window, think about your girlfriend inside watching the sunset or your cat’s lazy nap during a sun break.
The Cosworth-Ford Approach to Architectural Tool Making
A short while ago I pulled out the Slate Shingle Studio dog-and-pony show for a good friend and fellow University of Oregon architecture professor. His opening statement let me know right up front that the the department was not interested in collaborating with me.”We use computers,” he said, “but we don’t build engines.”
I thought about that statement a lot on my drive back home to Portland. I completely understood what he was telling me. After all, software development is justifiably perceived as a difficult and expensive long term process typically undertaken by outfits selling to a wide audience. Autodesk is a perfect example – 6,800 employees and a market cap of $1.9 billion. My UO colleague knows that he is not and does not want to be that.
The thing is, I don’t want to be that either. And I don’t think I have to be. The whole point of the “soft” in “software” is that it’s flexible, right? So how do I explain what I do, that those 6,800 others do not?

A sweet little 68 Formula Ford – petite 4 cylinder version of the full Formula One series – on display here in Portland
The answer came to me out of my past as a young Kansas lad with the typical teenage- male lust for cars, specifically the tubular Formula One racers of the mid-sixties. These beauties had elegance and style not seen before or since. My favorite? The British racing green Lotus powered with the Cosworth-Ford dual overhead cam V8.
The Cosworth Company didn’t want to build engines. They left that to Ford. What they did instead was to design and craft the camshafts, valves and heads that turned the Ford engines into the finest racing machines of the day. Cosworth-Ford engines won all but one Grand Prix race in ’68 and every race in ’69. They were the choice of the preeminent drivers of the day, including Graham Hill, Jackie Stewart, Bruce McClaren and Mario Andretti.
Large software firms today face the same challenges Cosworth/Ford had back in the heyday of Formula One racing: the only way to justify the extensive manpower and development time required to create a powerful tool like Revit, is to sell a lot of them. You have to match the base needs of lots of customers, well enough. But in a classic case of the innovator’s dilemma, the momentum created makes it difficult to respond or change direction with the nimbleness required in a dynamic market space such as architectural design. Indeed, Autodesk CEO Carl Bass commented at December’s Autodesk University that startups were the thing he feared most.
Enter Slate Shingle Studio. We aspire to be the architectural equivalent of the Cosworth Company. We don’t build engines; we turn new camshafts, shape valves, stiffen suspensions. But you still need world class drivers, and the best way to attract them is to soup-up the best machines. My goal is to take the same engines owned by everyone else on the block and to modify them to suit the needs of the particular race you are running. By identifying the right components and the right fit, we help you get the best performance gains.

In the mid 70's Chevy equipped about 4000 Vegas with 4-cylinder Cosworth-Ford engines. I'll likely never get the chance to drive a Lotus 49, but I'm still keeping my eyes open for one of these babies.
If my engine metaphor had been prepared before my trip to Eugene, I still might not have convinced my friend to collaborate with me. It turns out that he’s not driving the same races I’m building cars for. But I think we might have taken the conversation to a new and more interesting level.
Ah well, maybe we didn’t win Watkins Glen, but there is always Monaco.
My 5 Favorite Quotes From Smart Geometry 2012
“Architecture is an iatrogenic profession.” – Kiel Moe
“To learn from other disciplines, we as architects must overcome our short attention spans.” – Anna Dyson
“Sometimes you should just get out of the way and let something else happen.” – Perry Hall
“A friend of mine calls CFD: ‘Colors For Designers’” – Dru Crawley
“Let’s not be afraid to be artists. Let’s be architects as a form of contemporary art.” - Enric Ruiz Geli
(And a 6th as I sit here listening to the closing speaker “Enveloped by desire as he or she is surrounded by a shroud of erotic surprise” – Evan Douglis. Did I actually hear that correctly?)
Four Days in a SmartGeometry2012 Workshop
I must say that my first experience at Smart Geometry has been intense! Four days of ups and downs working in a group (called a “cluster” in SG speak) titled “Material Conflicts” and lead (or “championed”) by a group of software research and developers from Bentley. The overall goal of our cluster was to experiment with recent analysis capabilities added to Bentley’s Generative Components (GC) tools: EnergyPlus (for building energy analysis), STAAD (structural analysis), Kangaroo (dynamic structures), Locust Swarm (flocking behavior), and Darwin (multi-objective evolutionary search tool). The concept was to create projects using two or more of the analysis tools as drivers for an optimization search controlled by the Darwin search engine. My plan was to work with Mark Donofrio, UO colleague and fellow attendee, on a structural optimization problem.
Great concept! Two problems: 1) I didn’t bring a well enough prepared project and 2) their software was stable yet.
Day 1 got off to a slow start, in part due to problem #1 and problem #2 made Day 2 even more frustrating. On Day 3 my team, now composed of myself, Mark, Wendy and Mengchan (two great new friends and fellow attendees), began developing a group of structural models through various mechanisms. I dropped back into my own, stable, safe Rhino/C#/Visual Studio environment and began growing tree-based organic structures. This day was a series of ups and downs driven by feelings of success with the progress I was making versus feelings of frustration because I could have been doing the same thing at home in Portland, Oregon, and what the heck was I doing here! Headed back to the hotel early (meaning after only a 12 hour day) for some much needed rest.

Front view of the Tree Pavilion, a generative design example I created for structural testing. The "trees" were grown downward from a set of randomly points placed on the roof surface to a regular array of fixed points on the base. .
Which brings us to Day 4: the last workshop day of the conference. I woke early with my head full of discoveries about all of the successes and frustrations so far and what I was learning from the process. An hour more work and my trees started looking great. Even better, the models imported into Generative Components just advertised! Structural analysis and success were at hand!
Problem? Ummm… the export/import process through files naturally lost all of the connectivity structure I had in my trees. I had the lines but no longer in the form I needed to traverse and create the corresponding structural members I wanted to test. Answer? The Bentley engineers (who had been working incredibly hard throughout, debugging problems as they appeared and keeping us all up and running) recognized a designer with a high level of hacking skill and said, “hey, we can help you move those C# libraries over into GC. Grow the trees directly there and retain the information needed to do the structural analysis as well.”

Interior view of the Tree Pavilion. Although the trees were generated by clustering roof points downward to the trunks,, the sizes of structural elements had to be created working from the tree trunks upward. For this reason, keeping track of the connectivity of the tree form was critical.
Results for my four day’s work? Some fun new generated structural trees. Experience with GC. A new development environment and capability. A whole lot of new thoughts about why computational thinking and advanced software skills are important for doing this kind of development work. Not to mention the new friends, fun, and inspiration acquired along the way. Many, many answers to Day 3′s question, “Why am I here?” When the dust settles I know I will see this as having been an incredibly useful week. Yesterday, Day 5, we caught our breath and listened to round tables by a variety of creative people. Available to watch on the SmartGeometry website. Today we just finished an astounding presentation by Enric Ruiz-Geli of Cloud 9 Studios in Barcelona, hopefully that video will be available in the future as well. And watch for the background patter of twitter posts at #SG2012.
Smart Geometry 2012!
Very excited to be here in Troy NY participating in the 2012 Smart Geometry Workshop/Symposium! We’re off to a little bit of a slow start… getting organized, software installed, etc, etc. But soon to be up and running. Four days in groups referred to as “clusters,” mine is heavily Bentley’s Generative Components centric and titled “Material Conflicts“. I’ll be blogging the action throughout the week… for now here are some initial photos!
Blog’sploring: Kean Walmsley’s Through the Interface
Meeting Kean Walmsley at Autodesk University last month was certainly serendipitous. I was visiting with Scott McFarlane of Woolpert in Autodesk’s booth on the show floor. Scott had presented an excellent workshop the previous day on C# best practices and I’d wanted to learn more about his experiences in the Autodesk Developer Network. ADN is Autodesk’s fee-based program which provides licenses and API support to third party developers. (BTW, Scott recommended the support network as invaluable, a must have.)
In the course of the conversation with Scott I brought up one of my pet projects: programming in F#. F# is a nice little functional programming language developed by Microsoft and fully supported in their Visual Studio 2010 IDE (Integrated Development Environment – developer geek speak for a fancy editing and debugging environment used in writing programs.)
Functional programming languages have long been of interest in the academic community for their purity of structure. They support a particularly clean programming style which is a good match with my recursive thinking, so I have always enjoyed the opportunities I’ve had to work with them. Furthermore, these languages are highly suited to multithreading, a key to taking advantage of capacity available in both modern desktops and cloud computing. Indeed, Robert Aish of Autodesk Research is developing the functional programming language DesignScript specifically for parametric programming. It is currently available in AutoCAD and is being propagated to additional tools in their design suite. (For a nice introduction to F# and functional programming by Microsoft check here.)
Plugins for Autodesk and Rhino both target the C# language and VS2010. Since libraries compiled from any of the supported languages in that environment are supposedly interchangeable, I wondered aloud, “Was anyone using F#?” Scott pointed across the booth and said, “Well, Kean there has been working with F#, I think he has posted some things about it on his blog.”
Which brings me to my serendipitous meeting with Kean and later exploration of his blog, Through the Interface. Kean manages the technical arm of ADN. He blogs about his activities and travels, as well as providing a wealth of tips and information about software development in the Autodesk environment, including using F#.
All in all, I’m happy to say that the templates and information available on Kean’s blog have brought functional programming back onto my developer radar screen and to the top of my “stuff to experiment with” list.
Plugging-Into Disruptive Technology
Apps have changed the face of software design. You knew this already. If you’re in line with my current blog-reading demographic, you carry a smart phone and you’ve spent a few bucks buying your favorite apps. I love the app that tracks the bus coming toward me while I’m standing at my nearest bus stop, and the one that plots my best bike route between here and there.
As a software developer and architectural designer, I am also fascinated by the technological disruption initiated by the app world. The open source and commercial communities are accidentally colluding to lead us away from monolithic software systems and into a universe of platforms and user/developer groups extending those platforms. It is a response right out of Clayton Christensen’s The Innovator’s Dilemma, and exactly the kind of creative environment described in Steven Johnson’s Where Good Ideas Come From.
We see the same kind of change happening in the architectural CAD software community as well. Rhino’s open source approach to developing the next release of their 3d modeling product has enabled them to tap an enormous community of designers and developers, resulting in a wealth of creativity, and extensions that no one company or entrepreneur could possibly develop on its own. This is a win-win for both the company and the external talent. The company gains visibility, establishes a larger pool of committed users, and fosters new applications, while at the same time accessing an active and technically proficient set of beta testers who can look into every corner of the base tool’s capabilities. The users gain because the platform enables their creative ideas while relieving the overhead of developing a geometry system below it. As a developer, I appreciate the quality of the commercially developed platform, which supports the experimentation necessary for developing add-ons. I can be creative about the things I know, debugging my own code rather than debugging and rewriting the work of others.
Rhino’s development model is beginning to percolate throughout the architectural CAD community at large. Autodesk now touts their “open APIs;” attracting plugin developer technology is becoming the norm, and is clearly perceived as key to their continued success. And this approach is not limited to modeling tools. M-SIX, a quiet little startup here in Portland, Oregon, is using the same open interface model to provide a suite of cloud-based capabilities for large scale BIM collaboration and project management, enabling a much higher platform to stand on, and one tailored to the computational needs of architectural design.
Blog’sploring: Zach Kron’s BUILDZ
Last week’s trip to Autodesk University unearthed a wealth of excellent blog sites. One of particular interest to me is Zach Kron’s BUILDZ . I first tuned in to Zach’s blog after attending his excellent Vasari workshop Playing with Energetic Supermodels, co-presented with Matt Jezyk. I have developed a real attachment to BUILDZ since discovering Zach’s 3rd Annual Parametric Pumpkin Carving Contest, with its unique awards categories, “Baddest, Goodest and Mostest Parametric” pumpkin.
Aside from some bad-a** examples of parametrically designed jack-o-lanterns, BUILDZ has lots of useful information on using Revit as a parametric modeling tool. Good stuff.
A Visit to the Vdara Death Ray
While here in Las Vegas for Autodesk University, I could not pass up the opportunity to walk down the Strip and around the corner to the Vdara Hotel, famous for the so-called Vdara Death Ray. It turns out the Death Ray is a result of reflections off the Vdara’s sister hotel, the Aria, located just across the street. At certain times during the summer, the windows on the 61st story of the Aria line up just right and focus all that Las Vegas sunshine right down onto the outdoor pool located on the Vdara’s third floor.
Stories abound of melted plastic cups and burned flesh. Exaggerated? Perhaps. But every one of the staff members I queried knew exactly what I was talking about.
Of course the Vdara is not the only recipient of unwanted solar energy from a not-so-well-thought-out neighbor. Frank Gehry’s Disney Concert Hall required some judicious sandblasting to reduce reflections from the titanium mirror finish which caused extreme over-heating of apartments and sidewalks across the street.

The stepped planes of the Aria provide a nicely aligned mirror to warm the poolside guests at the Vdara
In the Vdara’s case, a little more design coordination would have helped, as the same developer built both hotels and opened the Aria just 15 days after the Vdara. The problem stems from the design of the Aria’s facade surface, which is stepped rather than a single smooth curve. It’s composed of a series of planer vertical strips arranged in a curved face, each stepped back from and slightly angled to the previous one. These highly mirrored strips reflect light downward onto the Vdara’s pool area.
The obvious question is, what went wrong in the design process? Assuming the designers were aware of the possibility of solar reflection, how could they have anticipated and corrected the problem in their design? One cannot, after all, anticipate or solve such a problem with the traditional solar shaders available on every modeling tool from SketchUp to Revit.
Enter my firm, Slate Shingle Studio. Using a combination of proprietary solar algorithms, parametric modeling and analysis, and the agility of a small computing house, we apply sophisticated computation techniques to specialized, small market problems. We seek aesthetic and environmental solutions for this kind of early design decision involving sun, wind and rain. An early design analysis could have foreseen this solar effect and saved hotel clerks, waiters and the Vdara’s insurance agents a lot of explaining.













