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

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. 

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