It turns out there is one thing that everyone knows about engineers: We Do Maths. I’ve lost count of the amount of times friends have simply deferred any arithmetic to my good-self because “you’re an engineer- you do maths“; dividing bills, working out petrol costs and calculating quantities- my apparent skills have no end. It’s got to the point where my somewhat-taller-half no longer actually does any maths, he just wonders out loud any arithmetic he requires the answer to and then stares meaningfully at me until I answer.

The slightly worrying thing about this whole situation is that I’ve also lost count of the number of times I’ve witnessed an engineer (myself included) struggle with a trivial calculation, joking: “it’s lucky I don’t do maths for a living…”. Of course, the fact is that the sort of maths engineers use on a daily basis has a habit of being a little more abstract and calculator based than your day-to-day restaurant disagreement. It doesn’t hurt, however, to know a few of the following tricks to make ball-parking easier and maintain the slightly dubious reputation engineers have for “doing maths”.

Double and Halve

People are good with the number two; whether it’s because it’s the first times-table most of us learn, or just because doubling and halving quantities comes naturally to us. By appreciating that we can almost instinctively divide and multiply by two you can substantially improve your mental arithmetic speed; it’s called the double-and-halve trick. When multiplying two numbers just halve the smallest and double the largest until you end up closer to a factor you’re familiar with:

Obviously this trick is at its most effective when you have a number that is a power of two. For those times when life gives you lemons, however, you can still achieve similar speeds by separating out the difficult portion:

Form the Square

Squaring numbers is a common thing in engineering; probably because of they way we work with physical quantities such as area. This trick is actually the application of a simple rule, and an equation that everyone learns and immediately forgets. For those of you who don’t know it, there is a rule for squaring any number ending in five: form a number using all but the last digit (i.e. 5), multiply that by itself plus one, and then finish it with 25:

It even works with decimals, just temporarily remove the point by multiplying though tens:

Of course, you’d be lucky if you managed to pull off a calculation where you only had to square something ending in a five. However, you are only ever ±5 away from a number ending in 5, and that’s where our GCSE maths equation makes an appearance:

Using this little gem, we can split our non-conforming number into something ending in five, and a number between -5 and 5 that we should be able to square in our heads. This allows us to use the ‘ending-in-five’ trick even when the number doesn’t:

Or, similarly, where you nearest five is greater than the number you’re trying to square:

Engineers Aren’t Mathematicians

This final trick isn’t really a trick at all, it is just the recognition that engineers aren’t mathematicians; we operate in uncertainties and precisions. Whilst I can’t calculate the square root of 73 in my head, I know that the answer is between 8 and 9, and is closer to 9; at a guess I’d say [Ed. you’ll have to trust me on this one:] 8.6, which (at 73.96) is good enough the majority of Civil Engineering applications.

By keeping an eye on the degree of accuracy you’re simplifying each stage by, you should be able ensure that you can calculate to a good enough aim for the application you need. You can improve your accuracy by acknowledging that, as an engineer, you’re trained to think conservatively and therefore you will want to normalise your conservatisms by taking geometric means between ranges (see Fermi Estimates for a guide).

It should be noted that being ‘close-enough’ when dealing in bistromathics is, alas, never good enough!

The post Maths In The Head appeared first on Being Brunel.

This week I was randomly introduced to the wonderful world of Fermi problems. If, like me, you have no idea what I’m going on about: Enrico Fermi was a physicist who was renowned for making good approximations with no actual data, and a Fermi estimate is a method for making a ball-park guess that might actually be right (for a given value of right). I know what you’re thinking: but that’s just engineering design!

Actually, it gets even eerier. The basis of the method is to divide a problem into several factors that you are better positioned to estimate, and combine them to provide a figure with little or no technical calculation. It’s starting to sound more and more like preliminary design- no? For example:

• There are 8 million people living in London
  
• The Shard took 3 years to build
• The magnitude of people working, given any day, on the Shard must have been in the hundreds… at an estimate I’d say between 50 – 250…
• … in the case of a range, take the geometric mean (the square root of the product)…
• … but because using a calculator is against the spirit of the method, estimate the geometric mean at the lower third: 50 + (250 – 50) / 3 is approximately 120.
• There are 360 days in a simple year, so it took 1080 days for 120 people to build the Shard…
• … or somewhere close to 1100 days for 100 people to build it for easy multiplication: 110’000 people days …
• … which, to the nearest magnitude, is a tenth of a million.
• So if all 8 million people in London stopped being so damn lazy and chipped in to that tenth of a million people days …
• … it would have taken a (1 / [8 / 0.1]) 80th of a day …
• … and as 24 hours fits almost trice into 80; that’s about a third of an hour …
• Which is about 20 minutes; but for the degree of accuracy:
• Let’s say a day.

As an example, this one is a bit more deliberate than it first seems. As a process, I expect most people who have ever done preliminary design recognise the method; even if you don’t give Fermi the credit: Idealise, simplify and state your assumptions. Similarly, the accuracy of the calculation aims for degrees of magnitude; whilst you might not know how many years the Shard took to build, you could guess it is a single figure.

Something I hadn’t been introduced to, before I started looking at the method, was use of a geometric mean to reduce a range to a representative value. I think there is a tendency in engineering to conservatism, which can cause a significant over-estimate. The geometric mean therefore helps us on two levels, at once it removes the temptation to play it safe with the highest value, and, because it tends towards the smaller number, allows us to acknowledge that our lower bound would have been conservatively picked, and the upper bound is most definitely exaggerated.

My final step of moving from 20 minutes to a day is a reflection of this. Because of the way the assumptions are multiplied, working always with conservative estimates compounds the conservatism of the design until your estimate is so far away from likely that you might as well have just guessed at the start. As the use of the method is most helpful prior to any detailed design, however, the end is the best place to apply a safety factor.

An advantage of using a formal Fermi method is that this estimate can provide a basis of sanity for further calculations. When a detailed analysis is undertaken, answers not within the magnitude of the estimate require the identification of the assumptions that led it out of kilter; justifying the sanity of the detailed calculation.

Finally, I’m sure anyone with any site experience might argue that, even if you could handle the logistics, eight million people could not build the Shard in a day, because actions such as curing, lifting, boring, etc. all impose time constraints. This highlights a limitation of the method; it requires linearity, or at least a scalar between the basis upon which the assumptions were made and the answer. Whilst there will be a range that throwing more people at the construction would have got it built faster, somewhere between that and a day new, non-modelled, effects begin to dominate.

Despite all this, an awareness between the similarities of the Fermi method and preliminary design calculations is useful. Appreciating the analogy helps both to formalise the process, prevent our tendency from conservatism snow-balling into a significant over-design, and leaves us with a set of assumptions to hone and evaluate when it comes to the details.

The post Fermi Estimates Preliminary Design appeared first on Being Brunel.

This week I’ve been having some fun prototyping a way of saving the world from having to pull out the Structural/Steel Designer’s Handbook every time they’re faced with something too easy to model, but more complex than WL/8.

Allow me to introduce the wonderful world of ‘SimplySupported‘. This little widget knows how to render beam diagrams and write out the static formulae for a library of known structural solutions. Unlike those collections of bending moment diagrams at the back of your structural handbook, however, SimplySupported also throws in the ability to calculate the reactions, moments and displacements for your own specified parameters.

As with all good prototypes, the main thing I learned whilst writing it was that I should have done it differently. This current (alpha) version has a good few demo structures in it, but not the whole handbook; and if anyone wants to have some fun extending the library- it’s fairly intuitive and almost well documented. Just remember to respect the GPL- if you make changes, you share them!

I can see you’re excited, so why not have some fun:

“Well Tom– you’ve been doing a lot with JavaScript recently; I’m beginning to suspect you’re up to something…” All I can say at the moment is: suspect away- although long time readers (if it turns out I have any) might be able to guess my evil plot. Expect great things to come (if you are a fan a disappointment).

The post Structural Diagrams Online appeared first on Being Brunel.

What does finding someone who shares your birthday, and a 1:100 storm have in common? They both happen more often than you’d expect. In fact, once there are 23 people in a room, you’ve got as much chance of guessing a coin-toss as finding two people born on the same day. That’s probability for you, about as intuitive as a rock in the face- or something like that.

Having enjoyed my wettest cycle of the year (yes, I know we’re only nine days in); I had good cause to reflect on the irony of having experienced so many “1:100” year storms during my lifetime- while ringing out my socks into the cistern. Perhaps the greatest concern is that the more “1:100” year rains I cycle through, the more likely I am to get equally soaked- confused yet?

The “1 in X” year description of an extreme event is an odd one (know as a Return Period). The cynic in me notes that the phrasing seems designed to dismiss the event as impossible to predict, whilst giving the client the impression that it’ll never happen again. In fact, I sincerely hope that Wikipedia’s article on the subject is accurate when it credits Civil Engineering for the terminology.

In an attempt to demonstrate the wonderful world of Return Periods, I’ve made this little widget. The graph shows the probability of a “1 in X” year event happening over a period of years. By moving the slider you can can change the return period and see how it affects your chances.

Despite everything, however, Return Periods should give hope to all those searching singles; despite there only being a 63% chance that you’ll meet that one “once in a lifetime” person, there’s a 1 in 5 chance that you’ve already met them.

Isn’t probability wonderful.

The post Flooding the Return Period appeared first on Being Brunel.

Last week was a busy one- I fractured my elbow, talked about computational design, terminated a 6” model astronaut and undertook some serious cowboy-coding.

Now for the long version: Remember that BSO (it’s been making a regular appearance here); well, I came off it and fractured my elbow, which was why- at the end of an introduction to parametric design at Fosters+Partners from a very forgiving young man- a slightly robust gesture to get my coat on resulted in the severing of an adjacent model astronaut’s legs. Mortifying as it was, I did leave inspired to put together a prototype parametric designer of my own, and the replacement of my social calendar (sorry Mr Gregory) with taking enough pain killers to topple a war elephant left me with the time to actually do it.

The Project Currently Known as Geomatrix

This nifty pet-project is called (until I can come up with a less X-rated sounding name) Geomatrix, and for the next three weeks I’ll be focusing on the individual aspects of the application as I write it (a ‘develop-along’ if you will). This week I’ll be wittering away about Parametric Design, next week we’ll be talking about the Direct Stiffness Method (hur hur hur…) and the week after we’ll be on to Optimisation and Targeting. At the end of which I’ll OpenSource the lot and hope that anyone cares enough to join in.

So at this juncture let me introduce you:

Click Here to Start Geomatrix

After a weekend of prototyping (lit. creating an application from libraries and scripts loosely held together by hope and gaffa tape), this is the beginnings of my contribution to parametric design. “Woah” I hear you cry; “an application that draws triangles very slowly and then falls over itself and dies; truly this Thomas is a Wizard!”. Well, enough of your sarcasm; the magic is in how it draws the triangles.

Parametric/Computational/Generative/ <%= @Adjective %> Design

And that, from what I can see, is the foundation of parametric design. Geomatrix (boy do I regret that name) doesn’t know it is drawing a series of triangles; instead it is following a few simple rules to generate the geometry (in this case, n number of adjacent triangles all L wide and H high). As you drag the sliders and the parameters change, the nature of the geometry changes. In fact, with the current model that represents 378 structures at your finger-tips; albeit thoroughly unimpressive ones.

So why is this interesting, and what’s it got to do with engineering? It’s true that, at present, parametric design is more likely to turn up in a conversation about “hocharchitektur” [coined it] than in the realm of engineering; the ability to develop complex shapes (like a Spirograph on acid) and then rationalise them into something constructable using a set of rules and fluid parameters. From a structural designer’s point of view, however, it represents a way to design and optimise for uncertainty, flexible modularity or even adaptability.

Parameters represents a holistic approach to design; the “let’s try everything and see what works” approach that would probably make some of the more senior engineers I know lay down and cry. But for complex structures there comes a point where judgement alone doesn’t cut it. A good example (from a structural perspective- forget those architects and their fancy first-modal failure shapes) is when you lay a slab across an existing series of pad foundations. At conceptual design you’ll never get the chance to actually go and do the SI you need to find all the damn things, but computationally it’s not very expensive to identify some likely foundation groupings, setup a few rules to generate the probable permutations, and then test each generated ‘site’ for the most adverse effects on the slab. You’ll then end up with a design thickness, optionally varied by probability of suitability.

Implementation and Abstraction

One thing I feel I should mention is that Geomatrix is designed to be an abstract permutative generator and optimiser. In its heart it doesn’t care if it’s generating letters of complaint in iambic pentameter from the twisted thesis of a literary criticism major, or iterating the structural options for building an elevator to the moon (presumably to save the model astronaut I maimed). It just so happens that in this demo the back-end is plugged into a frame analysis library and the front-end attached to a processing.js renderer.

Why is that somewhat random implementation detail important? Because it highlights where I think the real power of parametric design in structural engineering lies. In the world of BIM plugging in Geomatrix to Microstation, LUSAS and a pricing spreadsheet from Excel would result in a web interface where the number of columns supporting a slab could be manipulated in (near-real) time; each column being positioned in accordance with office-layout rules; the drawings kept up-to-date, the reinforcement designed and the build cost reported back.

It’ll be improving all the time, so feel free to check back every now and again. Next Monday we’ll be talking stiffness matrices…

Click Here to Start Geomatrix

The post Parametric Design appeared first on Being Brunel.

Engineers like books. Having your own private desk-library is a given for any consultant; usually stocked with tomes artificially thickened with the detritus of cryptic post-it notes, and folded-in print-outs.

Despite their Times best-seller status Civil Engineering books never seem to make the Tesco lost-leader list, and developing a collection can get expensive. So to help new students and graduates out, here are the top five books I’d expect to find on another engineer’s desk… (no advertising commission though!)

Structural Engineer’s Pocket Book

F. Cobb, Butterworth-Heinemann [Amazon]

Harking back to an older (and better…) time where tables where the principle mechanism of design; this book for big pockets collects together most of the useful facts, figures and generics of structural engineering. What else would you reach for when you wanted to know the structural area of an M20 bolt, the maximum bending moment of a fixed beam and a quick outline of timber design?

Craig’s Soil Mechanics

R.F. Craig, Spon Press [Amazon]

Perhaps a bit controversial, as I know most people who went to Southampton university will prefer Powries, but when it comes to Soil Mechanics it’s hard to do better than Craig’s. In-depth enough to tell you what you need, but accessible enough to flick-through without a Masters in Geotechnics; and forever up-to-date (as it nears it’s first double-figure edition).

Bridge Deck Behaviour

E. Hambly, John Wiley & Sons [Amazon]

Like it or lump it- Grillages are here to stay, and it seems (despite being dead these last 18 years) Hambly still has the last word. Covering all of the major bridge types, and with enough theory to give insight without being drier than a cinnamon challenge- it’s easy to see why Hambly remains the definitive authority for grillage design (even if I think FEA is better!)

Foundation Design and Construction

M.J. Tomlinson, Prentice Hall [Amazon]

While Craig’s provides a reference for anything that’ll get your hi-vis dirty- Tomlinson really shines when it comes to foundation design. His litany of each (and seemingly every) foundation type provides enough information to get on and design the for most common structures.

Concise Eurocodes

Various- although most can be found at the [BSI Shop]

Although guaranteed to tell you just enough to know you’ve got to learn more- the ‘Concise Guides’ appearing for the Eurocodes provide a great base to get something done before you drown in sub-scripted multi-referenced ignorance.

For anyone looking for a single ‘Concise Guide to all the damn Eurocodes,’ the Structural Elements Design Manual by DrayCott and Bullman (Pub. Butterworth-Heinemann) [Amazon] is probably the closest I’ve found to something usable enough to be complete, without being long enough to require lifting assessments.

After writing this I realised that what you’d expect to find on a British engineer’s desk is unlikely to make it round the world- so why not share where you’re from and what books you’d expect to find on another engineer’s desk?

The post 5 Books on Every Engineer’s Desk appeared first on Being Brunel.

What do Daniel Shenton and Civil Engineers have in common? They both believe that the world is flat. In the case of Mr Shenton, it’s because he’s belligerently antiquated; but for engineers it’s because working in two dimensions is easy, and three dimensions is hard (let’s leave alone time and probability for now.)

It’s a lazy way to introduce a subject, but: The New Dictionary of Civil Engineering defines Plane Strain as “strain in two dimensions with zero strain in the third dimension”, and Plane Stress as “stress in two dimensions with zero stress in the third dimension”. As such it’s been nominated for the least helpful explanation in the world [citation needed].

In this second post of Engineering Fundamentals I’m aiming to do a little better.

Plane Stress

Certainly Plane Stressful…

To get plane stress we take a plate and promise not to load the faces. This means that we can stretch and crush the plate to our heart’s content, but we can’t bend it. Considering that we’re now living in a cardboard cut-out of a world, where we can’t get in-front of the plate to push it; this shouldn’t be too much of an issue.

As we gradually increase the thickness of the plate, however, there comes a point where the inside of the plate is constrained by the outside of the plate, and a bevel will start to appear at the edges of the plate- shattering our belief in a world without thickness.

It’s at this point that us flat-earthers have to start acknowledging the third dimension…

Plane Strain

Taking the Plane Strain…

Plane Strain is the chronically obese brother of plane stress. As we keep fattening out once plane-stress plate into a prism, there comes a point where the magnitude of these thru-thickness effects are nothing compared to our push and pull.

It’s at this stage where we can once again start to believe the world is flat.

While plane Stress is sometimes used for plate girders, etc., Civil Engineers tend to use the Plane Strain assumption more- where long structures (like dams or retaining walls) can be simplified down to a single cross-section.

So who to say it’s not turtles all the way down?

The post Fundamentals: Plane Stress and Strain appeared first on Being Brunel.

What do Civil Engineers and Zen Buddhists have in common? They both believe in, and constantly strive for, equilibrium (nothing to do with Christian Bale).

A few weeks ago I had to do a test. Amongst other things it was on the fundamental principles behind classical engineering. Considering I have a degree in the subject, I did pretty badly. My excuse is this: In design we mostly use applied principles. In my eight pages of Eurocode calculations, or my report about the impact of loading on arches, I very rarely have to derive the more advanced theories and practices I’m applying. So intermittently, throughout this year, I thought I’d do a series on the fundamentals- as much for my own sake, than anyone else’s!

If civil engineering was religion (and in a way it is; institutionalised by men in funny hats), the first commandment would be:

The principle is easy: the sum of all the actions acting on a structure should come to zero.

Before Newton invented equilibrium in 1686, the world remained in check because of Aristotle‘s assertion that everything has its natural place. That is: rocks like to be on the ground, and therefore they fall, unless propelled by an external agent. About 1800 years later Gallilio chipped-in; removing the sense of belonging that came from a ‘natural place’ and instead suggesting that things move at a constant speed (which includes ‘at-rest’, unless you’re at the gym) until they are forced to change.

With his best seller: the Philosophiæ Naturalis Principia Mathematica Newton refined these theories with over 200 experiements (which seems overkill to me) and derived the infamous laws of motion. As far as Civil Engineers are concerned this was when it all began; hence the BN/AN (Before-/After- Netwon) calander we use amongst ourselves. The logic goes as such:

• Structures neither move, nor do they accelerate (this is an axiom that the public insists on…)
• Therefore the ‘velocity’ of the structure, and all of the components that make it, is always zero.
• That means that the net force on the structure is zero (Newton’s first law)
• All forces applied to a structure are due to accelerating masses (e.g. cake-mob loading; Newton’s second law)
• At a global level these actions on the structure are resisted by the reactions of its supports (Newton’s third law)

Like all good articles of faith, however, this doesn’t quite stand up to scrutiny; that is- Newton took the assumption that everything is a single point of mass. 50 years later, however, Euler wrote a second testament: “Laws of Motion 2: Motion Harder“, which bridges the gap. In practice, however, the distinction is rarely made by Civil Engineers.

So the next time you pick-up some engineering calculations (as I’m sure you do everyday), look-out for the incantation ΣF = 0. By invoking this statement, engineers call the structure into equilibrium; and once you know that a body is in equilibrium, working out the forces at any point within the structure is as simple as balancing the equation.

The post Engineering Fundamentals: Equilibrium appeared first on Being Brunel.

One of the most popular things about this blog (except the amazing drawings, obviously) is the EngCel add-in I shared a few months ago. As with all the software I write, however, it rarely remains static; over time adding new features as and when my frustrations with Excel spur me on. So this week I thought I’d update you all on some of the newest features, and perhaps cajole you into downloading the latest version.

Download the Latest EngCel

Colourful Formulae

One of the first things I look for in any development environment is syntax highlighting; and although I’ll happily acknowledge that engineering calculations in Excel isn’t exactly programming, however it’s close enough to be improved by some dynamic colouration (or mod_colour, as EngCel knows it).

Colourful Formulae

With the new mod_colour switched on, any new formula will colour depending on its usage:

• Formulas that are neither used by, or use other cells will turn grey (unused value)
• Formulas that are used, but not used by, other cells will turn red (input value)
• Formulas that only reference a single cell, without calculation, will turn orange (refereed value)
• Formulas that rely and are relied upon by other cells will turn blue (function)
• Formulas that use other cells but are not used themselves will turn green (result value)

At a glance you’ll now be able to tell which cells aren’t being used, which are the principle inputs and which are the results of a calculation. To enjoy colourful formulae just use the mod_colour mixin |@colour (there’s a ‘u’, I’m English), which will toggle colouring formulae on and off across the application.

Unfortunately, however, it’s a limitation of Excel that you can’t undo the changes a macro makes to your spreadsheet; which essentially means that by switching on mod_colour you’ll lose your undo function. Personally I don’t find this much of a loss compared to the increased clarity gained, but as a result mod_colour is turned off by default.

New Mixins

As well as the pass/fail ok/check mixins EngCel was originally released with, there are now some new ones:

The new EngCel Mixins

• |@!ok and |@!pass do the reverse of their namesake mixins, which is useful when you’re doing a factor of safety, rather than utilisation, calculation
• |@eng formats the cell as an engineering number; that is to say something which is grouped in exponents of three, e.g. x10³, x10⁶, x10⁹.
• |@help generates a new sheet which provides an introduction to EngCel. as well as a character map showing you the syntax for the in-line symbols

The New Help Tab

At the moment EngCel uses hard-coded mixins; I’m still looking for a way to allow users to safely add their own ones- but at present the limitations of Excel are thwarting my every attempt.

Named Cells

Not too many people know that Excel has the ability to use ‘names’ instead of ‘references’ for cells; e.g. A1 could just as easily be called “first_cell“. For actual tables this doesn’t make too much sense, and therefore the naming method in Excel is a tad cumbersome. For engineering calculations, however, naming cells is a god-send; I don’t know anyone who would prefer to know that D3 = D2*D1, when dead_weight = mass * gravity is readily available.

EngCel now provides an extension to the in-line formatting syntax that allows you to name the cell to the right with the words in the cell to the left; confused? Don’t be. All you need do is write the name of the symbol in the first column, in the adjacent column use EngCel in-line notation to form a lovely looking symbol and follow it with ‘=>’ to name the cell in the next column along. For example, entering the following in Excel:

Results in:

EngCel Named Formula

As this is pretty much the way every engineer I know writes calculations, it’s pretty easy to get used to and can make coming back to, or checking, a spreadsheet a breeze. Just note the Excel has its own conventions with naming, so stick to unique, character (no spaces) only variable names if you want an easy life.

So that’s it on EngCel latest features. I always keep the GitHub page for all of my software up-to-date, so if you want the latest and greatest features keep an eye on: https://github.com/thomasmichaelwallace/EngCel.

Download the Latest EngCel

The post EngCel: Colours, Names and More appeared first on Being Brunel.

Welcome to the third, and thankfully final, part of this series on Track Structure Interaction (TSI for all of you who had the first album). Since the 1950s we’ve been using continuously welded rail in the UK, and with the introduction of the Eurocode we’re finally being made to consider the effect this has on our structures. If you want a reminder take a look back to parts one and two– don’t worry, this post will still be here when you get back.

Loading The Structure

TSI considers only the loading which relies on the interaction between track and structure. Being a two-dimensional, primarily longitudinal, analysis the most prominent of these is traction and breaking. In the UK, at least, the NA breaking load, which inherits from BD 37/01, is always the worst case; however the unrestricted length is arguably unrealistic and there is potential to agree a 300m limit, in keeping with the unadjusted Eurocode loading. You are limited, however, to loading a maximum of two tracks at any one time, and the ballast springs must be updated to reflect this.

You also need to consider vertical loading (LM71 for short spans, SW/0 for long spans), as the bending deflection causes end rotation and shortening. Note that TSI is a global SLS analysis, and therefore doesn’t require partial or dynamic factors. Network Rail do, however, still specify the use of the future (α) factor; however a good case for the reduced (1.1) geotechical value can be argued given the dependence on soil properties.

As well as traffic actions the relative change in temperature between rail and structure leads to a transfer of stress as one restricts the other. The magnitude of this action depends on the fixity of the rail; with different generic ranges given for tracks with and without expansion joints (35^o and 20^o respectively). The effects resulting from thermal actions arguably develop over a long duration, and although not explicitly stated, I believe it would be hard to justify using anything but unloaded ballast stiffnesses for this loadcase.

TSI Loading for Maximum Deformation

The aim of TSI is to check relative movements between structures and the stresses in the rails. As a general guide applying horizontal load to the full length of the structure, and positioning vertical load to effect the largest bending moment will result in the worst case condition; thermal load should always be applied to the complete structure, and loads should not extend into the approach lengths (see the previous article for boundary conditions). Consideration of the distribution effects suggests that, for deflection, a good starting point is to use the lowest foundation stiffness with the highest ballast stiffness; and the reverse is true for rail stress. The complicated analysis, however, means that it is always worth checking all cases.

TSI Loading for Maximum Rail Stress

Doing A TSI Analysis

The non-constant stiffness of the ballast springs used in TSI makes it a second-order analysis. Although the Eurocodes do provide a hand calculation method (based on empirical relationships), the strict qualification requirements mean that most of the bridges suitable for such a check do not actually require the analysis, and in addition it does not consider the additional ballast stiffnesses included by Network Rail. The alternative is to use a finite element model, which the original documentation from the UIC provides some guidance for: notably that the maximum discrete element length should be limited to 2m and that linear superposition is allowable. It should be noted, at this point, that the likes of LUSAS already comes with a TSI module.

TSI Relative Deflection Criteria

The criteria for TSI are two fold. The relative movements of structures due to traffic loading (laterally, vertically and rotationally) must be within the tight limits imposed by the Eurocodes, and the stresses in the rails due to traffic and thermal loading cannot exceed the tensile and compressive restrictions provided, once again, by the Eurocodes. There are, however, a few missing criteria. The limits noted in the Eurocodes are only correct for UIC 60 Rail on straight (radius less than 1500km), ballasted, track on heavy concrete sleepers spaced at 650mm intervals. There is some guidance on concrete fixings in the original research; but curvature has yet to be commented on.

At A Glance

You should never undertake an analysis without a good idea of what the answer should be. To this effect the ‘restraint coefficients’ provided in the Eurocode hand calculation method provide a simplified suggestion: apply a proportion of the total breaking load to the fixed pier, as shown in the above table. From the lateral load and moment, and an estimated ground spring, you can get a ballpark figure for the movement expected in the TSI analysis. The following rules of thumb can also give you a feel for the answer before you start:

• Expansion joints are required for steel bridges longer than 60m
• Concrete bridges longer than 90m will need expansion joints
• These spans can be doubled for centrally fixed bridges
• Medium span consecutive bridges with shorter start/end spans perform well
• Movement of tall bridges will be dominated by the pile design
• Movement in short bridges will be dominated by surface ground properties

If the bridge fails there is not a lot that can be done, structurally, to resolve the issue (remember the first thing I said in this series was: do the TSI first). Typically the uncertainty surrounding geotechnical properties means that more detailed GI may reduce conservatism in values, thus reducing movement. Similarly changes to articulation and span (note the rules of thumb above) can help rescue a failing structure. It is often conservative to apply to rules of linear superposition to a TSI analysis and, for close-cases, it may be worth building a stress history/combined loadcase approach into the model.

And so ends my series on Track/Structure Interaction; it’s been fun, and I’ve learnt a lot putting it all together. Let’s hope next time I have to do some heavy research it’s into something more interesting!

Note that the bare facts of these articles are quoted from Network Rail (typically NR/L3/CIV/020) and research by the UIC (774-3R). The rest is interpretation and notes from a graduate’s experience. As always, your attention is drawn to the disclaimer at the bottom of every page.

The post Even More Track Structure Interaction appeared first on Being Brunel.