Eating your roof

Producing food is a critical need for any community project. Your first thought might be traditional gardens or farm plots, neatly ordered into precise rows, tucked away on a back corner of your yards. That’s certainly one vision of personal food production, but is far from the most efficient. Why not let your food production aid in other areas of your design?

A key point of many advocates of sustainable design is using a green roof because it saves energy (and money) you might otherwise use for heating and cooling. However, many designers of green roofs often miss a key point of overall efficiency, which is using edible plants for green roofing. If you’re to go to all the trouble of planting greenery on your building, why not plant stuff you can eat?

Of course, installing a green roof isn’t as simple as throwing some dirt and seedlings on your roof – it takes careful design to understand how a green roof affects your structure, internal temperature, rainwater runoff, and so forth. So let’s practice running some numbers. (Note: equation key is at the end of the post.)

Heat flux is a measure of the rate of heat energy over an area. It is the primary measure of energy losses and gains for home construction. For a traditional shingle roof in the Midwest, summer heat flux is 2.37 W/m^2 compared to 1.57 W/m^2 for a green roof, which is an improvement of 33% (summer heat flux is used here because in winter, everything’s white!). For a simplified calculation, let’s assume a flat roof for a square house 10 meters x 10 meters.

For asphalt shingles, H = (2.37)(100) = 237 W
For a green roof, H = (1.57)(100) = 157 W

The net energy savings over the summer months (June-July) can be calculated as follows.

E = (237 – 157W)*(90 days)*(24 h/day) = 172.8 kWh

This can help drastically shrink your estimates for energy and insulation requirements. (There is also an insulation effect from the soil I will roll into another post targeting earthen insulation.)

Using native soils, the typical loading on a roof could be 2300 – 7000 Pa, as opposed to under 230 Pa for a shingled roof. This is a significant weight addition and many buildings need structural reinforcement before they can support green roofs. A discussion on calculating structural requirements is upcoming, so I’ll save it for that post, but keep this in mind during your brainstorming.

Also, many green roof projects today use plastic barriers to prevent water intrusion into the building. One sustainable post-peak alternative might be using clay instead, but remember this would add significant weight and require greater roof reinforcement.

Green roofs may seem like a lot of work, but consider this: most shingles are made from asphalt, which is made from oil. As oil prices and scarcity increase, how will you protect your roof? A well-planned green roof seems like a good solution. (But there are others…)

Key:
W=watt
m^2=square meter
H = heat flux
kWh = kilowatt hours
Pa = Pascals (unit of pressure)

References: www.greenroofs.com
ASHRAE Journal

Web hosting recommendations

While blogspot is pretty good for straightforward blogs, it’s clear that my plans for this project require more functionality than they can offer. So, I’m looking for advice on good web hosting companies from those of you with experience.

I need a decently-priced service with some good tools for file sharing, forums, web-forms, and content search. I’m handy enough with HTML, but I don’t have a lot of time to spend developing advanced features.

With those thoughts in mind, does anybody have some good suggestions?

Comment roundup

There are a number of discussions and questions in the comments this week about some very key issues. I wanted to capture my thoughts in a full post so nobody misses them.

One commenter keenly pointed out that there is a distinction between sustainability and self-sufficiency. Sustainable design typically uses self-sufficiency as a path to sustainability, and that is the approach I’m using in the ‘Homestead Project’ example problem. Self-sufficiency is, of course, not failsafe: an independent farmer may still allow his field to erode away; a lazy hunter might leave half his kill to rot; or an electrical generation system may leach toxins into the environment.

I think he is correct in that the sustainability goals he cites should further modify our example problem. However, I feel there is no problem with a sustainable community being ‘high-tech’; it need only have ‘less tech’ (as in quantity) from what most of us are familiar. In fact, if we are truly looking at ultimate long-term sustainability for our species, we must develop the ability to expand civilization into space. We risk premature extinction if we do not. I believe this is a possible goal for a sustainable civilization, an assertion I will discuss at length in the future.

Also, please don’t misunderstand the purpose of the example problem. I have started with a small ‘community’ of a single family primarily to illustrate principles of Systems Engineering without getting lost in the complexities of a large community. I’m not making choices for anyone – everyone decides for themselves what their future looks like. A family which chooses self-sufficient isolation will most likely be vulnerable to lack of medical care, limited food diversity, depression (from lack of social interaction), critical tool shortages, and many other serious risks.

I plan to use the ‘Homestead Project’ as a baseline for building one or more larger projects, ones which serve to explore the trade-offs between individuals' skills and strengths, critical infrastructure, community size, strategies for government, and thoughts on security, among hundreds of other considerations.

If you remember one thing from this post, remember this: Do NOT get bogged down in the details of the example problems on this blog! Focus more on the structure, less on the content, as every project’s design and solution will be different. We will explore solutions and design strategies (look for such a post tomorrow), and that is when you want to critically examine the content.

Designing With Spoons: A Philosophy

Back in college I had a friend who was convinced the only utensil she needed in life was a spoon. She lived by that assertion – hacking away at dry dorm steak, deftly balancing leaves of lettuce, and smoothly buttering her bread, all with a spoon. The rest of us would laugh or shake our heads, wondering to one another about what a quirky girl she was.

It wasn’t until recently that I made the connection between spoons and her interest in environmental science: using only curvy silverware was an exercise in conservation. By reminding herself at every meal of what she truly needed she forced herself to consider what else she could do without.

In designing a sustainable future for ourselves, we must constantly remind ourselves what we might comfortably live without. Would our quality of life suffer if we didn’t jump for that new iPod? What if we stopped watering our lawns every day? Why not grow our own food?

These types of questions should be applied to sustainable design at every step of the way. Happiness is possible – perhaps only possible – without gregarious consumption. If our future pool of available resources is limited then it becomes even more critical to understand our true requirements.

The future is wrought with uncertain challenges, from Peak Oil to global warming to overpopulation. At some point we will be forced to live without many seemingly essential tools of our existence. If we make conscious decisions now, and design ourselves out of an unsustainable lifestyle, our challenges will seem more manageable.

My advice: Design smart, design completely, design for happiness. And make sure to include a spoon.

Space Shuttles gotta get flying...

I’ve been pulling 12-hour shifts at work for the past four days, but I’ll get back on the posting wagon again after tomorrow. In the meantime, enjoy the more philosophical post to follow shortly.

Acceptance Criteria

Something very critical to your overall design mindset is the concept of Acceptance Criteria. There are the qualities your design must have in order to be considered even a marginal success. Every other design goal can flop, but if the Acceptance Criteria fail then all is lost.

For our example problem, the Acceptance Criteria are things you (literally) cannot live without – food, water, and shelter. [An aside: This points me to another missing goal, Goal 5: “The community will provide shelter.” Seems obvious, but obviousness is no guarantee of success. BTW, I will soon be posting a document containing the goals, objectives, and requirements we’ve developed so far for the example problem.]

So how do you characterize the Acceptance Criteria? For this project we might say that the community must: 1) Provide at least 280 lpd of potable water (see earlier post); 2) Provide at least 8400 calories/day of food (also earlier); 3) Provide at least TBD* square feet of enclosed living space; and 4) Meet the first three criteria by 2009.

Your Acceptance Criteria should be in the back of your mind at every stage in the design. Post them in your work area. Look at them every day. If you start getting bogged down in one area of your design, take a step back and look at what’s really important. Electricity and plumbing are nice, but without the essentials you don’t have anything to put in your wafflemaker nor any way to flush a toilet. Keep the list of Acceptance Criteria small. Stay grounded and don’t let your project snowball to the point where it overwhelms you.

* TBD = To Be Determined. It is okay to leave a placeholder for data you need to look up. Just don’t forget about them and never move on to the next level of design until you fill in the blanks. (In my case, my notes with the information are packed up in a box at work – I’ll give you an update when I track it down.)

Water, water everywhere...

Just to get the designer wheels in your head started spinning, Peak Energy posted a good link to a story about a successful ground heat pump.

I have a little bit more to say about basic requirements as discussed in the previous post. Looking at Objective 2.1 (“The community will provide indoor plumbing adequate for four people.”), I’m starting to think that the driving goal (Goal 2) should be changed so that we can use it to address all the water management needs. This type of modification is common as Systems Engineering solutions are developed and I hope it shows you how fluid the design process is.

So, instead of Goal 2 reading “The community will have indoor plumbing”, how about “The community will provide adequate water supplies.” We’ll leave Objective 2.1 as it is, but add Objective 2.2: “The community will provide enough water to sustain four people.” Now that we fixed our goals and objectives, let’s define some requirements.

Taking some liberties with the data, the average human needs approximately 5 liters per day (lpd) for drinking, 45 lpd for hygiene and bathing, 20 lpd for cooking activities, and 3500 lpd for food production according to the Pacific Institute. (Very good link by the way.) Bear in mind these numbers reflect only the water “at the tap” – they take into account moderate efficiency improvements over the average American’s lifestyle and say nothing about recycling or help from local rainfall.

I will put these numbers into two categories: personal and agricultural, with respective values of 70 lpd and 3500 lpd. For the four-person community, this comes to 280 lpd for personal water and 14,000 lpd for agricultural water. This leads naturally to two requirements – “The community shall provide no less than 280 lpd of indoor water.” (Requirement 2.1.1) and “The community shall provide no less than 14,000 lpd of water for food production.” (Requirement 2.2.1)

Notice two things about these requirements: 1) They are wild-ass estimates and will surely be modified as your design develops and 2) they are intertwined with each other and their parent objectives. I could just as easily put Req 2.1.1 under Objective 2.2. Assigning requirements often comes down to intuition or preference, but remember that in the end every objective (for any project) must have at least one requirement. This ensures that every objective is met.

In future posts I will talk about planning for changes in your local water allocation due to global warming effects, aquifer depletion, or upstream pollution.

Estimating basic requirements

Okay, I promise this is nearly the last boring post before really diving into design strategies and solutions. I’ll try to make this as interesting as I can, but bear with me – this is important!

Now that we have satisfactorily defined our example problem, we can start figuring out what tangibles we need. This process is known in Systems Engineering-speak as requirements definition.

Requirements can be a complicated business, in identifying them, organizing them, and even properly writing them. I will illustrate proper requirement definition with a few examples, but I will not go into much depth on everything that goes into effective requirements. You can learn that much more effectively by reading some of the references I cite or taking a Systems Engineering class. That said, I can’t emphasize enough how important it is to define clear requirements for your project, whatever its scale. You need to have a clear understanding by all parties involved, using requirements that can’t be misinterpreted, or you risk disaster.

Let’s pick one of the objectives from the last post and start figuring out some requirements to satisfy it. Objective 3.1 states “The community shall produce enough food for four people.” That seems like a good place to start.

According to the USDA, the food intake requirement per person per day is about 2100 calories. To meet our objective of producing enough food for four people, we can write Requirement 3.1.1: “The community shall provide no less than 8400 calories of food per day.”

Notice the form of the requirement: it says nothing about how we will provide that food. It never says anything about farming, livestock, hunting, gathering; it says nothing about food storage; it says nothing about greenhouses or any sort. It says only what the designed community must provide in order to be considered a success. This is an example of a high-level requirement. As we develop a solution, we will start making design decisions and lower-level requirements will start to fall out. (Note: As we move into lower levels, the requirements will change from “The community shall…” to “The garden shall…” or “The storeroom shall..”, etc.)

For now, Requirement 3.1.1 looks like it meets Objective 3.1 well enough. This is an iterative process, so we may change it as we develop a better understanding of our true requirements (i.e. the two children don't need 2100 cal/day at the outset, so maybe the requirement could start small and ramp up as the kids' needs increase). I’m going to leave it at that tonight and continue discussing requirements in the next post. Then it gets fun, and we can start tossing around design solutions and strategies.

Setting up the problem

A Systems Engineering solution begins by accurately identifying the needs, goals, and objectives of your project. These items can be as broad or narrow as required, but they are strictly used to define the problem, not imply any sort of design solution – that comes later.

In engineering terms, a need is driving force behind a project. No numbers are allowed in need statements, only concepts. It is not uncommon for a project team to spend a week debating the best need statement, and its importance can’t be understated. Without it, everyone involved has a different idea (or no idea) about what they’re doing and might develop either incompatible or completely wrong designs. It’s also useful just for organizing thoughts.

I’ve introduced a very broad target need for this blog, which is the need for designing sustainable communities. But what does that mean? Are you starting a community from scratch on a barren patch of land? Are you reshaping an entire existing city? Are you constructing a home for only one family? The answers are different for every project, which makes the job of forming an engineering methodology all the more difficult.

For me, the best way to learn a concept is by case study: applying the theory to a real-world example problem. For the sake of argument, let’s pick an example and use it to illustrate the concepts every community designer needs to understand.

Say you have a 40-acre piece of land, half-woods and half-arable land, with no existing structures. This may be a dream situation for many, but remember this is only an example and you should have no problem applying these ideas even if you have a half-acre plot in the city—you’re just starting with a different set of resources. So what are our needs? One possibility is “There is a need to have a sustainable community on the existing land.” That’s accurate but very loosely defined – what do you mean by ‘community’ and what is meant by ‘sustainable’?

To keep things from quickly spiraling into complexity, suppose you have a family of four (two adults, two pre-adolescent children) defined as your initial community. Suppose further that you are beginning your project pre-peak (transport costs are low, all devices and materials we desire are within reach), you want your community completely self-sufficient, and you wish to retain a comfortable existence with electricity and indoor plumbing. These are the ‘non-negotiable’ facts.

With this new information in hand, we can write an even better need statement: “There is a need to have a homestead for our family that is completely self-sufficient and allows for a comfortable standard of living.” Great! That’s enough for us to continue on towards defining our goals and objectives for the project.

A goal is a statement describing how you will meet your needs and an objective provides a measurable method for meeting the goals. Like needs, goals do not contain numbers.

For our project we can define several goals:

Goal 1: The community will have electricity.
Goal 2: The community will have indoor plumbing.
Goal 3: The community will grow its own food.
Goal 4: The community will be safe for children.

You might be able to pick out a couple more yourself for the given example. Notice that while the goals are more specific than the need statement, they are still very broad statements.

Each goal must have at least one objective attached to it. The objectives may contain numbers, but remember we are not yet designing anything here, only defining the problem. For the goal statements above we may specify some objectives:

Goal 1: The community will have electricity.
Objective 1.1: The community will provide enough electricity for four people.
Objective 1.2: The community will use modern electrical appliances.

Goal 2: The community will have indoor plumbing.
Objective 2.1: The community will provide indoor plumbing adequate for four people.

Goal 3: The community will grow its own food.
Objective 3.1: The community will produce enough food for four people.

Goal 4: The community will be safe for children.
Objective 4.1: The community will be designed to minimize the danger to children.

As you can see, each objective is measurable and some include numbers. However, none of them point to any particular design solution.

Alright, so what have we gained with all this work? Let’s put the entire problem definition together (notice the organization – 90% of engineering is staying organized):

Need: There is a need to have a homestead for our family that is completely self-sufficient and allows for a comfortable standard of living.

Goal 1: The community will have electricity.
Objective 1.1: The community will provide enough electricity for four people.
Objective 1.2: The community will use modern electrical appliances.
Goal 2: The community will have indoor plumbing.
Objective 2.1: The community will provide indoor plumbing adequate for four people.
Goal 3: The community will grow its own food.
Objective 3.1: The community will produce enough food for four people.
Goal 4: The community will be safe for children.
Objective 4.1: The community will be designed to minimize the danger to children.

Wow. It seems like we just did a whole lot of work for nothing but a half-page of text. Why bother with all this Systems Engineering garbage? Why not just jump right into designing and building? If you run into any problems during the process, you’ll just fix them and move on. What’s the big deal?

The truth is the vast majority of projects that do not apply Systems Engineering principles are doomed to failure from the beginning—either by spiraling costs or schedule, designing into a corner, or outright disaster. You must put in the time to carefully plan your community because you literally can not afford for this project to fail. The lives of you, your family, or even your neighbors might depend on your community’s success. Consider everything, ignore nothing, and keep your design flexible. Don’t be intimidated by the scope of this design problem, even if you have no engineering experience: I and every other reader of this blog will help guide you through what you need in order to design a robust and sustainable post-peak oil community.

There is so much more to come…

References: Customer-Centered Products by Hooks and Farry
Systems Engineering Principles and Practices by Kossiakoff and Sweet

Designing the Future

The Peak Oil community focuses its efforts on two main themes: predicting the peak and exploring sustainable life. There is a great deal of discussion on sustainable design and organic subsistence farming, but there is very little in the way of comprehensively engineering future communities. I would like to change that fact.

A formalized engineering framework is needed in order for effective post-peak oil design. This goes far beyond the sustainable design or green building initiatives -- Peak Oil Design requires careful analysis of not only the nature of your shelter, but what you will produce, how you will produce it, how you will store it, and who you need to produce it. The list is lengthy and complicated.

Much of this information already exists singly within the blogosphere and elsewhere, but it is not taken as part of a comprehensive design. My approach is to use a Systems Engineering methodology to pull the required information together and develop the skill set needed.

Systems Engineering is an approach to defining all required aspects of a system by a comprehensive life-cycle analysis. It is an iterative technique that requires individuals from many different specialties in order to succeed. In the course of my career as a NASA engineer*, I have found systems engineering a very powerful and necessary tool.

My vision for this blog is to develop an engineering method for complete design of post-Peak Oil communities. I plan to post on varying aspects of community design -- anything from construction techniques and crop planning to required skill sets and security -- all progressively developed into a formal engineering methodology that we all can use as a blueprint for designing our own communities.

The key to systems engineering is open communication and iterative discussion, so comments are absolutely essential for the success of this project. One important thing to remember is that this project will never be completed -- as more information is compiled, the domain expertise of the Peak Oil community will expand and further enable a thriving sustainable future. Let's let this be the first post of many!


* Any opinions or statements found on this site are not representative of NASA or the U.S. government