Rotherwas Ribbon

It takes a lot to hold up a bulldozer, but near Hereford works on a new road project are being held up by a serpent. Or at least that is what it might be.

Nobody knew the Rotherwas Ribbon existed until earlier this year, but archaeologists working ahead of the bulldozers on a new road project have found a new archaeological site. The Ribbon seems to be nothing like existing UK sites and because only part of it is exposed, we don't know what future excavations will reveal. It must be an exciting time for archaeologists waiting to see what else might turn up at this site.


View Larger Map

For those involved in developing infrastructure it is more complex. I am excited by this discovery like archaeologists, but events like this always concern me. It is human nature to personalise events and infrastructure projects are no different; people associate infrastructure projects with the people who design them, build them and those who procure them. If a project is seen in a bad light, the people who build it are also often seen in a bad light. Even worse the people who build it can be seen as evil people intent on destruction.

This is not helped because of the negative image that infrastructure projects often have in countries where there is a good existing infrastructure. In these countries the effect of a project can often be small, with the public finding it difficult to engage with it. There is little passion for the project, but in contrast there might be a lot of passion about some of the perceived negative consequences. People fight to protect things that they feel might be damaged by a project; culture, the environment, tranquility, history. And that fight is often vocal, makes good stories for the media and draws in the public.

The negative perception of engineers is important, but it is not what concerns me when problems like the Rotherwas Ribbon occur is not how the public sees it, but how those involved in the project manage it. Often projects are well managed and come out with a good outcome, but things do go wrong. It is these projects that do go wrong which are the most damaging both for for the perception of the industry, and for the legacy that we leave behind. Good decisions have to made to avoid costing the taxpayer, the environment and our cultural heritage both now and in the future.

I wish those working on the project well. I have no doubt that hard decisions are being made by everyone on the project and that there will be a good outcome. I look forward to the day that I can go an visit the Rotherwas Ribbon in an environment that befits such an important piece of archaeology.

Engineering hints and tips

This blog did not seem like the right place to put some real hints and tips for engineering design so I've set up a separate blog to cover these (Engineering hints and tips)

Ancient mysteries and the Litho Lift

I have a deep fascination with the problems faced by ancient people in constructing their monuments. I know I'm not alone in this and it is a lucrative business these days with countless websites, television programmes and books all claiming to have cracked one of the ancient mysteries.

I stumbled upon another solution to the stonehange problem today (Stonehenge building riddle tackled). I love this solution, it is such a compelling machine; one of those solutions that seems obvious only when you've seen it. In some ways I wish I was the first person to have come up with this solution; and yet I know that it can not have been the way Stonehenge was actually built.

I would like to look at the Litho Lift initially from a pure engineering viewpoint. Looking at the scale model of the machine by simply taking moments it is clear that the force in the ropes are greater than the weight of the lintol stone itself. The inventor of the machine does propose a solution to this, by using counterweights to balance the load. To me, this is the start of the process of laying solutions on top of each other. You create a solution to a problem, it seems a nice solution so you decide to run with it. The only problem is that another problem is created. So you add some additional complication to your original solution to solve that second problem. That second solution then creates a third solution and so your original elegant solution ends up being surprisingly complicated.

Often, it is possible to have avoided the complex solution simply by picking different a different solution to begin with. The solution might not be as ingenious as the Litho Lift, but it would have been far easier to implement.

I have tried to put myself in the position of the people trying to build Stonehenge; I have no doubt these people were master craftsmen, with skills and knowedge often far exceeeding our own. I am not so sure that their ability to conceptually generate complex solutions to problems has reached our level of skill. Complexity and the tools used to manage it are features of the modern world , as are the tools and skills we have created to manage it.

I can not see the people building Stonehenge having used the Litho method to lift the lintols. To avoid creating a complex solution from scratch, large parts of the solution must have already been developed before Stonehenge was built. It is difficult to see how any of the individual parts of the machine would have benefited Neolithic man without the other parts. Of course I could be wrong, I am using essentilly the same argument against mans ingiuity that is used against natural selection evoving the eye.

My argument for not using the Litho Lift somehow does not appear to be as strong as my instinctive feeling that the Litho Lift is not the solution that was used. In the end, it is not my rational argument that sways the case. It is simply that I have moved one ton stones by hand as part of a team, and I have built large timber structures. I know how difficult it is creating a large timber structure and how simple it can be to move large loads with levers and brute force. I have no doubt that the people who built Stonehenge would have also gone for the simple solution - all they would have needed was patience and time, something which past generations have always demonstrated.

I am going to take it as my lesson for today. If I am going to try and develop an elegant solution, I must have experience of working with a problem. I must have an understanding of how much effort it actually takes to solve a problem with brute force and patience compared to inginuity and elegance. Sometimes the solution that involves the least work is not the right one.

The background to numerical models

'How important is it to understand how a numerical analysis programme works in order to use it for design?'. I guess if you asked any engineer this question the answer would always be very. But if we asked if those same engineers understand the analysis programmes that they use for design, we might get the answer no more often than I think we would find comfortable. It's an uncomfortable truth about the industry we work in.

When I ask myself the question why this should be the case I personally can't come up with one answer. One obvious reason would be that so many users are self taught when using analysis programmes. The documentation, especially covering the theory, is often poor and as usual the training of the user is also limited if it actually exists at all. Learning the theory behind a program is often very difficult and can be very mathematical..... but that doesn't mean you have to learn this hard maths to understand how a program works.

To prove this I want to consider a numerical analysis programme called UDEC (ref 1.). This is a very powerful tool, typically used for analysing two dimension rock mechanics problems such as rock slopes or tunnels in rock. The image shows a typical analysis of a tunnel in rock showing how the programme can analyse complex joint patterns in the rock around the excavation. So how does it actually work?

Rather than quoting the extensive manual, going into the finite difference method in detail I am going to give a very quick and dirty explanation of how it solves the problem. The solution method used by UDEC is basically to apply Newton's laws of motion to each block, zone or other structure within the model. From this an acceleration can be determined for each element. By considering very small time steps the gradually movement and straining of each part of the model can be calculated. Once the small movements and strains have been calculated for one time step, the resulting small changes in the contact stresses, stresses within blocks and any other forces on the model can be calculated. These forces can then be applied to the elements within the model and the acceleration and displacement can be calculated for the next time step. The model steps through time slowly until a solution is reached i.e. the out of balance forces within the model tend to zero.

That is all there is to it. It doesn't mean if you know this, you are ready to use the programme in anger. There is a lot more theory to learn, but that theory doesn't have to be mathematical. The problem is that it is finding non-mathematical explanations of the theory is difficult. If we can get more explanations of how things work without being too mathematical I can only see this as being a positive.

If you have any explanations for how things work or find any please post them here so that we can all improve our understanding of the tools we use.

Ref 1 - UDEC (Universal Distinct Element Code), HC Itasca

I think it's time for something positive, it's not good to dwell on the negatives too long. One of the greatest gatherings of minds in the world are the TED conferences. An astonishing array of people attend all with there own ideas and stories to tell. Bill Clinton, Al Gore and Bono have all given talks in recent years. 

Standing ovations are not common at this event, so what would it take for a teenager from Africa to get one? Could it be a story of person suffering, fighting against the odds, or making a stand. Not in this case, William Kamkwamba simply had an idea and he had a go. It is something we should all try and do more of. In the words of Nike; 'Just do it'. 

10 years and not much has changed

Last week I realised how little things have changed in the engineering world in the last 10 years. There was a time when the desktop computer was a specialist item. People had to share them, and only used them for special activities. The opposite is true now, an engineer not using a computer is a rarity and even the most mundane activities are now carried out the computer.

This was a massive leap forward, and we are surely still dipping our toe in the water. But what has changed since the desktop computer arrived on my desk? The software is essentially the same. Productivity software has hardly changed over the years. My design spreadsheets have hardly changed over the years, they are essentially the same tools as when I first developed them. The analysis tools that I use are still the same with very few changes having taken place. Even the CAD programmes used by draftsmen appear to have changed little in terms of their fundamental functionality. Changes have been made to these pieces of software, but few of the changes are to the fundamental functionality.

This lack of changes might not be a bad thing: 'if it ain't broke, don't fix it'. And yet I see the same mistakes being made now, as were being made 10 years ago. Errors in the transfer of data between packages, mistakes in the input parameters, incorrect assumptions about the way packages are used and errors in the post-processing of the data are all common. Yet nothing seems to have been done by the software manufacturers to prevent this. Simple tools could have been added with relative ease to reduce the number of these errors.

So why have things not changed? Probably because we don't realise that they do need changing. I suspect that the most contact a software manufacturer has with their clients is when the client is trying to solve a particular problem. If the software can't solve the problem, a quick and dirty solution would be developed in the short term and modifications might be made to a future release so that the software would ultimately be able to solve the problem. This means that each release of software will focus on these specific problems few users actually have, whilst ignoring some of the more fundamental issues that have to be addressed.

We need a paradigm shift in the way our technical and productivity software is produced. Manufacturers need reach out to their users and try and understand how their software is actually used. Equally, the users must start to realise the problems that they actually have. We need to critically assess how we do things and how things can change to make our experience better.

As a last note I thought I'd mention 'Numbers', the new spreadsheet application by Apple (part of iWork 08). This could potentially be a major paradigm shift in the way that spreadsheets are developed. By having multiple tables on one sheet it becomes a much more intuitive interface. It could even lead to modular spreadsheets with a library of tables that can be joined together like a computer programme, each table having already been verified. There would then be no need to check every cell on the spreadsheet, just to check that the tables have been put together correctly. I have yet to try out this application, but I do plan to do so in the near future. I am hopeful that this might be the biggest shift in the way that we use spreadsheets in many years.

It's not often that the world really gets to me, but the world we live in, and the people that design our world are changing... and often it is not for the better. 

To engineer things is a natural human instinct. It is one of the many things that has allowed human culture and society to evolve in the way it has. It is not a realm for the elite, but for everyone. Look at a child's fascination for Lego and building blocks. Building things is a natural instinct we all have, and engineering the things we build is part of that instinct. A building block tower is never built randomly, but blocks are chosen to create the biggest, the most attractive or simply the most interesting structure. All children, whether they know it or not, have a natural instinct and desire for engineering things. 

So what has this to do with the problems of the world? The engineer has always had the skills of a child; the ability to create, to study, to learn by experiment and to design a solution using their natural instincts. These skills we learn as children are probably the most important skills we have as engineers. I've lost track of the number of times that the numbers have said something should work but my instincts have said it wouldn't; and more often than not it was my instincts that were right and the numbers had that had the problem. 

But things are changing, the childlike skills are loosing their value and engineering is becoming all about the numbers. There must be many reasons why this is happening, it is so pervasive and yet damaging to the world that there must be a wide range of pressures that are causing the changes. 

I want this blog to be my fight back against the way that engineers are changing. Numeracy and the ability to enumerate problems are important skills for engineers, but the instinctive skills we learn from our childhood onwards are far more important. I want people who read this blog to be reminded of the skills they learnt as children and how important they are everyday in creating a better world. 

p.s. I choose the name of this blog from the book 'Design for the Real World' by Victor Papanek. In my opinion this should be required reading for all engineers.