Computational designers are architect/engineers who can program. They have domain expertise while possessing the computer skills to develop new workflows to support efficient project delivery.

15 mins read
Written by Kian Wee Chen
Published on Feb 19th 2025
Updated on Feb 20th 2025

Current Practice

Computational designers develop workflows from the early design stages all the way to the construction stages. For example, these workflows can include 3D scanning the existing site, building performance simulations in the design stages and digital fabrications in the construction stages. There are even potentials for computational designers to extend beyond the construction stages and develop workflows for building operations with the growing market for smart buildings.

Currently, computational designers predominantly develop workflows based on a few major proprietary software. However, this prevent open sharing of these workflows. For example, I have developed and openly shared an optimization routine in a proprietary CAD system called CADx. If designers who use CADy for their projects are interested in using the process, they need to buy CADx, import the CADy file into CADx, learn a new software suite and run the workflow. This is the case only if the two software interoperate. If not, you either have to remodel all your models again in CADx or use interoperability platform like (e.g. Speckle or COMPAS) to convert the data into CADx. These platforms use software-specific APIs to convert data between commonly use proprietary software packages. You can then modify and improve on the workflow and contribute back to the source. As a result many of the openly shared workflows are not truly open.

What are Open Workflows and Why Develop Open Workflows?

Open workflows will significantly reduce the cost of technology adoption in practice and especially in places that cannot afford these technologies. They are coincidentally located in the regions where rapid urbanization are taking place (e.g. Southeast Asia …). An open workflow at minimum uses open standards, and whenever possible prioritize the use of Free and Open Source Software (FOSS) and Free and Open Source Hardware (FOSH)). This will allow the workflow to be shared and readily extended to include new technologies as they emerge.

Open workflows allow other computational designers to readily improve and build upon it. As new improvements are made to the open workflow, the designer, industry and society stands to gain:

• Designers:
  1. Designer can reuse the improved open workflow for their own project.
  2. Workflow will always be usable regardless of access to software. This means the open workflow will truly belong to the designer.
  3. This will likely create more job opportunities for computational designers as smaller practices will be able to adopt these open workflows and readily integrate the it into their current practice without the need to buy expensive licenses. Currently, computational designers positions are limited to mainly bigger size companies.
• Industry:
  1. Solo Practitioners & Small Studios (1-5 people)– Focused on bespoke, highly customized computational workflows, but constrained by software costs and limited resources. Open workflows reduce financial barriers and foster collaboration.
  2. Medium-Sized Firms (5-50 people) – Computational designers streamline efficiency across projects, but interoperability and knowledge retention are key challenges. Open workflows enable scalability and standardization.
  3. Large Multidisciplinary Firms (50+ people)– Often have dedicated R&D teams developing internal digital tools. Open workflows ensure future-proofing, interoperability, and cross-discipline collaboration.
  4. Research & Academia– Experimental workflows push the boundaries of computational design, but open workflows are crucial for accessibility, reproducibility, and bridging industry-academia gaps.
• Society:
  1. Society progresses as we improve the way we design our built environment. This is only possible with the use of open-source technologies where everyone can contribute and modify the workflow to suit their own needs.

How to Develop Open Workflows

The question remains ‘Is it possible to develop open workflows using open standards, open-source software and open-source hardware?’ The answer to this question is YES! In my opinion, the Architecture, Engineering, Construction and Operation (AECO) open-source software ecosystem has matured to a point where it is sufficiently reliable and manageable to develop open workflows upon it. Drawing from my own experience, I am working on developing a workflow for the design of radiant ceiling panels. The target users are Heating Ventilation and Air-Conditioning (HVAC) engineers who would like to improve their design workflow from using static calculations to using Building Information Modeling (BIM) with Building Energy Model (BEM) to size the system. The workflow is not for a specific project, but to be implemented throughout a practice. Thus I have time for research and development. I decided to take this chance to show the potential of the current AECO open-source software ecosystem.

After some initial investigation, I was able to identify the open standards and open-source software required for the development. The two open standards used are Industry Foundation Class (IFC) and OpenStudio Model (OSMod). The open-source software used are FreeCAD for authoring/modifying IFC and OpenStudio SDK and OpenStudio Application for executing OSMod for building energy simulation. There are currently no reliable tool to do the conversion from IFC to OSMod. OpenStudio Application has an IFC import function through the BIMServer. It requires users to export IFC from FreeCAD, set up a running BIMServer, input the IFC to the BIMServer, and eventually import it using the OpenStudio Application. There are too many steps involve and most importantly the import function is not actively maintained. As a result, I decided to write my own command line conversion tool, ifc2osmod, using two Python libraries, ifcopenshell and OpenStudio SDK. For the conversion to work well, users will have to learn to model the IFC for the conversion. It requires the IFC model to be constructed in specific ways such as having a defined IFC Spatial Thermal Zone and custom IFC properties that specify the envelope construction. With this setup, I am able to setup a generic IFC to OSMod workflow.

Using the openly published generic workflow as basis, I then proceed to customized it for the specific task, which is to run simulations to support the design of radiant ceiling panels in a HVAC project. This requires me to identify the right configuration using OpenStudio’s Measure mechanism. Collect the correct data about the specific radiant panels that the practice uses to accurately reflect the performance. These practice-specific configurations and data will not be public. This allows the practice to maintain their competitive edge, protect their trade secret while reducing expensive software operation cost. At the same time, this open workflow will allow the computational designer to contribute back to the open-source community and reuse the open generic workflow wherever they are in the future.

As open standards are used in the workflow, it also allows other computational designers to readily swap out the open-source software for other software (open-source/proprietary) as long as it can export IFC and can import OSMod. For example, a practice can readily swap out FreeCAD for Revit, as long as you configure Revit to export the IFC correctly. Even if the IFC is not properly exported by Revit, users can still modify the Revit-exported IFC in FreeCAD to effectively use the workflow.

Why not use open-source interoperability platform for the workflows

Some might ask ‘why not use an open-source interoperability platform like Speckle or Compas?’, ‘why use IFC as the exchange format?’. Although IFC is notoriously difficult to work with, it is still the most complete and most used standards around. In addition, it has become more manageable to work with using ifcopenshell. Open-source interoperability platforms are great, however Speckle and Compas both do not have connections for FreeCAD and OpenStudio Application. I did some initial research on the platforms but have not used it for any projects. I would consider developing/integrating my ifc2osmod converter into the platform in the future, but I do not have time to learn and decide which platform to develop for now. Speckle targets the general AEC users, connecting mainstream proprietary software like Revit, Rhinceros3D, SketchUp and AutoCAD etc. Compas caters towards structural and robotics users, it provides connections between a mixed of software and file schema like Rhinoceros3D, Abaqus, IFC and OBJ.

Interoperability platforms have an important role when your open workflow needs to interface with proprietary software, which I feel will be a majority of cases considering most big companies have existing workflows based on proprietary software. My case is more likely to happen in smaller practices or companies that are willing to test out a completely new workflow. These interoperability platforms will provide you with the functionality to export the correct data from these proprietary software for your open workflows. If I have to adapt my workflow for another practice that heavily uses Revit and is unable to retrain their architects/engineers in FreeCAD for the workflow. I will use Speckle’s Revit connector to pull the data out from Revit and write an IFC exporter for Speckle (speckle2ifc). Once I have the right IFC file my workflow will function.

You might ask why not write a connector in Speckle for OpenStudio Application so you can go from Revit → Speckle → OpenStudio Application? I don’t do that cause I want the workflow to remain as open as possible. Since OSMod is an open standard, if another energy simulation software reads OSMod, I can easily swapped out OpenStudio Application for that software with minimal alteration to my workflow. Your workflow will remain more open if it uses open standards for exchange of data as compared to an interoperability platform that is a software-specific solution. Open standards take priority over software-specific solutions.

Then why not write an OSMod export for Speckle (speckle2osmod), so you can go from Revit → Speckle → OSMod. If I do this, I will need to maintain ifc2osmod and speckle2osmod for my workflow to remain open for Revit and FreeCAD, which will have overlapping functions with both libraries exporting to OSMod. If I do speckle2ifc and ifc2osmod, I do not repeat myself within the two libraries and each library serves a well-defined task. The latter case is conceptually clearer which makes it easier for maintenance.

Conclusion

I gave a brief description of current practices of computational designers, where workflows are mainly developed using proprietary software and that prohibits open sharing. Open workflows will allow for open sharing. At minimum open workflows uses open standards, and whenever possible prioritize the use of Free and Open Source Software (FOSS) and Free and Open Source Hardware (FOSH). There are many advantages such as it can be readily improved by the community, the designer can easily access and use the workflow wherever they work, smaller companies can readily adopt these workflows and create more job opportunities, and lastly the society benefits as these open workflows provide better ways for designing the built environment. However, are open workflows achievable with the current state of AECO open-source ecosystem? I demonstrated the feasibility with my own open workflow project. Open workflows have the power to reshape computational design, making tools more accessible, workflows more adaptable, and knowledge more widely shared. By using open standards and open-source tools, we can democratize technology and empower designers worldwide. What are your thoughts? Have you encountered challenges when developing open workflows? Let’s continue the conversation in the comments!

Acknowledgement

Thanks Yazid for his insightful feedback on the role of computational designers in practices of different scales.

Resource

• OSArch
• Open Tool Chain
• Chen, K.W., Janssen, P., Aviv, D., Ninsalam, Y., Meggers, F., (2022). A Framework for Considering the Use of Computational Design Technologies in the Built Environment Design Process. ITcon 27, 1010–1027. [DOI]