Gijs Joosen is senior architect at ONL [Oosterhuis_Lénárd] in Rotterdam. The office founded by prof. ir. Kas Oosterhuis and visual artist Ilona Lénárd. He studied both architecture and design systems at the Eindhoven University of Technology. He has been with ONL since 2003 and worked on numerous projects including the Liwa Tower in Abu Dhabi, the cyclists bridge in Deventer and the Ekris Headlights in Utrecht.
ONL is a firm that seems to have specialised in computational architecture. How did this happen?
What is specific to our architecture are the aesthetics of long fluid lines. The car industry is exemplary for this kind of design aesthetics. We are fascinated by creating long fluid lines in surfaces. These do not just improve the structural quality of the surface, but also enrich it visually through the play of light and shadows. The modern sports car features a richly moulded surface that casts smooth shadows where it is slightly convex or concave and a crisp shadow where the surface is folded more acutely.
In order to implement the aesthetics of these fluid lines and surfaces in architecture it is necessary to use computational design tools. clients do not come to us for our expertise in the field of computational architecture, but for our designs.
What would be an example of computational design in your practise?
We start with the design of a type of system with a very simple set of rules within which we can reach a high degree of complexity by playing with a few parameters. This is really something you also find in nature; a set of simple rules and parameters can generate very complex variations. This is why I always differentiate between complex and complicated; the former remains manageable where the latter is needlessly difficult.
In the case of the Soundbarrier that ONL designed at Leidsche Rijn near Utrecht the set of rules are three fluid lines. The ground line, the top line and a middle line that folds or bends the resulting surface. We tried to achieve a play of long fluent lines and shadows that can be perceived when driving past the barrier. By playing with these lines along the entire length of the barrier no part of the structure is ever the same.
A starting point in the execution of the barrier was our mantra of ‘one building, one detail’. In order to properly realise this we have to ‘bring the design process forward’. So, first we talk to the manufacturers that produce the structural components with CNC based machines. This gives us an idea of what the machine is capable of and how its operating software works. When we understand this we document the design in such a way that generates only the specific data that the machine needs to operate, a so called “lean” model, as opposed to handing over an all-encompassing digital 3d model saying ‘It’s all in there, extract whatever data you need’. We bring together the processes seamlessly in order for the information we deliver to the manufacturer to go straight into the machine’s operating software.
The interesting thing about this type of computer operated manufacturing is that for the machine it does not make a difference whether it goes through 200 of the same operations or 200 different ones. The only difference lies in feeding the operating software 200 different scripts. We call this principle of one machine producing an enormous number of slightly different components ‘Mass Customisation’.
What does this design approach mean in terms of the tolerances that we see in current building practise?
Funny you should ask, because we made a full scale mock-up of the sound barrier using conventional tolerances in drilling oversized holes for the bolts. However the ‘Computer Aided Manufacturing’ was so precise that in the end the whole mock-up sagged a few centimetres solely due to the tolerances in the structure. Because of this we could significantly reduce the tolerances since all the members were manufactured to such a high level of accuracy.
How do you communicate between the systems of all the professionals involved in the design and its execution? For example between the architect and the structural engineer?
In the case of the Haarrijn sound barrier we determined the shape of the surface with a set of fluid lines as well. In this case we left the dimensions of the structural grid as a variable parameter. We designed a structural principle with one generic node detail that was capable of accommodating all the necessary member angles. This detail and the set of fluid lines generated an image of what the project would roughly look like. This was presented to the client for approval. The actual dimensioning of the structural grid was linked to the structural engineer’s calculations for optimisation.
So we build a Grasshopper Script with the grid dimensions as parameters that influence the length of the steel members, the distance between the foundation footings and the number of nodes in the structure. The fluid lines generating the surface are constant, but the grid within the surface can still be changed. For this model we wrote our own export module that generated an XML file containing the metadata of the structural elements. In this metadata we can link all kinds of additional information to the elements. This means that when the structural engineer opens the file he gets an actual model that contains all the relevant structural data. This approach is quite extraordinary because usually the engineer would be given a set of drawings by the architect. From this he would remodel the structural system and then check it with calculations. This method however, will not suffice in the case of a two kilometre long barrier with over fifty thousand individual components. I want to be able to vary the grid size between 2 and 10 metres and everything in between and directly get exact calculations of the structural behaviour. It would be highly inefficient and ineffective to recalculate the whole model for each variation in grid size.
By exporting such a structural model we can also start comparing data on grid density and overall costs. The spacing of the foundation footings, the number of nodes and the quantity of steel are dependent on the grid dimensioning and naturally there is an optimum in terms of costs. By linking the grid density parameter to the structural calculations we can instantly get feedback on design decisions and we can begin to optimise the design for cost efficiency. We call this ‘value engineering’. Another advantage is that the price of steel changes a year from now when at the start of construction we can instantly find the new optimum grid density at the new price.
Do you have any advice for current students that would like to work in the field of computational architecture? Also, are students from the TUDelft faculty of architecture generally well prepared to engage with computational architecture as it is practised in your office?
What we generally see is that mostly computational architecture skills stem from a certain personal urge to work with these types of applications and software. You do not see much of this in the actual architecture education, but we do see that for example Grasshopper is a pretty common tool that a lot of students at the TU have experience with.
I myself studied in Eindhoven when computational architecture was just emerging and back then it did not play a significant role in education. However you can see that a number of people is getting interested and is starting to figure out computational design. I see it as an instrument. It is more like a particular way of thinking that you need to master apart from the instruments that you use; when you have developed that way of thinking it is quite generically applicable. It is a specific approach to a design where you start to use software only because you are too lazy and it becomes too much work to thrash out the design in a conventional way.
When you hire TU students do you have to still train them within the office?
Yes, we almost always do this. When we take some they generally need a period of 6 months to get up to speed with the thought processes and to master the instruments (software) to the point that you can use it appropriately.
Which software would you like to see TU students become familiar with when they aspire to work with computational architecture?
Rather separate computational architecture completely from the software. Software is interchangeable. I mean ten years ago we used Autolisp, five years ago we used Max-script, now we use Grasshopper and everything in between and it can all be substituted. It is all about the way you think about computation. If you must you could do it using Notepad – just like with a website. If you just understand how it works. That is much more important than knowing the software.