Med Mart 4: Facade Design Coordination

The ambitious schedule of the Cleveland Medical Mart and Convention Center project required us to reexamine and retool some of the ways we design, document, and deliver a project.   As the leaders of the design effort, we at LMN knew that we would need to find and build smart connections between our generative design tools and our documentation process in order to not only meet deadlines, but also adapt to the parameters that were developing throughout the design-assist process.

Our role in this phase of the project shifted from that of the prime-contract holder to design oversight.   This meant that despite leading the design effort for the facade system, all contract documents would be produced by the local design-build team.  Our role would be to share as much information as possible with the design-build team, who in turn would provide the final construction documents for the project.  With only three and a half months to design, coordinate, and produce shop drawings for the 250,000 square foot facade, that process would need to be both efficient and collaborative.

Traditionally in this hybrid design-bid-build/design-build process, the input of experts tends to be incorporated very late in the process, allowing little time for the modification of design elements to make them more feasible for construction and maintenance.  But because of the ambitious schedule and evolving complexity in the design, we knew it would be crucial for us to engage as many of the fabricators and specialists in the process as early as possible.  We also knew that the more information we could share with our extended design-assist partners, the more rapidly we would be able to optimize our system for both cost and constructability.

Cricket

One of the keys to meeting these goals was building a strong link between our generative tools (based in Rhino) and our BIM coordination tool, Revit.   We began work on a small utility we called “Cricket.”  Cricket formed the bridge between Grasshopper and Revit, allowing us to leap from Grasshopper to Revit without hassle.  Cricket was composed of two pieces: 1) a series of custom Grasshopper components (Cricket Family, Cricket Type, Cricket Point, Cricket Vector) that would “chirp” their list contents into memory (or a file); and 2) a Revit-based Cricket listener that positions and orients pre-built Revit families and types upon an updated “chirp.”  Updating the entire facade in Revit took approximately 20-30 seconds.  Here’s an overview information flow in the earliest version of Cricket:

During the Cleveland Med Mart design, Cricket was completely unidirectional: only allowing us to leap from Grasshopper to Revit.  (We are currently working on a version that allows Revit to “chirp” back to Grasshopper, so shared parameters of a Revit family can be referenced from within Grasshopper).  However, even in the unidirectional version, an efficient connection between these two platforms enabled us not only to easily document and track changes and developments in the design evolution, but more significantly enabled our collaborators to quickly gauge the impacts of the quickly evolving design.  This allowed us to make large-scale calibrations of the facade system late in the game as required without compromising the ambitious schedule.

Adapted Output

One of the great benefits of making a BIM platform like Revit the central design coordination tool is the flexibility of content output.  As our master building shell model became the main tool for coordination, we adapted the outputs from that file to meet the needs of our collaborators.  The file formats requested were as varied as the project team: our local architect and GC team coordinated directly to the .RVT file; the curtain wall fabricator preferred to use an .IFC file; the precast contractor worked directly from 2D .DWG files; the envelope consultants used 2D .PDF sheets.   While in an ideal world we would have had all parties working within the same platform, in this case the speed and intensity of the process proved it more important for the builders and specialists to work within their comfort zone.

Re-tooling

Throughout the design process we continually worked to adapt our tools to make the collaboration process more efficient.  One of the more effective adaptations we developed was in response to the significant amount of manual analysis and re-drawing done by the precast fabricators.

As the design evolved, the concrete panel configurations changed very frequently.  With the cost of on-site installation greatly outweighing the cost of factory-controlled labor, the precast fabricator was looking to minimize the overall number of pieces they needed to erect.  With every new version that emerged from our office, our precast fabricator would need to re-draw the elevations showing combined panels. Their basic criteria was simple: panels would maintain their 10 foot width, but could be as tall as 27 feet.

We knew we could simplify and accelerate this process, so with their criteria in mind, we expanded our Grasshopper definition to group adjacent panels together into combined panels.  The process starts by sorting all of the panels into columns and then attempting to join each column together.  Panels that were not joined together are sent to the end of the process for documentation.  If multiple panels are joined together into a new combined panel then they are sent to the next step.  Combined panels that are greater than 27 feet in length are broken into smaller pieces.

The entire collection of combined panels is then examined to find how many unique sizes there are, and a catalog of panels is created. Each combined panel is colored, numbered, and tagged with information related to panel sizes, orientation, quantities, and an identifier. In addition to the catalog, a set of colored and tagged elevations are generated so the fabricators could understand all the parts of the system.

Initially we tried to limit the number of unique parts in the facade system but the number of configurations quickly began to increase from six different panels to over 100 configurations once corners, soffits, parapets, and combined panels were taken into consideration.  Combining the panels played a large role in the increased number of configurations, but it also reduced the number of pieces that will be lifted into place from 880 to around 400.

Process Makes Progress

Perhaps the most significant gain to come from these advances in our working process was the almost immediate establishment of a high level of trust between architects, consultants, and fabricators. We were able to connect our generative work to multiple documentation methods and file formats, each tailored to the needs of our collaborators. Changes made to the system or configuration were immediately documented, greatly easing the work required to track quantities and costs. This freed us from having to manually update large portions of the documentation so the design could continue to evolve as the large team of specialists collaborated with us to refine the facade system.

As our team-based working progress developed we were able to find creative and efficient ways to work through the complex and sometimes prohibitive contract structures, and the sharing of information was key.  It gave all parties access to all the parameters and variables of a rapidly evolving design solution.  It established trust, and allowed a complex system to develop at a rapid pace with the input of many experienced experts.  But above all, this process has required architects who are willing to ask questions, bring experts to the table, and lead a smart collaborative process.

We are finding that design collaboration and project delivery can be increasingly more productive and efficient when paired with smart, nimble, and adaptive design tools.  To us this is part of a natural evolution towards the concept of “BIM-as-process.”  No longer does it need to be synonymous with a software platform/file-type; perhaps now BIM can be considered the central characteristic of a more holistic approach to design and delivery.

In our next post, we’ll show how we used rapid-prototyping to parallel the full-scale fabrication process of the precast panels.  We’ll discuss how this better informed the physical-digital-physical-digital- chain leading to the scale-model and the actual facade.  Stay tuned…

Related Posts:

Med Mart: Introduction

Med Mart 1: Generation of Facade Geometry

Med Mart 2: Panel Texture and Geometry

Med Mart 3: Daylighting the Atrium

Med Mart 5: Panel Fabrication

10 Comments

  1. Adam says:

    Very interesting work and great solutions. I am very curious about the link “Cricket” that you created for importing into Revit. I’m a beginner in GH and Revit but very familiar with Rhino. Having that link seems essential to making GH a real solution for our projects. Is this something you guys are going to release as a product or is it purely an in-house toy. Thanks.

  2. dbelcher says:

    Adam-

    Thanks!
    At the moment, Cricket is an in-house LMN-only utility. However, we’re expanding its functionality and improving performance (faster faster faster). At the moment, the main job is rebuilding Cricket around the Revit 2012 API and reworking our components on the Grasshopper side. There’s a lot of tinkering going on – esp. in creating a bi-directional interface – so it’s not ready for release yet. We’ll post more about it as it evolves.

    Best,
    -Dan

  3. Zaki Mallasi says:

    Hello,

    I have come across this post and found it very inspiring and informative to façade engineering especially when it targets to automate the process towards digital fabrication from the BIM model.

    I have been developing his FREE Revit –add-on which communicates to an analytical image as source data to configure the panels in the façade. I would love to share and work with you on ideas related to this. Here is a web link to my Blog.

    http://www.iconviz.com/blog

    Thanks – Zaki

  4. fascinating process. I mainly design small projects and this is very interesting, rarely seen and which must be challenging especially regarding the communication with everyone involved. Can you expand on this?

  5. scrawford says:

    Christian,

    A project of this scale does pose the challenge of having multiple parties involved. In this case none of them were located in the same state or region (Seattle, Chicago, Cleveland). Fortunately, everyone made an effort to understand each others issues and try to find solutions that didn’t leave someone with the short straw. In the end, the most important thing is to get these discussions started early so that the communication process is established before the large issues arise.

    Scott

  6. Wonderful article! That is the type of info that should be shared across the net.

    Shame on the search engines for no longer positioning this post
    higher! Come on over and visit my site . Thanks =)

Leave a Comment