Computational Design for Civil Engineers

Dynamo and Computational Design

Dynamo is a platform enabling designers to explore visual programming, solve problems, and create custom tools.

Visual programming is the process of establishing rules that can describe the relationships among the parts of a design. The rules and the relationships are formalized into an algorithm.

An algorithm is a set of instructions to follow to perform a task. The instructions can be textual in plain English, Italian or French, etc., or can be expressed in a graphical way, for example using languages such as UML or BPMN.

For a computer to be able to understand these instructions there is the need to adopt an intermediate language that is human readable but that a computer can also understand. There are several possible traditional scripting languages such as C#, Python, JavaScript.

Dynamo is a platform that can define algorithms visually and the sequence of instructions are generated using blocks called Nodes that perform predefined tasks, joined together in sequence using Connectors. A Dynamo algorithm is called a Graph to emphasize the visual programming approach which is one of the main differences between Dynamo and any other scripting language.

Dynamo is some sort of a digital Swiss-knife that can contain just right blade for the job and even if it is very intuitive in the way it can be used, it is also very effective. Another important characteristic of Dynamo is that, for whatever reason, if a blade should be missing it supports several ways to either add one from a public repository of external packages or create more sophisticated functionalities using traditional scripting languages such as Python or C#.

Dynamo commoditizes programming and brings it closer to the designers, taking care of the sophisticated operations such as handling databases and transactions, serializing changes, and updating the models rather than performing a “fire-and-forget” automation. Dynamo is in the sweet spot in between interactive tools such as Civil 3D or Revit and more traditional scripting languages to leverage product APIs.

Dynamo can be found as a standalone application called Sandbox but also integrated with a host application such as Revit or Civil 3D. For more information about Dynamo integrations and where to get it visit https://dynamobim.org/download/. 

For more mature Dynamo integrations with host applications such as Revit, Dynamo comes with an optional simplified interface called Dynamo Player that allows you to select a graph from a list, provide the necessary user inputs via a dynamic interface, and run the execution of the graph. Dynamo Player can turn the Dynamo graphs into something that resembles in many ways custom add-ons for the host application with the advantage that they can be developed without requiring a deep understanding of the host application API.

Why Use Dynamo

Dynamo allows the designers to do more and control complex modeling that would be otherwise impossible or extremely difficult or time consuming to do manually with out-of-the-box functionalities of the host application.

Dynamo can provide a way to achieve a higher level of model data consistency to ensure better quality across multiple projects and teams without relying on the skills of the individuals, capturing best practices and scaling them throughout the business with automation.

Dynamo allows automation of repetitive tasks, reducing the effort required to achieve the same outcome and allowing designers to focus of the part of their jobs that require critical thinking.

Dynamo is particularly versatile and allows designers with no coding background to prototype solutions to solve immediate problems and express their needs in a language that is easy to comprehend by a professional developer. A developer has the possibility to focus on ample development and implementations without risking of becoming a bottleneck for other departments. If necessary, the experienced developer can extend the nodes in Dynamo and even overwrite or add new behaviors to the application to suit Company needs and project requirements. As a plus, Dynamo provides out-of-the-box features such as reading and writing Excel spreadsheets or implementing a Create-Read-Update-Delete paradigm. Dynamo also reduces the need for updating the code when a new API is released as the visual programming approach is almost immune to deprecation cycles.

A Dynamo file is structured as a JSON file, an organized collection of data that is used by the Dynamo application to implement a logic interpreting on the fly what is in this text. This implies that a Dynamo file cannot be “complied” like a plug-in written in C# or locked down for preventing someone from fiddling with the logic of the nodes, at the end of the day it is just a text file that anyone can open with a text editor.

CivilConnection and CivilPython

CivilConnection is the name of the Dynamo custom package for Dynamo for Revit that enables the Civil 3D - Dynamo - Revit technology stack for Autodesk Consulting engagements that have been known as "Linear Structures.” It enables the usage of a linear reference system defined in an open Civil 3D document (e.g., a corridor, alignment, feature line, etc.) to create and/or update elements in a Revit document. It also enables you to import and update the elements from a Revit document into a Civil 3D document.

Automation is not something new in the infrastructure space. There have been several attempts in the past, recurring to plug-ins based on a constrained form to execute very specific tasks. Although they do not require the user to understand the automation steps, these plug-ins could not be flexible enough to accommodate all the project requirements and needs. On top of that, some plug-ins were retired and left a technology gap to be addressed. After considering all these factors, a custom tool was developed directly by the designers for the designers is still the best solution.

CivilConnection eases the definition of prototypes with a toolkit philosophy: it contains a range of functionalities generic enough to cover most use cases that can be combined to solve very specific project challenges. And all this using a visual programming approach rather than traditional scripting languages.

CivilConnection is mostly based on a technology called Component Object Model or COM. Over the years Civil 3D and in general most Autodesk products introduced a more efficient API based on .NET.

The intention behind CivilPython was to enable the same kind of prototyping approach that was available for Dynamo users in Revit, using the Python syntax to leverage the .NET Revit API. CivilPython is a custom command that enables to select and execute Python scripts in AutoCAD and Civil 3D. It also has a command line version of the command that can be launched from CivilConnection through COM. That was it, now CivilPython also contains some commands that are necessary for CivilConnection to access data using .NET rather than COM.

CivilConnection and CivilPython are open source and can be found at this link along with examples and documentation https://github.com/Autodesk/civilconnection Design Automation Traditionally designers apply their intuition to define a design of a building or a bridge. The design intent is captured in detailed drawings and the relationships of the parts of the design, their qualities and quantities are explicated using dimensions, text notes, etc. We can call this kind of process “static design.”

With dedicated modelling software and intelligent parametric objects, the design process changed radically. Designers can now explore more options more quickly; the software takes care of updating a complex system of relationships between parts in three dimensions thanks to the parameters expressed either analytically (e.g., changing a “thickness” in a subassembly) or graphically (e.g., overriding the “width” or “elevation” parameters in a subassembly using targets). For example, in Civil 3D the designer defines the following inputs: the alignment and vertical profile, the baseline regions and assigns an assembly, specifies the sampling frequency and specifies the targets. Then the software takes care of generating all the corridor sub-elements (e.g. feature lines, surfaces, solids) and updating them dynamically if any of the user inputs changes.

The next step in the evolution of design is the possibility to introduce algorithms, a set of instructions, a system of rules that allows to generate the objects and that can produce predictable results. This approach enhances the ability of the designers to introduce new dynamic relationships in the software, relationships that the software was not originally designed for. A very simple application in Civil 3D is the creation of discrete elements along a corridor (e.g., concrete ties along a rail track), so that the location and orientation of the discrete objects is connected to the feature lines in the corridor.

Computational design needs an intermediate environment between the designer and the software to prototype and assemble these new relationships. It also needs an intermediate language between the design and the software to translate the rules of the design intent into instructions for the software. The intermediate environment could be a VBA macro editor, a Visual Lisp editor, MS Visual Studio, etc., to leverage some sort of traditional scripting to define the sequence of instructions.

Dynamo is an intermediate environment that allows the designers to leverage both visual programming and traditional scripting via Python and explore a computational design approach in their daily jobs.

The best advice I can give to someone that is starting to approach computational design, regardless the level of expertise in coding, is to plan the automation. Defining all the steps in the algorithm, identifying the inputs and their suppliers, defining a process to consume the inputs and create suitable output that can be consumed later for other BIM uses.

A very intuitive tool that allows you to draft any algorithm in a visual way is called Business Process Modeling Notation, or BPMN. This approach allows you to abstract and analyze the problem at hand and subdivide it into smaller problems that can be solved at a later stage, but without losing focus on the overall objective.

This allows you to identify opportunities for the automation to improve efficiency with less effort. For example, a process can be greatly simplified (e.g. reducing number of steps, reducing number of decisions to handle, etc.) if the inputs are provided in a slightly different way from the usual, something that the input supplier can do with little effort (e.g. adopting a naming convention for Point Codes in subassemblies) but that can bring great benefits when it comes to acquire, interpret, and process the data.

BPMN can also be used to “debug” existing processes or algorithms (regardless if they were developed using traditional scripting or visual programming). There is a free web-based tool called BPMN.IO that was used to create the diagrams in this document. It is highly recommendable to introduce something similar in any design process to capture ideas, plan the development and frame a problem to formulate a very precise question when asking for help.

A live webinar on design automation was presented in June 2019 on Dynamo for Civil 3D for the first time after the Civil 3D 2020 global launch in April of the same year. In the webinar were presented examples of how to use automation for civil workflows rail, road, and site development. Check out the webinar recording. The presentation and the data set used in the examples presented in the webinar can be found in this post on the Civil 3D section of the Dynamo Forum.

Dynamo for Civil 3D

In Civil 3D 2020 it is possible to find an integration with Dynamo. Initially Dynamo for Civil 3D was available as a separate install accessible from the manage.autodesk.com under the addons for Civil 3D 2020. With Civil 3D 2020.1, Dynamo comes directly with the product.

It is possible to access Dynamo for Civil 3D when the workspace is set to Civil 3D, from the Mange tab under the Visual Programming panel on the ribbon. There are currently two icons, one that launches the Dynamo application interface, the other that launches a headless Dynamo session that runs a script.

Alternatively, Dynamo can be launched at the command line typing the AECCLAUNCHDYNAMO command.

Dynamo for Civil 3D comes with a set of example use cases to show how to apply computational design to enhance transportation workflows with automation. There are two components to consider: the AutoCAD objects and the Civil 3D objects. In these first releases of Dynamo for Civil 3D, the nodes available are mainly focused around enabling transportation model authoring workflows dealing with Alignments and Corridors. In the future we can expect to find more objects accessible via Dynamo and to implement functionalities that can enable other civil disciplines and BIM uses (e.g., drawing production, visualization).

Dynamo can read the data in a DWG file and for objects it can return proxies, or “wrappers” that represent a node in the Dynamo library. Dynamo can also write back to the DWG a given set of objects (e.g. Line, Polyline, Circle, Text, Block Reference, etc.) and in doing so it keeps track of which objects have been created through Dynamo.

AutoCAD and Civil 3D Nodes

The aim of this section is not to list the nodes currently present in Dynamo for Civil 3D--that would be rather pointless as they can change quite a lot in between versions. It is more important to understand how the nodes are organized in the Dynamo library, what are the relationships between object types, and what are the current limitations.

Dynamo Bindings

When the Dynamo application is visible and the graph creates objects in the DWG, the trace of the Dynamo owned objects can be serialized in the Dynamo file itself. This mechanism is called “Binding”: for each node that creates objects from Dynamo into the DWG, Dynamo stores their “fingerprints” in the Bindings section of the Dynamo JSON structure, so that if the inputs change, Dynamo can confidently update only the objects that are owned by the graph accordingly. The user needs to save the file after the execution for Dynamo to be able to store the trace data into the Bindings section.

If there are no valid Bindings in the Dynamo graph (e.g., the Bindings were removed from the JSON file, or someone manually deleted the objects that were generated by Dynamo, or the Dynamo graph was previously used on a different DWG file), after the execution new objects are created rather than update existing ones, and the bindings relationships in the JSON file are overridden as soon as the user saves the Dynamo file.

By design, Dynamo for Civil 3D connects with one DWG document at a time and interacts only with that document for the entire session. This is a limitation that mimics the same implementation that we find in Dynamo for Revit. This is in part due to how Bindings in Dynamo work: you can have a dynamic behavior only if you make sure you have a 1:1 relationship between a Civil 3D model and a Dynamo file.

When using the Run Script option, the Dynamo interface is not visible which means that after the execution, the user cannot save the graph. This implies that the Bindings section of the JSON file is wiped out after the execution and the Dynamo graph is more of a “fire-and-forget” rather than dynamically updating existing objects. We find a similar behavior (no bindings) if objects are created through a Python Script rather than using Dynamo nodes. Because of this, it is recommended to define a naming convention for your Dynamo graphs that shows the relationship between the graph and a Civil 3D model.

Dynamo Standards

As soon as Dynamo allowed the creation of node groups and colors in 2015 (0.8.1) I developed a standard to unify the look and feel of Dynamo graphs. The standard is based on a very simple fact: every automation on a model, regardless of the language used, is a sequence of functional tasks. I’ve associated a color in the palette in Dynamo, from left to right like reading a book, for these sequences of logical functions.

Adopting a standard improves readability and supports adoption of the Dynamo graphs within a company. Also leaving exhaustive commentary around the logic is an added value and best practice that should always be applied in any development.

For node groups though, it is better to be very concise and assign a short sentence to express the task, something like Verb + Noun, something that forces the developer to convey a high-level idea of what the collection of nodes in the group is supposed to do. That is why it is recommendable to plan the development using, for example, a BPMN diagram to use as a draft for renaming the node group in Dynamo.

Automated Workflows in Dynamo

At a very high level, a Dynamo graph can enable some form of the following workflows.

Extract Data from the Model

The automation reads the model objects data programmatically and then sends it to another application for consumption. To enable this workflow the automation should provide functionalities to:

• Select objects, either directly or based on a property or classifier (e.g. select all the lines in a model)
• Get properties, every objects in a host application is more than just an abstract piece of geometry and contains information such as handles/ids, type, and other kind of metadata associated (e.g. the length of a line, the color, the name of the layer etc.), the data needs to be extracted and interpreted (e.g. it is a piece of text, a number or another object, etc.)
• Write the values to an external storage, this can take any form and requires managing the creation of data streams and serialization towards different formats (e.g. text, CSV, XLSX, XML, JSON, image formats, etc.) An example of this workflow could be extracting the elevation of feature lines at given station intervals and write the resulting information to a custom report in Excel.

Modify Existing Objects with External Data

The automation reads the external data, accesses the model objects properties, updates the values, and saves the changes to the database (e.g. the location of Cogo Points, the starting station of an alignment, etc.). To enable this workflow the automation should provide functionalities to:

• Select objects, either directly or based on a property or classifier (e.g. select all the lines in a model)
• Read an external source or input, for example a numeric value specified by the user or the location of the external source (e.g. server, cloud-based repository, etc.); the automation should be able to interpret the data contained in the source/input and return the values in the automation environment for further processing.
• Modify objects. The automation should be able to open a transaction with the host application, find the properties that needs to be modified as the user intended (metadata and non) assign the new value, and commit the changes to the model database.

An example of this workflow could be reading the property set values from an Excel spreadsheet and update the values on the correspondent objects in the model.

Create or Update Objects

The automation receives some inputs, processes the data following the computational rules, and creates objects in the host application model. If the inputs change, executing the automation one more time updates the definition of the elements previously created they are new or update their definition if there are any existing objects connected to a previous execution of the automation. To enable this workflow the automation should provide functionalities to:

• Acquire user inputs, either directly or from an external source.
• Process data define the logical steps to transform the inputs into abstract Dynamo geometry items that can be used to drive the creation of model objects.
• Create/update model objects, a set of functionalities that can transform a Dynamo abstract object into a concrete model object for the host application. An example of this workflow could be creating bollards along the side of a road.

Computational Design for Civil Workflows

The webinar referenced above briefly discussed some use cases to demonstrate design automation applications of Dynamo for Civil 3D in three different areas: Rail, Roads, and Site Development. The scope in this article is to provide some context and highlight the logic behind the graphs that were used during the webinar and point out the Dynamo for Civil 3D functionalities used to obtain the results. The approach used in this document explains the goal and the logic used to reach it, the object types involved and how to find the relationships that keep the logic together using Dynamo nodes.

Rail

With Civil 3D 2020 there are many improvements to support rail workflows. A complete list of these improvements can be found on the Civil 3D online help under the Release Notes. When it comes to automation it is always useful to identify the components of the tasks in relation to their outcomes such as Do More, Do it Better, or Do it with Less Effort.

Civil 3D already provides a set of tools to deal with the modeling and management of the linear elements such as the actual rails, so what can an automation do to improve the modelling workflow? The use cases presented below cover different aspects, from detailed modelling to usage of external data source through visual programming, taking advantage of Dynamo for Civil 3D functionalities.

Concrete Ties

The key learnings for this example are:

• How to get a Corridor Feature Line from the document
• How to get a Coordinate System on a Corridor Feature Line
• How to create a range of stations
• How to create Block References

A concrete tie or sleeper is a typical example of discrete element that participates to the detailed modeling of a rail track that is hard to position and maintain in Civil 3D. In AutoCAD terms, a concrete tie is a Block Reference, something that could come for Revit or Inventor, then exported to DWG. It is important to know the local origin and insertion point for Block Reference and its name before using it in the automation.

The concrete ties follow the Center Line of the tracks of the rail corridor, the Block References are placed at regular intervals of 2’ (ca 0.6m), orthogonally to the Alignment. At a high level it is relatively easy to think about what is needed to place a Block Reference: the name, the layer, the location in X, Y and Z (where Z is the elevation of a linear reference such as the Baseline or a rail Feature line) and the rotation around the vertical axis. To place a Block Reference there is need for some more data, but it is safe to assume that these are default values for now (e.g. the scaling factors, and of course, the target block where we need the Block Reference to be created, in other words, the Model Space of the document).

This is an effective technique when it comes to automation: starting with the end in mind and building the automation going “upstream” so to speak. The next step then is to understand what the inputs are to provide to the function that creates the Block Reference and so on.

Let’s focus on the location: the request is to tessellate the linear reference (e.g. the Baseline) at regular intervals. The intervals may or may not coincide with the sampling intervals defined in the Corridor parameters. This is already powerful: it is possible to consider a Corridor and its Baselines and query some stations that may not be in the definition of the Corridor on the fly, without the need to rebuild the Corridor!

Now it’s time to look at the rotation of the concrete ties: the ask is to make these elements orthogonal to the Alignment. The default orientation of the Block Reference is known (e.g. parallel to the global X axis), so the ask is to calculate the rotation necessary to have the Block Reference orthogonal to the Alignment at a given station. In Dynamo, to calculate angles there is need to operate with Vectors. On DynamoPrimer.com there are very useful notions of trigonometry that every Dynamo user should be familiar with and the assumption here is that the reader understands how this is done.

In the 2020.1 release of Dynamo, the Block Reference creation has been simplified greatly with the introduction of a node that takes as an input a Coordinate System--learn more. This object conveys at once the information of the location and orientation and saves us a lot of trouble trying to calculate the rotation for each concrete tie.

In geometrical terms, the ask is to calculate a Point that is sitting on the Baseline or a Feature Line curve at a given station (the station is measure along the Alignment used to create the corridor) and the direction of the curve in that point. There is a Dynamo node that does exactly that.

Traversing the data in the Document it is possible to recall the Corridor and the Baseline by their names and after select the Corridor Feature Line by the Point Code assigned in the subassembly definition.

This is the logic used to place a single Block Reference, what about the others though? This is done via a “loop,” something that tells Dynamo how many times to repeat a set of instructions providing the correct inputs at the beginning of each repetition.

Loops in Dynamo are handled through a couple of paradigms called lacing strategy and replication guides. For a detailed explanation of how this works refer to the Wiki pages on the Dynamo GitHub, starting here.

In a nutshell: each input port on a node has a default “rank” of input (a single input, a list of inputs, a list of lists of inputs, etc.). If the input provided has a rank higher than the default, this will trigger a loop and the function defined by the node will be repeated several times. At each repetition the function will traverse the list of inputs. To determine exactly how this is done, for how many times, and how the output is structured, the user can specify the lacing strategy on the node via right click and/or using the chevrons next to the input ports of the node.

So now the question is how to specify a list of stations to calculate multiple Coordinate Systems on a Feature Line. To do that there is need for a range, Dynamo provides a node and several Code Block syntaxes to generate range of number, in this case a range of stations on a Feature Line. (Note: These are not the stations used to sample the Feature Line in the Corridor.)

Putting it all together returns an automation that in very few nodes can place discrete Block References along a Corridor and dynamically update the model to react to design changes (e.g. the alignment, the vertical profile, the block definition, the spacing of the block references, etc.). This allows you to do more with Civil 3D, create better models, and update the models if something changes with less effort.

Paolo Emilio Serra is a construction engineer by trade. He worked as BIM manager in an architectural firm for 5 years in Milan, Italy. Since 2014 he works as an Implementation Consultant BIM for Autodesk. With Autodesk he has been delivering Customer Success Services to engineering Companies, supporting BIM workflows and Digital Transformation in their business processes. Paolo’s main focuses are on automation, generative design, integration between AEC and ENI industries. Paolo is an architecture enthusiast and a Revit user since 2006. He started to discover the possibilities of automation and customization with the Autodesk product APIs and Dynamo. He developed the CivilConnection Dynamo package that creates dynamic relationships between Civil 3D and Revit for Linear Structures BIM workflows. He also provided support to the product team in Autodesk to introduce Dynamo for Civil 3D. He owns the blog Punto Revit.

Safi Hage is a structural engineer by trade. Since 2014 he is a designated support specialist at Autodesk working with enterprise priority customers worldwide focused on the AEC industry. Before joining the Premium Support Organization, he was an Autodesk Technical Consultant BIM for 6 years.

Want more? Download the full class handout to read on.