By: Adam Oswald
The Health Sciences Education Building (HSEB) on the Phoenix Biomedical Campus was completed by CO Architects in 2012 and was always intended to be the first phase of a two-phase project. We began design work on the phase two Biosciences Partnership Building (BPB) directly north of HSEB in summer 2014. The design was an extension of the previous work, including a very similar consultant/contractor team, and an early decision to use as many of the building systems from HSEB as possible.
Like HSEB, the BPB building skin is composed of a set of 24 copper panels. Each panel is built by lofting a surface between two edge profiles, with four profiles to choose from and a resulting combination of eight panels for each of three types.
When designing the system for BPB, the main challenge was to take a fabrication method that had worked well previously and adapt it to a building that was larger, had a more complex massing, and introduced a number of folding conditions not encountered on HSEB.
Where the HSEB skin was drawn, laid out, and modeled manually, we wanted to explore computational tools to automate as much of the process as possible. The team’s experience in Rhino and need for complex geometry made Grasshopper a natural choice to begin exploration, but with Revit as the primary documentation tool for the office, finding a way to translate our Rhino geometry to Revit was key. Because of the importance of being able to map each unique panel, we wanted to move beyond just bringing dumb geometry into Revit and actually be able to tag each panel with its type. After some exploration, we settled on using Excel and Dynamo to bring an information model across the platforms.
BPB was developed side-by-side in Rhino and Revit. Rhino allowed us to develop a precise shell model and quickly 3D print multiple iterations, while Revit served as the main platform for floor and lab layouts. Since the HSEB enclosure system specified several rules for panelization, we were able to build the Grasshopper script abstractly around those rules before we had settled on a skin geometry.
The final script operated on a Rhino surface model of the enclosure and generated linework of each panel, as well as center points and ordered corner points. Panel order within each row was randomly generated by coding the panel types and ensuring each row of panels followed the rule that end profiles always aligned, producing a flowing effect across the facade.
Then, rather than export geometry directly to Revit, we exported lists of corner point coordinates, paired with a string of coded panel types. That Excel data was read by Dynamo, which placed each panel in a pre-made adaptive components family and assigned a type based on the code string.
In Revit, we had modeled each panel as an adaptive components family, then nested those families in a controller panel family, where the key parameter selected which nested family to draw based on the coded panel type input. Those codes could be adjusted manually after running the script if there were any mistakes in ordering. In addition to choosing the panel type, the panel codes also selected a conditional text tag parameter, allowing us to tag every panel in the working drawings.
Flowchart of the panelization process, traversing several different software platforms
Existing Panels from the Phase 1 Building
The existing system was composed of 24 standard panel types, organized into three groups by height. Each group has 8 panels, defined through permutations of 4 profiles.
The set of copper panels used on HSEB, which became the first parameter for BPB.
Diagrams of the geometry created in Rhino, prior to exporting panel data to Excel and Dynamo
Normalized parameter information for the 12 profiles used to create the panels
An adaptive components family of one of the panels. The normalized parameter information made it possible to build only three of these — one for each panel type. Each unique panel was a different combination of values, which was then nested in a controller family that accepted numerical panel type input.
No geometry was exported from Rhino, only points and a randomized type string. Both had to be ordered to show up correctly in Revit, so two sorting tests were applied in Grasshopper: first to organize the corner points the same way for every panel, second to sort the panels left-to-right, or counter-clockwise, around the building.
The Dynamo script places each panel and assigns types based on the Grasshopper data exported to Excel. Panel types can be changed manually in Revit.
Only a minor adjustment is needed for an existing curtain panel tag family to read the panel type data and translate it to the type list used by the fabricator, allowing us to tag every panel at once.