Tip:
Highlight text to annotate it
X
>> Our next speaker is John Haymaker. >> HAYMAKER: Great. Thank you all for being
here and thanks to sponsors, organizers, and all of you for coming and listening. John,
you couldn't have set up my talk any better about the need for conceptual design tools.
I hope I can follow through. So, the work I'm going to present here is work I did at
Stanford. I have recently left there and started a company. And like all professors, I'm really
presenting the work of many people other than myself. I really tried to put together a multidisciplinary
group of architects, engineers, structural and mechanical. No electrical engineers, that
would have been my next add, as well as mathematicians and decision-analysis people. I called my
talk Expanding Design Spaces kind of for two reasons. One is the design spaces we need
to consider today are expanding greatly. Twenty years ago when I was learning to be an architect,
energy barely even entered the conversation. Material use was barely talked about. There
are all these kind of weird guys down the hall in the architecture department who were
kind of the environmental guys. And we sort of steered clear of them. We wanted to do
the cool design. Now, it's very much front and center. We need to consider environmental
issues. We need to consider equity issues. We need to consider economic issues. So the
things we need to consider are growing greatly. Also, all of the different options that we
have to choose from, I've learned yesterday that, wow, we have added manufacturing now
to consider in terms of the construction methods we're going to use; something I never even
thought about five years ago. So, all sorts of new technologies that we're dealing with,
new ways to analyze all of these different spaces. So, the potential space that we need
to look through has grown tremendously and we're starting to get tools that are going
to help us search through that space more efficiently and effectively. So, just generally,
I guess our baseline, how do good designs emerge today? Well, theory we need to [INDISTINCT]
design spaces. We can't rely on our precedent and say, "Hey, last time we built a building
just like this. Let's just do it again." We have to really step back, look at all the
possibilities, search through them, understand trends, get to the best designs. So, design
space generally consists of four subspaces, the objective space. What are the things we
are trying to achieve? In this case, we're talking about a high rise in Switzerland,
so we want the cost to be 150 million, about 150 rooms and iconic buildings, view of the
Alps, maybe some energy efficiency goals, maybe some other types of goals. And understanding
which are most important; is really about energy efficiency? Is this about great rooms
and great views? What are the tradeoffs there? Next, we need to figure out what the alternative
space is. We need to know kind of logical and geometric features are of this alternative
space. We might be interested in, in this case, looking at a design that looks a bit
like a ski pole or perhaps one that looks a bit like a ski boot. We need to describe
those things geometrically so we understand what the alternatives are. Next, we need to
understand the impact space. Okay, how are these different alternatives going to perform
in terms of all these different objectives we're concerned with and all these different
issues? And then finally, we need to make some value assessments. We need to finally
picked a design. Well, this one is better for energy, not so good for aesthetics. This
other one is vice-versa. Which one are we going to choose? Which one do we think is
going to, you know, be most sustainable for us, our clients, users going forward? So,
good design decisions require efficiently effective processing an amazing amount of
information. And I tend to try to break it down to sort of six buckets, I guess. Who
are the teams who are involved in this process? Who are our stakeholders? Who are designers?
Who are decision-makers? Who are the gate keepers who can constrain this design space
we're going to look at. Next are the objectives; environmental, social, economic objectives
that we are considering. We need to know about these weights; which are more important to
who? How certain is all of this information? We need to understand our options. What are
the alternatives? Who provides them? What information is available about each of these?
We need to analyze all these options again for all these impacts. Finally, we need to
pick out that design. It's really hard work and designers today, out of necessity, take
a lot of shortcuts, make some mistakes and work inefficiently though this process. So
let me just give you a couple of examples. This is just from down the road at Stanford
University in the Graduate School of Business. As we observe the process, this is something
we would see fairly often is inconsistency in the information. So, if you look in one
part of the file structure, you see that they made some decision matrix. It said that for
the HVAC options for one part of the building looked like displacement ventilation was going
to be a pretty bad idea. Go into the other part of the file structure and look at that;
they got displacement ventilation all over this building. What happened? Maybe somebody
made a mistake and missed it. Maybe there was some process that wasn't clear. But this
information is very inconsistent and can be very disconcerting for a large team who's
trying to make sense of all the information and move forward. Why did they choose displacement
ventilation? Another problem is we have difficulty sharing process information across projects.
So, in this case, the structural engineer in the project was asked to consider life
cycle environmental impacts of the materials. Should we be building our of concrete or steel
here? So we had this great [INDISTINCT] three-dimensional CAD or we call building information model
now. And he went out and said, "Okay, I have this information, I have these quantities.
How do I go about understanding what my environmental impacts are?" He spent about, you know, four
hours that he had in the design budget to work on it. Couldn't find the process, gave
up, never got the information to the owner, and they made decisions about structural materials
without that kind of LCN information. Well, but as it turned out, this is a big multinational
engineering firm over in Australia. They had a process already being developed and being
used in some pilot projects which could do exactly that. So the exact same organization
couldn't communicate that there was a process to do what one engineer needed to do on one
project, they already knew how to do it on another. Finally, firms tend to have difficulty
stepping back and saying, okay, you know, every project is unique. Let's step back and
say what are we doing over and over and over again? How can we start to find some efficiencies
there? So here is an example where they have we have their architectural model. We have
to go through a number of really where it might be considered value-adding issues of
generating that model, strategizing what they want to model, and interpreting the results
of the daylight analysis. But then they spend about 12 hours doing what everyone considered
non-value added information; taking the architectural model, you know, stripping it out, simplifying
it, changing the geometry so it'll fit into the daylight analysis, running that daylight
analysis. Okay. You do it once, that's 12 hours. But how many times do they do this
on one project? How many times do they do it across many projects? The management had
no clue. So just to sort of summarize the problem as I see it right now. During very,
very limited explorations of design spaces today and conceptual design when--as John
pointed out, we can really make the big impacts. Pretend that, you know, these are gross averages
from a number of different observations we've done. But conceptual design can last in the
range of about five weeks. It can be a team of about, you know, 1,800 architectural man
hours. Very few mechanical and structural man hours are really bringing those people,
as John mentioned, after the fact to try to, you know, fix what we've done. Clarity requirements,
really going in there and understanding, okay, what are the requirements? What are you guys
trying to achieve? You know, what are your energy goals? What are your space goals? What
are your other goals? Very low, very hard to really figure out what those objectives
are. They're in people's minds, they're in different Word documents spread out, meeting
minutes and things like that. Not very good at collecting and communicating the objectives
that everybody is trying to achieve. How many alternatives are we really able to model and
analyze in a meaningful way to get good feedback from? We're doing, you know, in the order
of magnitude of three before they really fix on the design and try to fix that particular
geometry. And the types of analyses we're doing really focused on architectural in first
class. Not a lot of real energy in other issues. And we communicate our rationales. We go through
these spaces very poorly as well. This diagram tires to say that, you know, we communicate
the designers and the alternatives. Architects are great at getting up their and showing
their pretty pictures and saying, you know, John Haymaker and Associates on this side.
Isn't this a beautiful design? Let's us build it. But all this other information; who are
the managers and decision makers who are really involved in this, who are the stakeholders
we are trying to satisfy, what are the goals, who are the gate keepers, what are the constraints,
what are all the analyses that led to our final decision of a design is not communicated
well. So, if you think of these kind of design spaces as consisting of objectives-based,
alternatives-based impacts based in value space, I'm arguing that generally, the quality
of these spaces and the clarity with which we communicate them is shockingly poor today.
So how do we make decisions today? Well, we fall back on some maybe less effective methods.
But ones that I run into a lot, we rely on precedent. We do what we've always done before;
relying on power, you know, that guy in the thing slams his hand on the table and says,
"We're going to do it this way. Let's move on." Persistence, the other person in the
meeting says, "No, no. I really want to do it this way. I really want to do it this way,"
and you finally just give in. Intuition, "Yeah, this feels about right." Approximation, "Well,
you know, might be this way or might be that way." Or we just try to simplify things and
make decisions with less information. So generally, you know, what are the research questions
that I've been trying to attack with this team is how can projects teams generate and
communicate better design processes, design spaces and design decisions more effectively
and efficiently? I mean, it really has to do with being within the project on a project
team and then these larger scales of the cross projects and across the whole organization,
how can we start to manage these design spaces better? So, I'm just going very quickly give
you snapshots of five tools that we've tried to build to expand some aspect of these design
spaces or communicate them better. Talk about PIP, the Process Integration Platform; MACDADI,
Multi-Attribute Collective Design Assessment Decision Integration; Design Scenarios, requirements-driven
parametric design spaces; PIDO, Process Integration Design Optimization; and finally, DEAM, which
is a Design Exploration Assessment Methodology. Explain each of those to you in a moment.
So PIP, this a collaborative tool. Basically, when we're collaborating in projects today,
we're really looking at this, a file structure which breaks our information down into some
kind of hierarchy. What's missing there is the process, all of the dependencies between
all of this information. So, this tool does something fairly simple; just allows you to
draw an arrow between files. So, here we kind of have a high level process where they're
going through that teams, and objectives, and preferences, and alternatives, and impacts,
and value. And then each of these folders, for example, the alternative, breaks down
into how do we actually define that alternative. Well, there was some preliminary information
we went through. We built a couple of CAD models. Then how do we analyze those? Well,
this is the analysis of the day lighting analysis, the energy analysis, life cycle analysis,
et cetera. Break into the light--day lighting analysis. This is the process we went through
for that day lighting analysis. So, the opportunity for teams to get together and really map out
the dependencies between their files and we find that's actually some pretty useful and
interesting information. So, it allows you to create and relate your information. Now
once you have these lines between them, you can start to search this information and more
information to search including the dependencies. You can say, "Hey, I'm looking for a process
that starts with an architectural IFC model, a kind of standard day lighting--sorry--data
format that we have and has an output of LCA. Is there anywhere in this world of processes
where somebody else has done this?" So, we can start to pull up processes in that way.
And then finally, we can start to develop some community and some metrics around these
processes, people talking about how well they've performed, how often they've been run and
things like that. And what else? Through some initial tests of using these in classrooms
and in some classroom design [INDISTINCT] we find that when people are dealing with
their information in this way, there are more trend discussions. We start to see people
talking about the trends of these spaces rather than just point designs. They tend to iterate
through the process a little bit more. They understand how their information relates to
other information. Excuse me. And will, therefore, iterate through the process. Your information
is more consistent and the designers are less confused about what is really going on. Find
improved sharing between projects as well that there are less process mistakes and people
are able to take information from past projects and import it into their projects more successfully.
And finally, this improved understanding across projects. And I'll just give you a couple
of examples of some views that we're able to create that I think are kind of interesting.
So, this is the class grades for a class project. Here are the different projects here and the
different designers within each project. So, basically what we can see here is, you know,
designer for sharing information with--excuse me--no information with designer one but is
sharing information with designer three. So, you just see it as a sort of generally rough
view. We don't have any statistical significance on this. But it starts to show some correlation
between how tightly people are integrating their information, how much they're connecting
it, drawing these arrows, and the ultimate project grade. You know, are--they're able
to come up with better projects if they can within this process view and understand how
their information relates. And just another view, here we can start to look at specific
tools and the information flow between those. We can start to understand that, wow, we're
doing a lot of translation between AUTO-CAD and Revit. So, let's go take a look at that
across the firm and see what's going on. Maybe we should do some more automation there where
we're helping the information through. Okay. So that's generally a process mapping and
integration tool. This is MACDADI; again, a sort of six-step processing tool. It helps
people formalize and communicate decisions. So, this is the front page. You can see a
series of decisions that we have there on the left and I'm going to just quickly go
through a high-speed rail decision here in Palo Alto. Decision here was whether we should
tunnel the tracks through Palo Alto and build density up over the air rights to help pay
for it or if we should just build it as a current plan, an elevated track which will
go right down the current right-of-way of the Cal train. So, these are our four options.
This is a summary that says according to this analysis, we should tunnel it and build mid-density
around it. Okay, so how do we get to that? Well, the first step is to go in model your
teams. Who are your different stake holders? In this case, we had people like Palo Alto
government, people who worked in Palo Alto but don't live there, et cetera. We could
have different gate keepers. These are building department people, perhaps Stanford University
or other people who had the ability to really restrict some of the alternatives. We have
the designers and we have the decision makers. Next step is defining all the objectives,
so getting them all in one page, trying to organize them and communicate them. And for
each objective, for example, the ability to bike and walk, we start to try to describe
what would be a good solution for this. Say eight miles of biking trials through Palo
Alto. What would be a very bad solution? No miles of biking trials. So, we can start to
understand how we're going to measure each of these objectives. Now, there can be fairly
qualitative, aesthetic and other sorts of objectives. I feel it's important to get those
in here as well. And if it's just, "We're going to ask the architect," that's a fine
metric if we don't have anything else. We then send those objectives out to all the
stakeholders and they have the ability to weight them, a fairly simple process at this
point of just trying to--you give them a hundred points and let them weigh their particular
preferences over the different objectives. We can start to view that and understand,
okay, well, what are the drivers on this project? Well, connectivity seems to be really a big
driver on the project and the ability to bike and walk to living and working environments
seems to be very important to a lot of stakeholders, and we could start to drill in and understand
who it's important to. Next, we just want to communicate what all the different alternatives
are, give information about them. We want to go through a rigorous aspect of making
sure analyzing all the alternatives for all the goals. We find we often miss, you know,
some of these analyses. We focus on perhaps just one or two of them and make decisions
based on that. We then want to present something that we call value which is essentially taking
this idea of an impact of an alternative on a goal and multiplying it through that by
the preference for that goal. So, if you care a lot about something and it performs well,
there's a lot of positive value. If you care a lot about something that performs negatively,
there's a lot of negative value. And we can drill into that information and really start
to understand different stakeholders and what value their getting from different alternatives
and start to drill down on that information. And, for example, here we see a comparison
of increasing housing capacity versus ability to bike and walk and see which alternatives
are performing well in terms of just those two goals. Okay. So, that's MACDADI. The next
tool is called Design Scenarios which is really just talking about this process of, okay,
we understand what our objectives are; how do we define an alternative space that's going
to really well meet those? We could just sort of guess or have an informal process of getting
from those down to the alternatives or perhaps there's a more structured way to make sure
we get a better alternative space so we can start to look at. So, this is a just a process
of four models where we're going to first talk some of about some scenario logic. We're
going to start with our goals. And this is what a real model will look like and I'll
just drill on in just a moment. We'll go into that goal and we'll start to break it down
in terms of things like action items. How are we going to achieve that goal? Are we
going to maximize the unit exposure to water? We're going to control the unit orientation
and we're going to calculate the percent of unit space in the water and we're going to
control the tower orientation. And then each of these breaks down in terms of some strategies
and ultimately, parameters, things that we can start to manipulate and wiggle around
to try to optimize for that design. We then take those parameters [INDISTINCT] and one
thing that we get that's very interesting right there as we start to really already
understand which ones of these decision goals are impacted by which ones of these parameters
and things like that. So we can start to understand how our parameter is going to be impacting
our objectives right there. And the next step is then to take those parameters and build
a parametric model. So we'll take some of those parameters and group them into, like,
perhaps the floor point of the building and then describe the geometry that will actually
fit around those parameters and help us actually create geometry for it. And constrain that
geometry and ultimately--so here's the model for a real project that we did with [INDISTINCT]
with shows we had the floor plate which relates to the slabs and the unit walls and the unit
walls relate to the different glass walls in the south and the east and things like
that. So we're starting to connect components to the building and describe them parametrically
and start to generate these type of designs spaces that you're hopefully objective driven
because we've connected them to the objectives. We analyze them, we bring them into a big
spreadsheet where you put the different alternatives, the goals. We score them and we understand
how well they perform. Okay. So the next project is about going from alternatives to impacts
and doing that more effectively and efficiently. So here we looked to a mechanical engineering
technology called process integration design optimization used in aerospace automobiles.
This is a platform made by Phoenix Integration. And we wrapped--you basically wrap commercial
tools and then put them in this platform to orchestrate things like design space exploration
and optimization. So we've wrapped Digital Project which was an architectural flavor
of Catia, Energy Plus which is the kind of leading energy model for us right now. GSA
is a structural application made by EARP and wrap it into a of process flow like this.
And we have an optimizer provided by Phoenix in this case. So our first attempt at this
was to just do a very simple case, take a classroom building. You can see we were going
to orient the orientation, the building length, the window to wall ratio. Some problems like
that is what we were interested in looking through. And we were able to now start to
get some really interesting performance trend feedback which just hasn't been available
to designers until very recently. So this diagram is called a parallel coordinates plot.
Basically the blue lines are the best designs and the cheapest that you could follow them
through and understand that there are two building lengths, for example, that lead to
best structural--the cheapest structural solution. And here we're looking at tradeoffs between
structural cost and life cycle cost. So I'll just drill into a couple of projects related
to [INDISTINCT] in a little more depth. So this is work by Ben Welle and what he's trying
to do here is to--John mentioned that Design Explorer was great for square buildings. We're
trying to develop a more robust workflow which can work for more complicated buildings. So
we're basically going to take the Digital Project Catia model, put it through what's
called an IFC translator, put them--the model into Energy Plus, put in the radians. We're
going to take that day lighting information, plug that into the energy, because you want
to know how much daylight you need so you know how much you can turn on the lights,
et cetera. And then we put it into this optimization flow. To give you sense some of the issues
we have to deal with for this data flow, all sorts of things like what you call space boundaries,
single level space boundaries, third level space boundaries. So you can see the difference
here. it's just about how the thermal flow goes through the walls and things. That we
need to set up that geometry differently for Energy Plus than the way it came out of the
architectural model. We need to deal with the way we model things like columns and overhangs
and things, et cetera, differently. Energy Plus just expects different geometry than
the architectural model. So we have a number of automated translations that work through
that. And you can see the types of buildings that we're able to now push through this process
and get accurate results. And now we're able to get this kind of information, we can understand
that, hey, overhang on the depth--overhang depth on the west facade is the real driver.
That's what's going to, you know, drive most of our energy performance. We can talk about
these other things but if we really want to focus on it, let's talk about overhang on
the west. You can see some relationships between, for example, west overhang depth and south
overhang depth and their tradeoffs when you're considering annual energy costs. Second project
is--this is structural so this is a case where, in a structural frame, you sometimes have
continuous variables and you sometimes have discreet variables, case of a structural frame.
Each of this members are going to be discreet. You have like a different size steel that
you could put in there off the shelf but the geometry itself is continuous, right? You
can move it an inch, an inch, an inch up or move this node back or forth or something.
So, in this case, we've developed a specialized optimizer which can do both the sizing with
the [INDISTINCT] as well as dealing with shape optimizer issues. This is just showing some
moderate improvement over--let me just see here. Well, I'll just go to the next one.
We were able to show moderate improvement over existing structural optimization. Optimization
algorithms, they've been around for a while and so we can show for smaller problems some
improvement. But the real issue is when you start to bring this into large projects with
many, many members. So here's steel stadium roof and you can see that we're able to really
reduce structural steel weight by a significant amount, 24% in this case. I show this example
because I feel like there's incredible fat on our buildings. When people are using this
technology in aerospace for airplane wings and stuff like that, they get super excited
about like a 0.5 percent improvement. So there's real opportunity here. Just the last piece
of work I want to talk about is so as a designer, we come and we face different challenges.
We might have fairly simple challenges of a relocatable classroom building in San Diego.
We might have extremely complicated challenges of Google Campus somewhere else. So we have
a series of different challenges, we have a bunch of different strategies. We can just
let the designer go and pick an alternative and that would be our strategy, or we can
do some of these really advanced strategies that I've told you and each of them afford
a different type exploration. So wouldn't it be great, as Hobb mentioned before, to
say, "Hey, I've got this problem. I want to, you know, pick this building design and plunk
it in there." I think we need take a step back from that and say, "Well, I have this
problem. What's the right process for me to attack this problem?" And so that's what this
really work is trying okay say is can we measure challenges? Can we measure strategies? Can
we measure the exploration? And we've just--I'll shoot through that but we did a shred test
with allowing people to produce--given different challenges, apply different strategies and
we can measure their exploration and understand what strategies challenge is the best. And
just a couple of interesting things that emerged was that when we allow people to just get
point data, so we say give us a design and we're going to give you the energy performance
back. You look at the energy performance, you can give us another design. We'll give
you the energy performance back. Amazingly, their exploration [INDISTINCT] to achieve
better designs was not much better than if we didn't give them any energy information
at all. They just a relied on their precedent. This is for professional designers, I should
say. But when we start to give them trend data about, you know, looking through the
whole space, give them the trends, then they're able to achieve much better designs much more
quickly. So we've had some early efforts of really bringing these architects and engineers
and stakeholders together. This is a shred where I can see a bunch of blonde heads there.
We brought some researchers and professionals in from Finland. In about an afternoon, we
were able to go through this process with all these different tools and look through
a fairly large space and get people to understand where the best designs might be for. In their
case, the classroom building in Helsinki. So where are we now? I argue that we're getting
a little bit better in terms of the quality and clarity of these spaces but there's a
lot of work to do. One thing I run into building these models is challenge and people don't
want to commit to really changing their process and doing something else even if it will lead
to better designs eventually. So it's just kind of ongoing research question about, you
know, how much clarity and how quality should this design space be for different challenges?
So this is one tool that we've built which is just trying to show different options,
the different stakeholders and what the value is to each option. It's just one page that
allows these stakeholders to go on and say, "Hey, I like this one because of this. I like
this one because of that." And we then compare and understand on just one page the design
space without all that other detail. So in just summary, a sustainable building design
involves exploring and communicating design spaces. Project Two has really struggled to
do this efficiently and effectively today. We have tools emerging that do improve this
exploration and communication but there are great organizational, cultural, educational
and technical challenges remaining to apply this to practice. Thank you.
>> ECK: Hello. I'm Douglass Eck from Google. I wonder if you could go back to one of the
slides from PIP where you had all the graph--the big graph up, you know, way back to the first
third of your talk. I know. >> HAYMAKER: Sorry about that.
>> ECK: That's okay. >> HAYMAKER: Go ahead and start the question
if you like, or I can... >> ECK: So I'm at this from a software development
view. >> HAYMAKER: Yes.
>> ECK: And there are numbers--a number of graphical languages in software development
that work for small problems. >> HAYMAKER: Yes.
>> ECK: I can think of my area of music and there are lots of great little software development
platforms that let you pull together boxes and arrows and build cool things. And I would--I
would hold it to be almost a universal that these sorts of programming paradigms don't
scale well. They don't scale well at all. >> HAYMAKER: Yes.
>> ECK: And I'm wondering if you've had issues with--yeah, that's the one that scared me
right there. >> HAYMAKER: Yup.
>> That scared--oh no, like underneath this or behind all this, have you thought about
ways to take advantage of the paradigm of open source software development, which is
really about building small reasonable components of code and defining carefully ways for pieces
of code to communicate with one another? Or is it that architects love this kind of stuff?
I'm not saying it's bad, it's just--but honestly, for me as a software developer, I look at
this and I think I don't know I'd ever spin up and be able to use something like that.
>> HAYMAKER: Sure. Good. It's a great question. This is an exploration to see, you know, how
well can this scale to the architectural domain. And it--another challenge that we have is,
you know, in practice now, we have lots of people using lots of tools already. I mean,
these are all commercial tools that we're wrapping in here, right? So I have done some
previous projects where I, you know, went down to the very bottom and talked about the
different components and how they should plug together and get the data to flow through
automatically. You know, I'd love some help from you guys to figure out how to do that
better. This was really coming out a little bit from a different side, which is, okay,
we're starting here, right? We already have this file--folder hierarchy with everybody
with all their information and what we're missing--one thing we're missing is that just
knowing that something depends on something else, that gets completely lost. [PAUSE] [INDISTINCT]
class project working for 10 weeks on one design problem, this does actually scale pretty
well, you know, for the number of nodes and links and things like that. Some of the things
that help are, you know, we have a hierarchical organization as well as a graph organization.
You can kind of work through either view when you want to, depending on what you need to
do. So I found that it did scale up to that level. I'm, you know, certainly interested
in bringing that on to larger projects and seeing where it starts to break down and what
the other issues are related to that. Okay. >> POVINELLI: Michelle Povinelli from University
of Southern California. I think we've all had the experience where we've been in a building
and you can see what the architects wanted to do and you can also see which parts worked
or didn't work. Maybe you see a collaboration space that was clearly meant as a collaboration
space that no one ever uses or chairs in the lobby that people don't sit in, et cetera.
So I'm interested in how much data you have about which parts of buildings worked. There
a lot of building existing. There a lot of building that have been built already. How
can you get data about what worked and didn't work and maybe use that to constrain the design
process or guide architects? >> HAYMAKER: Yup.
>> POVINELLI: We saw the session this morning and yesterday was all about how, if you have
enough data, you can do feature extraction and start to guide designs. Do you have access
to that kind of thing in this field? Or what would it take technologically to start gathering
the kind of data that could feed back to your models?
>> HAYMAKER: Great question. So we certainly have a process called Post Occupancy Evaluation
where we go--should go into buildings after the fact and understand how well they're working
and record them based on the metrics that we used when we were designing. It's kind
of a great IDM practice. Most projects kind of run out of money. It's usually in the construction
budget, first of all, unfortunately that, I mean, you run out of money and you end up
cutting that out and don't do any Post Occupancy Evaluation. Another problem with Post Occupancy
Evaluation, I think, is that, you know, the metrics used to design the building get sort
of lost. I mention that they're never communicated well. So then how do you go in after and say,
"Well, is this performing based on designer intent or not?" because the designer intent
is fairly diffused and lost. So, I guess I view the Mac Daddy Tool as--and I guess PIP
as well, as the first step in that which is, in design, it must be more clear and structured
about to where we're going to put this information together and present it. I haven't done any
work and following this model through the construction and the operation phase but I
think it would be wonderful. You know, I have these graphs of value; it'd be wonderful if
during construction, people were, you know, tracking all their decisions based on the
value they're providing to the client and as well an operational return say, were really
providing that value in the--in the end building. Okay. Question?
>> STOCK: I'm Herman Stock at MIT. You mentioned that many of our buildings have too much fat
right now. >> HAYMAKER: Yeah.
>> STOCK: Given that [INDISTINCT] sort of the design parameters and forcings and so
on, how much of that fat is sort of needed in terms of extra safety and how much can
you really shave off? >> HAYMAKER: It's a great question and I love
[INDISTINCT] my colleagues to jump in on that as well but--and for example, structural engineering,
I think, what we saw there was there were already factors of safety put into these analysis
packages, right? It was 1.4 and 1.7 for live and dead lodes or something like that. So,
you know, there is already some factor of safety in there for that uncertainty, I guess.
I'm--all of my work has assumed that the tools are good and that, you know, if there's certainly
a lot of work to do to validate the energy analyses and the structural analyses to make
sure that they are--we don't have to add that extra factor of safety. But I think, you know,
the work says we can include that factor of safety into the analyses tools if we want
to and then we should be able to optimize to that point and not add, you know, all these
sort of softer factors of safety based on designer's intuition and things like that.
Does that make sense? >> Great.
>> HAYMAKER: Okay. >> We have time for one more quick question.
>> Raul [INDISTINCT] MIT. So this is a question for you and John since there's no panel today.
So trees have evolved over billions of years of evolution to stand tall and collect a lot
of sunlight for their energy. And given that most of us are going to be living in the cities
in the future, which means we'll going to have a lot of skyscrapers, you think it's
practical to build buildings like trees where you actually have stuff that comes up and
then branches out and then is covered with photovoltaics to have high roof area? Or do
you think that would be extremely expensive and impractical to have all these branched
structures coming off the building? >> HAYMAKER: You know, certainly, the discussion
yesterday with the added manufacturing, I have no present knowledge in what that stuff
could cost but that seemed pretty promising that you would be able to, you know, generate
that kind of, I guess, complexity more easily and construct it more easily than you could
today. I don't quite know what that looks like yet. But it seems like a big part of,
like, building that thing would be the just cost of building such a structure and handling
all those cantilevers and things like that. But with better structural analysis and better
construction techniques, I believe we could build something like that and perhaps even
do it in a financially feasible way. Really, I guess, for me, the question would be what
are we going to put in that building? What does it need to do? You know, that says--John
showed that great thing about... >> [INDISTINCT] speaking of Apollo Building
in [INDISTINCT] >> HAYMAKER: Yup.
>> And opening [INDISTINCT] everyone is talking [INDISTINCT]
>> Can I--can I just... >> [INDISTINCT]
>> Can I just chime in real quick say that braches sway a lot and humans don't like that
much acceleration normally, number one. Number two, there are setback laws because daylight
is a natural resource and if all the tress--if all the buildings create a canopy and the
streets are dark, we're unhappy. So biology can do a lot for architecture in terms of
inspiration but we have to be careful just to copy directly and say, "We've got it. We're
going to--buildings are going to be trees." But I agree that trees are an unbelievable
work of technology that we're only beginning to understand and if buildings could be more
like trees and how they perform, absolutely. But we can't translate the metaphor directly.
>> HAYMAKER: Thank you, John.