Designing with Computers - Essay

Computational Design Research

2026-01-15T00:00:00-05:00

Computational design is the study of using computer programming to solve architecture/engineering design problems.

Introduction

Computational designers are architect/engineers who can do computer programming. They have domain expertise while possessing the computer skills to develop new workflows to support efficient project delivery. Thus a practical and easy to remember definition of computational design is the study of using computer programming to solve engineering/architecture design probems. Programming (including both textual codes like Python & Javascript, and visual programming like Grasshopper & Dynamo) provides designers full access to computation capabilites as compared to the limited access provided by Graphic User Interface (GUI). In my opinion, this is the main difference between computational design and Computer-Aided Design (CAD), where in the CAD field, designers are primarily reliant on the software GUIs.

Motivation

As Architecture, Engineering, Construction & Operation (AECO) industry continues to digitalize through digital transformation effort globally, it is increasingly common for practices to have computational designers on their team. As computational design plays a bigger role in AECO projects, it is useful to look at how we can improve and grow the field through research work.

Research in Computational Design

Research in computational design occurs on a spectrum as shown above. On the one end, we have computational leaning research and on the other design leaning research. Generally, there are three anchor points on the spectrum: Data structures and algorithms, software development and applications in projects. It is important to note that most research do not cleanly fall into either category but rather is a mix depending on where it lies on this spectrum.

Data structures and algorithms are computational leaning research that investigates:
1. data structures or schemas for computation work in the AECO field
2. develops or improves algorithms that efficiently do computation on these data structures
3. examples are researchers looking at data schemas like
  - Industry Foundation Class (IFC) for Building Information Modeling (BIM),
  - CityGML and CityJSON for City Information Modeling,
  - OpenStudioSDK for building energy simulation,
  - Brick Schema for building operations
Software development are research in the middle of the spectrum where it applies the results from the data structures and algorithm research and use it to develop software and programming libraries for used in projects. Examples include:
- ifcopenshell a programming library for processing IFC data,
- Galapagos and Wallacei are Rhino Grasshopper 3D plugins for executing optimization algorithm in design
Applications in projects are research that focuses on the use of these software tools in case studies. They share insights into the benefits and challenges of using these new technologies in design.
- Generative design of terraced concert hall – a case study of Taipei music and library centre
- Design space construction: a framework to support collaborative, parametric decision making

Alot of my research works fall around software development and applications in projects while slightly leaning towards software development. Most of my applications are demonstration cases with only a couple of projects that were actually built.

Conclusion

I have described a Computational <-.--.--.-> Design research spectrum with 3 anchor points and gave examples of research work that falls on the anchor points. A computational design researcher work will probably cover a range rather than only occupying a discrete point on the spectrum, as I have illustrated with my own works. Combining this framework with the Building Design Process framework from my previous post, it will provide researchers with an insight of where their works stand relative to the field and how it can eventually be use in practice. For practice this will give them a big picture of how research can support and improve their design process. I hope the 2 frameworks can be use to create a feedback loop between research and practice and accelerate innovations in the AECO industry.

Let’s continue the conversation in the comments!

Reasoning Patterns of Design

2025-12-02T00:00:00-05:00

A framework to explain and describe the act of design.

Motivation

This post is inspired by The core of ‘design thinking’ and its application. I provide my intepretation of the core ideas presented in the article in this post.

Reasoning Patterns in Sciences

What (the thing) + How (Working Principle) = Result (Observed)

This equation will be used to describe the basic reasoning patterns in problem solving in the sciences.

What (the thing) + How (Working Principle) = ?

Deductive reasoning is used when the 'What' and the 'How' are known, and we can confidently predict the results.

Deductive reasoning is the process of drawing valid inferences. An inference is valid if its conclusion follows logically from its premises, meaning that it is impossible for the premises to be true and the conclusion to be false. Wikipedia

What (the thing) + ? = Result (Observed)

When we know the 'What' and we can observe its 'Result'. We can use inductive reasoning to propose the 'How' (working principles governing the result) based on observations. This is the creative act of proposing a hypothesis. The hypothesis is then tested, measured by how well the result can be predicted.

Inductive reasoning refers to a variety of methods of reasoning in which the conclusion of an argument is supported not with deductive certainty, but at best with some degree of probability. Wikipedia

Reasoning Patterns in Design

What (the thing) + How (Working Principle) = Value (Aspiration)

The act of design can be described with a slightly different equation shown above where instead of the result we have the value we aspire to achieve with the implementation of the design.

? + How (Working Principle) = Value (Aspiration)

In a conventional problem, abductive reasoning is employed where designers design a thing ('What') that operates with a known working principles and within certain scenarios to achieve the desired 'Value'.

Abductive reasoning is a form of logical inference that seeks the simplest and most likely conclusion from a set of observations. While inductive reasoning draws general conclusions that apply to many situations, abductive conclusions are confined to the particular observations in question. Wikipedia

? + ? = Value (Aspiration)

In an open complex problem both the 'What' and 'How' are unknown. The only known is the 'Value', what the design is supposed to achieve.

To resolve such an open and complex problem. Designers can work backwards from the only known aspect. By proposing different working principles that can facilitate the achievement of the 'Value'. A designer is framing the design problem.

? + How (Working Principle)? = Value (Aspiration)
    <------------------------------------------->
                        Frame

With the framing, designer can then approach the problem conventionally. As a designer proposes new 'What' solutions, each solution can be tested by observing the 'Value' when the 'What' + 'How' is put together. If the 'Value' observed is desired, we can say the proposed solution is a successful solution.

What (the thing) + How (Working Principle) = Value (Aspiration)?

Applying the Framework

How can you apply this into your design process? I will use an example office design project to illustrate the application.

Conventional Office

In the design of a conventional office we assume a framing of the following:

How (Working Principle): People come to the office, have a designated seat/cubicle/room for them to carry out their work.
Value (Aspiration): People get their work done and delivers the result efficiently.

So you design a conventional office space as specified,

What (the thing) - office space with cubicles, office rooms and so on etc.

Post Covid Office

Post Covid, remote/hybrid offices are more common. We start to see a change in the 'How', the values still remain the same:

How (Working Principle): For a hybrid/remote office, no designated seats are required. People can work from home and only go to the office when necessary. Work can be done as long as you have access to a computer and internet.

In this case what needs to be design is no longer a conventional office. You will still need a space, but it might not be used for working. Rather the space might be for discussion, gatherings and presentations. This will totally change what needs to be designed.

What (the thing) - a space for gatherings and discussions. Hot desking for people who still wishes to come into office. Storage cabinets for workers as no one has any designated seats anymore.

Conclusion

The framework is able to describe the reasonings during design. By making the reasonings behind design explicit, it helps designers better understand their design process. I feel this demystify the design process. Thus allowing designers be more intentional about how they can improve their design skills, as they can more effectively communicate ther design process and receive feedback on how to improve it.

References

Dorst, K., 2011. The core of ‘design thinking’ and its application. Design Studies 32, 521–532. https://doi.org/10.1016/j.destud.2011.07.006
Lawson, B., 2019. The Design Student’s Journey: Understanding How Designers Think. Routledge, Oxon, England.
Lawson, B., Dorst, K., 2009. Design Expertise. Routledge, Oxon, England.

A Framework to Understand Building Design Process for Computational Design Research

2025-12-01T00:00:00-05:00

The framework provides a practical overview of the design process of a building project by placing it in context within the built environment and outlining its key stages, participants and tasks.

Motivation

The building design process is often times long and messy with many participants. It has always been a challenge for me to describe the building design processes and how my computational design research can improve and optimize the process. I have come up with a framework that provides a practical overview of the design processes to help me think about the subject. The framework is a consolidation of other frameworks I have came across throughout my research career. It has been helpful for me and I hope it can be helpful for you too.

Situating Building Design Project within Our Built Environment

Before diving into the building design process, I think it is worth to understand where a building design is situated within the bigger context, our built environment. A simple framework of our built environment based on 6 scales is presented here to facilitate the understanding.

Products - products such as graphic design, furniture, laptops.
Interiors - space within a structure.
Structures - external form constructed from products that contained interior spaces.
Landscapes/Urban Designs - planned outdoor spaces.
Cities - structures and urban areas clustered together defining a community.
Regions - cities and landscapes group together due to common social, political and economical characteristics.

A building design project falls into the structures category. There is a content <-> component <-> context relationship between the categories.

In designing a building (structure), you will need to be aware of the content in the building (interior) and where the building is situated, the context of the building (landscape). It provides a framework for the things to consider when approaching a design project. Now that we have a sense of where building design is within the bigger built environment context, let's dive into describing the building design project.

Work Stages of a Building Design Project

Generally, a design project can be separated into 4 main work stages.

Pre-design - conceptualize the design brief e.g. site selection, specifications etc.
Design - propose design solutions.
Construction - design and build the chosen solution.
Operation - operate and maintain the built artefact.

A fifth stage Demolition could be added to it, however it is not common practice yet for designers to consider demolition during design.

Professions

Depending on the type of contract (Integrated Project Delivery, Design-Bid-Build or Design Build etc.) chosen for the project, different building professionals will participate at different stages of the design process. For example, in the more traditional Design-Bid-Build contract, engineering consultants will join the design process in the later stages while in the Integrated Project Delivery contract, ideally engineering consultants join in much earlier in the design process. For more information refer to my previous post (Architectural Design is the Start of the Building Design Process).

Design Tasks

Within each stage, there will be a set of deliverables. The deliverables can be drawings, 3D models, analysis or mock-ups. Design tasks are performed to produce the deliverables. Design task can be defined as a node with inputs and outputs, depending on the task at hand it might or might not need inputs (existing data/information), but it definitely has an output that is the deliverable. It is also defined by other attributes like the professions who are performing the tasks, processes and tools involved in producing the deliverables. A design stage is made up of a network of design task nodes feeding into each other with the aim of producing deliverables to hit the contractual milestones of the design stage.

Case Study: Example Building Retrofit Project

In this section I illustrate the first two design stages (conceptualization and criteria design) of an example building retrofit project using the described framework. The primary driver of the project is to improve the daylighting performance of the existing interior layout. By illustrating the design processes with the framework, we can readily see the computational design tools that can support the performance objectives. IoT lighting lux sensors to understand the existing daylighting levels and daylighting simulations to evaluate potential design options that can improve the current performances. We can also see the connections between the design tasks across the different design stages (right-click -> Open image in new tab for a bigger image).

Conclusion

I have described a framework that helps computational design researchers think about how their work can support a building design project. I did a quick and simple demonstration of the framework on an example project. The exercise of illustrating the design process with the framework has been very helpful for me in thinking about how my work can support design work in practice, I hope it will be useful for you too.

Let’s continue the conversation in the comments!

References

Mcclure, W.R., Bartuska, T.J. (Eds.), 2007. The Built Environment: A Collaborative Inquiry into Design and Planning, 2nd ed. John Wiley & Sons Inc., New Jersey, USA.
Lawson, B., 2019. The Design Student’s Journey: Understanding How Designers Think. Routledge, Oxon, England.
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. https://doi.org/10.36680/j.itcon.2022.049

Architectural Design is the Start of the Building Design Process

2025-09-02T00:00:00-04:00

As architectural design usually serves as the basis for other engineering domain designs, an architectural design that has meaningfully considered and accomodated for engineering performances will significantly facilitate the realization of high-performance buildings and zero-energy buildings.

Building Design Process

Due to the nature of AECO industry, the design process for each building project is unique depending on where it is located. As each location will have its own unique site conditions, climate, building codes and construction practices. Although unique, the process generally shares similarities. The design process can be divided into four main stages: pre-design, design, construction and operation stages. Depending on the type of contract chosen for the project (Integrated Project Delivery, Design-Bid-Build or Design Build etc.), different building professionals will get involve at different stages of the design process.

The design process when reduced to its basics follow these steps (as shown in the diagram below): architects produce architectural designs, based on the architectural design, structural engineers will develop the structural design, mechanical engineers will develop the Heating Ventilation and Air-Conditioning (HVAC) design, and electrical engineers will develop the electrical design. Control engineers will develop building controls based on the HVAC and electrical designs. The final drawings/models are consolidated for the builders to do cost estimation and construction. This is an iterative process, feedback will be provided to improve on the architectural and engineering designs and the design process repeats. Post construction, there will be a comissioning phase for each domain expert to verify the building is constructed and function as specified by the drawings before the it is allowed to be handed over to the facilities and be occupied by its users.

The professions involve and their importance in the design process will differ depending on the scale and building type. For example, packaged HVAC systems are usually used in residential projects, the mechanical engineers role will be less important. Control engineers will not be necessary as the building systems are relatively simple and does not need much automation or controls. However, in a high-rise office building, mechanical engineers will play a more important role as built-up HVAC system will be used. Controls will be essential as automation and central control will be needed for efficient management of building systems in such a big building. Circulation specialists will be required as vertical circulation (elevators) is a major building systems in high-rise office buildings.

The difference between a conventional design-bid-build from an integrated project delivery is that this full design cycle happens in the the later design stages, while in an integrated project delivery this full design cycle happens from the early stages throughout the design process. - In the design-bid-build project all the professions that is required to complete the design cycle are present only at the construction stage. - In integrated project delivery, you include as many professions possible right from the start of the building project.

Architectural Design: A Good Beginning is Half the Battle

As you can see from the described design process, architects usually kick-starts the design process by giving form to the building. The structural, mechanical, electrical and control engineers develop their design based on the underlying architectectural design. As mentioned above, this is an iterative process. If we get it right from the start (architectural design) we can reduce the number of iterations and reach the target earlier. In my previous post (Domain Expertise, Models and Simulation Programs: How to Use Building Performance Simulation in Architectural Design) I have briefly described the need for architects to improve their engineering knowledge and how we can use Building Performance Simulation (BPS) to facilitate architectural engineering education. I hope this post will make a stronger case that since architectural design is usually the start of a building design process, it is essential architects improve their engineering knowledge. If architects can meaninfully consider and accomodate for high performance building systems in their design, it will make constructing a high performance building or even Zero Energy Building (ZEB) more achievable.

I hope this post provides you some insights on the issue. What are your thoughts? Let’s continue the conversation in the comments!

Resource

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]

Southeast Asia Building (SEAB) Magazine Inteview on the Use of GIS in Architectural Design

2025-05-30T00:00:00-04:00

My interview with SEAB about the potential advantages of using GIS in architectural design. You can read the full issue here.

Interview Extract from the May-June 2025 SEAB Magazine

I hope this post provides you some insights on the issue. What are your thoughts? Let’s continue the conversation in the comments!

Resource

GIS4Design user manual

Domain Expertise, Models and Simulation Programs: How to Use Building Performance Simulation in Architectural Design

2025-05-08T00:00:00-04:00

Current Modeling and Simulation Practice in Architecture Design

Architects are experts in building designs and building aesthetics. They use 3D models of varying abstractions throughout their design process to visualize their designs. This range from highly abstract 3D models in the early design stages for exploring design concepts to highly realistic models for presentation and communication to stakeholders in the detailed design stages. They use rendering programs (basically lighting simulations) with the 3D models to produce photorealistic drawings for presentation and prediction of the building design and aesthetics. Conventionally, this is how models and simulation programs are primarily used in architectural design.

With raising concerns of climate change, it is becoming common that architects model for Building Performance Simulation (BPS) even during the early design stages. BPS is a general term that encompasses all performance simulations related to building design. Daylighting and Heating Ventilation & Air-Conditioning (HVAC) related simulations are the two most commonly used by architects for predicting operational energy consumption. The general attitude towards BPS modeling is that since architects are already building 3D models for visualization, they should have the skill to effectively model for BPSs or more ideally the 3D model built by them can be readily converted for BPS with minimal modification. However, the 3D model abstraction for rendering programs differs significantly from the abstraction necessary for BPSs. Even within BPSs, daylighting, HVAC and structural simulations require significantly different modeling abstractions. As a result, most of the time architects have to remodel their designs for each different simulation based on their limited domain knowledge, making this a labor intensive and time consuming process.

The most common solution to this issue is by developing BPS plugins for 3D Computer-Aided Design (CAD) or Building Information Modeling (BIM) programs that is commonly used by architects. This enable architects to rapidly remodel their design within a familiar interface. If certain modeling rules are followed, in theory the BPS plugin can automatically retrieves and inputs the model into the simulation program. Or if the plugin is in a BIM program, in theory the BIM data is information rich, there should be minimal remodeling as the plugin should have sufficient information to readily convert the BIM data to a simulation model. This solution main drawback is it is program specific, it only benefits the users of a specific modeling program. I have discuss this issue in my other blog post on open workflows. However, this solution still do not address a more fundamental difficulty when architects utilize BPSs in their design, the lack of domain expertise when modeling for different BPSs. This is what I am interested to talk about in this article.

What is the Challenge of using BPS in Architecture Design?

The core difficulty of using BPS is architects lack domain expertise on the performances that are being simulated. This results in two issues, the inability to

Prepare the model for input to the simulation and
Judge the validity of the simulation results.

I will use a specific example to further elaborate on these issues. In modeling for OpenStudio Application, an open-source whole building energy simulation program, architects have to decide on the HVAC thermal zones. Thermal zones are not the same as architectural programming spaces. They are areas that share similar thermal condition requirements and thermal environment controls. In a real building, this is usually translated as the area that is sharing the same thermostat. That thermostat is providing thermal control by allowing users to define the air temperature setpoint and providing feedback to the HVAC by monitoring the actual air temperature. Thermal zones are not necessarily defined by solid objects like walls. In OpenStudio, thermal zones are defined by a closed volume geometry with no boundary surface thickness. The thermal properties are then defined in a construction object and referenced by the boundary surface that is using that construction. The construction object can be just air. Overlapping boundary surfaces of adjacent thermal zones have to be modeled in a particular way for the simulation to acccurately calculate the heat transfers. Due to the lack of HVAC knowledge, architects often confuse thermal zones with architectural spaces and model them incorrectly. As energy modeling has less tolerance for error, modeling practices acceptable for architectural visualization will not work for energy simulation. As a result, error arises and simulations are halted. I have only pointed out one issue concerning geometry modeling, not to mention the other HVAC parameters that are required for the simulation. Although, specifying HVAC parameters can often be solved with the use of HVAC templates once the geometries are properly modeled.

The second issue arises after a successful simulation run. Architects are not able to judge the validity of the results. Is the Energy Use Intensity (EUI), cooling and heating load profiles reasonable for this building type of this scale? This could be partially solved by running simulation on a typical building (PNNL provides a collection of typical buildings for multiple building types in various climates) before running the simulation on your design. Using a typical building as reference, architects might be able to have a better ball park on their results. However, it is still difficult to effectively utilize the simulations results to inform design decision. For example, if the results are not reasonable, “What has gone wrong in the model and how do I fix it?” If the results are reasonable, “What are the design variables I can change to improve the results?” It is difficult to make sense and use the result for design without the necessary domain knowledge. This example specifically illustrates the challenge when running whole building energy simulation with OpenStudio, but generally these issues apply to other BPSs too.

How should Architects use BPS in Design?

Some might ask “What do you mean architects lack architecture engineering knowledge? Shouldn’t they learn sufficient engineering knowledge from school and practice?” From my own experience being an architecture HVAC researcher and lecturer, architects I have spoken to generally lack the necessary engineering knowledge to effectively use BPS in design. It is only reasonable, in a design team there are already professional HVAC and structural engineers who are in charge of those aspects in a building design. So should architects use BPS in their design process? My answer to this question is still YES, but only when the building performances are significantly affected by the architectural design. One obvious example is daylighting as its performance is so closely linked to building orientation and window designs. If that is the case, architects will need to improve their architecture engineering knowledge. How much should an architect know then? They do not need to know as much as the engineers who are officially in charge of those engineering aspects. My view is they just need to know enough to effectively use BPS in their design process. Architects can then meaningfully consider high performance building systems when doing architectural design and facilitate an integrative design process when working with the engineers in the team.

This gives us a framework to reconsider our current architecture engineering education. I shall call it the BPS-based design oriented framework. By first defining the performance metrics useful for supporting architecture design decisions, we can then decide what are the appropriate BPSs to run to acquire those metrics during design process, and lastly learn the required engineering knowledge to meaningfully run the BPS and interpret the performance metrics for design. In my opinion, current engineering education in architecture are too detached from the design process. The knowledge is taught in isolation with no clear indication of how these knowledge can be directly applied in the architectural design process. Often times, students are overloaded with multiple architecture engineering domain knowledge (HVAC, structure, daylighting etc.) with no clear method of applying them in design. As a result, they lost interest and walk away with limited understanding on the subject.

Using a concrete example, daylighting in architectural design, we will first introduce the unit of Lux (lx) for measuring illumination. Lux measures the amount of illumination (light) falling on a horizontal plane. An acceptable value for doing office work is within range of 300-500 lx. We then continue to define an appropriate performance metric called Useful Daylight Illuminance (UDI) that could be useful for early design stages. UDI is defined as percentage of annual daytime hours that a given point in a space is within a specified illumination range, typically between 100-2000lx. The lower lux threshold can be adjusted based on the project, for example it can be adjusted to be 500 lx to ensure the space is sufficiently bright for office work. The upper lux threshold is based on the higher probability of glare when illuminance is above 2000 lx. We can then define the performance goal of 100% of floor space achieving 50% UDI.

Once the performance metric is clear, we can move on to learn about the simulation program and their underlying methods to calculate the performance metric. For example, an open-source program, OpenStudio Application is able to calculate UDI. We can elaborate on the underlying calculation method and practice how to model for OpenStudio Application. The key to this approach is it needs to focus on design oriented hands-on exercise. It is very important to explicitly state when to utlize this BPS, at which design stage and what are the design information required for the simulation modeling. Architects will learn the appropriate performance metric, how to model for the BPS, interpret the simulation result, and when to apply it in their design process. With this approach, architects can optimize their design throughout the process, but most importantly the BPS results will facilitate integrative design discussion with other engineering consultants.

Conclusion

I gave a brief description of the current BPS modeling practice in architectural design process and pointed out the main issue is the lack of domain expertise. This causes two issues; 1) the inability to appropriately model for BPS and 2) judge the validity of the simulation result. I suggest that the key to solving this issue is through improving the architecture engineering education by introducing a BPS-based design oriented curriculum. This will replace the current architecture engineering education that overloads architects with engineering knowledge with no clear method of application in design. It is a targetted approach that explicitly define the performance metric to attain, introduce the BPS program, how to model for it, and when in the design process to use the program. I hope such an approach will significantly improve engineering literacy among architects and allow them to make well-informed building performance related design decision in their projects. Architects have a major role in designing the built environment. They need to be equipped with effective architecture engineering knowledge so that they can be in a better position to facilitate and push for decarbonization of our built environment. I hope this post provides you some insights on the issue. What are your thoughts? Let’s continue the conversation in the comments!

Resources

Why Computational Designers Should Develop Open-Source Workflows

2025-02-19T00:00:00-05:00

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.

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]