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.
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.
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.
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…