Collaborative parametric design models allow you to work together for better solutions
Even though it is a hot topic, parametric design has been around for a while. Ever since programming exists, parametric models could be made. However, back then it required much skill of the individual doing this, both with programming and their specific profession (such as structural engineering or architecture). This made the threshold to start building parametric models very high and that is also why parametric modelling has only been achievable for a small group of people for a long time.
The major difference between now and then, is that building a parametric model has become way easier. This is mainly due to the rise of visual programming tools, such as Grasshopper or Dynamo. Instead of hard-core scripting, pre-coded building blocks can be linked to form logic that shapes a parametric model, or anything else for that matter. This type of “simple” programming is known of its’ steep learning curve and enables users to quickly reach a level, where one can actually use it for their work-related activities.
Additionally, another factor contributing to the democratization of parametric design is the fact that there is much more content available today. If you run into a problem, a quick Google-search will bring you to the right forum page, or even better, a YouTube tutorial explaining step-by-step what needs to be done.
Lastly, visual programming can be seen as a gateway programming language. Because similar as with conventional programming, you do need to break down the desired process into a series of computational steps where input is processed into the desired output. This ability is what we refer to as computational thinking. In visual programming the ability for computational thinking is trained, which makes the step towards the more abstract conventional programming much easier.
The development of a parametric model depends on several factors. Developing such a model costs time, which needs to be in balance with the projects’ budget as well. Generally, a parametric model grows during a project if it continues to add value. For example, in the beginning phase, one uses a parametric model to quickly investigate the impact, consequences, or characteristics of different designs. Based on that information, a well-informed decision can then be made. Only in case more details are required on a (or several) design(s), the model will be developed further to do so.
In some cases, this may instigate the start of an automation process in which the output is used for multiple projects instead of just one. In that case, the developments become process-based instead of project-based. This means that in every new project the same script is used and further developed, since for every new project, more resources are made available for additions or improvements. With large developments like this, it is more common to use conventional programming methods rather than visual programming methods since it is more suited to work on with multiple people, more memory-efficient, and easier to maintain overview.
I think the scale of the development determines whether one can call it automation or parametric design. To me, parametric design is more applicable to visual programming workflows and small-scale developments whereas automation, to me, refers to large scale developments for which more conventional programming languages are often used.
In a parametric model, often one or multiple software packages are linked in which the data is centralized. This means that one data source is responsible for providing all linked software packages with the needed input. In contrast to a traditional process where software packages are used individually, individual input data has now been defined. This can be laborious when changes occur in the project because the input data of every single software package that is used needs to be changed as well.
How centralised data in a parametric model is shared with different software often reminds me of the hub and spoke model in aviation. Centralised data is the hub, for example Schiphol that links to multiple small range city destinations, hence software packages. In the hub and spoke model, less flights (or less links) are needed compared to when creating a link between every destination (or every software package). This frees up resources and enables a more efficient throughput of people (or data).
My guess is that large scale developments, hence automation, will become much more prevalent within the construction industry. Currently, most projects start from scratch, so creating an automated process around a certain type of building or a certain type of structure will definitely result in a more efficient way of working with a constant flow of qualitative output.
For engineers, this will change their way of working. Their work will shift from them repeatedly designing similar things by hand towards constructing the logic that is needed to generate models that do this for repetitive work for them. Moreover, monitoring and validating existing automated processes will become a major part of their job as well, since engineers will stay responsible for the output they send to others. To be able to monitor and validate automated processes, some programming competence is needed to for example identify bugs and solve these. Therefore, I think that the engineer of the future will become much more data-oriented, simply because they have to.
There is quickly a lot of expertise involved in programming. There are many different things you must keep in mind: Stability, version compatibility, speed, and go on. Especially for lesser experienced programmers, this can quickly become a dilemma because there are only so many hours in a working day to spend on specializing in a certain field. This makes it nearly impossible to specialize in two fields and reach the same results compared to someone that is fully committed to specializing in only one field.
However, thanks to visual programming, the bar to entry is getting lower since it makes programming easier to grasp. Additionally, there is an increasing amount of software packages that do a lot of the work for you, enabling you to fully focus on the task at hand, which is finding a solution to the engineering problem instead of focussing on software engineering.
For my graduation, I deliberately chose a topic for which I could develop my visual programming and conventional programming skills, even though I did not have much experience with it. Programming was something I always wanted to learn but did not find the time for while following courses at the university.
During my graduation I built a script for steel trusses that integrated both the analyses of the main bearing structure and every structural connection into one workflow. To achieve this, I used a combination of the visual programming tool Grasshopper and conventional programming with C#, which I used to build my own Grasshopper components. I remember that when the first time the script did a full run analysing every connection, I was so amazed that I had actually managed to achieve this. It truly felt like magic.
Deliberately choosing to develop my programming skills has also been advantageous for my career. Having basic competence in programming is beneficial because it is going to increase the likeliness of getting programming related tasks at work assigned and this will then again increase your programming skills. The beauty of having programming competence beside your expertise, is both skills can really amplify each other. As an engineer it enables you to tackle more complex projects, which let you automate the boring repetitive stuff so you can focus on what really matters.
For me it even opened the possibility to continue my graduation work at Bouwen met Staal in the form of the SMARTconnection research project, which is the main reason why I am currently in the unique position of having two employers.
I would recommend companies to have all of their employees learn basic programming concepts. Something simple like basic principles comparable with an A1 level for languages, but then for programming. For everyone, including team managers and people from higher level layers. They donot need to be able to build scripts themselves, but I think companies can add great value if the decision makers can identify when [parametric design])(https://www.viktor.ai/blog/46/parametric-design-cloud-engineering-construction) or automation can bring more efficiency and added value to the project. With such an awareness throughout multiple company layers, we as an industry can add more value to projects, the core business of our organizations, and fully utilize the potential that this digital era brings!
See how you can build your own parametric design application now!
Or find out more about the many applications of collaborative parametric design in the Cloud with VIKTOR.