A Case for Computational Design: A Systems Perspective
The current pandemic has upended our social and physical systems, testing the limits of their resiliency. The Merriam-Webster dictionary defines resilience as "an ability to recover from or adjust easily to misfortune or change." However, when misfortune strikes, time is critical for an effective, resilient response. The faster a system responds to an external force, the lesser it will impact the system.
Systems Perspective
One could take a sledgehammer approach and throw all available resources to respond to the external force. However, the response itself will alter the system's shape. For a system to not entirely change its form, the fewer inputs (or resources) that the response requires, the more a system will remain closer to its original condition.
We must explore any opportunity to improve resilience within the civil engineering community. The implications of improved resilience within civil engineering are far-reaching, extending beyond profitability. Systems designed by the civil engineering community is the connective tissue of contemporary society. Computational design is a tool in our toolbox that we will explore here.
This article outlines steps for using a computational design tool: Dynamo, a visual programming application that interfaces with Autodesk Civil 3D (C3D). I intend to help readers imagine the possibilities of computational design within civil engineering. In the example outlined here, I will show how to perform a simple cross-slope analysis using C3D, Dynamo, and Microsoft Excel.
Imagine the steps and time it takes for you to analyze cross-slopes for several miles of a roadway. The task at hand is to produce a report to identify deficient cross-slopes along a highway. While in this example, we are connecting data from C3D to Excel. Imagine the possibilities with the Internet of Things (IoT). For instance, elevation data from GPS enabled stakes placed along the slopes of a cliff sends updates to the cloud to update the survey; subsequently, we execute the script. Anytime the slopes exceed a critical value, it could trigger an appropriate response. What is the common denominator in these examples? It is the promise, and potential, of reducing the response time to an external change. Thus, increasing system resilience.
The Problem – As an example, let us consider performing a cross-slope analysis on a two-lane roadway.
Data Inputs – The 3D topography of the existing ground, roadway centerline, and lanes edges (see Figure 1.0).
Figure 1.0
Data Output – The output contains coordinates (X, Y, and Z) and station values along the Centerline, Left, and Right Edge of Pavements (EOP).
Dynamo Process
First, let us delve into the Dynamo script that solves the above problem. Subsequently, we compare the Manual and Dynamo methods. For the comparison to be useful, we will use similar workflows in both cases. Hopefully, it showcases the potential benefits of computational design.
Dynamo is a visual programming application. Users can connect logical blocks of pre-programmed computer code, called nodes. Every node takes in an input and produces an output. The output from each node becomes the input for subsequent nodes.
From a data perspective, there are three necessary actions to perform a cross-slope analysis. We need to collect, process, and export the data. We analyze the data in Excel using formulas and data links. The three logical steps are necessary regardless of the Manual or Dynamo script methods. Figure 2.0 provides an overview of the nodes and logical steps within Dynamo.
Figure 2.0
Collecting Data - We collect data by connecting a series of nodes shown in Figure 3.0. Data collection steps begin with a node that loads the C3D document with the corridor requiring cross-slope analysis. It is essential to note you must have the C3D file open; subsequently, you open the Dynamo script. Currently, Dynamo can process only one file at a time. After loading the C3D file, the next node loads all the baselines.
Note the values in the code block of baselines to be extracted (see Figure 3.0). It consists of an array of three elements — "CL," "LL01" and, "RL01" — this array limits the baselines to the Centerline, Left, and Right EOP. Moreover, the order of the array elements is essential, as Dynamo maintains that order through the Data Processing and Data Export steps shown here.
While a node extracts the geometry of the points of the baselines with marked points "CL," "LL01," and"RL01", it does not contain station values. Hence, we need another node that collects the station values. Its output has an array with three lists of station values for Centerline, Left, and Right EOP. Important to note, both arrays within the data collection step contain lists in the order of "CL," "LL01," and "RL01"; hence, the first, second, and third elements in the array contain geometry and station values for the Centerline, Left and Right EOP.
Figure 3.0
Processing Data - Thus far, Dynamo has collected two arrays, each with three lists containing the geometry of points and corresponding station values. We need to split each element within these arrays into individual lists for Centerline, Left, and Right EOP.
Data processing (Figure 4.0) involves splitting the above arrays into separate lists, each for the baselines. Subsequently, we need to merge the list for geometry and station values into one list. Notice the code block a[0]; it instructs Dynamo to pick the array's first element. Remember the order of codes listed above: "CL," "LL01," and "RL01." Hence, the 0 in a[0] corresponds to the Centerline (Figure 4.0). The difference for Left and Right EOP is the code block a[1] and a[2], respectively.
Figure 4.0
Exporting Data - The final logical step is exporting data (Figure 5.0). The main inputs are lists containing the geometry and station values derived from the data processing steps above, Excel file name, and sheet name. The steps shown in Figure 5.0 are for the Centerline. They are replicated from the additional two baselines. The differences for the other baselines are providing appropriate file and sheet names.
Figure 5.0
Systems Comparison
There are many ways readers may accomplish the above task manually. Let us review two conceptually similar workflows for the Dynamo and Manual methods to facilitate a useful comparison.
I. Initial C3D setup
- Create or Data Reference existing ground surface
- Create and a two-lane assembly (see Figure 1)
- Add Marked points with codes "CL," "LL01," and "RL01" to the Centerline, Left and Right EOP, respectively (See Figure 1).
- Create a Centerline, Left and Right EOP alignments, and sample corresponding existing ground profiles (see Figure 1)
- Create a corridor using the above Centerline and target Left and Right EOP (see Figure 1)
- Create point groups, one each for the Centerline, Left, and Right EOP
- Using the "Create COGO Points from Corridor" command, choose the "CL," "LL01," and "RL01" codes to insert the points into their respective Point Groups
- Export each of the point groups into separate Excel files to a known location
II. Initial Excel setup
- Create an Excel file with four sheets. One for the summary and one each for the Centerline Left and Right EOP.
- Link the data to each of the COGO points exported file in their corresponding sheets using the "Get Data from file" command within Excel
- Setup the formulas in the summary sheet for distances and slopes for the Left and Right lanes
- You can use conditional formatting to highlight cells where cross-slopes are not between 0.5% and 2.0% (See Figure 6.0). You can use values that are critical to your case.
Figure 6.0
III. Report re-run to accommodate changes
- Delete all points within each of the point groups for Centerline, Left, and Right EOP
- Using the "Create COGO Points from Corridor" command, choose the "CL," "LL01," and "RL01" codes to insert the points into their respective Point Groups
- Similar to step I (8), export the point groups into three separate files, ensure to overwrite the files
- To update the summary, open Excel and refresh the data sources (See Figure 7.0)
Figure 7.0
Using Dynamo
- Initial C3D setup: Only steps I (1) through I (5) are necessary
- Initial Excel Setup: Same steps as the manual process
- Initial Dynamo step: logic and process outlined in the section above
- Run the Dynamo Script anytime to accommodate any change
- To update the summary, open Excel and refresh the data sources
Comparing the Manual and Dynamo processes, superficially, it appears that we save only three steps during the initial setup and three actions while re-running the report. However, when we examine actions I (6) through I (8), we notice three steps within each step. Similarly, steps III (1) through III (3) each require three steps, one each for the Centerline, Left, and Right EOP.
The comparison shows nine extra steps for initial setup and further nine steps to re-run the report. For every additional lane added to the system, the number of steps increases by three for both the initial setup and report re-runs. Finally, we must keep in mind that each extra manual step introduces the potential of human error.
Conclusion
Using a systems approach, we can classify the report as the output, the steps to accomplish the task as resources, and change in topography as an external impact on the system. A resilient system responds to the changes by consuming fewer resources without altering the form of the system. In the two methods outlined above, we examined the resources required to respond to an external change.
Dynamo is just one tool within the computational design toolset. It is a visual programming application. Like most visual programming applications, it has limitations in implementing loops and recursive logic structures. Hence, we should consider textual programming languages, in addition to a visual programming application like Dynamo.
Computational Design is vital to develop resilient systems and should become part of our toolbox. Comparing a simple system above shows us the importance of adding a computational design to our toolbox. It dramatically minimizes the steps required to respond to an external force. The difference gets even more exaggerated when the complexity of the system increases.
It would be a pleasure to discuss your experiences or questions regarding computational design within engineering with anyone. Do not hesitate to contact me anytime.
Anand Stephen, PE, CME is a Civil Engineer who has designed infrastructure projects across the US. He has over two decades of experience spanning engineering, software development, and sociology. He has led digital delivery and digital change in several AEC firms. Anand mentors and teaches engineers to use 3D design technologies. He has experience designing and programming enterprise software systems. Besides, he has taught courses at the university. For any comments or questions, you can contact Anand at astephen@gfnet.com.
