Virtual Insanity...

A mini blog, just because sharing is caring and we do love spreading our digital workflows around.

So as a preface this isn't, as the title might suggest, a post having a dig about Virtual Reality. It's not even about Virtual Reality, rather Mixed Reality and what we've been benefiting from in our workflows. Virtual Insanity....just because it popped into my head and let's face it..who doesn't like classic Jamiroquai?

We've been lucky enough to be using the Microsoft Hololens to improve our design processes. 

So far we've been using models:

• During concept design (from Rhino) to really help evaluate the credibility of the schemes.
• During design review (from our SCIA engineer analysis model) to check on the modelling and detail.
• During Coordination (a holo review in a digi meeting is surprisingly less unnerving than you'd think although to the outside world probably looks like a normal meeting but with a group of people in headsets waving their hands around an empty table).
• During production (from the Revit model) .

Because a video can tell 5.508 million words, Martin has put together a video of the Mixed reality build of a Stadium Structure that may be familiar captured straight from the Hololens.  

Follow this handy link  (click on the image) and enjoy. 

If your socks are slightly blown off, consider the state of mine having used the workflows and seen the improvements we've made in our design processes. Let's just say I need new socks. 

It's been a lot more useful and successful than many emerging technologies we've had over the past few years and is already pretty well integrated into the teams workflows. Be on the lookout because anyone who tells you Mixed Reality in our industry is a gimmick hasn't used it yet. 

And with that I sign off, but not before leaving another Jamiroquai link

MB

Do Engineers Have Digital Dreams?

So originally this was going to be called "Do Engineers Have Electric Dreams?" as a take on "Do Androids Dream of Electronic Sheep?" the novel by Phillip K.Dick upon which Blade Runner was based. By changing the title to Do Engineers Have Digital Dreams? it has more relevance to the construction industry as a whole.

Early wireframe 3D analysis model

When I first joined the industry, digital engineering was very basic. 2D drawings were the norm, companies were beginning to play with some 3D modelling software such as Rhino and 3D plus. Structural analysis was still conducted on a member by member basis with basic wire frames models being adopted and 2D Finite Element Analysis of concrete plates. The emphasis of the industry was to drive repetition to save time time on analysis and drawing. The mantra often being "if it's easy to design it's easy to build".








12 years on and I can say that thankfully with the digital tools available we can design complex structures in about half the time it took 10 years ago. What's more we can actually communicate this information to clients and contractors in multiple formats that allows for understanding of both the complexity and cost.  So why is it that many companies are not maximising or using the tools available to them? Why are the engineers not having digital dreams? I've thought about this over the past few years and have come to some conclusions.

To me, the most basic form of a Digital Tool-kit is a 3rd party plugin to Revit or Bentley Structure, normally produced by the structural analysis developer that allows the transfer of data between the software. Typically this transfers geometry and materials, and sometimes includes analytical information such as releases and loads. However very rarely do these plug-ins do what the developer says they do. From my experience anything other than a concrete flat slab with straight columns or similar in composite steel just won't transfer, often the "round trip" simply doesn't work

.

I have spent many a day with software suppliers telling them this is how the software needs to work and this is how we want to work. The problem to me is that a basic 3D model i.e. flat slab and column, is very easy to draw in a 3D modelling package and very easy to draw in an analysis package. So why mess around with sharing the information backwards and forwards when its likely not to work without a series of bespoke work-arounds? Importantly this wastes already limited time and fee.

Where is the incentive for a design practice to use even the most basic form of tool-kit if in the long run it costs more money to use? Firms get suckered by the big sell and as soon as you try and use the plug-ins they breakdown very quickly. Unfortunately most design firms are often on tight fees and this potential for waste in time and fee just can't happen.

So consider you are a director in a company and the first experience you have of the digital world of engineering is spending £1000 up front and £500 a year on maintenance  on a plug in which is no use whatsoever. You're probably going to call it all a waste of time and money and go back to how you did things previously.

If you want to know about music you are going to listen to BBC 6 music, if you want to be sold music you are going to listen to BBC Radio 1. This is true of software in the construction industry If you talk to the big software developers they are going to sell you software but if you talk to the digital engineers in the industry they are going to tell you about the tools available to develop your own processes and tool kits.

And here's the real hook, it shouldn't cost you any capital expenditure at all to develop your own toolkits. Most worthwhile toolkits are free! Yes free! and all you have to do is share and be active with the community. You will also have to free up some time for someone in your business to learn, play, and develop a series of process that suit your company and the way it works, but that is a controllable expenditure.

I can't sit here and write a catch all solution for you, each company is different with different design ethos, software and needs, but I can write about my experience and it is as follows.

When I was at AECOM we originally decided that we wanted to use Rhino with the plug-in Grasshopper to hold all the geometry for the structures we were designing, we would then pass this through into our analysis package, originally by excel but later the team developed an XML plug in called Panda (See Ricky's post Enter The Panda). The files were then passed through to Revit by a link which was an enhanced beta version of the standard plug in which we developed with the software company. This worked really well until the designs became too complicated with bespoke nodal connects and free formed surfaces.

Drawing complex geometry before Dynamo

We identified that our weak link was the transfer of geometry into Revit (Revit is notoriously  difficult to draw complex geometry in) so we looked to other means. Dynamo was the obvious choice, in layman's terms Dynamo is to Revit what Grasshopper is to Rhino. Although a number of years behind in development we could programme Dynamo to directly translate our grasshopper geometry into Revit. We could also link our analysis results from SCIA engineer back into Grasshopper so we could also export all the structural information relating to the design back into Revit via Grasshopper and Dynamo. So if you can create a parameter for it in Revit then you could transfer the data, from releases to reactions, connection forces to deformations at specified points it could all come through.

Throughout all this development we hit a number of stumbling blocks, but the key was this, we had the basic tools to get around the problems. Often all we needed was to apply the tools in a different way or ask the Grasshopper or Dynamo community if someone had a work around or a component that would solve the issue.

So what does this all cost, well on the assumption you have a copy of Revit and or Rhino, then Dynamo and Grasshopper are both free to download. There are numerous websites with tutorials and YouTube videos. So really the only outlay is an investment in time, and an investment into understanding what digital engineering can give you.

So  engineers can dream of a digital world....it's here waiting for you.

Upstairs,Downstairs and Heroes

Happy new year! He says…over a month late. So it’s been a tad busy since the last post, Ricky's back in Oz, Tom’s up to his eyeballs in it (it being projects and knowing him producing some fine homemade xmas chutney) and I've barely had a minute to catch my breath between projects and Autodesk University.I realise we said we’d talk about Red Panda, the link between Revit and Panda Lite…but in the meantime two things have happened. 

1.  I had a bit of brain wave about how to improve the link and...
2.  I became horrifically busy and haven’t had the change to implement said wave of the brain.

So Red Panda will have to wait and instead I thought I’d write an entry about a few things in the past couple of months that had me thinking about the future of digital engineering.

Three months back I sat in a keynote speech from the head of the IstructE and he talked about the digital revolution. He said a few other things which rang a bell with me. He talked about all the things structural engineers need to be able to do and whilst it was the kind of list you would expect, El Presidente said there was something missing from his list…Digital technologies.....our favourite..

He also said we were the generation that had upwards and downwards learning.In the past the seniors taught the juniors in a downward learning process, but the digital revolution has meant the juniors are often teaching the seniors and that also got my bell a’ ringing.  Then I flew out to Autodesk University 2015 and sat in Brian Ringley’s talk on Rhynamo – Case studies. Right at the end  of the talk someone asked him what we should be learning (or something similar to that effect) and his answer was that he truly believed that if you aren't bringing programmers into your team you’ll fall by the wayside. It’ll be of little surprise to read that this also had my bell ringing..like a big ole siren alarm.

Now the point about getting programmers into a team is an important one because there is one caveat, or rephrasing, I’d add to that statement. Many of the programmers that were at AU were also architects, either currently or in previous lives. They learnt to programme and applied that learning to their architectural workflows – square hole, square peg. Apply those same workflows to a structural design process and the results can sometimes look like, well a circular peg sticking out of a square hole. That’s no slight on architectural coders, I wouldn't expect an architect to know that I’d like to further increase my interoperability script by adding the limiting temperature of a steel beam from my analysis package to my production model any more than an architect would expect me to understand…well the raft of brilliant aesthetic and functional derivations that I have seen architectural scripts involve and can but marvel at and learn from.

Add to this that the generations coming through after us are going to know even more than us about programming and I truly believe that as structural engineers we need to understand how to programme at a basic level to make the most of the upstairs downstairs (I think it sounds better than upwards/downwards) teaching process that is only going to get more prevalent as years go past.

As an hombre that’s only ever used visual scripting processes like grasshopper and dynamo I've noticed that there aren’t many coding tutorials out there relevant to structures, so as and when I find good resources I’ll try and share them here (spreading the love as Ian in the team likes to call it). Likewise, if you’re reading this and fancy spreading the love in reverse I’d love to hear about where you learnt to script and where you found good relevant information.
Changing the subject back to the talk that got me thinking in the first place, The Vice president of the IstructE, soon to be president also said a fair few things at the ceremony that rang a bell with me. His question was to name our top ten structural heroes.
Where are the structural heroes? Ask anyone to name a structural engineer….they’ll give you Brunel..who else?! Now I’ll give you a list of people I've worked with/continue to work with who do beyond excellent work that inspires me but I think the VP’s point was that in a room full or structural engineers we probably couldn't pull together two to three engineers who would appear on all our collective lists.  Even the VP’s list only had one name on it that I had on mine! Incidentally that was, Laurent Ney, who I saw talk at IASS 2015 this year and who makes engineering cool to non-engineers. Have a butchers at the roof of the Amsterdam Maritime Museum…Tres Cool, Tres Bon. Don’t care who you are, that is cool.

So what does this have to do with digital engineering? Well, on the flight out to AU I couldn't help but I wonder if our Vice president missed a trick, I wonder if he’s only partially right about Structural Heroes.Sure we should definitely have more engineering heroes, but doesn't that miss the key of the digital revolution? That digital workflows are bringing us closer with architects and mechanical/electrical engineers and geotechnical engineers and lighting engineers and fire engineers and sustainability engineers and so on and so on that our buildings heroes of the future might not be structural engineers…the boundaries between disciplines may become blurred enough that in a few years time the person that inspires me happens to be an artist* who turns structural design into a whole new spaces…Or perhaps it will be the VR guru who took my structural designs and created a virtual world from them to explore which led to even more exciting design?

I think it’s time to wrap it up there as I imagine anyone who has read this far is most likely thinking “you have time to write this…you got time to perfect Red Panda and share it here too…..so get the hell on with it”….but one last thing before departing: Autodesk University 2015: in short – the highlights:

Dynamo was everywhere!

Dynamo to control all your database needs

3D printing is coming in big time!

3D printed but a bit too revealing for me

Contractors on major projects are starting to look at model only submissions

Yep,  that's from a presentation where it's in the contract to provide a model and not 2D shop drawings for approval

Take the most developed Robotic technology around…use it to make a better bar

But can it make a black yukon sucker punch?

Autodesk know how to put on a great party and bring people together of all professions!

I made a friend.

*and Finally Finally....as eluded to earlier, Jason Bruge came in for a talk and was inspiring for many reasons but as a man with a healthy obsession with Pandas was particular excellent, so go watch this : https://www.youtube.com/watch?v=WCce646GqIE

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...