Enter the Panda – linking geometry to structural analysis

My team designs big stuff, with complex geometry. For a while now (since well before my time with the team; I’ve been here for a year and a half) we’ve been using Grasshopper 3D to define our geometry – beams, columns, trusses, struts, etc – with some pretty cool results.

Geometry definition of the Al Wakrah stadium roof, Qatar, produced in Grasshopper by AECOM Sports in London.

Alright, it’s all well and good to parametrically define some funky geometry – and maybe impress some architects along the way – but that’s just the first step. Let’s look at structural engineering in terms of The Three D’s: Define, Design, Draw. What we’ve done so far is just step 1, Define.

The second D, Design, requires the use of a three dimensional finite element analysis package, in our case Nemetschek’s Scia Engineer. Previously, we did one of two things to go from Define to Design: we either used Scia’s spreadsheet input by outputting our parametric members and nodes from Grasshopper into an xls document, opening Excel, copying the whole lot and pasting it into Scia; or we baked our geometry from Grasshopper into Rhino, output a dwg from Rhino, then imported it into Scia.

Both of these methods can be rather clumsy, lead to rounding errors, have some major drawbacks (e.g. the spreadsheet method can’t import curved members at all), and, most importantly, are long-winded. Thus whenever you make a change to the geometry it takes a long time (by parametric design standards) to rebuild the geometry in your analysis model. You then need to redefine all of the member and node parameters, such as element releases, supports, cross-section information, and loads.

Enter Panda, our in-house Grasshopper tool which takes geometry of any kind and converts it into Scia’s native XML format, ready for import directly into Scia. When set up properly, we can import an entire model, open it up in Scia, and press Run, without having to set up any additional parameters from within the Scia interface. The model will already include everything we need to analyse the structure and run Scia’s automatic steel design functionality.

Below are some screenshots of the Grasshopper script, including a zoom-in of our Model Creator component. As you can see, everything from cross section, load cases & combinations, applied forces, hinges, supports and design parameters (buckling lengths and restraints) are already defined before we even open Scia. The “Pandarator” – the component to the right of the Model Creator – is the final step; it writes out the complete XML file, ready for import into Scia.

So how do you do this yourself? Well, it’s all about learning about Scia’s native XML format and how to generate the files, and then automating the process. You can start by exporting an XML file from Scia, looking at how it works, and adapting the code for your own scripts.

Or if you just want to get a quick geometry model into Scia, as part of this blog post we’re releasing Panda Lite – a free Grasshopper component we’ve created to generate a Scia XML file from a set of lines and arcs. Simply plug the curves into it, set an xml filename, start a new model in Scia, and go to File->Update->XML. It’s that easy!

Get it here and try for yourself: PandaLiteHere! *

And what about the third D, Draw? Well, that’s the second part of the Panda suite: our link from Grasshopper to Revit, with Autodesk’s Dynamo as an intermediary. But that’s the topic of a future Blog entry to be posted by my esteemed colleague, MBMB (a.k.a. Matt Byrton).

End User Agreement*

Pandametrics (The Zen Art of Parametrics) Episode II

And we’re back, Pandametrics….so onto the Do’s and Don’ts of Pandametrics a glimpse at some most excellent shell design workflows and a hint of Ricky’s upcoming blog.

Do’s and Don’ts

This is not to say that it’s better to just rely on good old fashioned know how, what we mean by Pandametrics is that you should use parametric design to focus on improving what you can automate to allow you more time to focus on the fun stuff, the structure interfaces and detailing that give a building some real finesse.

For example, if your architect lets you know that their geometry is dictated by a specific grid and that the values of this grid could change then you’re going to see a massive improvement in your workflow by tying all of your follow-on design to the grid. It would then follow that as the grid changes so your analysis model would update loadings and then your production model would follow suit. Clearly this is going to save you time and efficiency by not repeating work when a grid increases by 800mm and you find you need to check through all of your hand calculations to see if the member size is still valid.

The images below are from a parametric process we created for taking non definable geometry and turning it into a panelised system for analysis (you might recognise the shape as Smiljan Radics most excellent 2014 Serpentine Pavilion); in this instance a change in this rather unique shape can be panelised and evaluated in a matter of hours, saving time and efficiency to spend on the detailing and really nailing down the architectural vision.

Serpentine 2014 - Architect model, to GH, to Shell...ready for analysis

Obviously the gold standard is to produce a holistically optimised solution, weighting every parameter from every discipline and optimising accordingly but if you've ever tried to optimise a structure for every possible evaluative parameter that can be applied in a single workflow you've no doubt found yourself staring at a huge tangle of unmanageable workflows that at best resemble the operating board of a NASA shuttle…too many adjustable items to ever consider a solution optimal. Also, a good workflow should never require astronaut levels of training to understand it!  

There are academic studies (do find the Delft University of Technology’s excellent paper of optimisation of parameters, it’s a good read and a look to the future which we’ll no doubt talk about in a future blog on this year’s IASS symposium) that are considering how the selection of parameters of a whole building can be optimised. However, even in these studies there is not an attempt to bring all of the building disciplines into a singular giant AI controlled workflow, rather to evaluate the end processes of each workflow, consider the impact on the building of each of the disciplines’ input parameters in isolation, and select the best combination. Maybe in the future we will be seeing this kind of cross discipline work across a single workspace, but whilst there is still a surprising resistance to moving towards 3D modelling (I realise I’m most likely preaching to the converted here) this could be some way off.

To get the most from your parametric design you should be considering a simplistic set of input parameters that will form the beginning of your workflow. The parameters should form the key part of your workflow in which as they change, any additional work created is minimised in the follow-on processes

So what’s it all mean?

The biggest tip I could offer to someone who is looking to implement parametric design into their day-to-day processes is to start by looking at your existing workflows and design processes. It is often argued that parametric design is only applicable for complex geometry. Tish and pish I say. I have used parametric design to allow me to map complex geometry for an anatomically correct stadia roof, I have used parametric design to assign connection forces for a fully welded truss, I have used parametric design to manage an architectural grid and I have used parametric design to link a layout of a simple pavilion steel frame to an architectural GRP Shell geometry (this shell analysis will look familiar, and not just because I put some of the shell panelisation script in an image above).

Lovely parametric shell being analysed in SCIA engineer

Parametric design is both underused and inappropriately used in the construction industry and the zen art of parametric design is to take this wonderful tool and do what we as engineers do best, use our experience and intuition to improve our designs and workflows to make us more efficient and create better designs. A couple of years back (before my time with the team) there was a brief that included 6 stadia designs and 3 days with which to design them all. Suffice to say they smashed all 6 stadia, partly through being awesome, but partly because they used their intuition and experience with parametric design to go beyond traditional design practices.  

Pandametrics has led to the development of our key tools for creating a series of interconnected parametric models that simplify and improve the workflows from geometry definition to analysis to production, without losing any of the data links that could prove exceedingly useful in the BIM environment (more on BIM to come in a future blog, it wouldn’t be right to have an engineering blog without discussing BIM after all). We’ve called it (unsurprisingly) Panda and very shortly our resident structural genius and antipodean legend Ricky will be telling you all about it with a nice little free download for those who fancy a go at tying Rhino/Grasshopper and SCIA engineer together and want to know the processes so you can build one yourself. 

Pandametrics (The Zen Art of Parametrics) – Episode I

Defining Pandametrics:

Parametric design – defining a series of design processes by a set of adjustable parameters

Zen – enlightenment through meditation, self contemplation and intuition

Not a panda...but pretty Zen

In structural engineering when we talk about parametrics we are traditionally talking about our modelling and design workflows, where the input parameters are a series of geometric definitions such as intersecting circles, variable frame settings, definable surface forms etc.

However, we often meet many definitions of parametric throughout the construction industry, just as we meet many definitions of BIM (an argument for another day)!

The zen art of parametrics, or Pandametrics as we like to call it (in true naming workflows and software after animals fashion), is using our experience and intuition to pick the right parameters for the most holistically efficient design workflow. 

A brief aside,  As I'm writing this at this years Autodesk University 2015 I'll take this opportunity to point out that architects and engineers who have been using parametric design, you're the choir and this is piece is going to come across as me preaching what you already know, although hopefully with a few talking points or bits you've not considered. Primarily this is written from the point of view of talking to those who haven't used parametric design but are considering making the plunge. Anyway, I digress, back to the content...

Why Panda? –  Some Chinese philosophers believe that the black and white of the Panda represents the opposing forces of Yin and Yang and in the time honoured tradition of using animal names for workflows and plugins we have focused on the Panda. Is there an animal more zen that representing the balanced peace and harmony of parametric design? 

Zen Panda

Let's expand that…

When I am asked to create a parametric model my first task is to work out what the key adjustable inputs are that can optimise our solution and most importantly what constitutes ‘optimised’.

We should talk about what we mean by optimised as it forms the foundation of the parametric process. In my experience, optimised in terms of building structures could be any number of things, for example:

• A found form which produces pure structures such as a pure tension structure, or a pure arch.

• a form which is confined by specific criteria such as avoiding ponding, or minimum curvature. 

• a structure which can be mapped to a specific aesthetic but adjusted for material performance.

• workflows which improve interoperability speeds to allow rapid prototyping and analysis. 

• a structure which is optimised for alternative key performance indicators such as cost, or additive material tonnage, or reductive material tonnage, or aesthetic, or energy performance, or user comfort…..the list goes on ad infinitum.

Benefits of Parametric Design

The largest benefit of producing a parametric model should come from an understanding of

1. the specific outcome you are looking to achieve; and
2. which small group of inputs with best help you achieve this.

One thing I can say for certain is that creating a parametric design process without fully understanding both of these will end in something too unwieldy to be practical or so inflexible it finds itself on the scrap heap the second your input requirements change. 

The basic benefit of all parametric design (sweeping statement coming) should be to make your design processes more efficient and anything that has to be binned off at the first hurdle because it's too inflexible fails even this simple test.

And I’m gonna stop right there… right before launching into the do’s and don’ts of parametric modelling, mainly because this blog is getting a bit on the long side, but also because it means when we return for the thrilling conclusion there will also be a hint of the workflows we’ve developed and a lead in to the free bit of software for download that Ricky has been pioneering….watch this space

I’m completely functional, and all my circuits are functioning perfectly

In case the title of this blog is lost on you (much as I’m regularly finding my endless pop culture references are lost to the current generation of grads) a blog about engineering in a digital age needed to begin with a reference that fit with what we’ll be posting about. If you’ve still not clocked on, the quote is from HAL 9000. If you’ve still not clocked on, go and watch 2001: A Space Odyssey right now, shame on you….shame…..shame*….

The film gave a chilling insight into a possible future and whilst this blog is going to steer clear of speculation as to the aggressive nature of humanity and how it may be eventually mimicked by Artificial Intelligence, we will be talking a lot about the technology driven changes that are going on in the engineering world and how they are affecting us at every level.

In further blog writing tradition, it’s time to introduce the principal authors, Matt Burton (that’s me), Tom Webster and Ricky Feigin. The three of us are structural engineers who met in AECOM sports and have had many an engineering adventure (think Lord of the Rings but with geometric modelling, grasshopper scripts and a whole heap of steelwork). We’ve shared a passion for pushing digital technologies in our day to day work and have noticed that there aren’t as many engineers out there shouting about these technologies as there should be. We’re also pretty damn good table football players and take such matters very seriously, as our latest team outing will attest to (Back Middle, left to right- Tom is fake bearded Brazillian Ronaldo, I have a ginger beard and a classic Sampdoria 2001 shirt and Ricky is the spit of Warwick Capper).

Sadly our time in the same team has since ended and Tom is off with Webb Yates, Ricky is soon to be taking up a role with Beca in Melbourne and, well, I’ve been described as an AECOM lifer. Thankfully all of the opinions on this blog and associated material is our own and not reflective of our companies, and, more importantly, our shared passion for digital engineering is ongoing and we’ll now be bringing opinions and developments from different parts of the structural world and from different continents.

Between us we’ve designed schools, research buildings, commercial towers, World Cup stadia, train depots, retail centres, warehouses, airports and internationally renowned Pavilions. Digital Engineering has played a part in each and every project we’ve been involved with and like a cross between a concise brain dump and a very loose lecture we’ve decided to start writing about and sharing our experiences about Digital Engineering.

We’ll hopefully be able to bring the opinions of some of the many great building specialists we’ve either worked with or continue to work with to the blogs and in occasionally have them write a guest blog.

We’ll also have some details (and possibly videos) of papers that my colleagues and I presented at this year’s IASS conference in Amsterdam on Digital Engineering techniques.

Some of the upcoming blog subject titles we’ll sharing in the upcoming weeks and months in no particular order (crazy project deadlines and unknown unknowns notwithstanding):

• Pandametrics (The Zen Art of Parametrics)

• Enter the Panda

• Pandametrics (or how I learned to stop worrying and love BIM)

• Do Engineers Have Electric Dreams?

• Pandametrics (a wolf in sheep’s clothing)

What do these bizarre and often Panda related titles mean and how do they apply to your workflows? You’ll have to check back in for an update, or keep an eye out on our twitter feed.

*if that reference is lost then it’s time to get up to date with Game of Thrones…shame…shame**

**  Shame...shame...