fbpx
';
side-area-logo

Building with Science #008: Testing of Building Facades

Shawn McIsaac

You should test the weather tightness of a curtain wall, windows, and designs under cyclonic winds, rain, and earthquakes but you shouldn’t think that is a guarantee of performance in-situ: that would be silly. Equally as silly as believing you need to test claddings to determine their weather tightness or that makes them weather proof.

There are lots of ways to demonstrate if your system could theoretically keep water out of a building before we stuff it into a really high building, made up entirely of glass. And more than a few ways to make sure they stays on the building when a hurricane rolls through, or an earthquake (a volcano is more likely in Auckland but we’ll park that for a moment).

Facade testing is just one, very complicated and expensive way and for windows and curtain wall makes perfect sense. Doors and windows are tricky. They have lots of joints, lots of complicated drainage channels, gaskets and they have parts that move. You can’t easily tell that a window system will or won’t work from a set of drawings. Well, we can tell if something definitely won’t work, but can’t always tell if it will work.

For instance, the picture above is Matthew at a test chamber in China. We were testing these doors because they were really Big Fucking Doors (I called this system the Allwin BFD, 3.3mX4.5m) and this had never been done before. These were going in the facade of a 17-story apartment building and because these were giant complicated doors and we needed to confirm they worked. And they did.

This particular testing method is proof of concept testing. Iron out all the bugs and things you didn’t know you didn’t know (known unknowns). This is a test for curtain wall systems, it has failure criteria suited to curtain walls. These failure criteria are of arguable relevance even for curtainwall, let alone being used for claddings. And you do this because these are complicated systems.

Claddings however are really dumb technology in comparison. They don’t move, they have very few joints, they have gigantic drainage cavities. We don’t really need a test to tell us if a rainscreen cladding system is going to keep water out, it will, every time. That’s how rainscreens work.

Water always gets past the cladding layer. Always, always, always. And if you think it won’t you’re wrong.

(see previous article, Building With Science 007 for more information).

And funny enough in the case of this article, and our Verification Methods, a positive test would be less reliable indication than designing a wall correctly. We have not one but two ways to get a false positive code compliance path Verifications Methods based on testing (E2/VM1 and E2/VM2) and neither one test the right thing.

Let’s talk about failure criteria first. What is a pass and what is a failure?

NZS 4284 defines failure under water testing as follows:

Under static and cyclic pressures there shall be no leaks. For both the static and cyclic water tests, a leak is considered to occur when one or more of the following occur: 

(a) Water appears on any inside surface of the facade and is visible from an occupied space. 

(b) Uncontrolled water appears on any inside surface of the facade. 

(c) Water appears that is likely to wet insulation, fixtures and finishes. 

(d) Water appears in other locations specified as unacceptable by the Specifier. 

What does a) b) c) mean? If water gets to a place where it is a problem, that is bad. I’ll toast to that. But this tricky little criteria d) has steered an entire generation of designers and manufacturer’s towards a terribly embarrassing understanding of performance.

In the case of the building code, the specifier is MBIE (with guidance from some scientists I’m sure, who happen to have a testing rig, perhaps).

And in the case of E2/VM1 and E2/VM2, the ‘location specified as unacceptable’ is completely wrong and foolish.

As we’ve established almost 20 years ago, face sealed systems have been demonstrated through testing, experience, and practice to be completely infeasible methodology to prevent water entry. We tried, and so did Europe, Japan, Canada, the US, and Australia (they just don’t know it yet), to make perfect claddings which you could do in a lab, but can’t do in the real world. Didn’t go very well.

So why (why oh why oh why) would we test to see if we can make a face sealed cladding system work? Why did we define our own failure criteria as:

…no water shall be transferred to the plane of the wall underlay…

The wall underlay is the weather resistive barrier (WRB). It’s sole purpose in life is preventing water getting through it so why can’t water get to that layer? It literally has one job and that’s it. Just let the WRB do it’s job. I personally would have defined the failure criteria as getting passed the WRB, but getting past the cladding? That’s a really stupid place to define failure.

Now stopping water getting in is a good idea. We should all do that. But we should also design walls that accommodate (dry out) water entry. That’s the idea of vapour permeability, rain-screen claddings and building (with) science. You could of course design this system, pass this test, and real world pops up and this still result in a miserable failure. Is that that a good test?

Hypothetically (and I’ll prove this one day soon) I could get a face-sealed monolythic cladding system to pass these Verification Methods. And there would be nothing stopping me from getting a building consent, you could not reject a Verification Method, even though we know it to be false.

Walls work because they prevent more wetting that drying, not because they passed an arbitrary test in a laboratory under the installation of the best installation team, and given as many attempts as they want. These false positives, are further proof that the guys writing the building code need better advice than they are getting. We’re just wasting everyone’s time and money entertaining these bogus concepts.

Recommend
  • Facebook
  • Twitter
  • LinkedIN
Share
Tagged in