A simple Dynamo definition created according to the Dynamo Standard
White arkitekter AB is the largest Scandinavian architectural practice, comprising over 800 architects, engineers, and design professionals, with 16 offices in Sweden, Denmark, Norway and UK. Our commissions range from strategic urban plans to interior design. The internal team Digital Design and BIM is responsible for developing standards and workflows for full BIM integration, and the Dsearch Innovation Environment specifically targets design computation in project implementation as part of the White Research Lab – the internal research & development network. Our company strives towards new technologies, tools and workflows which can make our work better and more efficient.
We have been following the development of Dynamo for a while now. We have tested it inside our research and development environments and implemented it in a number of projects around our offices. As a part of our Dynamo implementation, we have created a customized method, which we refer to as the “Dynamo Standard”. The Dynamo Standard is a simple scheme that guides designers on how to organize their Dynamo definitions. With the creation of this standard we try to emphasize the ease of use and reuse of the Dynamo definitions, as well as their application by users with varying levels of visual programming skills. The Dynamo Standard follows our already well-established standard for the Grasshopper platform, based on the experience gained from project implementations completed by Dsearch Innovation Environment. A clear-cut correspondence between the design workflows within these two visual programming environments is very important for us in terms of establishing a more general approach to the organization of visual scripts – regardless of the platform, the application or their purpose.
Dynamo has proved to be a very useful tool in wide range of tasks, from managing Revit parameters through automating Revit functions up to Revit family creation. At the moment, users of Dynamo at White arkitekter AB can be divided into “Developers” of scripts, mostly including Revit model managers and “Users” who can be anyone from architects to model managers unfamiliar with visual programming. As a part of raising the awareness for the tool, we encourage “Users” to see what is under the hood in the Dynamo definitions that were created for them.
Top level division between the Template and the functional part of Dynamo Definition
The division between the generally-accessible User Interface and the restricted-access Back-end part
The Dynamo Standard in itself consists of a guiding document and the Dynamo Template, packaged inside a custom node. This node can be opened in parallel with the current Dynamo workspace, allowing the template to be easily copied between workspaces.
The guiding document describes how to start a new dynamo script, how to connect to the internal and packages, and how to visually organize and annotate the Dynamo definition, so that it is easy to read, reusable and open for further development and changes. Custom node libraries and standard packages are located on our servers and linked to Dynamo via Manage Node Paths. For standard packages, we currently consider Lunchbox, Steam Nodes, Archi-lab and Clockwork.
The Dynamo Template is a part of every Dynamo definition. It guides the workflows of the designer as the Dynamo definition is being created.
The organization of the Dynamo definition itself can be divided into several levels. At the top level, the definition is divided into into 2 parts – the Graphic Standard Template and the Functional part of the Dynamo Definition.
Graphic Standard Template
Color-coding of the Dynamo definition
The Graphic Standard Template is a set of groups and nodes which help to organize the definition. It is located at the top part of the definition and serves as a guide for grouping, color-coding and annotating the definition. It contains project information, author name, Dynamo version and a list of included Dynamo packages.
The actual functional part of the Dynamo definition is divided into 2 parts: the User Interface (UI) and the Back-End. This division allows the definition to be distributed between users with varying visual programming skills. Users with very basic skills can interact with the UI interface part, without having to worry about breaking the back-end function of the definition. This interaction is emphasized by color-coding the node groups. The groups with bright colors are open to interact with while the Back-End grey colored groups are not.
All inputs and controls are gathered in the User Interface on the left side of the script. The Input groups typically contains geometry and other constraints (most commonly from Revit). The Control groups collect modifiers, sliders and numeric value controls. The Input groups are colored purple and the control groups are green.
The Back-End (or “Design”) part of the definition consists of all functional “blocks” of nodes, designated in grey. The entire functional part of the definition is encoded here. Grey color indicates that this part is to be used only by advanced users. However, the Back-End is not packed into one custom node and hidden from other users. We believe that this exposure attracts attention and motivates the users to examine the definition more deeply. This offers an opportunity for users to contribute to the internal “quality control” for the definition and an easier and faster way to localize possible bugs.
There is one more colorful set of groups that can be located either in the User Interface section or in the Back-End section. These include “To Revit”, “Annotation” and “Monitor”. They contain nodes which link the definition to Revit, contain additional annotation and permanent “watch” nodes for data supervision.
Within our Graphic Standard we suggest that the Dynamo definition is modularized to flexibility and ease of reuse. This modularization is created by organizing the definition into functional blocks, where each block has its own input and output, and belongs to a color-coded group. Input and Output are created by empty data container nodes that pass data without change. The data containers are named according to the data they carry. At the moment, the data containers are custom nodes with one internal code block [out=in]. It is possible to use “identity” node instead of the code block. This redundancy makes it easier to modify, insert or reorganize the Dynamo definition.
Modularization of the definition into functional blocks
Input-output containers of functional blocks
The Graphic standard for Grasshopper follows similar layout. On the left is an extended version of the Project info with a semi-automated definition and project log.
The Graphic Standard for Grasshopper on which the Dynamo Standard is based, has been established in Dsearch Innovation Environment for several years. It has the same division between the Template with color-coding, User Interface (UI) and Back-end definition as the described Dynamo Standard. Color groups are the same with exception of Bake, which is replaced by “To Revit” and Visibility that is omitted in the Dynamo Standard. The Project info panel has an extended functionality with semi-automatic log that allows registration of definition changes, used plug-ins and versions into a central Dsearch document. Similar functionality may be added to the Dynamo Standard in future development.
By creating our own standards for visual programming, we wish to encourage a wider use of this tools within the office, regardless of the level of experience. Additionally, we strive to enhance the exchange of the definitions throughout the office and to provide for effective quality assurance that matches our general office standards. We are continuously developing our methodology and standards to accommodate the changes in our different toolsets, including Dynamo, in order to boost the overall quality and efficiency of our everyday design work.
Specialist, Dsearch, White Research Lab
White arkitekter AB
Vladimir Ondejcik is an architect and a specialist in design computation in the Dsearch team at White arkitekter AB. He is responsible for Dynamo and its implementation into the office, and also works as a model manager for large hospital projects. Since graduating Cum Laude in Non-Standard and Interactive Architecture at the Hyperbody group of Delft University of Technology, he has previously also worked as an architect for C.F Moller.