Thursday, June 01, 2017

Computational Architecture in a Production Workflow

Besides maybe writing about Japanese architecture, one of my favourite topics to write about is computational architecture because its study so directly applies to those serious about building a lot. Knowledge of parametric and computational design techniques are increasing within the AEC industry. However, the use of this technology to define the form of high-concept, high-design projects – while very dramatic – represents only a small portion of what actually gets built every year. There are a variety of reasons for this, none of which really need to be unpacked here, because the substance of this article is concerned with expanding the range of buildings that could conceivably be supported by parametric and computational architecture techniques. A much larger area of application is indeed on the production side; harnessing computational architecture to facilitate efficient production workflows to design and build as far as the eye can see.

The uses of the DynamoBIM visual programming interface within the production environment is pretty much unlimited, and different firms will have different pain points they might possibility want a tool like Dynamo to fix. A long list of Dynamo production tutorials representing a range of functions put together by The Revit Kid author Jeffrey A. Pinheiro illustrates this point. From a strategic and organizational perspective, in the design studio it's important to remember problems still exist within the spaces between tutorials, and problems exist between those spaces too, and so on. Therefore, what follows doesn't focus so much on coding specific scripts, but rather offers guidance on how to think about Dynamo when faced with a problem in REVIT, either design-wise or technical. Encouraging a perspective that comes directly from business school, the first and last measure to use when navigating this question is whether it's cost prohibitive or not to use Dynamo when the same thing could be accomplished in REVIT alone. But even this framing of the question doesn't capture its full complexity because some scripts will take a lot of effort to initially code but could offer substantial gains to subsequent projects. I love the complexity of this topic, which is exactly what a modern building project is, so we press forward:

Coding efforts that can be reused and have a reasonable chance of being brought to fruition on time and on budget are good candidates to consider when trying to expand an organization's application of computational architecture on the production side. Luckily, we've have a huge body of knowledge about how to do parts of this process from the software development industry. As a mature industry, they have lots to say about expertise in programming, and the factors which influence software development. However, the depth of this field also results in an extremely wide range of talent coming into the AEC industry. There is a huge range in programming skills. What would take me hundreds of nodes in Dynamo could be accomplished in a block of Python code by some members of the DynamoBIM forums. Is their code objectively better? Probably. But these scripts and programs need to make it back to the production environment, where their success is judged on a physical building, therefore, this specific knowledge in programming needs to be balanced with specific knowledge of building science and building design management.

I can imagine some uses of computation architectural in the conceptual stage for more conventional projects. Building performance analysis, for example, delivers lots of useful information to drive high-performance sustainable design efforts without necessarily aiming for the Pritzker prize. But really the use of Dynamo can start right at the very beginning of the production cycle to set up comprehensive REVIT project templates that are both more complex than previous and more accurate/consistent (because use of Dynamo can drastically lower the threshold for implementing quality assurance steps within the development process). Coming from a structural engineering background, I've seen some egregious carelessness in studios setting up grids. They always get coordinated and fixed before documents ever start going out, but what boggles the mind is how they crop up in the first place. Interfacing with Dynamo, precise control of the grid layout is increased, but the workflow to return helpful information to the design team about its accuracy is also reduced. This extends to any object in REVIT where coordination and precision is key. The example sits at the core of why Dynamo is so helpful: Complex operations can be done to the 3D model easier, but information can also be taken and structured from the model just as easily.

Establishing a library of reusable DynamoBIM scripts can eventually grow into a valuable knowledge management asset for an organization. However, sometimes these challenges in the design studio require one-off solutions to fix. One can take elements from the modelling environment and manipulate them in all sorts of complex ways using formulas that would be impossible to accomplish in REVIT alone. This feature can solve many problems if some skill is gained in coding and controlling lists in Dynamo. So if only a certain configuration of elements needs to be updated, computational architectural is the tool that allows these operations to be carried out on the digital model with greater accuracy and efficiency than ever before. Both the ability to reuse powerful scripts and having a computational architecture Swiss army knife to assist problem solving each combine to increase productivity in the production stage. ArchSmarter writer Michael Kilkelly has an excellent video up showing some advance MEP scheduling of >1000 pieces. If one has the power of MS Excel to shape schedules, these sorts of operations become trivial. It's so important in the production phase to be constantly harnessing the efficiency and accuracy gains offered by computational architecture. There is so much positive feedback to be gained in these sorts of systems as the team's skill at programming improves and library of quality scripts grows.

The market battleground where sharp computational architecture skills will be an advantage in the future is sustainable architecture. Building performance analysis is still very much a black art in the AEC industry. REVIT's out of the box optimization and analysis packages are wildly inaccurate but at the same time building performance analysis still has all sorts of valuable insights to offer the design process. Streamlining building performance analysis with DynamoBIM has all sorts of benefits, though the main obstacle to increasing accuracy remains outside the scope of Dynamo alone to fix, and will require more industry research and coordination. There is no easy to way navigate the helpfulness of Dynamo in the design process (and the risks of inaccurate analysis) except to encourage an intelligent case-by-case approach. Some types of solar modelling or structural optimization will be at low risk for these types of inaccuracies, energy modeling on the other hand, probably most useful for jurisdictional reasons, remains defendable territory for specialist firms.

One more variable sits at the heart of computational architecture which is only visible to control when adopting a collaborative design approach. There is a point in any computational architecture project where it might become more advantageous to reach outside the firm for expert help than struggle along oneself. If a design studio encounters a skills gap, do they try to jump it alone, or hire out? Lots of BIM consulting firms are starting to pop up to cater to the demand created by this skills gap. However, it's still up to the project manager to aim and direct this effort, and there is very little room for error with budgets and schedules so tight. Ultimately, adopting a multidisciplinary approach on every project softens the panic at having to integrate different specialities in the modern design studio. I wish to leave readers with the impression a computational architecture interface such as Dynamo or Grasshopper should be treated just like any other BIM input tool like a mouse or keyboard. This is what distinguishes a BIM manager from a digital design expert and BIM champion; the comfort one has using their tools.

No comments: